redis批量操作及性能分析

redis批量操作及性能分析

用过redis的小伙伴都知道，这东西是C/S的，就单纯的ser key vvv 就要走一次TCP，记得官方是说redis的qps将近10W，这...我不太敢相信，一秒钟之内对一个服务10W次TCP会啥样，当然可以走集群负载均衡，把Redis分片了，但是分片的话又会设计到很多东西，之前我整理过，想了解的看下这: https://blog.csdn.net/u013761036/article/details/103636870 。

OK下面说正事，基于redis的这种模式，我们在日常使用的时候一定要注意进行批量操作，这对系统调优很重要，带来的效果会非常大。

几种常见的批量操作方式

批量命令（multi）

管道（pipelining）

事务（transaction）

基于事务的管道（transaction pipelining）

 

1.批量命令：

每个数据类型都对应着几个批量操作的命令，例如mset/mget/hmset/hmget...,这种的一次可以对多个key进行操作，相比于所有姿势这个是最快的，因为这里面的对多个key进行一次性操作，是一个命令，注意，是一个命令。不是把很多命令打包，也不是缓存了很多命令最后一起执行。这是最快的方式。一次连接，一个命令。并且这个是原子操作。但是缺点是并不是所有命令都支持，只支持一小部分基本的命令，所以最终结论是，能用这个就一定用这个，不能的话在用其他批量处理的姿势。

 

2.管道：

   管道的话这么理解，有9个任务，我们直接扔在一个管道里了（过大的话会被自动分批发送），可能会变成3截。每截3个。每次发送一截。这样不用建立9次连接发送9个。3次就可以了，这个就是管道的原理。同时一定要注意，管道的批量操作是建立在协议上的优化，就是就是依靠协议进行分批操作。同时一定一定记住，管道不是原子操作。

 

3.事务：

   这么理解，先喊一声 准备，然后把所有任务都扔在车里（此时已经陆续的传给操作端了），然后再喊开始，所有被传过去的任务才开始执行。就是分三部分，准备好了、上任务、干活。是不是感觉这东西可能会比管道慢点，因为管道是 仍一批过去、干活 再扔一批过去、干活 不用等都到了再开始统一干活。没错。实际测试结果也是事务略微慢于管道一点点，但是重点是这东西是 原子操作 原子操作 原子操作。

 

4.基于事务的管道：

管道是建立在协议上的，而事务是redis的命令。量道理可以通过协议的思路，也是就是管道把事务给拆成一节一节的。这个姿势就是 基于事务的管道。性能略微好于事务。效果不明显，操作也比较麻烦，所以较少使用。通常姿势就是 能1.批量就批量，不能的话如果必须原子操作就3.事务，否则就2.管道。

 

5.Redis批量操作原子性：还有就是关于每个姿势到底是不是原子操作这个事，有很多争论，其实要是理解redis工作原理和研究过redis分片的话（最好手写那两个算法，很简单），很容易分清状况，并且考虑的时候要全面，分片姿势有很多种的，虽然常见算法有两种，key范围和hash key，但是别忘记了分片的位置也很关键。你可以在客户端分片（这可能会导致业务代码里有分片代码），也可以在中间件里分，就是把任务都扔给一个类似消息队列的，然后统一处理，再或者自己搭建redis集群，然后在入口负载均衡的地方分。这导致的结果都将不一样，同时还要考虑你每个环节用的什么框架，如果是手写的要看自己的实现方式是啥样的。有的是命令转发，有的是直接自己处理了，然后解析命令了。这都不一样。

等有时间，我会补一个压力测试的笔记。

总结

以上是生活随笔为你收集整理的redis批量操作及性能分析的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。