最近使用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框架都会有超时重试机制，在使用的时候要注意。