当前位置: 代码迷 >> 综合 >> redis的pipeline学习
  详细解决方案

redis的pipeline学习

热度:90   发布时间:2023-09-28 01:36:50.0

总结:redis中的pipeline,是批量操作。一次发送多个命令。显然速度会比一次一次发送的更快。但是每次显然两者都有各自的优缺点。

1.pipelined.sync()表示我一次性的异步发送到redis,不关注执行结果。
2.pipelined.syncAndReturnAll()程序会阻塞,等到所有命令执行完之后返回一个List集合。
3.pipeline也不适合组装特别多的命令,因此如果是成千上万的这种命令,我们还是要进行命令的拆分。

 

public class PiplineTest {

    private static int count = 10000;

 

    public static void main(String[] args){

        useNormal();

        usePipeline();

    }

 

    public static void usePipeline(){

        ShardedJedis jedis = getShardedJedis();

        ShardedJedisPipeline pipeline = jedis.pipelined();

        long begin = System.currentTimeMillis();

        for(int i = 0;i<count;i++){

            pipeline.set("key_"+i,"value_"+i);

        }

        pipeline.sync();

        jedis.close();

        System.out.println("usePipeline total time:" + (System.currentTimeMillis() - begin));

    }

 

    public static void useNormal(){

        ShardedJedis jedis = getShardedJedis();

        long begin = System.currentTimeMillis();

        for(int i = 0;i<count;i++){

            jedis.set("key_"+i,"value_"+i);

        }

        jedis.close();

        System.out.println("useNormal total time:" + (System.currentTimeMillis() - begin));

    }

 

    public static ShardedJedis getShardedJedis(){

        JedisPoolConfig poolConfig = new JedisPoolConfig();

        poolConfig.setMaxTotal(2);

        poolConfig.setMaxIdle(1);

        poolConfig.setMaxWaitMillis(2000);

        poolConfig.setTestOnBorrow(false);

        poolConfig.setTestOnReturn(false);

        JedisShardInfo info1 = new JedisShardInfo("127.0.0.1",6379);

        JedisShardInfo info2 = new JedisShardInfo("127.0.0.1",6379);

        ShardedJedisPool pool = new ShardedJedisPool(poolConfig, Arrays.asList(info1,info2));

        return pool.getResource();

    }

}

 输出结果:

1

2

useNormal total time:772

usePipeline total time:112

 从测试的结果可以看出,使用pipeline的效率要远高于普通的访问方式。

 那么问题来了,在什么样的情景下适合使用pipeline呢?

 有些系统可能对可靠性要求很高,每次操作都需要立马知道这次操作是否成功,是否数据已经写进redis了,那这种场景就不适合。

还有的系统,可能是批量的将数据写入redis,允许一定比例的写入失败,那么这种场景就可以使用了,比如10000条一下进入redis,可能失败了2条无所谓,后期有补偿机制就行了,比如短信群发这种场景,如果一下群发10000条,按照第一种模式去实现,那这个请求过来,要很久才能给客户端响应,这个延迟就太长了,如果客户端请求设置了超时时间5秒,那肯定就抛出异常了,而且本身群发短信要求实时性也没那么高,这时候用pipeline最好了。

  相关解决方案