這篇文章主要介紹“redis緩存中的事務(wù)處理講解”，在日常操作中，相信很多人在Redis緩存中的事務(wù)處理講解問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”Redis緩存中的事務(wù)處理講解”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

創(chuàng)新互聯(lián)公司是一家專業(yè)提供和龍企業(yè)網(wǎng)站建設(shè),專注與網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、html5、小程序制作等業(yè)務(wù)。10年已為和龍眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進(jìn)行中。

從數(shù)據(jù)庫(kù)事務(wù)說(shuō)起

 通常我們提及數(shù)據(jù)庫(kù)都不可避免的要提到事務(wù)，那么什么是事務(wù)呢?事務(wù)是指作為單個(gè)邏輯工作單元執(zhí)行的一系列操作。所以，首先事務(wù)是一系列操作，這一系列操作具有二態(tài)性，即完全地執(zhí)行或者完全地不執(zhí)行。因此事務(wù)處理可以確保除非事務(wù)單元內(nèi)的所有操作的成功完成，否則不會(huì)***更新面向數(shù)據(jù)的資源。我們這里舉一個(gè)例子，數(shù)據(jù)庫(kù)中除查詢操作以外，插入(Insert)、刪除(Delete)和更新(Update)這三種操作都會(huì)對(duì)數(shù)據(jù)造成影響，因?yàn)槭聞?wù)處理能夠保證一系列操作可以完全地執(zhí)行或者完全不執(zhí)行，因此在一個(gè)事務(wù)被提交以后，該事務(wù)中的任何一條SQL語(yǔ)句在被執(zhí)行的時(shí)候，都會(huì)生成一條撤銷日志(Undo  Log)，而撤銷日志中記錄的是和當(dāng)前擦作完全相反的操作，比如刪除的相反操作是插入，插入的相反操作是刪除等。我們通常所說(shuō)的事務(wù)回滾其實(shí)就是去執(zhí)行這些插銷日志里的相反操作，這同樣告訴我們一個(gè)道理，只有事務(wù)中的一系列操作完全執(zhí)行的情況下可以回滾，如果是在意外情況下導(dǎo)致事務(wù)中的一系列操作沒(méi)有完全執(zhí)行，這個(gè)時(shí)候我們是不能保證數(shù)據(jù)一定可以回滾的。

 在數(shù)據(jù)庫(kù)相關(guān)理論中，一個(gè)邏輯工作單元想要成為事務(wù)，就必須滿足ACID，即原子性、一致性、隔離性和持久性。(1)：原子性這個(gè)概念其實(shí)就是指，一個(gè)事務(wù)內(nèi)的所有SQL操作都是一個(gè)整體，因此只有所有的SQL操作都完全執(zhí)行成功，該事務(wù)方可以認(rèn)為提交成功。如果在提交事務(wù)過(guò)程中某一條SQL語(yǔ)句執(zhí)行失敗，則整個(gè)事務(wù)必須回滾到事務(wù)提交前的狀態(tài)。(2)：而一致性這個(gè)概念則是指，事務(wù)在完成的時(shí)候，必須要保證所有的數(shù)據(jù)都保持一致的狀態(tài)，而落實(shí)到數(shù)據(jù)庫(kù)的各個(gè)組成部分上，則要求開發(fā)人員能夠保證數(shù)據(jù)、索引、約束、日志等在事務(wù)前后具備一致性。(3)：隔離性這個(gè)概念主要針對(duì)并發(fā)，其核心思想就是不同的并發(fā)事務(wù)對(duì)數(shù)據(jù)產(chǎn)生的修改必須是相互隔離的，假設(shè)有兩個(gè)不同的事務(wù)A和B并發(fā)執(zhí)行，那么對(duì)A來(lái)講，它在執(zhí)行前的狀態(tài)只有兩種，即B執(zhí)行前和B執(zhí)行后。同理，對(duì)B來(lái)講同樣是如此，這樣的特性我們就稱為隔離性。(4)：持久性相對(duì)簡(jiǎn)單，是指事務(wù)完成以后它對(duì)數(shù)據(jù)的影響是***性的。

