顺丰Redis-Sentinel架构部署
[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/sf-redis-sentinel-design.html
背景
介于Redis-Sentinel的高可用性，我们在顺丰内部的Redis集群中，大量使用了Redis-Sentinel来保证Redis的高可用性
但是由于Redis主从的复制是异步的，从节点数据略微落后于主节点数据，为了业务的一致性，一般从节点是闲置的，也就是说不会做读写分离
但这种情况下，Redis的最高吞吐量会被限制死在单机的吞吐量上，这对于一些高吞吐量的业务来说，是不够的。 因此有了下面的架构
大概架构思想
当然没下面这么简单,实际上还有一致性hash分片的概念,这里简化了,一致性hash分片的概念可以参考下面的文章
参考:Jedis之ShardedJedis一致性哈希分析
- 部署3套Redis-Sentinel集群，每套集群包含3个Sentinel节点，3个Redis节点
- 用户事先配置好所有的Redis-Sentinel节点；
- 用户连接上Redis-Sentinel节点，通过Sentinel节点获取到当前的主节点；
- 用户get/set时，根据key的hash值取余，确定选择到哪个Redis集群操作
通过以上方式，可以让Redis吞吐量提升到N倍，N为Redis集群的数量。
扩容&数据迁移
可能用的更多的是数据迁移工具，如redis-migrate-tool，但是这个工具是基于redis的复制机制，会更好一些，不会那么麻烦，运维自己玩就好😄
当然，也有别的方案，麻烦点，但是也可以实现，如下图
存在的风险是，数据同步完成后 到 新集群模式应用前这段时间的数据会丢失，根据业务，可能需要走兼容性方案，如双写等
其他补充-Redis-Sentinel的连接流程
- 客户端首次连接：客户端初始化时，会与Sentinel节点建立连接，并获取当前可用的Redis主节点信息
- 客户端连接到主节点：根据Sentinel提供的主节点信息，客户端选择一个主节点进行连接，并发送读写请求
- 后续通信直接与主节点：一旦客户端与主节点成功建立连接，后续的读写请求将直接与该主节点进行通信，无需再经过Sentinel节点
在正常情况下，客户端与主节点之间的通信是直接的，不需要再与Sentinel节点交互。然而，如果发生主节点故障或主节点不可用，Sentinel会通知客户端重新连接，并通过Sentinel节点获取新的可用主节点信息
顺丰Redis-Sentinel架构部署