JedisCluster与ShardedJedisPool的区别

1，jedis客户端操作redis主要三种模式：单台模式、分片模式（ShardedJedis）、集群模式（BinaryJedisCluster），分片模式是一种轻量级集群。

2，shardedjedispool分片集群与jediscluster集群同样不具有高可用特性，但基于shardedjedispool的ShardedJedisSentinelPool可以实现集群高可用，redis服务一台master挂机，sentinel哨兵进行主从切换之后，客户端程序自动完成同步的主从切换。 
具体的实现方式就是通过sentinel的sentinelGetMasterAddrByName(masterName);(实际执行sentinel的get-master-addr-by-name命令)获取哨兵监控的所有master节点；然后用一个MasterListener启用一个线程，利用redis的订阅与发布机制，订阅+switch-master频道，时时获取redis服务端主从切换的信息。

3，ShardedJedisPool是redis没有集群功能之前客户端实现的一个数据分布式方案，redis3.0提供集群之后，客户端则采用JedisCluster实现连接redis集群环境。 
ShardedJedisPool使用的是JedisShardInfo的instance的顺序或者name来做的一致性哈希 。JedisCluster使用的是CRC16算法来做的哈希槽。

4，集群环境，各个服务之间的数据是隔离的

无论是ShardedJedisPool的一致性哈希算法还是JedisCluster的CRC16哈希槽算法，都是把所有的服务叠加然后进行均匀的分割，分割出来的每一个段或槽都是不重复的，所以导致存储的数据彼此之间也是处于隔离状态的

5,JedisClusterd实现原理

 

JedisCluster初始化时，所有的集群连接信息都是封装在JedisClusterInfoCache里，由于jedis本身不是线程安全的，所以使用对象池JedisPool来保证线程安全，在JedisClusterInfoCache中，除了要保存节点和槽的一一对应关系，还要为每个节点建立一个对象池JedisPool，并保存在map。这个类主要用于保存集群的配置信息，并且是JedisCluster初始化部分的核心所在。JedisClusterConnectionHandler是cache类的一个窗口，cache类似数据管理层，而Handler就类似于操控数据提供服务的Service层。

Jedis建立集群的过程很清晰，传入节点信息，通过其中一个节点从redis服务器拿到整个集群的信息，包括槽位对应关系，主从节点的信息，将这些信息保存在JedisClusterInfoCache中。

在发送请求时，JedisCluster对象先从初始化得到的集群map中获取key对应的节点连接，即一个可用的Jedis对象。然后通过这个对象发送get key 命令。
    通常，根据key计算槽位得到的节点不会报错。所以如果发生connectionException,或者MovedDataException,说明初始化得到的槽位与节点的对应关系有问题，即与实际的对应关系不符，应当重置map。 如果出现ASK异常，说明数据正在迁移，需要临时使用返回消息指定的地址，重新发送命令。在这里，Jedis通过异常反馈，智能地同步了客户端与服务端的集群信息。

 如果集群环境中，某一个master挂掉，交由jediscluster管理的集群访问程序，必然会出现异常，所以jediscluster并未实现集群环境下的高可用，只是实现了分布式，只有重启服务重新初始化新的集群环境，程序方可正常运行。