vlambda博客
学习文章列表

Redis集群-7集群运维



Redis集群(最新版5.0.0)

     

     

     

     

     

     

      7.集群运维

     


集群完整性

默认情况下redis的16384个槽必须全部指定,不然会导致集群不可用。但是出现故障到完成转移的过程,集群不可用一般不允许,可将参数cluster-require-full-coverage配置为no,只影响故障节点所负责的槽。


集群带宽消耗

集群的带宽主要分为读写命令带宽和Gossip消息消耗。

      1.尽量避免大规模集群,针对不同场景进行集群拆分。
      2.合理配置cluster-node-timeout,满足业务又能降低消息发送频率。
      3.尽量均匀的部署在更多的机器上。同样的集群规模,节点越均匀整个集群的可用带宽上限越高。

集群倾斜

集群倾斜主要有两方面:数据倾斜和请求倾斜。

数据倾斜

数据倾斜有几种:节点和槽分配不均;不同槽对应键数量差异过大;集合对象含有大量元素;内存相关配置不一致等。
1.节点和槽分配不均,可查看下然后将槽进行均匀分配调整。
2.不同槽对应键数量差异过大。redis对键进行crc16算法一般是均匀的,crc16算法我也在之前文章介绍过。使用了hash_tag的场景会导致数据倾斜,hash_tag的数据离散度较差 ,允许key的部分字符串计算hash。大量使用hash_tag会产生不同的键映射到同一槽上。
3.大集合要根据业务场景进行拆分。
4.内存相关配置指hash-max-ziplist-value、setmax-intset-entries等压缩数据结构配置。内存压缩结构不一致会造成倾斜。

请求倾斜

      1.合理设计key。大对象进行拆分,避免hgetall整体读取。

      2.热key避免映射到同一槽。

      3.一致性要求不高的场景,客户端使用本地缓存减少调用。

集群读写分离

集群模式下从节点不接受读写请求,可以使用readonly打开客户端只读。 读写分离有许多问题: 复制延迟,读取过期数据,从节点故障等问题。 读写分离成本比较高,需要对客户端进行修改实现。

      1.维护每个主节点可用从列表,针对从节点故障问题。

      2.对读命令维护节点路由。

      3.从节点新建连接开启readonly状态。

      读写分离用于业务场景:多节点跨机房部署降低延迟;故障转移时从节点可用。但是这些场景可以通过不同机房部署独立的redis集群,客户端多写维护多份数据副本解决。

手动故障转移

手动故障转移和自动转移很相似,不过手动少了故障发现过程。

       1.从节点通知主节点停止请求。

       2.主节点将延迟复制的数据发送给从节点。

       3.从节点接收数据,复制偏移量一致,保证数据不丢失。

       4.从节点发起投票,不需要延迟出发,立即触发。选举成功变为主节点,并向集群同步。

        5.主变从,从变主。

应用场景

       1.主节点迁移。遇到节点部署调整时先把主节点通过手动故障转移变为从节点,再下线操作。

        2.强制故障转移。自动转移失败时,人工介入转移,自动故障转移失败的场景:主节点和从节点同时都故障,调整网络拓扑降低概率;所有的从节点不具备资格;网络故障不能完成选举;集群一半以上的主节点故障。