建设银行官方网站电子银行登录,石家庄seo推广公司,贵州省公路建设有限公司网站,东莞公司网站制作要多少钱概述
Redis 2.8版本发布稳定版Redis Sentinel#xff0c;不过Sentinel集群版存在一些问题#xff1a;
高可用性#xff1a;Sentinel集群对Redis既有的主从集群提供有限的高可用保障#xff1b;在线扩容#xff1a;节点下线#xff0c;触发选举#xff0c;选举涉及两个…概述
Redis 2.8版本发布稳定版Redis Sentinel不过Sentinel集群版存在一些问题
高可用性Sentinel集群对Redis既有的主从集群提供有限的高可用保障在线扩容节点下线触发选举选举涉及两个阶段新增节点数据迁移过程麻烦。
对比Redis Sentinel
Redis Sentinel即Redis 哨兵集群区别如下
集群架构 Redis Sentinel是一主多从 Redis Cluster是多主多从数据一致性 Redis Sentinel由于没有分片Sentinel对数据一致性的保障会更好一些结构相对简单脑裂问题会相对少一些主从之间的数据一致性问题相对简单。主从切换后存在数据一致性的小概率问题例如主节点故障前的未同步数据丢失但整体上保持一致性较好Redis Cluster由于数据分片Redis Cluster在发生主从切换和网络分区时可能存在数据不一致的风险。 扩展性 Redis Sentinel扩展性差受限于单机性能和存储能力。尽管可以通过添加从节点分担读请求但所有写操作仍然只能在主节点进行Redis Cluster扩展性好可通过加节点来扩展存储容量和处理能力。每个节点只负责一部分数据可实现负载均衡。 适用场景 Redis Sentinel适用于中小型应用数据量和请求量相对较小的场景或者不需要水平扩展的情况Redis Cluster适用于大规模应用需要处理大数据量和高并发的场景且需要水平扩展能力。 运维 Redis Sentinel运维复杂度较低适合中小规模的Redis部署。需要维护Sentinel实例并且在节点增加或减少时配置相对简单Redis Cluster运维复杂度较高适合大规模的Redis集群。节点的增删、分片的重新分配、集群状态的维护等都需要较高的运维能力。
简介
从Redis3.0开始提供Redis Cluster集群支持用于在多个Redis节点间共享数据提高服务可用性。Redis Cluster采用去中心化结构无需proxy代理应用可以直接访问集群中的数据节点。
Redis Cluster要求至少需要3个Master才能组成一个集群同时每个Master至少需要有一个Slave节点。各个节点之间保持TCP通信。当Master发生宕机Redis Cluster自动会将对应的Slave节点提拔为Master来重新对外提供服务。
Redis Cluster功能负载均衡故障切换主从复制。
Redis Cluster集群内置数据自动分片机制集群内部将所有的key映射到16384个Slot中集群中的每个Redis Instance负责其中的一部分的Slot的读写。集群客户端连接集群中任一Redis Instance即可发送命令当Redis Instance收到自己不负责的Slot的请求时会将负责请求Key所在Slot的Redis Instance地址返回给客户端客户端收到后自动将原请求重新发往这个地址对外部透明。一个Key到底属于哪个Slot由crc16(key) % 16384决定。
通信
集群机器等数据信息通常有两种方式
集中式把集群信息保存在配置中心。好处元数据的更新和读取时效性非常好一旦元数据出现变更立即就更新到集中式的存储中其他节点读取时立即就可以感知到。缺点所有的元数据的跟新压力全部集中在一个地方可能会导致元数据的存储有压力Gossip好处元数据的更新比较分散不是集中在一个地方更新请求会陆陆续续打到所有节点上去更新降低压力。缺点元数据更新有延时可能导致部分操作有滞后。
通信的端口就是本身Redis监听端口10000。假如监听端口6379通信端口就是16379。
Gossip
Gossip协议的主要职责就是信息交换常用的Gossip消息有ping、pong、meet、fail等。
meet用于通知新节点加入。消息发送者通知接收者加入到当前集群meet消息通信正常完成后接收节点会加入到集群中并进行周期性的ping、pong消息交换ping集群内交换最频繁的消息集群内每个节点每秒向多个其他节点发送ping消息用于检测节点是否在线和交换彼此状态信息。ping消息发送封装自身节点和部分其他节点的状态数据pong当接收到ping、meet消息时作为响应消息回复给发送方确认消息正常通信。pong消息内部封装了自身状态数据。节点也可以向集群内广播自身的pong消息来通知整个集群对自身状态进行更新fail当节点判定集群内另一个节点下线时会向集群内广播一个fail消息其他节点接收到fail消息之后把对应节点更新为下线状态。
当新增一个节点也就是meet消息过程
节点A会为节点B创建一个clusterNode结构并将该结构添加到自己的clusterState.nodes字典里。节点A根据cluster meet命令给定的IP地址和端口号向节点B发送一条meet消息。节点B接收到节点A发送的meet消息节点B会为节点A创建一个clusterNode结构并将该结构添加到自己的clusterState.nodes字典里面。节点B向节点A返回一条pong消息。节点A将受到节点B返回的pong消息通过这条pong消息节点A可知节点B已成功接收到自己发送的meet消息。随后节点A将向节点B返回一条ping消息。节点B将接收到节点A返回的ping消息通过这条ping消息节点B可知节点A已经成功接收到自己返回的pong消息握手完成。之后节点A会将节点B的信息通过Gossip协议传播给集群中的其他节点让其他节点也与节点B进行握手。最终经过一段时间后节点B会被集群中的所有节点认识。
当一个节点故障怎么判断下线 集群中的每个节点都会定期向其他节点发送ping命令如果接受ping消息的节点在指定时间内没有回复pong则发送ping的节点就把接受ping的节点标记为主观下线。
如果集群半数以上的主节点都将主节点A标记为主观下线则节点A将被标记为客观下线通过节点的广播即下线。
故障切换
当一个从节点发现自己正在复制的主节点进入已下线状态时从节点将开始对下线主节点进行故障转移步骤如下
从节点会执行SLAVEOF no one命令成为新的主节点新的主节点会撤销所有对已下线主节点的槽指派并将这些槽全部指派给自己新的主节点向集群广播一条pong消息这条pong消息可以让集群中的其他节点立即知道这个节点已经由从节点变成主节点并且这个主节点已经接管原本由已下线节点负责处理的槽新的主节点开始接收和自己负责处理的槽有关的命令请求故障转移完成。
一致性Hash算法
参考一致性Hash算法。
一致性哈希算法在节点太少时容易因为节点分布不均匀而造成缓存热点的问题。为了解决此问题可考虑引入虚拟节点机制即对每一个节点计算多个Hash每个计算结果位置都放置一个虚拟节点以实现数据的均匀分布和负载均衡。
Hash Slot
译为哈希槽也叫Hash槽。Redis Cluster有16384个哈希槽对每个Key计算CRC16值后对16384取模可获取Key对应的哈希槽。
Redis Cluster中每个Master都会持有部分槽。假如有3个Master则每个Master持有5000多个哈希槽。哈希槽让节点的增加和移除变得简单增加一个Master就将其他Master的哈希槽移动部分过去减少一个Master就将它的哈希槽移动到其他Master上去。移动哈希槽的成本非常低。客户端API可以对指定的数据让他们走同一个哈希槽通过hash tag来实现。
任何一台机器节点宕机另外几个节点都不受影响。因为Key查找的是哈希槽而不是机器。
一致性
CAP一致性模型中Redis Cluster是AP系统它在网络分区时会优先保证可用性。
参数
提供如下配置项参数
cluster-enabledcluster-config-filecluster-node-timeout表示当某个节点持续timeout的时间失联时才可以认定该节点出现故障需要进行主从切换。如果没有这个选项网络抖动会导致主从频繁切换即数据的重新复制cluster-slave-validity-factorcluster-require-full-coverage推荐设置为no表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时集群仍然可用如果为yes则集群不可用cluster-migration-barrier数据迁移的副本临界数这个参数表示的是一个主节点在拥有多少个好的从节点的时候就要割让一个从节点出来给另一个没有任何从节点的主节点cluster-allow-reads-when-down
问题
Redis Sentinel集群存在的问题一致性和脑裂Redis Cluster集群依旧存在。Redis Cluster集群模式的问题如下
一致性Redis Cluster是AP系统它在网络分区时会优先保证可用性。在发生网络分区或某个主节点故障的情况下如果刚提升的主节点还未完全同步旧主节点的数据可能会出现数据丢失或数据不一致的情况脑裂问题如果出现网络分区或通信故障多个节点可能会认为自己是主节点导致多个主节点同时接受写请求。这种情况下不同的主节点可能会保存不同的数据从而导致数据不一致。当网络恢复后可能会有一些数据被丢弃或覆盖运维管理复杂Redis Cluster需要管理多个节点包括主从节点的状态、节点的增加和减少、哈希槽的重新分配等随着集群规模的扩大网络延迟和管理复杂性也会随之增加数据迁移 哈希槽迁移Redis Cluster使用哈希槽来分片和存储数据但在节点新增或删除时数据的重新分布可能导致负载不均衡或部分节点的存储压力过大热点问题由于数据的分片机制如果某些键特别热门可能会导致对应的节点负载过高出现性能瓶颈在进行数据迁移或重新分配哈希槽时可能会对集群性能产生影响尤其是在大规模数据迁移时可能导致延迟增加和吞吐量下降 客户端复杂Redis Cluster需要支持客户端处理集群模式包括重新连接、节点切换、哈希槽定位等功能。
优化措施
最小复制偏移量机制Redis Cluster通过判断从节点的复制偏移量确保提升为主节点的从节点具有最新的数据以此减少数据丢失的风险Quorum机制Redis Cluster在进行主从切换时会要求多数派投票这样可以降低脑裂的可能性
客户端
JedisCluster集群寻址
JedisCluster配置只用指定集群中某一个节点的IP端口信息即可。JedisCluster初始化时会基于配置节点获取整个集群的信息cluster nodes命令。拿到集群中所有Master信息遍历每个Master节点通过IP端口构建Jedis实例然后put到一个全局nodes变量里面Map类型 key为IP端口值为Jedis实例nodes值如下 nodes{172.19.93.120:6380redis.clients.jedis.JedisPool74ad1f1f,.....} 在上面遍历Master过程中还做一件事遍历此台Master负责的槽索引然后又put到一个全局map slots里面。值为上面的Jedis实例 slots值如下
slots{0redis.clients.jedis.JedisPool74ad1f1f,
1redis.clients.jedis.JedisPool74ad1f1f,
2redis.clients.jedis.JedisPool74ad1f1f,
....
5461 redis.clients.jedis.JedisPool65aa1f2f,
..其他Master机器
16383redis.clients.jedis.JedisPool756d1afd}基于上面的slots变量当有值set时会先算出slot get CRC16(key)(16383-1)假如是12182然后调用slots.get(12182)得到Jedis实例然后去操作Redis。如果发生MovedDataException说明初始化得到的槽位与节点的对应关系有问题节点新增或者宕机就会重置slots。
实战
安装
Redis 5.0之前的版本提供基于Ruby的集群管理工具redis-trib.rb需Ruby 2.3版本。
安装Ruby
wget https://cache.ruby-lang.org/pub/ruby/2.6/ruby-2.6.2.tar.gz
tar -zxf ruby-2.6.2.tar.gz
cd ruby-2.6.2/
./configure --prefix/usr/local/ruby
./configure --prefix/opt/ruby/
make make install为redis-trib.rb安装Redis驱动gem install redis
Redis 5.X 版本已经将集群管理功能集成到redis-cli里面不再推荐使用redis-trib.rb。
命令
创建集群
cluster meet ip port # 将ip和port指定的redis实例添加到当前集群中,在同一个节点操作添加其他所有的节点
cluster replicate node_id # 将当前节点设置为指定节点的从节点,搭建集群时使用查看集群信息
cluster info # 查看集群信息包含几个节点槽位分配和集群状态
cluster nodes # 展示redis集群中所有节点的ip端口node id主从关系等
cluster slaves node_id # 列出指定node_id从节点信息,node_id必须是Master角色,否则报错运维集群节点
cluster failover # 手动进行故障转移
cluster forget node_id # 从集群中移除指定节点这样就无法完成握手过期时为60s60s后两节点又会继续完成握手
cluster reset [HARD|SOFT] # 重置集群信息soft是清空其他节点信息但不修改自己的idhard会修改自己的id默认soft
cluster count-failure-reports node_id # 列出某个节点的故障报告
cluster SET-CONFIG-EPOCH # 设置节点epoch只有在节点加入集群前才能设置槽位相关操作
cluster slots # 列出节点和槽位的关系映射信息
cluster keyslot # 列出key被放置在哪个槽上
cluster countkeysinslot #
cluster getkeysinslot #
cluster setslot slot node node_id # 将槽指派给指定的节点如果槽已经指派给另一个节点那么先让另一个节点删除该槽然后再进行指派
cluster setslot slot migrating node_id # 将本节点的槽迁移到指定的节点中
cluster setslot slot importing node_id # 从 node_id 指定的节点中导入槽 slot 到本节点
cluster setslot slot stable # 取消对槽 slot 的导入import或者迁移migrate
cluster flushslots # 移除指派给当前节点的所有槽使当前节点变成一个没有指派任何槽的节点拓展
16384个槽
为啥设计为16384个槽
可能有些面试官真的会问出这个面试题。参考GitHub issue 2576。
翻译
如果槽位为65536发送心跳信息的消息头达8k心跳包过于庞大。 在消息头中最占空间的是myslots[CLUSTER_SLOTS/8]。Redis节点每秒需要发送一定数量的ping消息作为心跳包。当槽位为65536时大小为65536÷88kbping消息头太大浪费带宽。Redis的集群主节点数量基本不可能超过1000个。 集群节点越多心跳包的消息体内携带的数据越多。如果节点过1000个也会导致网络拥堵。不建议Redis Cluster节点数量超过1000个。节点数在1000以内的集群16384个槽位够用槽位越小节点少的情况下压缩率高。 Redis主节点的配置信息中负责的哈希槽是通过bitmap保存。在传输过程中会对bitmap进行压缩。如果bitmap的填充率即slots / N很高的话N表示节点数bitmap的压缩率就很低。如果节点数很少而哈希槽数量很多的话bitmap的压缩率就很低。而16384÷82kb
