本文圍繞以下幾點進行闡述：
- 為什么使用redis
- 使用Redis有什么缺點
- 單線程的Redis為什么這么快
- Redis的數(shù)據(jù)類型，以及每種數(shù)據(jù)類型的使用場景
- Redis的過期策略以及內(nèi)存淘汰機制
- Redis和數(shù)據(jù)庫雙寫一致性問題
- 如何應對緩存穿透和緩存雪崩問題
- 如何解決Redis的并發(fā)競爭問題
一、為什么使用Redis
筆者認為，在項目中使用Redis，主要是從兩個角度去考慮：性能和并發(fā)。當然，Redis還具備可做分布式鎖等功能的其它功能，但如果只是為了分布式鎖這些其它功能，完全還有其它中間件（如Zookpeer等）可以代替，并不是非要使用Redis。
因此，這個問題主要從性能和并發(fā)兩個角度去答：
1、性能
如下圖所示，我們在碰到需要執(zhí)行耗時特別久、且結(jié)果不頻繁變動的SQL時，就特別適合將運行結(jié)果放入緩存。這樣，后面的請求就去緩存中讀取，使得請求能夠迅速響應。
題外話：忽然想聊一下這個迅速響應的標準——其實根據(jù)交互效果的不同，這個響應時間沒有固定標準。不過曾經(jīng)有人這么告訴我：“在理想狀態(tài)下，我們的頁面跳轉(zhuǎn)需要在瞬間解決，對于頁內(nèi)操作則需要在剎那間解決。另外，超過一彈指的耗時操作要有進度提示，并且可以隨時中止或取消，這樣才能給用戶最好的體驗。”
那么瞬間、剎那、一彈指具體是多少時間呢？
根據(jù)《摩訶僧祗律》記載：一剎那者為一念，二十念為一瞬，二十瞬為一彈指，二十彈指為一羅預，二十羅預為一須臾，一日一夜有三十須臾。
那么，經(jīng)過周密的計算，一瞬間為0.36秒,一剎那有0.018秒，一彈指長達7.2秒。
2、并發(fā)
如下圖所示，在大并發(fā)的情況下，所有的請求直接訪問數(shù)據(jù)庫，數(shù)據(jù)庫會出現(xiàn)連接異常。這個時候，就需要使用Redis做一個緩沖操作，讓請求先訪問到Redis，而不是直接訪問數(shù)據(jù)庫。
二、使用Redis有什么缺點
大家用Redis這么久，這個問題是必須要了解的，基本上使用Redis都會碰到一些問題，常見的主要是四方面的問題：
- 緩存和數(shù)據(jù)庫雙寫一致性問題
- 緩存雪崩問題
- 緩存擊穿問題
- 緩存的并發(fā)競爭問題
這四個問題，筆者個人覺得在項目中比較常遇見，具體解決方案，后文會給出。
三、單線程的Redis為什么這么快
這個問題其實是對Redis內(nèi)部機制的一個考察。其實根據(jù)筆者的面試經(jīng)驗，很多人其實都不知道Redis是單線程工作模型。所以，這個問題還是應該要復習一下的。主要是以下三點：
- 純內(nèi)存操作
- 單線程操作，避免了頻繁的上下文切換
- 采用了非阻塞I/O多路復用機制
我們現(xiàn)在仔細地說一說I/O多路復用機制，因為這個說法實在是太通俗了，通俗到一般人都不懂是什么意思。打一個比方：小曲在S城開了一家快遞店，負責同城快送服務。小曲因為資金限制，雇傭了一批快遞員，然后小曲發(fā)現(xiàn)資金不夠了，只夠買一輛車送快遞。
經(jīng)營方式一：
客戶每送來一份快遞，小曲就讓一個快遞員盯著，然后快遞員開車去送快遞。慢慢的小曲就發(fā)現(xiàn)了這種經(jīng)營方式存在很多問題，幾十個快遞員基本上時間都花在了搶車上了，大部分快遞員都處在閑置狀態(tài)，誰搶到了車，誰就能去送快遞。
隨著快遞的增多，快遞員也越來越多，小曲發(fā)現(xiàn)快遞店里越來越擠，沒辦法雇傭新的快遞員了，快遞員之間的協(xié)調(diào)很花時間，大部分時間花在搶車上。綜合上述缺點，小曲痛定思痛，提出了下面的經(jīng)營方式↓
經(jīng)營方式二：
小曲只雇傭一個快遞員，客戶送來的快遞，小曲按送達地點標注好，然后依次放在一個地方。最后，那個快遞員依次去取快遞，一次拿一個，開著車去送快遞，送好了就回來拿下一個快遞。
上述兩種經(jīng)營方式對比，是不是明顯覺得第二種，效率更高、更好呢？在上述比喻中：
- 每個快遞員→每個線程
- 每個快遞→每個Socket(I/O流)
- 快遞的送達地點→Socket的不同狀態(tài)
- 客戶送快遞請求→來自客戶端的請求
- 小曲的經(jīng)營方式→服務端運行的代碼
- 一輛車→CPU的核數(shù)
于是我們有如下結(jié)論：
- 經(jīng)營方式一就是傳統(tǒng)的并發(fā)模型，每個I/O流(快遞)都有一個新的線程(快遞員)管理。
- 經(jīng)營方式二就是I/O多路復用。只有單個線程(一個快遞員)，通過跟蹤每個I/O流的狀態(tài)(每個快遞的送達地點)，來管理多個I/O流。
下面類比到真實的Redis線程模型，如圖所示：
參照上圖，簡單來說就是，我們的Redis-client在操作的時候，會產(chǎn)生具有不同事件類型的Socket。在服務端，有一段I/O多路復用程序，將其置入隊列之中。然后文件事件分派器依次去隊列中取，轉(zhuǎn)發(fā)到不同的事件處理器中。
需要說明的是，這個I/O多路復用機制，Redis還提供了Select、Epoll、Evport、Kqueue等多路復用函數(shù)庫，大家可以自行去了解。
四、Redis的數(shù)據(jù)類型及各自使用場景
看到這個問題，是不是覺得它很基礎(chǔ)？其實筆者也這么覺得。然而根據(jù)面試經(jīng)驗發(fā)現(xiàn)，至少80%的人答不上這個問題。建議在項目中用到后，再類比記憶，體會更深，不要硬記。基本上，一個合格的程序員五種類型都會用到：
1、String
這個其實沒什么好說的，最常規(guī)的Set/Get操作，Value可以是String也可以是數(shù)字，一般做一些復雜的計數(shù)功能的緩存。
2、Hash
這里Value存放的是結(jié)構(gòu)化的對象，比較方便的就是操作其中的某個字段。筆者在做單點登錄的時候，就是用這種數(shù)據(jù)結(jié)構(gòu)存儲用戶信息，以CookieId作為Key，設置30分鐘為緩存過期時間，能很好地模擬出類似Session的效果。
3、List
使用List的數(shù)據(jù)結(jié)構(gòu)，可以做簡單的消息隊列的功能。另外還有一個就是，可以利用Lrange命令，做基于Redis的分頁功能，性能極佳，用戶體驗好。
4、Set
因為Set堆放的是一堆不重復值的集合，所以可以做全局去重的功能。
為什么不用JVM自帶的Set進行去重？因為我們的系統(tǒng)一般都是集群部署，使用JVM自帶的Set比較麻煩，難道為了做一個全局去重，再起一個公共服務？太麻煩了。
另外，就是利用交集、并集、差集等操作，可以計算共同喜好、全部的喜好、自己獨有的喜好等功能。
5、Sorted Set
Sorted Set多了一個權(quán)重參數(shù)Score，集合中的元素能夠按Score進行排列。可以做排行榜應用，取TOP N操作。另外，Sorted Set還可以用來做延時任務。最后一個應用就是可以做范圍查找。
五、Redis的過期策略及內(nèi)存淘汰機制
這個問題其實相當重要，從這個問題就可以看出來到底Redis有沒有用到位。比如，你Redis只能存5G數(shù)據(jù)，可是你寫了10G，那會刪5G的數(shù)據(jù)。怎么刪的？這個問題思考過么？還有，你的數(shù)據(jù)已經(jīng)設置了過期時間，但是時間到了，內(nèi)存占用率還是比較高，有思考過原因么?
Redis采用的是定期刪除+惰性刪除策略。
為什么不用定時刪除策略？
定時刪除，用一個定時器來負責監(jiān)視Key，過期則自動刪除。雖然內(nèi)存及時釋放，但是十分消耗CPU資源。在大并發(fā)請求下，CPU要將時間應用在處理請求，而不是刪除Key，因此沒有采用這一策略。
定期刪除+惰性刪除是如何工作的呢？
定期刪除，Redis默認每個100ms檢查是否有過期的Key，有過期Key則刪除。需要說明的是，Redis不是每個100ms將所有的Key檢查一次，而是隨機抽取進行檢查（如果每隔100ms，全部Key進行檢查，Redis豈不是卡死）。因此，如果只采用定期刪除策略，會導致很多Key到時間沒有刪除。
于是，惰性刪除派上用場。也就是說在你獲取某個Key的時候，Redis會檢查一下，這個Key如果設置了過期時間，那么是否過期了？如果過期了此時就會刪除。
采用定期刪除+惰性刪除就沒其他問題了么？
不是的，如果定期刪除沒刪除Key。然后你也沒及時去請求Key，也就是說惰性刪除也沒生效。這樣，Redis的內(nèi)存會越來越高，那么就應該采用內(nèi)存淘汰機制。
在Redis.conf中有一行配置：
# maxmemory-policy volatile-lru
該配置就是配內(nèi)存淘汰策略的：
- Noeviction：當內(nèi)存不足以容納新寫入數(shù)據(jù)時，新寫入操作會報錯。應該沒人使用吧；
- Allkeys-lru：當內(nèi)存不足以容納新寫入數(shù)據(jù)時，在鍵空間中，移除最近最少使用的Key。推薦使用，目前項目在用這種；
- Allkeys-random：當內(nèi)存不足以容納新寫入數(shù)據(jù)時，在鍵空間中，隨機移除某個key，應該也沒人使用吧；
- Volatile-lru：當內(nèi)存不足以容納新寫入數(shù)據(jù)時，在設置了過期時間的鍵空間中，移除最近最少使用的Key。這種情況一般是把Redis既當緩存又做持久化存儲的時候才用。不推薦；
- Volatile-random：當內(nèi)存不足以容納新寫入數(shù)據(jù)時，在設置了過期時間的鍵空間中，隨機移除某個Key。依然不推薦；
- Volatile-ttl：當內(nèi)存不足以容納新寫入數(shù)據(jù)時，在設置了過期時間的鍵空間中，有更早過期時間的Key優(yōu)先移除。不推薦。
PS：如果沒有設置Expire的Key，不滿足先決條件（Prerequisites）；那么Volatile-lru、Volatile-random和Volatile-ttl策略的行為，和Noeviction（不刪除）基本上一致。
六、Redis和數(shù)據(jù)庫雙寫一致性問題
一致性問題是分布式常見問題，還可以再分為最終一致性和強一致性。數(shù)據(jù)庫和緩存雙寫，就必然會存在不一致的問題，想要回答這個問題，就要先明白一個前提：如果對數(shù)據(jù)有強一致性要求，就不能放緩存。我們所做的一切，只能保證最終一致性。
另外，我們所做的方案其實從根本上來說，只能說降低不一致發(fā)生的概率，無法完全避免。因此，有強一致性要求的數(shù)據(jù)不能放緩存。
在互聯(lián)網(wǎng)領(lǐng)域，緩存由于其高并發(fā)和高性能的特性，已經(jīng)在項目中被廣泛使用。在讀取緩存方面，大家沒什么疑問，都是按照下圖的流程來進行業(yè)務操作。
但是在更新緩存方面，對于更新完數(shù)據(jù)庫，是更新緩存呢，還是刪除緩存；又或者是先刪除緩存，再更新數(shù)據(jù)庫，其實大家存在很大的爭議。
從理論上來說，給緩存設置過期時間，是保證最終一致性的解決方案。這種方案下，我們可以對存入緩存的數(shù)據(jù)設置過期時間，所有的寫操作以數(shù)據(jù)庫為準，對緩存操作只是盡最大努力即可。也就是說如果數(shù)據(jù)庫寫成功，緩存更新失敗，那么只要到達過期時間，則后面的讀請求自然會從數(shù)據(jù)庫中讀取新值然后回填緩存。因此，接下來討論的思路不依賴于給緩存設置過期時間這個方案。
在這里，我們討論三種更新策略：
- 先更新數(shù)據(jù)庫，再更新緩存；
- 先刪除緩存，再更新數(shù)據(jù)庫；
- 先更新數(shù)據(jù)庫，再刪除緩存。
應該沒有人會問我，為什么沒有先更新緩存，再更新數(shù)據(jù)庫這種策略吧？
1、先更新數(shù)據(jù)庫，再更新緩存
這套方案，大家是普遍反對的。為什么呢？有如下兩點原因。
- 原因一（線程安全角度）
同時有請求A和請求B進行更新操作，那么會出現(xiàn)
- 線程A更新了數(shù)據(jù)庫；
- 線程B更新了數(shù)據(jù)庫；
- 線程B更新了緩存；
- 線程A更新了緩存。
這就出現(xiàn)請求A更新緩存應該比請求B更新緩存早才對，但是因為網(wǎng)絡等原因，B卻比A更早更新了緩存。這就導致了臟數(shù)據(jù)，因此不考慮。
- 原因二（業(yè)務場景角度）
有如下兩點：
- 如果你是一個寫數(shù)據(jù)庫場景比較多，而讀數(shù)據(jù)場景比較少的業(yè)務需求，采用這種方案就會導致，數(shù)據(jù)壓根還沒讀到，緩存就被頻繁地更新，浪費性能；
- 如果你寫入數(shù)據(jù)庫的值，并不是直接寫入緩存的，而是要經(jīng)過一系列復雜的計算再寫入緩存。那么，每次寫入數(shù)據(jù)庫后，都再次計算寫入緩存的值，無疑是浪費性能的。顯然，刪除緩存更為適合。
接下來討論的就是爭議最大的，是先刪緩存、再更新數(shù)據(jù)庫，還是先更新數(shù)據(jù)庫、再刪緩存的問題。
二、先刪除緩存，再更新數(shù)據(jù)庫
該方案會導致不一致的原因是，同時有一個請求A進行更新操作，另一個請求B進行查詢操作。那么會出現(xiàn)如下情形：
- 請求A進行寫操作，刪除緩存；
- 請求B查詢發(fā)現(xiàn)緩存不存在；
- 請求B去數(shù)據(jù)庫查詢得到舊值；
- 請求B將舊值寫入緩存；
- 請求A將新值寫入數(shù)據(jù)庫。
上述情況就會導致不一致的情形出現(xiàn)。而且，如果不采用給緩存設置過期時間策略，該數(shù)據(jù)永遠都是臟數(shù)據(jù)。
那么，如何解決呢？采用延時雙刪策略。
偽代碼如下：
public void write(String key,Object data){
redis.delKey(key);
db.updateData(data);
Thread.sleep(1000);
redis.delKey(key);
}
轉(zhuǎn)化為中文描述就是：
- 先淘汰緩存；
- 再寫數(shù)據(jù)庫（這兩步和原來一樣）；
- 休眠1秒，再次淘汰緩存。
這么做，可以將1秒內(nèi)所造成的緩存臟數(shù)據(jù)，再次刪除。
那么，這個1秒是怎么確定的，具體該休眠多久呢？
針對上面的情形，讀者應該自行評估自己的項目的讀數(shù)據(jù)業(yè)務邏輯的耗時。然后寫數(shù)據(jù)的休眠時間則在讀數(shù)據(jù)業(yè)務邏輯的耗時基礎(chǔ)上，加幾百ms即可。這么做的目的，就是確保讀請求結(jié)束，寫請求可以刪除讀請求造成的緩存臟數(shù)據(jù)。
如果你用了MySQL的讀寫分離架構(gòu)怎么辦？
在這種情況下，造成數(shù)據(jù)不一致的原因如下，還是兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作。
- 請求A進行寫操作，刪除緩存；
- 請求A將數(shù)據(jù)寫入數(shù)據(jù)庫了；
- 請求B查詢緩存發(fā)現(xiàn)，緩存沒有值；
- 請求B去從庫查詢，這時，還沒有完成主從同步，因此查詢到的是舊值；
- 請求B將舊值寫入緩存；
- 數(shù)據(jù)庫完成主從同步，從庫變?yōu)樾轮怠?/li>
上述情形，就是數(shù)據(jù)不一致的原因。還是使用雙刪延時策略。只是，睡眠時間修改為在主從同步的延時時間基礎(chǔ)上，加幾百ms。
采用這種同步淘汰策略，吞吐量降低怎么辦？
那就將第二次刪除作為異步的。自己起一個線程，異步刪除。這樣，寫的請求就不用沉睡一段時間再返回。這么做，加大吞吐量。
第二次刪除，如果刪除失敗怎么辦？
這是個非常好的問題，因為第二次刪除失敗，就會出現(xiàn)如下情形。還是有兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作，為了方便，假設是單庫：
- 請求A進行寫操作，刪除緩存；
- 請求B查詢發(fā)現(xiàn)緩存不存在；
- 請求B去數(shù)據(jù)庫查詢得到舊值；
- 請求B將舊值寫入緩存；
- 請求A將新值寫入數(shù)據(jù)庫；
- 請求A試圖去刪除請求B寫入對緩存值，結(jié)果失敗了。
這也就是說，如果第二次刪除緩存失敗，會再次出現(xiàn)緩存和數(shù)據(jù)庫不一致的問題。
如何解決呢？
具體解決方案，且看筆者下文對第三種更新策略的解析。
三、先更新數(shù)據(jù)庫，再刪除緩存
國外提出了一個緩存更新套路，名為《Cache-Aside pattern》[1]，其中就指出：
- 失效：應用程序先從cache取數(shù)據(jù)，沒有得到，則從數(shù)據(jù)庫中取數(shù)據(jù)，成功后，放到緩存中；
- 命中：應用程序從cache中取數(shù)據(jù)，取到后返回；
- 更新：先把數(shù)據(jù)存到數(shù)據(jù)庫中，成功后，再讓緩存失效。
另外， Facebook也在論文《Scaling Memcache at Facebook》[2]中提出，他們用的也是先更新數(shù)據(jù)庫，再刪緩存的策略。
這種情況不存在并發(fā)問題么？
不是的。假設這會有兩個請求，一個請求A做查詢操作，一個請求B做更新操作，那么會有如下情形產(chǎn)生：
- 緩存剛好失效；
- 請求A查詢數(shù)據(jù)庫，得一個舊值；
- 請求B將新值寫入數(shù)據(jù)庫；
- 請求B刪除緩存；
- 請求A將查到的舊值寫入緩存。
如果發(fā)生上述情況，確實是會發(fā)生臟數(shù)據(jù)。
然而，發(fā)生這種情況的概率又有多少？
發(fā)生上述情況有一個先天性條件，就是步驟3的寫數(shù)據(jù)庫操作比步驟2的讀數(shù)據(jù)庫操作耗時更短，才有可能使得步驟4先于步驟5。可是，大家想想，數(shù)據(jù)庫的讀操作的速度遠快于寫操作的（不然做讀寫分離干嘛，做讀寫分離的意義就是因為讀操作比較快，耗資源少），因此步驟3耗時比步驟2更短，這一情形很難出現(xiàn)。
假設，有人非要抬杠，有強迫癥，一定要解決怎么辦？
如何解決上述并發(fā)問題？
首先，給緩存設有效時間是一種方案。其次，采用策略二里給出的異步延時刪除策略，保證讀請求完成以后，再進行刪除操作。
還有其他造成不一致的原因么？
有的，這也是緩存更新策略二和緩存更新策略三都存在的一個問題，如果刪緩存失敗了怎么辦，那不是會有不一致的情況出現(xiàn)么。比如一個寫數(shù)據(jù)請求，然后寫入數(shù)據(jù)庫了，刪緩存失敗了，這會就出現(xiàn)不一致的情況了。這也是緩存更新策略二里留下的最后一個疑問。
如何解決？
提供一個保障的重試機制即可，這里給出兩套方案。
- 方案一：
如下圖所示：
流程如下所示：
- 更新數(shù)據(jù)庫數(shù)據(jù)；
- 緩存因為種種問題刪除失敗；
- 將需要刪除的key發(fā)送至消息隊列；
- 自己消費消息，獲得需要刪除的key；
- 繼續(xù)重試刪除操作，直到成功。
然而，該方案有一個缺點，對業(yè)務線代碼造成大量的侵入。于是有了方案二，在方案二中，啟動一個訂閱程序去訂閱數(shù)據(jù)庫的binlog，獲得需要操作的數(shù)據(jù)。在應用程序中，另起一段程序，獲得這個訂閱程序傳來的信息，進行刪除緩存操作。
- 方案二：
流程如下圖所示：
- 更新數(shù)據(jù)庫數(shù)據(jù)；
- 數(shù)據(jù)庫會將操作信息寫入binlog日志當中；
- 訂閱程序提取出所需要的數(shù)據(jù)以及key；
- 另起一段非業(yè)務代碼，獲得該信息；
- 嘗試刪除緩存操作，發(fā)現(xiàn)刪除失敗；
- 將這些信息發(fā)送至消息隊列；
- 重新從消息隊列中獲得該數(shù)據(jù)，重試操作。
備注說明：上述的訂閱binlog程序在MySQL中有現(xiàn)成的中間件叫Canal，可以完成訂閱binlog日志的功能。至于Oracle中，筆者目前不清楚有沒有現(xiàn)成中間件可以使用。另外，重試機制，筆者采用的是消息隊列的方式。如果對一致性要求不是很高，直接在程序中另起一個線程，每隔一段時間去重試即可，這些大家可以靈活自由發(fā)揮，只是提供一個思路。
本文其實是對目前互聯(lián)網(wǎng)中已有的一致性方案，進行了一個總結(jié)。對于先刪緩存、再更新數(shù)據(jù)庫的更新策略，還有方案提出維護一個內(nèi)存隊列的方式，筆者看了一下，覺得實現(xiàn)異常復雜，沒有必要，因此沒有在文中給出。最后，希望大家有所收獲。
七、應對緩存穿透和緩存雪崩問題
關(guān)于“如何應對緩存穿透和緩存雪崩”這兩個問題，說句實在話，一般中小型傳統(tǒng)軟件企業(yè)很難碰到。如果有大并發(fā)的項目，流量有幾百萬左右，這兩個問題一定要深刻考慮：
1、應對緩存穿透
緩存穿透，即黑客故意去請求緩存中不存在的數(shù)據(jù)，導致所有的請求都懟到數(shù)據(jù)庫上，從而數(shù)據(jù)庫連接異常。
解決方案：
- 利用互斥鎖，緩存失效的時候，先去獲得鎖，得到鎖了，再去請求數(shù)據(jù)庫，沒得到鎖，則休眠一段時間重試；
- 采用異步更新策略，無論Key是否取到值，都直接返回。Value值中維護一個緩存失效時間，緩存如果過期，異步起一個線程去讀數(shù)據(jù)庫，更新緩存，需要做緩存預熱（項目啟動前，先加載緩存）操作；
- 提供一個能迅速判斷請求是否有效的攔截機制，比如利用布隆過濾器，內(nèi)部維護一系列合法有效的Key，迅速判斷出，請求所攜帶的Key是否合法有效，如果不合法，則直接返回。
2、應對緩存雪崩
緩存雪崩，即緩存同一時間大面積的失效，這個時候又來了一波請求，結(jié)果請求都懟到數(shù)據(jù)庫上，從而導致數(shù)據(jù)庫連接異常。
解決方案：
- 給緩存的失效時間加上一個隨機值，避免集體失效；
- 使用互斥鎖，但是該方案吞吐量明顯下降了；
- 雙緩存。我們有兩個緩存，緩存A和緩存B。緩存A的失效時間為20分鐘，緩存B不設失效時間，自己做緩存預熱操作。然后細分以下幾個小點：a. 從緩存A讀數(shù)據(jù)庫，有則直接返回；b. A 沒有數(shù)據(jù)，直接從B讀數(shù)據(jù)，直接返回，并且異步啟動一個更新線程；c. 更新線程同時更新緩存A和緩存B。
八、如何解決Redis并發(fā)競爭Key問題
這個問題大致就是同時有多個子系統(tǒng)去Set一個Key。這個時候要注意什么呢？本人提前百度了一下，發(fā)現(xiàn)大家思考的答案基本都是推薦用Redis事務機制。但本人不推薦使用Redis的事務機制。因為我們的生產(chǎn)環(huán)境，基本都是Redis集群環(huán)境，做了數(shù)據(jù)分片操作。你一個事務中有涉及到多個Key操作的時候，這多個Key不一定都存儲在同一個Redis-Server上。因此，Redis的事務機制，十分雞肋。
解決方法如下：
如果對這個Key操作不要求順序
這種情況下，準備一個分布式鎖，大家去搶鎖，搶到鎖就做Set操作即可，比較簡單。
如果對這個Key操作要求順序
假設有一個Key1，系統(tǒng)A需要將Key1設置為ValueA，系統(tǒng)B需要將Key1設置為ValueB，系統(tǒng)C需要將Key1設置為ValueC。期望按照Key1的Value值按照 ValueA→ValueB→ValueC的順序變化。這種時候我們在數(shù)據(jù)寫入數(shù)據(jù)庫的時候，需要保存一個時間戳。假設時間戳如下：
- 系統(tǒng)A Key 1 {ValueA 3:00}
- 系統(tǒng)B Key 1 {ValueB 3:05}
- 系統(tǒng)C Key 1 {ValueC 3:10}
那么，假設這會系統(tǒng)B先搶到鎖，將Key1設置為{ValueB 3:05}。接下來系統(tǒng)A搶到鎖，發(fā)現(xiàn)自己的ValueA的時間戳早于緩存中的時間戳，那就不做Set操作了。以此類推。
其他方法，比如利用隊列，將Set方法變成串行訪問也可以。總之，靈活變通。
完畢！~！！
