redis的集群化方案

Posted 2021-03-18 又一春夏

关于 目前有三种 

（1）Twitter开发的twemproxy

（2）豌豆荚开发的codis

（3）redis官方的redis-cluster

Twemproxy

 

 

 

 架构简单 就是用proxy对后端redis server进行代理 但是由于代理层的消耗性能很低 而且通常涉及多个key的操作都是不支持的 而且本身不支持动态扩容和透明的数据迁移 而且也失去维护 Twitter内部已经不使用了

          redis-cluster是三个里性能最强大的 因为他使用去中心化的思想 使用hash slot方式 将16348个hash slot 覆盖到所有节点上 对于存储的每个key值 使用CRC16(KEY)&16348=slot 得到他对应的hash slot 并在访问key时就去找他的hash slot在哪一个节点上 然后由当前访问节点从实际被分配了这个hash slot的节点去取数据 节点之间使用轻量协议通信 减少带宽占用 性能很高 自动实现负载均衡与高可用 自动实现failover  并且支持动态扩展 官方已经玩到可以1000个节点 实现的复杂度低 总之个人比较喜欢这个架构 因为他的去中心化思想免去了proxy的消耗 是全新的思路

           但是它也有一些不足 例如官方没有提供图形化管理工具 运维体验差 全手工数据迁移 并且自己对自己本身的redis命令支持也不完全等 但是这些问题 我觉得不能掩盖他关键的新思想所带来的的优势 随着官方的推进 这些问题应该都能在一定时间内得到解决 那么这时候去中心化思想带来的高性能就会表现出他巨大的优势 

          codis使用的也是proxy思路 但是做的比较好 是这两种之间的一个中间级 而且支持redis命令是最多的 有图形化GUI管理和监控工具 运维友好 这个过段时间会详细另外写出来原理 工作机制和搭建实现

CLUSTER

 

 

 

1. 介绍

• redis3.0及以上版本实现，集群中至少应该有奇数个节点，所以至少有三个节点，官方推荐三主三从的配置方式
• 使用哈希槽的概念，Redis 集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽。集群的每个节点负责一部分hash槽。
• 使用主从复制模型，每个节点都会有N-1个slave。如果master不可用，会选举slave为新的master继续服务；如果同个节点的master和slave都失效，整个集群将不可用。

2. 集群的不足：

• Redis集群并不支持处理多个key的操作，因为这需要在不同的节点间移动数据,从而达不到像Redis那样的性能,在高负载的情况下可能会导致不可预料的错误。举例来说，当两个set映射到不同的redis实例上时，你就不能对这两个set执行交集操作。
• 涉及多个key的redis事务不能使用。
• 无法使用多个DB. select 禁止使用

集群

cluster info ：打印集群的信息
cluster nodes ：列出集群当前已知的所有节点（ node），以及这些节点的相关信息。

下面是常用的参数：
redis-cli --cluster help

1、create：创建集群
2、check：检查集群
3、info：查看集群信息
4、fix：修复集群
5、reshard：在线迁移slot
6、rebalance：平衡集群节点slot数量
7、add-node：将新节点加入集群
8、del-node：从集群中删除节点
9、set-timeout：设置集群节点间心跳连接的超时时间
10、call：在集群全部节点上执行命令
11、import：将外部redis数据导入集群

CODIS

Codis动态迁移原理:

 

 

 动态迁移场景：

1、服务slot_1的group原为group 1，codis-config 现发起迁移指令 pre_migrate slot_1 to group 2，将slot_1状态标记为”pre_migrate”；
2、等待所有的proxy回复收到迁移指令；
3、将slot_1状态标记为”migrating”，服务slot_1的server group改为group2
4、codis-config不断发送SLOTSMGRT命令给group1的redis ，直到slot_1所有的key迁移完成；
5、迁移过程中, 如果请求 slot_1 的 key 数据, proxy 会将请求转发到group2上, proxy会先在group1上强行执行一次 MIGRATE key 将这个键值提前迁移过来. 然后再到group2上正常读取
6、将slot_1状态标记为”online”

zookeeper 数据:

扩容操作

Codis的动态扩容/缩容能力是它的一大亮点之一。它可以对Redis客户端透明。在扩容时，Codis提供了SLOTSSCAN指令，这个指令可以扫描指定的slot上的所有key，然后对每个key进行迁移。在扩容过程中，如果有新的key需要转发到正在迁移的slot上，那么codis会判断这个key是否需要迁移，如果需要，则对指定的key进行强制迁移，迁移完成后，再将命令转发到新的Redis上。

看了上面的介绍是不是觉得扩容是一件很麻烦的事情，Codis已经为我们考虑到这点了，它提供了自动均衡的功能，只需要在界面上点一下"Auto Rebalance"按钮，就可以自动实现slot迁移（可以说非常贴心了）。缩容也比较简单，只需要将需要下线的实例的slot迁移到其他实例上，然后删除group就可以了。

Codis的缺点

当Redis Group的master挂掉时，codis不会自动将某个slave升为master，codis提供了一个叫做codis-ha的工具，这个工具通过dashboard提供RESTful API来实现自动主从切换。但是，当codis将某个slave升为master时，其他的slave并不会改变状态，仍然会从旧的master上同步数据，这就导致了主从数据不一致。因此，当出现主从切换时，需要管理员手动创建新的sync action来完成数据同步。

此外，Codis还面临一个比较尴尬的情况就是，由于它不是Redis“亲生”的，因此，当Redis发布了new feature时，它总会慢一步，因此，它需要在Redis发布new feature后迅速赶上，以保持竞争力。

hash_tag

当一个key包含 {} 的时候，就不对整个key做hash，而仅对 {} 包括的字符串做hash。

假设hash算法为sha1。对user:{user1}:ids和user:{user1}:detail，其hash值都等同于sha1(user1)。

 

def HASH_SLOT(key)
    s = key.index "{"
    if s
        e = key.index "}",s+1
        if e && e != s+1
            key = key[s+1..e-1]
        end
    end
    crc16(key) % 16384
end

　比较