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批量操作及性能分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。