为什么要使用反向代理
如果没有反向代理，一台Redis客户端需要跟很多个客户端连接：
多客户端与Redis链接.png
看着是不是很懵逼？没关系，主要连接需要消耗线程资源，没有代理的话，Redis要将很大一部分的资源用在与客户端建立连接上，Redis的高可用和可扩展性，无论是自带的Sentinel还是Cluster都要求客户端进行额外的支持，而目前基本上没有合适的客户端能够做这些事情，客户端来做这些事情也并不合适，它会让维护变的跟糟糕。
因此客户端和Redis服务端之间加一层代理成了一种理想的方案，代理屏蔽后端
Redis实现细节想客户端提供Redis服务，可以完美的解决Redis的高可用和扩展性的问题。
如何使用代理
很简单，将请求链接到代理服务器上，有Proxy负责将请求转发到后面的Redis服务器实例：
Proxy.png
那么问题来了，如果Proxy挂了呢？
所以Proxy需要做集群，前面再加一层负载均衡（LVS）,而其单机也存在故障的风险，所以整一个主备，备机通过KeeAlived来检测主LVS的健康状况，出现故障自动切换过去：
LVS keepalived.png
redis cluster
Redis Cluster 的实现方案十分的聪明，它的分区方式采用了虚拟槽分区。
Redis Cluster 首先会预设虚拟槽，每个槽就相当于一个数字，有一定范围，每个槽映射一个数据子集。
Redis Cluster中预设虚拟槽的范围为 0 到 16383
- Redis Cluster 会把 16384 个槽按照节点数量进行平均分配，由节点进行管理。
- 当一个 key 过来的时候，会对这个 key 按照 CRC16 规则进行 hash 运算。
- 把 hash 结果对 16383 进行取余。
- 把余数发送给 Redis 节点。
- 节点接收到数据，验证是否在自己管理的槽编号的范围：
5.1. 如果在自己管理的槽编号范围内，则把数据保存到数据槽中，然后返回执行结果。
5.2. 如果在自己管理的槽编号范围外，则会把数据发送给正确的节点，由正确的节点来把数据保存在对应的槽中。
注意：Redis Cluster 的节点之间会共享消息，每个节点都会知道是哪个节点负责哪个范围内的数据槽
虚拟槽分布方式中，由于每个节点管理一部分数据槽，数据保存到数据槽中。当节点扩容或者缩容时，对数据槽进行重新分配迁移即可，数据不会丢失。
cluster.png
————————————————————
坐标帝都，白天上班族，晚上是知识的分享者
如果读完觉得有收获的话，欢迎点赞加关注
