redis cluster

朱雀 2023-05-28 05:26 106阅读 0赞

# 官方集群方案 #

redis cluster是Redis的分布式集群解决方案，在3.0版本推出后有效地解决了redis分布式方面的需求  
实现了数据在多个Redis节点之间自动分片、故障自动转移、扩容机制等功能。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NkbXhkemI_size_16_color_FFFFFF_t_70][]

# 集群关心的问题  #

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取消当前连接的可读状态。  
注意：主从节点依然存在数据不一致的问题

# 分片集群示意图 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NkbXhkemI_size_16_color_FFFFFF_t_70 1][]

# 集群数据迁移方式 #

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 的新主节点。  
\- 集群仍然能继续正常工作。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NkbXhkemI_size_16_color_FFFFFF_t_70 2][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NkbXhkemI_size_16_color_FFFFFF_t_70]: /images/20230528/cb448757747e42a9856d2d7e7730a0e1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NkbXhkemI_size_16_color_FFFFFF_t_70 1]: /images/20230528/b9e793bc2601442d9d059ed1d6a43470.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NkbXhkemI_size_16_color_FFFFFF_t_70 2]: /images/20230528/d04f4c26bafc4a8ab1b2b9e056ddbec7.png