jedis超时重试机制注意事项

最近使用redis集群进行incr操作，总是发现计数不准确，后来经过检查发现redis在执行incr超时会执行重试机制，造成计数不准确，测试代码：

/**
     *  incrf:
     *  将 key 中储存的数字值增一。
     如果 key 不存在，那么 key 的值会先被初始化为 0 ，然后再执行 INCR 操作。
     如果值包含错误的类型，或字符串类型的值不能表示为数字，那么返回一个错误。
     本操作的值限制在 64 位(bit)有符号数字表示之内。
     这是一个针对字符串的操作，因为 Redis 没有专用的整数类型，所以 key 内储存的字符串被解释为十进制 64 位有符号整数来执行 INCR 操作。
     返回值：     执行 INCR 命令之后 key 的值。

     这里有问题，最终数据结果大于10000 
     这是因为设置的超时时间太小了，他去重试了，所以最终结果大于10000
     */
    @Test
    public void incrTest() throws InterruptedException { /** * 测试线程安全 */ jedisCluster.del("incrNum"); final AtomicInteger atomicInteger = new AtomicInteger(0); final CountDownLatch countDownLatch = new CountDownLatch(10); ExecutorService executorService = Executors.newFixedThreadPool(10); for(int i = 0 ; i < 10 ; i ++){ executorService.submit(new Runnable() { @Override public void run() { //每个线程增加1000次，每次加1 for(int j = 0 ; j < 1000 ; j ++){ atomicInteger.incrementAndGet(); jedisCluster.incr("incrNum"); } countDownLatch.countDown(); } }); } countDownLatch.await(); System.out.println(jedisCluster.get("incrNum")); System.out.println(atomicInteger); }
这是个多线程的demo，不管多线程还是单线程，我最终得到的结果都是比10000大。这就奇怪了，incr是原子的，理论上不应该会这样。我起初以为是jedis客户端的BUG，后来仔细一看才发现，这不是BUG，是我在创建jediscluster的时候设置的超时时间太短了，导致其超时重试。

解决办法

将超时时间设置的大一些。

我们在使用这些开源框架的时候，一定要全面了解其运作原理，这样才能事半功倍。另外需要注意，想httpclient、dubbo等RPC框架都会有超时重试机制，在使用的时候要注意。

转载于:https://www.cnblogs.com/chasechen/p/7490856.html