Redis中的事務(wù)處理

 好了，截止到目前為止，我們對(duì)數(shù)據(jù)庫(kù)中事務(wù)處理的相關(guān)理論有了一個(gè)基本的認(rèn)識(shí)，或許這個(gè)世界上的數(shù)據(jù)庫(kù)系統(tǒng)千差萬(wàn)別，但我相信在事務(wù)處理這個(gè)問(wèn)題上它們最終會(huì)殊途同歸，就像我們解決并發(fā)過(guò)程中的沖突問(wèn)題，常規(guī)的做法依然是加鎖一樣，這是我之所以要花費(fèi)精力去理解和解釋這些理論知識(shí)的原因，技術(shù)可謂是日新月異，如果我們總是一味地為新技術(shù)而疲于奔命，那么或許我們會(huì)漸漸地失去對(duì)這個(gè)行業(yè)的熱愛，我相信原理永遠(yuǎn)比框架更為重要，沒(méi)有系統(tǒng)學(xué)習(xí)過(guò)計(jì)算機(jī)專業(yè)的課程，這件事情讓我至今都頗為遺憾。Redis中的事務(wù)是可以視為一個(gè)隊(duì)列，即我們可以通過(guò)MULTI開始一個(gè)事務(wù)，這相當(dāng)于我們聲明了一個(gè)命令隊(duì)列。接下來(lái)，我們向Redis中提交的每條命令，都會(huì)被排入這個(gè)命令隊(duì)列。當(dāng)我們輸入EXEC命令時(shí)，將觸發(fā)當(dāng)前事務(wù)，這相當(dāng)于我們從命令隊(duì)列中取出命令并執(zhí)行，所以Redis中一個(gè)事務(wù)從開始到執(zhí)行會(huì)經(jīng)歷  開始事務(wù) 、 命令入隊(duì) 和 執(zhí)行事務(wù) 三個(gè)階段。下面是一個(gè)在Redis中使用事務(wù)的簡(jiǎn)單示例：

127.0.0.1:6379> MULTI OK 127.0.0.1:6379> SET Book_Name "GIt Pro" QUEUED 127.0.0.1:6379> SADD Program_Language "C++" "C#" "Jave" "Python"  QUEUED 127.0.0.1:6379> GET Book_Name QUEUED 127.0.0.1:6379> EXEC 1) OK 2) (integer) 4 3) "GIt Pro"

我們可以注意到Redis中的事務(wù)和通常意義上的事務(wù)基本上是一致的，即

• 事務(wù)是由一系列操作組成的單個(gè)邏輯工作執(zhí)行單元。特別地，因?yàn)樵赗edis中命令是存儲(chǔ)在一個(gè)隊(duì)列中，所以，事務(wù)中的所有命令都會(huì)按順序執(zhí)行，并且在執(zhí)行事務(wù)的過(guò)程中不會(huì)被客戶端發(fā)送的其它命令中斷。

• 事務(wù)是一個(gè)原子操作，事物中的命令只有兩種執(zhí)行結(jié)果，即全部執(zhí)行或者全部不執(zhí)行。如果客戶端在使用MULTI命令開啟事務(wù)后因?yàn)橐馔舛鴽](méi)有執(zhí)行EXEC命令，則事務(wù)中的所有命令都不會(huì)執(zhí)行。同理，如果客戶端在使用MULTI命令開啟事務(wù)后執(zhí)行EXEC命令，則事務(wù)中的所有命令都會(huì)執(zhí)行。

• Redis中的事務(wù)可以使用DISCARD命令來(lái)清空一個(gè)命令隊(duì)列，并放棄對(duì)事務(wù)的執(zhí)行。如果命令在入隊(duì)時(shí)發(fā)生錯(cuò)誤，Redis將在客戶端調(diào)用EXEC命令時(shí)拒絕執(zhí)行并取消事務(wù)，但是在EXEC命令執(zhí)行后發(fā)生的錯(cuò)誤，Redis將選擇自動(dòng)忽略。

我們知道，常見的并發(fā)控制方案主要有悲觀鎖和樂(lè)觀鎖兩種方案，這里首先來(lái)解釋下這兩種概念。所謂悲觀鎖，顧名思義是一種悲觀的策略，悲觀鎖認(rèn)為：在對(duì)任何記錄做修改前都應(yīng)該加鎖，如果加鎖失敗則表明該機(jī)錄正在被修改，此時(shí)應(yīng)該拋出異常;如果加鎖成功則修改記錄并在事務(wù)完成后解鎖;如果有其它人修改則應(yīng)該等待當(dāng)前修改解鎖或者是拋出異常。而所謂樂(lè)觀鎖，顧名思義是一種樂(lè)觀的策略，樂(lè)觀鎖認(rèn)為：每次從記錄中查找數(shù)據(jù)別人都不會(huì)修改，因此這個(gè)過(guò)程中不需要加鎖，但是在更新記錄的時(shí)候，會(huì)通過(guò)版本號(hào)來(lái)判斷別人是否修改過(guò)當(dāng)前記錄。

