jedis连接池JedisSentinelPool企业级应用（示例以及踩过的坑）

在使用客户端jedis去操作redis的时候，通常来说，企业一般会标配集群+哨兵模式。使用jidis连接池的重要性不亚于mysql的Druid，良好的连接池配置，对redis读写性能是非常友好的。

话不多说，直接上代码（固定架构）

public class Test {
    public static void main(String args[]) {
        //连接池配置
        JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
        jedisPoolConfig.setMaxTotal(10);
        jedisPoolConfig.setMaxIdle(5);
        jedisPoolConfig.setMinIdle(5);
        //哨兵信息
        Set<String> sentinels = new HashSet<String>(Arrays.asList(
                "10.201.7.171:26379",
                "10.201.7.175:26379",
                "10.201.7.176:26379"
        ));
		//创建连接池
		//mymaster是我们配置给哨兵的服务名称
		//sentinels是哨兵信息
		//jedisPoolConfig是连接池配置
        JedisSentinelPool pool = new JedisSentinelPool("mymaster",sentinels,jedisPoolConfig);
		//获取客户端连接
        Jedis jedis = pool.getResource();
		//设置k1
        jedis.set("k1", "v1");
        String myvalue = jedis.get("k1");
		//获取k1的值
        System.out.println(myvalue);
    }
}

通常来说，在第一次获取连接池中的连接jedis的时候，需要加锁

synchronized(new Object)
		{
			//获取jedis连接代码（即上述）
		}

因为在服务启动的时候有多线程的请求可能性，可能对redis造成影响。

下面是本人踩过的坑

当我的redis集群+哨兵模式部署完成的时候，此时我的服务用的还是老的连接池（公司老连接池用的是单机版redis）。当我请求一个线程去redis进行写操作的时候，我发现，并没有实现主从复制，也即没有出现集群都包含key的情况，然后我debug了一下，发现debug的时候整个集群中是都有我的key的。然后，我把老服务停了下，重新启动，再次请求，发现集群也都有相同的key了。

• 出现这个错误的原因是之前第一次获取jedis实例的时候，加了一把锁，导致无论这么重新配置我的连接池信息，都获取的是老连接池中的连接。当我重启动服务器再次请求一次线程时，就可以重新加载我的新配置了。至于为什么debug就能出现集群key呢？是因为我打的直接是获取jedis连接代码里面的断点（默认认为我重新加载了配置并且我是第一次请求线程）