redis工作模式
- 单机
- sentinel
- 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部署在一起
客户端连接
- 从sentinel地址列表中挑一个
- 询问master并连接
- role，询问身份
- 期间发生重连都要重复上述过程
- 当发生故障转移，该节点会kill掉所有的客户端连接，节点会立即或者等分区结束后降为slave
- 对于连接池，每次新连接都需要检测地址有没有变， 有的话所有连接都重置。
cluster模式
- 更多的并行内存，不仅限与单机内存
- multi-key 限制
- redis使用hash slot而不是一致性hash，16384个节点。key计算crc后取mod
- 如果发生迁移，迁移状态完成前老节点继续承担工作，完成后新节点承担，如果老节点找不到，老节点会让你从新节点请求。
- 节点间通过gossip协议同步节点的slot元信息，每个节点随机向K个节点发送自身持有的M个meta信息。
- 客户端随机连一个节点，如果数据不在当前节点，会收到一个MOVED重定向
- 每个节点可以有多个slave，同理failover也通过gossip协议感知。
- 一样可能写丢失
- 可以通过配置timeout以及最小写副本数量来缓解写丢失。
- gossip协议最终收敛，去中心化，可拓展性强，但只能最终一致性，数据传输也比较冗余。
