redis集群简单介绍

redis工作模式

1. 单机
2. sentinel
3. cluster

sentinel模式

基本部署模式

       +----+
       | M1 |
       | S1 |
       +----+
          |
+----+    |    +----+
| R2 |----+----| R3 |
| S2 |         | S3 |
+----+         +----+
quorum = 2 保证顺利投票
1. 由于redis没有类似mongo的 write concern选项，切换会丢数据，可以用配置min-slaves-to-write来缓解
2. 可以实现故障转移failover，基本的sentinel部署结构
3. 也可以把几个sentinel配置在单独的机器中，总体思路是把sentinel分开部署，甚至考虑和client部署在一起

客户端连接

1. 从sentinel地址列表中挑一个
2. 询问master并连接
3. role，询问身份
4. 期间发生重连都要重复上述过程
5. 当发生故障转移，该节点会kill掉所有的客户端连接，节点会立即或者等分区结束后降为slave
6. 对于连接池，每次新连接都需要检测地址有没有变， 有的话所有连接都重置。

cluster模式

1. 更多的并行内存，不仅限与单机内存
2. multi-key 限制
3. redis使用hash slot而不是一致性hash，16384个节点。key计算crc后取mod
4. 如果发生迁移，迁移状态完成前老节点继续承担工作，完成后新节点承担，如果老节点找不到，老节点会让你从新节点请求。
5. 节点间通过gossip协议同步节点的slot元信息，每个节点随机向K个节点发送自身持有的M个meta信息。
6. 客户端随机连一个节点，如果数据不在当前节点，会收到一个MOVED重定向
7. 每个节点可以有多个slave，同理failover也通过gossip协议感知。
8. 一样可能写丢失
9. 可以通过配置timeout以及最小写副本数量来缓解写丢失。
10. gossip协议最终收敛，去中心化，可拓展性强，但只能最终一致性，数据传输也比较冗余。