官方集群方案
redis cluster是Redis的分布式集群解决方案,在3.0版本推出后有效地解决了redis分布式方面的需求
实现了数据在多个Redis节点之间自动分片、故障自动转移、扩容机制等功能。
集群关心的问题
1 、增加了 slot 槽的计算,是不是比单机性能差?
共16384个槽,slots槽计算方式公开的, HASH_SLOT = CRC16(key) mod 16384 。
为了避免每次都需要服务器计算重定向,优秀的java客户端都实现了本地计算,并且缓存服务器slots分配,有变动时
再更新本地内容,从而避免了多次重定向带来的性能损耗。(结合画图过程理解)
2、 redis 集群大小,到底可以装多少数据?
理论是可以做到16384个槽,每个槽对应一个实例,但是redis官方建议是最大1000个实例。存储足够大了
3、 集群节点间是怎么通信的?
每个Redis群集节点都有一个额外的TCP端口,每个节点使用TCP连接与每个其他节点连接。检测和故障转移这些步骤基
本和哨兵模式类似(毕竟是同一个软件,同一个作者设计)。
4、 ask 和 moved 重定向的区别
重定向包括两种情况
若确定slot不属于当前节点,redis会返回moved。
若当前redis节点正在处理slot迁移,则代表此处请求对应的key暂时不在此节点,返回ask,告诉客户端本次请求重
定向。
5 、数据倾斜和访问倾斜的问题
倾斜导致集群中部分节点数据多,压力大。解决方案分为前期和后期:
前期是业务层面提前预测,哪些key是热点,在设计的过程中规避。
后期是slot迁移,尽量将压力分摊(slot调整有自动rebalance、reshard和手动)。
6 、 节点之间会交换信息,传递的消息包括槽的信息,带来带宽消耗。
注意:避免使用大的一个集群,可以分多个集群。
7、 Pub/Sub 发布订阅机制
注意:对集群内任意的一个节点执行publish发布消息,这个消息会在集群中进行传播,其他节点接收到发布的消息。
8 、 读写分离
redis-cluster默认所有从节点上的读写,都会重定向到key对接槽的主节点上。
可以通过readonly设置当前连接可读,通过readwrite取消当前连接的可读状态。
注意:主从节点依然存在数据不一致的问题
分片集群示意图
集群数据迁移方式
slot 手动迁移怎么做?
迁移过程如下,大致描述如下:
在迁移目的节点执行cluster setslot <slot> IMPORTING <node ID>命令,指明需要迁移的slot和迁移源节点。
在迁移源节点执行cluster setslot <slot> MIGRATING <node ID>命令,指明需要迁移的slot和迁移目的节点。
在迁移源节点执行cluster getkeysinslot获取该slot的key列表。
在迁移源节点执行对每个key执行migrate命令,该命令会同步把该key迁移到目的节点。
在迁移源节点反复执行cluster getkeysinslot命令,直到该slot的列表为空。
在迁移源节点和目的节点执行cluster setslot <slot> NODE <node ID>,完成迁移操作。
集群从节点迁移
reids集群实现了一个叫做复制(从节点)迁移的概念,以提高系统的可用性。
假设集群有三个主节点 A A ,B B ,C C。 。 A A 、B B 都 各有一个从节点, A1 和 和 B1 。 节点C C 有 两个从节点: C1 和 和 C2
迁移过程如下,大致描述如下:
- 主节点 A 失效。A1 被提升为主节点。
- 节点 C2 迁移成为节点 A1 的从节点,要不然 A1 就没有任何从节点。
- 三个小时后节点 A1 也失效了。
- 节点 C2 被提升为取代 A1 的新主节点。
- 集群仍然能继续正常工作。