Jedis cluster 源码解读

1、底层结构分析
我们从JedisCluster类入手

public class JedisCluster extends BinaryJedisCluster implements JedisCommands,
    MultiKeyJedisClusterCommands, JedisClusterScriptingCommands

这个类继承了BinaryJedisCluster，实现了JedisCommands,
MultiKeyJedisClusterCommands, JedisClusterScriptingCommands，而这三个接口，主要是redis的命令。可以不用关注。
JedisCluster的构造器最终调用了父类BinaryJedisCluster的构造器方法

public JedisCluster(Set<HostAndPort> jedisClusterNode, int timeout, int maxAttempts,
      final GenericObjectPoolConfig poolConfig) {
    super(jedisClusterNode, timeout, maxAttempts, poolConfig);
  }

  public JedisCluster(Set<HostAndPort> jedisClusterNode, int connectionTimeout, int soTimeout,
      int maxAttempts, final GenericObjectPoolConfig poolConfig) {
    super(jedisClusterNode, connectionTimeout, soTimeout, maxAttempts, poolConfig);
  }

BinaryJedisCluster类有两个属性，分别是

protected int maxAttempts;
protected JedisClusterConnectionHandler connectionHandler;

构造器方法主要是初始化这俩属性。所以一步一步看进去，就要看这个方法

this.connectionHandler = new JedisSlotBasedConnectionHandler(jedisClusterNode, poolConfig,
        timeout);

JedisSlotBasedConnectionHandler类是JedisClusterConnectionHandler的子类
而关于槽点、redis请求时根据key计算槽点然后到哪个节点请求数据都是在这两个类里做的。
先看基类JedisClusterConnectionHandler

public abstract class JedisClusterConnectionHandler implements Closeable {
  protected final JedisClusterInfoCache cache;

  public JedisClusterConnectionHandler(Set<HostAndPort> nodes,
                                       final GenericObjectPoolConfig poolConfig, int connectionTimeout, int soTimeout) {
    this.cache = new JedisClusterInfoCache(poolConfig, connectionTimeout, soTimeout);
    initializeSlotsCache(nodes, poolConfig);
  }

  abstract Jedis getConnection();

  abstract Jedis getConnectionFromSlot(int slot);

  public Jedis getConnectionFromNode(HostAndPort node) {
    return cache.setupNodeIfNotExist(node).ge