在多個客戶端同時處理相同的數據時，不謹慎的操作很容易導致數據出錯。一般的關系型數據庫中有事務保證了數據操作的原子性，同樣Redis中也設置了事務，可以理解為“將多個命令打包，然后一次性、按順序執行”，防止數據出錯，同時提升性能。

Redis事務

關系型數據庫中，要使用事務，首先向數據庫服務器發送BEGIN，然后執行各個相互一致的寫操作和讀操作，最后，用戶可以選擇發送COMMIT來確認之前所做的修改，或者發送ROLLBACK來放棄那些修改。

同樣，Redis中也有簡單的方法處理一連串相互一致的讀操作和寫操作。首先是以MULTI命令開始事務，后續跟著一連串命令，最后以EXEC結束事務或者以DISCARD命令撤銷所有命令并結束事務。Redis官方文檔中對于事務以及事務常用命令做了詳細介紹。

事務原子性

Redis事務中的所有命令能夠保證被順序執行(FIFO)，中間不會被其他客戶端打斷。它本身應對外部請求是單任務的，也是多線程安全的。關系型數據庫的事務具有原子性特點，而Redis事務就沒法確定說是原子性的。看一下官方文檔中Errors inside a transaction一節，事務中有兩種command errors：一種是在MULTI之后，EXEC執行之前，由于命令的語法錯誤或者服務器內存不夠等原因，命令根本不會被放入暫存隊列，Redis會拒絕執行接下來的EXEC操作，這和我們理解的原子性原理是一致的；

另外一種是在EXEC之后，當隊列中的某條命令執行失敗，Redis也會繼續執行完其他命令，且不支持回滾，最關鍵的地方反而還不支持原子性！

Redis官方文檔中對其不支持回滾的特性也做了說明，Redis命令只會在語法錯誤或者對某個Key執行了不屬于該類型的相應操作，而這些錯誤應該是在開發過程中就避免的 = =；Reids也正是因為不支持回滾所以才能更簡單快速(好傲嬌~)

所以我們在使用Redis事務過程中一定要注意：Redis事務所指的原子性僅僅只針對將命令加入執行隊列的過程，Redis事務不支持在命令執行過程中的錯誤回滾。《Redis設計與實現》中對Redis事務的ACID特性做了全面的講解。

Redis事務鎖Watch

Watch是Redis提供的事務鎖，是一種樂觀鎖。在MULTI命令之前執行WATCH命令，當EXEC提交之后，在實際執行任何命令之前，如果發現被Watched的key值發生了改變，整個事務被丟棄，返回為空。

個人理解，使用Redis事務結合Watch命令，只是能保證在事務內被watched的key不會被重復錯誤修改，一定程度上能夠保證原子性，但也只是針對被watched的key。

Python Redis事務

python中通過管道Pipeline實現Redis事務。當我們要使用事務時，首先實例化一個Pipeline類，可以先實例化StrictRedis類，然后調用實例的pipeline()方法；也可以直接實例化Pipeline類。兩種方法都會創建BasePipeLine實例。Redis事務中對應的MULTI， EXEC, DISCARD, WATCH操作都對應到BasePipeLine中的相應方法。#?1redis?=?Redis(host='127.0.0.1',?port=6379)

pipe?=?redis.pipeline()#?2pipe?=?Pipeline(host='127.0.0.1',?port=6379)

在python中使用事務的流程也基本不變，建立Pipeline以后，調用multi()方法，表示事務開始，然后依次執行所有redis命令，然后調用execute()方法提交事務。同樣在事務開始之前，可以調用watch()方法監控keys。try:

pipe.watch('key1')

pipe.multi()

pipe.set('key2',?2)

pipe.incr('key1')

pipe.set('key3',?3)

pipe.execute()except?redis.exceptions.WatchError:????#?發生watcherror時業務應該怎樣處理，丟棄事務或者重試

pass

看一下python中execute()方法的源碼：def?execute(self,?raise_on_error=True):????????"Execute?all?the?commands?in?the?current?pipeline"

stack?=?self.command_stack????????if?not?stack:????????????return?[]????????if?self.scripts:????????????self.load_scripts()????????if?self.transaction?or?self.explicit_transaction:

execute?=?self._execute_transaction????????else:

execute?=?self._execute_pipeline

conn?=?self.connection????????if?not?conn:

conn?=?self.connection_pool.get_connection('MULTI',???????????????????????????????????????????????????????self.shard_hint)????????????#?assign?to?self.connection?so?reset()?releases?the?connection

#?back?to?the?pool?after?we're?done

self.connection?=?conn????????try:????????????return?execute(conn,?stack,?raise_on_error)

except?(ConnectionError,?TimeoutError)?as?e:

conn.disconnect()????????????if?self.watching:

raise?WatchError("A?ConnectionError?occured?on?while?watching?"

"one?or?more?keys")????????????return?execute(conn,?stack,?raise_on_error)????????finally:????????????self.reset()

命令執行后，程序會捕獲ConnectionError和TimeoutError，當連接超時并且沒有設置重試retry_on_timeout參數，異常直接拋出，否則會進行一次重試。最終調用reset()重置所有參數。

redis-benchmark

Pipeline能夠將一堆命令先收集起來，再一起發送給Redis服務器處理，減少了和Redis的連接通信次數。但當Pipeline中命令的數量過大，管道中所有命令和執行結果會被緩存到Redis內存，同時也會造成網絡通信變慢，得不償失。那么，Pipeline每次接收的命令數量是多少才能達到最優的執行效率(How many commands could redis-py pipeline have?)？

Redis提供了redis-benchmark命令，模擬N個客戶端同時發送M條命令，并返回執行統計結果。我們可以通過參數設置模擬客戶端數量，請求總數，是否使用Pipeline以及Pipeline中命令數量，指定命令類型等。

首先模擬無Pipeline情況下執行情況，假設給定100000條請求，模擬get和set請求，執行結果如下。普通情況下，平均每秒執行102145.05條SET請求，平均每秒執行98716.68條GET請求。$?redis-benchmark?-n?100000?-t?set,get?-q

SET:?102145.05?requests?per?second

GET:?98716.68?requests?per?second

加入Pipeline，每個Pipeline執行100條命令，執行結果如下。執行效率顯著提高了，尤其是對于GET請求。$?redis28-benchmark?-n?100000?-t?set,get?-P?100?-q

SET:?552486.19?requests?per?second

GET:?800000.00?requests?per?second

如果把Pipeline的最大執行命令數設置到10000，執行結果如下。這種情況下，對效率沒有顯著提升了，而且如果每條命令數據所占的字節數變大，執行效率更低。$?redis-benchmark?-n?100000?-t?set,get?-P?10000?-q

SET:?118764.84?requests?per?second

GET:?150602.42?requests?per?second

到底應該把Pipeline的命令數設置為多大才合適，沒有確定的答案，有的人給的建議是100-1000，具體設置為多大需要在當前Redis連接狀況，Redis內存大小等基礎上不斷測試找到那個sweet spot。

作者：rainybowe

鏈接：https://www.jianshu.com/p/32bf08e885b0

總結

以上是生活随笔為你收集整理的python redis事务_python redis事务源码及应用分析的全部內容，希望文章能夠幫你解決所遇到的問題。

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