pc端网站模型建设工具,怎么做兼职类网站吗,wordpress标签转换,wordpress图片后加载很慢1.1 Redis可以用来做什么#xff1f;
参考答案
Redis最常用来做缓存#xff0c;是实现分布式缓存的首先中间件#xff1b;Redis可以作为数据库#xff0c;实现诸如点赞、关注、排行等对性能要求极高的互联网需求#xff1b;Redis可以作为计算工具#xff0c;能用很小的…1.1 Redis可以用来做什么
参考答案
Redis最常用来做缓存是实现分布式缓存的首先中间件Redis可以作为数据库实现诸如点赞、关注、排行等对性能要求极高的互联网需求Redis可以作为计算工具能用很小的代价统计诸如PV/UV、用户在线天数等数据Redis还有很多其他的使用场景例如可以实现分布式锁可以作为消息队列使用。
1.2 Redis和传统的关系型数据库有什么不同
参考答案
Redis是一种基于键值对的NoSQL数据库而键值对的值是由多种数据结构和算法组成的。Redis的数据都存储于内存中因此它的速度惊人读写性能可达10万/秒远超关系型数据库。
关系型数据库是基于二维数据表来存储数据的它的数据格式更为严谨并支持关系查询。关系型数据库的数据存储于磁盘上可以存放海量的数据但性能远不如Redis。
1.3 Redis有哪些数据类型
参考答案
Redis支持5种核心的数据类型分别是字符串、哈希、列表、集合、有序集合Redis还提供了Bitmap、HyperLogLog、Geo类型但这些类型都是基于上述核心数据类型实现的Redis在5.0新增加了Streams数据类型它是一个功能强大的、支持多播的、可持久化的消息队列。
1.4 Redis是单线程的为什么还能这么快
参考答案
对服务端程序来说线程切换和锁通常是性能杀手而单线程避免了线程切换和竞争所产生的消耗Redis的大部分操作是在内存上完成的这是它实现高性能的一个重要原因Redis采用了IO多路复用机制使其在网络IO操作中能并发处理大量的客户端请求实现高吞吐率。
关于Redis的单线程架构实现如下图 1.5 Redis在持久化时fork出一个子进程这时已经有两个进程了怎么能说是单线程呢
参考答案
Redis是单线程的主要是指Redis的网络IO和键值对读写是由一个线程来完成的。而Redis的其他功能如持久化、异步删除、集群数据同步等则是依赖其他线程来执行的。所以说Redis是单线程的只是一种习惯的说法事实上它的底层不是单线程的。
1.6 set和zset有什么区别
参考答案
set
集合中的元素是无序、不可重复的一个集合最多能存储232-1个元素集合除了支持对元素的增删改查之外还支持对多个集合取交集、并集、差集。
zset
有序集合保留了集合元素不能重复的特点有序集合会给每个元素设置一个分数并以此作为排序的依据有序集合不能包含相同的元素但是不同元素的分数可以相同。
1.7 说一下Redis中的watch命令
参考答案
很多时候要确保事务中的数据没有被其他客户端修改才执行该事务。Redis提供了watch命令来解决这类问题这是一种乐观锁的机制。客户端通过watch命令要求服务器对一个或多个key进行监视如果在客户端执行事务之前这些key发生了变化则服务器将拒绝执行客户端提交的事务并向它返回一个空值。
1.8 说说Redis中List结构的相关操作
参考答案
列表是线性有序的数据结构它内部的元素是可以重复的并且一个列表最多能存储2^32-1个元素。列表包含如下的常用命令
lpush/rpush从列表的左侧/右侧添加数据lrange指定索引范围并返回这个范围内的数据lindex返回指定索引处的数据lpop/rpop从列表的左侧/右侧弹出一个数据blpop/brpop从列表的左侧/右侧弹出一个数据若列表为空则进入阻塞状态。
1.9 你要如何设计Redis的过期时间
参考答案
热点数据不设置过期时间使其达到“物理”上的永不过期可以避免缓存击穿问题在设置过期时间时可以附加一个随机数避免大量的key同时过期导致缓存雪崩。
1.10 Redis中sexnx命令的返回值是什么如何使用该命令实现分布式锁
参考答案
setnx命令返回整数值当返回1时表示设置值成功当返回0时表示设置值失败key已存在。
一般我们不建议直接使用setnx命令来实现分布式锁因为为了避免出现死锁我们要给锁设置一个自动过期时间。而setnx命令和设置过期时间的命令不是原子的可能加锁成果而设置过期时间失败依然存在死锁的隐患。对于这种情况Redis改进了set命令给它增加了nx选项启用该选项时set命令的效果就会setnx一样了。
采用Redis实现分布式锁就是在Redis里存一份代表锁的数据通常用字符串即可。采用改进后的setnx命令即set…nx…命令实现分布式锁的思路以及优化的过程如下
加锁
第一版这种方式的缺点是容易产生死锁因为客户端有可能忘记解锁或者解锁失败。
setnx key value
第二版给锁增加了过期时间避免出现死锁。但这两个命令不是原子的第二步可能会失败依然无法避免死锁问题。
setnx key value expire key seconds
第三版通过“set…nx…”命令将加锁、过期命令编排到一起它们是原子操作了可以避免死锁。
set key value nx ex seconds
解锁
解锁就是删除代表锁的那份数据。
del key
问题
看起来已经很完美了但实际上还有隐患如下图。进程A在任务没有执行完毕时锁已经到期被释放了。等进程A的任务执行结束后它依然会尝试释放锁因为它的代码逻辑就是任务结束后释放锁。但是它的锁早已自动释放过了它此时释放的可能是其他线程的锁。 想要解决这个问题我们需要解决两件事情
在加锁时就要给锁设置一个标识进程要记住这个标识。当进程解锁的时候要进行判断是自己持有的锁才能释放否则不能释放。可以为key赋一个随机值来充当进程的标识。解锁时要先判断、再释放这两步需要保证原子性否则第二步失败的话就会出现死锁。而获取和删除命令不是原子的这就需要采用Lua脚本通过Lua脚本将两个命令编排在一起而整个Lua脚本的执行是原子的。
按照以上思路优化后的命令如下
加锁 set key random-value nx ex seconds # 解锁 if redis.call(“get”,KEYS[1]) ARGV[1] then return redis.call(“del”,KEYS[1]) else return 0 end
1.11 说一说Redis的持久化策略
参考答案
Redis支持RDB持久化、AOF持久化、RDB-AOF混合持久化这三种持久化方式。
RDB
RDB(Redis Database)是Redis默认采用的持久化方式它以快照的形式将进程数据持久化到硬盘中。RDB会创建一个经过压缩的二进制文件文件以“.rdb”结尾内部存储了各个数据库的键值对数据等信息。RDB持久化的触发方式有两种
手动触发通过SAVE或BGSAVE命令触发RDB持久化操作创建“.rdb”文件自动触发通过配置选项让服务器在满足指定条件时自动执行BGSAVE命令。
其中SAVE命令执行期间Redis服务器将阻塞直到“.rdb”文件创建完毕为止。而BGSAVE命令是异步版本的SAVE命令它会使用Redis服务器进程的子进程创建“.rdb”文件。BGSAVE命令在创建子进程时会存在短暂的阻塞之后服务器便可以继续处理其他客户端的请求。总之BGSAVE命令是针对SAVE阻塞问题做的优化Redis内部所有涉及RDB的操作都采用BGSAVE的方式而SAVE命令已经废弃
BGSAVE命令的执行流程如下图 BGSAVE命令的原理如下图 RDB持久化的优缺点如下
优点RDB生成紧凑压缩的二进制文件体积小使用该文件恢复数据的速度非常快缺点BGSAVE每次运行都要执行fork操作创建子进程属于重量级操作不宜频繁执行所以RDB持久化没办法做到实时的持久化。
AOF
AOFAppend Only File解决了数据持久化的实时性是目前Redis持久化的主流方式。AOF以独立日志的方式记录了每次写入命令重启时再重新执行AOF文件中的命令来恢复数据。AOF的工作流程包括命令写入append、文件同步sync、文件重写rewrite、重启加载load如下图 AOF默认不开启需要修改配置项来启用它
appendonly yes # 启用AOF appendfilename “appendonly.aof” # 设置文件名
AOF以文本协议格式写入命令如
*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n
文本协议格式具有如下的优点
文本协议具有很好的兼容性直接采用文本协议格式可以避免二次处理的开销文本协议具有可读性方便直接修改和处理。
AOF持久化的文件同步机制
为了提高程序的写入性能现代操作系统会把针对硬盘的多次写操作优化为一次写操作。
当程序调用write对文件写入时系统不会直接把书记写入硬盘而是先将数据写入内存的缓冲区中当达到特定的时间周期或缓冲区写满时系统才会执行flush操作将缓冲区中的数据冲洗至硬盘中
这种优化机制虽然提高了性能但也给程序的写入操作带来了不确定性。
对于AOF这样的持久化功能来说冲洗机制将直接影响AOF持久化的安全性为了消除上述机制的不确定性Redis向用户提供了appendfsync选项来控制系统冲洗AOF的频率Linux的glibc提供了fsync函数可以将指定文件强制从缓冲区刷到硬盘上述选项正是基于此函数。
appendfsync选项的取值和含义如下 AOF持久化的优缺点如下
优点与RDB持久化可能丢失大量的数据相比AOF持久化的安全性要高很多。通过使用everysec选项用户可以将数据丢失的时间窗口限制在1秒之内。缺点AOF文件存储的是协议文本它的体积要比二进制格式的”.rdb”文件大很多。AOF需要通过执行AOF文件中的命令来恢复数据库其恢复速度比RDB慢很多。AOF在进行重写时也需要创建子进程在数据库体积较大时将占用大量资源会导致服务器的短暂阻塞。
RDB-AOF混合持久化
Redis从4.0开始引入RDB-AOF混合持久化模式这种模式是基于AOF持久化构建而来的。用户可以通过配置文件中的“aof-use-rdb-preamble yes”配置项开启AOF混合持久化。Redis服务器在执行AOF重写操作时会按照如下原则处理数据
像执行BGSAVE命令一样根据数据库当前的状态生成相应的RDB数据并将其写入AOF文件中对于重写之后执行的Redis命令则以协议文本的方式追加到AOF文件的末尾即RDB数据之后。
通过使用RDB-AOF混合持久化用户可以同时获得RDB持久化和AOF持久化的优点服务器既可以通过AOF文件包含的RDB数据来实现快速的数据恢复操作又可以通过AOF文件包含的AOF数据来将丢失数据的时间窗口限制在1s之内。
1.12 如何实现Redis的高可用
参考答案
实现Redis的高可用主要有哨兵和集群两种方式。
哨兵
Redis Sentinel哨兵是一个分布式架构它包含若干个哨兵节点和数据节点。每个哨兵节点会对数据节点和其余的哨兵节点进行监控当发现节点不可达时会对节点做下线标识。如果被标识的是主节点它就会与其他的哨兵节点进行协商当多数哨兵节点都认为主节点不可达时它们便会选举出一个哨兵节点来完成自动故障转移的工作同时还会将这个变化实时地通知给应用方。整个过程是自动的不需要人工介入有效地解决了Redis的高可用问题
一组哨兵可以监控一个主节点也可以同时监控多个主节点两种情况的拓扑结构如下图 哨兵节点包含如下的特征
哨兵节点会定期监控数据节点其他哨兵节点是否可达哨兵节点会将故障转移的结果通知给应用方哨兵节点可以将从节点晋升为主节点并维护后续正确的主从关系哨兵模式下客户端连接的是哨兵节点集合从中获取主节点信息节点的故障判断是由多个哨兵节点共同完成的可有效地防止误判哨兵节点集合是由多个哨兵节点组成的即使个别哨兵节点不可用整个集合依然是健壮的哨兵节点也是独立的Redis节点是特殊的Redis节点它们不存储数据只支持部分命令。
集群
Redis集群采用虚拟槽分区来实现数据分片它把所有的键根据哈希函数映射到0-16383整数槽内计算公式为slotCRC16(key)16383每一个节点负责维护一部分槽以及槽所映射的键值数据。虚拟槽分区具有如下特点
解耦数据和节点之间的关系简化了节点扩容和收缩的难度节点自身维护槽的映射关系不需要客户端或者代理服务维护槽分区元数据支持节点、槽、键之间的映射查询用于数据路由在线伸缩等场景。
Redis集群中数据的分片逻辑如下图 1.13 Redis的主从同步是如何实现的
参考答案
从2.8版本开始Redis使用psync命令完成主从数据同步同步过程分为全量复制和部分复制。全量复制一般用于初次复制的场景部分复制则用于处理因网络中断等原因造成数据丢失的场景。psync命令需要以下参数的支持
复制偏移量主节点处理写命令后会把命令长度做累加记录从节点在接收到写命令后也会做累加记录从节点会每秒钟上报一次自身的复制偏移量给主节点而主节点则会保存从节点的复制偏移量。积压缓冲区保存在主节点上的一个固定长度的队列默认大小为1M当主节点有连接的从节点时被创建主节点处理写命令时不但会把命令发送给从节点还会写入积压缓冲区缓冲区是先进先出的队列可以保存最近已复制的数据用于部分复制和命令丢失的数据补救。主节点运行ID每个Redis节点启动后都会动态分配一个40位的十六进制字符串作为运行ID如果使用IP和端口的方式标识主节点那么主节点重启变更了数据集RDB/AOF从节点再基于复制偏移量复制数据将是不安全的因此当主节点的运行ID变化后从节点将做全量复制。
psync命令的执行过程以及返回结果如下图 全量复制的过程如下图 部分复制的过程如下图 1.14 Redis为什么存的快内存断电数据怎么恢复
参考答案
Redis存的快是因为它的数据都存放在内存里并且为了保证数据的安全性Redis还提供了三种数据的持久化机制即RDB持久化、AOF持久化、RDB-AOF混合持久化。若服务器断电那么我们可以利用持久化文件对数据进行恢复。理论上来说AOF/RDB-AOF持久化可以将丢失数据的窗口控制在1S之内。
1.15 说一说Redis的缓存淘汰策略
参考答案
当写入数据将导致超出maxmemory限制时Redis会采用maxmemory-policy所指定的策略进行数据淘汰该策略一共包含如下8种选项
策略描述版本noeviction直接返回错误volatile-ttl从设置了过期时间的键中选择过期时间最小的键进行淘汰volatile-random从设置了过期时间的键中随机选择键进行淘汰volatile-lru从设置了过期时间的键中使用LRU算法选择键进行淘汰volatile-lfu从设置了过期时间的键中使用LFU算法选择键进行淘汰4.0allleys-random从所有的键中随机选择键进行淘汰allkeys-lru从所有的键中使用LRU算法选择键进行淘汰allkeys-lfu从所有的键中使用LFU算法选择键进行淘汰4.0
其中volatile前缀代表从设置了过期时间的键中淘汰数据allkeys前缀代表从所有的键中淘汰数据。关于后缀ttl代表选择过期时间最小的键random代表随机选择键需要我们额外关注的是lru和lfu后缀它们分别代表采用lru算法和lfu算法来淘汰数据。
LRULeast Recently Used是按照最近最少使用原则来筛选数据即最不常用的数据会被筛选出来
标准LRU把所有的数据组成一个链表表头和表尾分别表示MRU和LRU端即最常使用端和最少使用端。刚被访问的数据会被移动到MRU端而新增的数据也是刚被访问的数据也会被移动到MRU端。当链表的空间被占满时它会删除LRU端的数据。近似LRURedis会记录每个数据的最近一次访问的时间戳LRU。Redis执行写入操作时若发现内存超出maxmemory就会执行一次近似LRU淘汰算法。近似LRU会随机采样N个key然后淘汰掉最旧的key若淘汰后内存依然超出限制则继续采样淘汰。可以通过maxmemory_samples配置项设置近似LRU每次采样的数据个数该配置项的默认值为5。
LRU算法的不足之处在于若一个key很少被访问只是刚刚偶尔被访问了一次则它就被认为是热点数据短时间内不会被淘汰。
LFU算法正式用于解决上述问题LFULeast Frequently Used是Redis4新增的淘汰策略它根据key的最近访问频率进行淘汰。LFU在LRU的基础上为每个数据增加了一个计数器来统计这个数据的访问次数。当使用LFU策略淘汰数据时首先会根据数据的访问次数进行筛选把访问次数最低的数据淘汰出内存。如果两个数据的访问次数相同LFU再比较这两个数据的访问时间把访问时间更早的数据淘汰出内存。
1.16 请介绍一下Redis的过期策略
参考答案
Redis支持如下两种过期策略
惰性删除客户端访问一个key的时候Redis会先检查它的过期时间如果发现过期就立刻删除这个key。
定期删除Redis会将设置了过期时间的key放到一个独立的字典中并对该字典进行每秒10次的过期扫描
过期扫描不会遍历字典中所有的key而是采用了一种简单的贪心策略。该策略的删除逻辑如下
从过期字典中随机选择20个key删除这20个key中已过期的key如果已过期key的比例超过25%则重复步骤1。
1.17 缓存穿透、缓存击穿、缓存雪崩有什么区别该如何解决
参考答案
缓存穿透
问题描述
客户端查询根本不存在的数据使得请求直达存储层导致其负载过大甚至宕机。出现这种情况的原因可能是业务层误将缓存和库中的数据删除了也可能是有人恶意攻击专门访问库中不存在的数据。
解决方案
缓存空对象存储层未命中后仍然将空值存入缓存层客户端再次访问数据时缓存层会直接返回空值。布隆过滤器将数据存入布隆过滤器访问缓存之前以过滤器拦截若请求的数据不存在则直接返回空值。
缓存击穿
问题描述
一份热点数据它的访问量非常大。在其缓存失效的瞬间大量请求直达存储层导致服务崩溃。
解决方案
永不过期热点数据不设置过期时间所以不会出现上述问题这是“物理”上的永不过期。或者为每个数据设置逻辑过期时间当发现该数据逻辑过期时使用单独的线程重建缓存。加互斥锁对数据的访问加互斥锁当一个线程访问该数据时其他线程只能等待。这个线程访问过后缓存中的数据将被重建届时其他线程就可以直接从缓存中取值。
缓存雪崩
问题描述
在某一时刻缓存层无法继续提供服务导致所有的请求直达存储层造成数据库宕机。可能是缓存中有大量数据同时过期也可能是Redis节点发生故障导致大量请求无法得到处理。
解决方案
避免数据同时过期设置过期时间时附加一个随机数避免大量的key同时过期。启用降级和熔断措施在发生雪崩时若应用访问的不是核心数据则直接返回预定义信息/空值/错误信息。或者在发生雪崩时对于访问缓存接口的请求客户端并不会把请求发给Redis而是直接返回。构建高可用的Redis服务采用哨兵或集群模式部署多个Redis实例个别节点宕机依然可以保持服务的整体可用。
1.18 如何保证缓存与数据库的双写一致性
参考答案
四种同步策略
想要保证缓存与数据库的双写一致一共有4种方式即4种同步策略
先更新缓存再更新数据库先更新数据库再更新缓存先删除缓存再更新数据库先更新数据库再删除缓存。
从这4种同步策略中我们需要作出比较的是
更新缓存与删除缓存哪种方式更合适应该先操作数据库还是先操作缓存
更新缓存还是删除缓存
下面我们来分析一下应该采用更新缓存还是删除缓存的方式。
更新缓存优点每次数据变化都及时更新缓存所以查询时不容易出现未命中的情况。缺点更新缓存的消耗比较大。如果数据需要经过复杂的计算再写入缓存那么频繁的更新缓存就会影响服务器的性能。如果是写入数据频繁的业务场景那么可能频繁的更新缓存时却没有业务读取该数据。删除缓存优点操作简单无论更新操作是否复杂都是将缓存中的数据直接删除。缺点删除缓存后下一次查询缓存会出现未命中这时需要重新读取一次数据库。
从上面的比较来看一般情况下删除缓存是更优的方案。
先操作数据库还是缓存
下面我们再来分析一下应该先操作数据库还是先操作缓存。
首先我们将先删除缓存与先更新数据库在出现失败时进行一个对比 如上图是先删除缓存再更新数据库在出现失败时可能出现的问题
进程A删除缓存成功进程A更新数据库失败进程B从缓存中读取数据由于缓存被删进程B无法从缓存中得到数据进而从数据库读取数据进程B从数据库成功获取数据然后将数据更新到了缓存。
最终缓存和数据库的数据是一致的但仍然是旧的数据。而我们的期望是二者数据一致并且是新的数据。 如上图是先更新数据库再删除缓存在出现失败时可能出现的问题
进程A更新数据库成功进程A删除缓存失败进程B读取缓存成功由于缓存删除失败所以进程B读取到的是旧的数据。
最终缓存和数据库的数据是不一致的。
经过上面的比较我们发现在出现失败的时候是无法明确分辨出先删缓存和先更新数据库哪个方式更好以为它们都存在问题。后面我们会进一步对这两种方式进行比较但是在这里我们先探讨一下上述场景出现的问题应该如何解决呢
实际上无论上面我们采用哪种方式去同步缓存与数据库在第二步出现失败的时候都建议采用重试机制解决因为最终我们是要解决掉这个错误的。而为了避免重试机制影响主要业务的执行一般建议重试机制采用异步的方式执行如下图 这里我们按照先更新数据库再删除缓存的方式来说明重试机制的主要步骤
更新数据库成功删除缓存失败将此数据加入消息队列业务代码消费这条消息业务代码根据这条消息的内容发起重试机制即从缓存中删除这条记录。
好了下面我们再将先删缓存与先更新数据库在没有出现失败时进行对比 如上图是先删除缓存再更新数据库在没有出现失败时可能出现的问题
进程A删除缓存成功进程B读取缓存失败进程B读取数据库成功得到旧的数据进程B将旧的数据成功地更新到了缓存进程A将新的数据成功地更新到数据库。
可见进程A的两步操作均成功但由于存在并发在这两步之间进程B访问了缓存。最终结果是缓存中存储了旧的数据而数据库中存储了新的数据二者数据不一致。 如上图是先更新数据库再删除缓存再没有出现失败时可能出现的问题
进程A更新数据库成功进程B读取缓存成功进程A更新数据库成功。
可见最终缓存与数据库的数据是一致的并且都是最新的数据。但进程B在这个过程里读到了旧的数据可能还有其他进程也像进程B一样在这两步之间读到了缓存中旧的数据但因为这两步的执行速度会比较快所以影响不大。对于这两步之后其他进程再读取缓存数据的时候就不会出现类似于进程B的问题了。
最终结论
经过对比你会发现先更新数据库、再删除缓存是影响更小的方案。如果第二步出现失败的情况则可以采用重试机制解决问题。
扩展阅读
延时双删
上面我们提到如果是先删缓存、再更新数据库在没有出现失败时可能会导致数据的不一致。如果在实际的应用中出于某些考虑我们需要选择这种方式那有办法解决这个问题吗答案是有的那就是采用延时双删的策略延时双删的基本思路如下
删除缓存更新数据库sleep N毫秒再次删除缓存。
阻塞一段时间之后再次删除缓存就可以把这个过程中缓存中不一致的数据删除掉。而具体的时间要评估你这项业务的大致时间按照这个时间来设定即可。
采用读写分离的架构怎么办
如果数据库采用的是读写分离的架构那么又会出现新的问题如下图 进程A先删除缓存再更新主数据库然后主库将数据同步到从库。而在主从数据库同步之前可能会有进程B访问了缓存发现数据不存在进而它去访问从库获取到旧的数据然后同步到缓存。这样最终也会导致缓存与数据库的数据不一致。这个问题的解决方案依然是采用延时双删的策略但是在评估延长时间的时候要考虑到主从数据库同步的时间。
第二次删除失败了怎么办
如果第二次删除依然失败则可以增加重试的次数但是这个次数要有限制当超出一定的次数时要采取报错、记日志、发邮件提醒等措施。
1.19 请介绍Redis集群的实现方案
参考答案
Redis集群的分区方案
Redis集群采用虚拟槽分区来实现数据分片它把所有的键根据哈希函数映射到0-16383整数槽内计算公式为slotCRC16(key)16383每一个节点负责维护一部分槽以及槽所映射的键值数据。虚拟槽分区具有如下特点
解耦数据和节点之间的关系简化了节点扩容和收缩的难度节点自身维护槽的映射关系不需要客户端或者代理服务维护槽分区元数据支持节点、槽、键之间的映射查询用于数据路由在线伸缩等场景。
Redis集群中数据的分片逻辑如下图 Redis集群的功能限制
Redis集群方案在扩展了Redis处理能力的同时也带来了一些使用上的限制
key批量操作支持有限。如mset、mget目前只支持具有相同slot值的key执行批量操作。对于映射为不同slot值的key由于执行mset、mget等操作可能存在于多个节点上所以不被支持。key事务操作支持有限。同理只支持多key在同一节点上的事务操作当多个key分布在不同的节点上时无法使用事务功能。key作为数据分区的最小粒度因此不能将一个大的键值对象如hash、list等映射到不同的节点。不支持多数据库空间。单机下的Redis可以支持16个数据库集群模式下只能使用一个数据库空间即DB0。复制结构只支持一层从节点只能复制主节点不支持嵌套树状复制结构。
Redis集群的通信方案
在分布式存储中需要提供维护节点元数据信息的机制所谓元数据是指节点负责哪些数据是否出现故障等状态信息。常见的元数据维护方式分为集中式和P2P方式。
Redis集群采用P2P的Gossip流言协议Gossip协议的工作原理就是节点彼此不断通信交换信息一段时间后所有的节点都会知道集群完整的信息这种方式类似流言传播。通信的大致过程如下
集群中每个节点都会单独开辟一个TCP通道用于节点之间彼此通信通信端口号在基础端口号上加10000每个节点再固定周期内通过特定规则选择几个节点发送ping消息接收ping消息的节点用pong消息作为响应。
其中Gossip协议的主要职责就是信息交换而信息交换的载体就是节点彼此发送的Gossip消息Gossip消息分为meet消息、ping消息、pong消息、fail消息等。
meet消息用于通知新节点加入消息发送者通知接受者加入到当前集群。meet消息通信正常完成后接收节点会加入到集群中并进行周期性的ping、pong消息交换。ping消息集群内交换最频繁的消息集群内每个节点每秒向多个其他节点发送ping消息用于检测节点是否在线和交换彼此状态信息。ping消息封装了自身节点和一部分其他节点的状态数据。pong消息当接收到meet、ping消息时作为响应消息回复给发送方确认消息正常通信。pong消息内封装了自身状态数据节点也可以向集群内广播自身的pong消息来通知整个集群对自身状态进行更新。fail消息当节点判定集群内另一个节点下线时会向集群内广播一个fail消息其他节点接收到fail消息之后把对应节点更新为下线状态。
虽然Gossip协议的信息交换机制具有天然的分布式特性但它是有成本的。因为Redis集群内部需要频繁地进行节点信息交换而ping/pong消息会携带当前节点和部分其他节点的状态数据势必会加重带宽和计算的负担。所以Redis集群的Gossip协议需要兼顾信息交换的实时性和成本的开销。
集群里的每个节点默认每隔一秒钟就会从已知节点列表中随机选出五个节点然后对这五个节点中最长时间没有发送过PING消息的节点发送PING消息以此来检测被选中的节点是否在线。如果节点A最后一次收到节点B发送的PONG消息的时间距离当前时间已经超过了节点A的超时选项设置时长的一半cluster-node-timeout/2那么节点A也会向节点B发送PING消息这可以防止节点A因为长时间没有随机选中节点B作为PING消息的发送对象而导致对节点B的信息更新滞后。每个消息主要的数据占用slots槽数组2KB和整个集群1/10的状态数据10个节点状态数据约1KB。
1.20 说一说Redis集群的分片机制
参考答案
Redis集群采用虚拟槽分区来实现数据分片它把所有的键根据哈希函数映射到0-16383整数槽内计算公式为slotCRC16(key)16383每一个节点负责维护一部分槽以及槽所映射的键值数据。虚拟槽分区具有如下特点
解耦数据和节点之间的关系简化了节点扩容和收缩的难度节点自身维护槽的映射关系不需要客户端或者代理服务维护槽分区元数据支持节点、槽、键之间的映射查询用于数据路由在线伸缩等场景。
Redis集群中数据的分片逻辑如下图
