redis批量操作及效能分析
。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批量操作詳解及效能分析
指令執行開銷 高併發下 資源競爭和系統排程排程開銷 管道 pipelining 事務 transaction 基於事務的管道 transaction in pipelining mset 適用於string型別 hmget 適用於hash型別 hmset 適用於hash型別 批量命令在key數目巨大...
Redis特點分析及效能優化
redis key值是二進位制安全的，這意味著可以可以使用任何二進位制序列作為key值。空字串也是有效的key值。key取值原則 1.鍵值不需要太長，消耗記憶體，且在資料中查詢這類鍵值計算成本較高 2.鍵值不宜過短，可讀性較差，不宜資料分類和擴充套件 過期1.redis中可以給key設定乙個有效時間...
redis效能分析
1 伺服器 減少記憶體交換，設定淘汰策略，分析命令處理總數，診斷響應延遲 避免操作大集合的慢命令 管道命令 通過這些命令可儘量減少使用多命令的次數。set mset get mget lset lpush,rpush lindex lrange hset hmset hget hmget 2 監控客...