Redis的各种架构说明

类型	客户端	LB策略	出现的版本	说明
单点	Jedis，Lettuce	无	*	-
客户端分片	ShardedJedis	consistent hashing	2.x	多台单机Redis服务，通过ShardedJedis达到分片目的 SJ上维护哈希环
主备+哨兵	按是否需要分片选择J/SJ	客户端实现	*	主备用于容灾，哨兵用于替换主备节点 类似mysql和keepalived
Proxy	Jedis	consistent hashing&..	2.x	Proxy是Server和Client的中间层，本身也有很多种开源的实现： 1. Codis/Twemproxy：外接ZK/etcd做路由,旁路组件对redis节点进行探活。 2. smart-jedis：3.0+的版本中，可以从cluster中直接拉取slot的归属信息来做路由表。 -. Proxy一般会将某些命令禁用，比如keys/smembers/pub、sub等
Cluster	JedisCluster	hash slot 没有一致性哈希灵活，但胜在简单，性能也不错。	3.0+	存储层面上做分片，每个节点管理一部分slot。 没有哨兵做监控，主要是gossip来进行状态和管理的slot信息交换。当大多数节点认为某一master下线后，会启动failover流程。
Proxy+Cluster	Jedis	存储层是hash slot，proxy不做路由，直接读slot info即可	3.0+ 5.0的redis计划自带proxy	Redis Cluster并没有提供Proxy层，而是告知客户端将key的请求转发给合适的nodes。因此需要一个Smart Client来保存集群中nodes与keys的映射关系（slots），并保持此数据的更新，以便将请求直接发送到正确的nodes上。 Proxy把这个工作自己完成了，对外表现得就像单点redis那样。 另外，这种代理Cluster的Proxy处理的数据量一般很大，所以还会加入一些高级特性，比如： 1. 请求过滤 2. 大key/热key监控 等