通常來(lái)講，樂(lè)觀鎖適合在寫沖突相對(duì)較少的場(chǎng)合下，悲觀鎖適合在寫沖突相對(duì)較多的場(chǎng)合下。Redis中提供了一種稱為check-and-set的機(jī)制，該機(jī)制主要通過(guò)WATCH命令來(lái)實(shí)現(xiàn)，其原理正是基于樂(lè)觀鎖的策略，Redis會(huì)在執(zhí)行EXEC命令前檢查被監(jiān)視的鍵對(duì)應(yīng)的值是否發(fā)生變化，如果該值發(fā)生變化表明有人修改過(guò)這個(gè)鍵中存儲(chǔ)的值，此時(shí)Redis將會(huì)自動(dòng)取消當(dāng)前事務(wù)。我們來(lái)看這個(gè)簡(jiǎn)單的例子：

WATCH Record_Count val = GET Record_Count val = val + 1 MULTI SET Record_Count $val EXEC

在這個(gè)例子中，我們嘗試在事務(wù)中對(duì)Record_Count做一個(gè)自增操作，這段代碼在非并發(fā)的情況下是沒(méi)有問(wèn)題的，可是在并發(fā)的情況下，如果在執(zhí)行EXEC命令前有一個(gè)用戶修改了Record_Count的值，那么我們此時(shí)的結(jié)果就會(huì)比期望的結(jié)果小1，現(xiàn)在我們有了WATCH，Redis就會(huì)對(duì)Record_Count進(jìn)行監(jiān)聽，當(dāng)Redis監(jiān)聽到該值發(fā)生變化的時(shí)候，這個(gè)事務(wù)就會(huì)被自動(dòng)取消，進(jìn)而避免造成沖突。

如何管理Redis的鍵

 其實(shí)從切題的角度來(lái)講，這篇博客基本上說(shuō)清楚了事務(wù)處理問(wèn)題，因此這篇博客雖然沒(méi)有給大家?guī)?lái)多少驚喜，卻依然可以非常恰到好處的結(jié)題，可是因?yàn)橹坝信笥言诓┛椭辛粞圆?wèn)到Redis的鍵管理的問(wèn)題，所以博主決定在這里簡(jiǎn)單的討論下這個(gè)問(wèn)題，鑒于博主和大家一樣都是感剛接觸Redis，所以下面的觀點(diǎn)僅僅是一家之言，如果有疑問(wèn)可以在博客中留言，歡迎大家批評(píng)指正。我認(rèn)為Redis中的鍵的管理，基本上有兩種策略，即惰性刪除和定期刪除，而實(shí)際上這正是Redis默認(rèn)的鍵刪除策略：

redis使用 惰性刪除 和 定期刪除  兩種策略來(lái)刪除過(guò)期的鍵：惰性刪除策略在碰到過(guò)期鍵時(shí)方進(jìn)行刪除操作，定期刪除策略則每隔一段時(shí)間主動(dòng)查找并刪除過(guò)期鍵。

所以，基于這兩種鍵刪除策略，我們可以想到的做法有：

• 對(duì)于臨時(shí)變量可以采用臨時(shí)鍵來(lái)存儲(chǔ)，在數(shù)據(jù)庫(kù)全局設(shè)定一個(gè)過(guò)期時(shí)間，由Redis在鍵過(guò)期后自動(dòng)刪除。

• 對(duì)于持久化數(shù)據(jù)可以采用普通鍵來(lái)存儲(chǔ)，通過(guò)服務(wù)器和客戶端間定義協(xié)議來(lái)由客戶端主動(dòng)刪除鍵。

• 對(duì)于不同模塊中的鍵采取統(tǒng)一規(guī)范的命名規(guī)則來(lái)命名鍵，從而解決Redis中鍵管理混亂的問(wèn)題。

設(shè)計(jì)合理的鍵回收機(jī)制，避免Redis使用超過(guò)95%以上的內(nèi)存，或者通過(guò)設(shè)置Redis中的***內(nèi)存容量及其內(nèi)存策略來(lái)主動(dòng)觸發(fā)Redis對(duì)鍵的淘汰。

到此，關(guān)于“Redis緩存中的事務(wù)處理講解”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！

當(dāng)前標(biāo)題：Redis緩存中的事務(wù)處理講解
標(biāo)題URL：http://chinadenli.net/article8/poodop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、網(wǎng)站維護(hù)、微信小程序、全網(wǎng)營(yíng)銷推廣、靜態(tài)網(wǎng)站、自適應(yīng)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)