在使用客户端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连接代码里面的断点(默认认为我重新加载了配置并且我是第一次请求线程)