memcached提供了2個命令 gets + cas。gets取出資料的時候，同時返回版本號；修改之後, cas回去的時候，會比較該版本號和伺服器上最新的版本號。如果不等，則cas失敗。
redis提供了watch命令，如下所示：
watch key1 //修改資料之前，執行watch，意思監聽此key
multi
set key1 foo //如果別的客戶端在此期間修改了該key1，此處更新將失敗
exec
multi
get foo
...incr foo
exec
另外，由於redis是單執行緒的，因此事務裡面的多條語句執行時，不會被打斷。
我們都知道, memcached內部是多執行緒的，而redis是單執行緒的。多執行緒好理解，但redis為什麼要搞成單執行緒呢？
個人認為，有以下幾個原因：
（1）redis有各種複雜的資料結構list, has, set。也就是說，對於乙個(key, value)，value的型別可以是list, hash, set。在實際應用場景中，很容易出現多個客戶端對同乙個key的這個複雜的value資料結構進行併發操作，如果是多執行緒，勢必要引入鎖，而鎖卻是效能殺手。
相比較而言，memcached只有簡單的get/set/add操作，沒有複雜資料結構，在互斥這個問題上，沒有redis那麼嚴重。
（2）對於純記憶體操作來說，cpu並不是瓶頸，瓶頸在網路io上。所以即使單執行緒，也很快。另外，如果要利用多核的優勢，可以在乙個機器上開多個redis例項。
樂觀鎖以及樂觀鎖的實現
樂觀鎖以及樂觀鎖的實現 一 為什麼需要鎖 併發控制 在多使用者環境中，在同一時間可能會有多個使用者更新相同的記錄，這會產生衝突。這就是著名的併發性問題。典型的衝突有 1.丟失更新 乙個事務的更新覆蓋了其它事務的更新結果，就是所謂的更新丟失。例如 使用者a把值從6改為2，使用者b把值從2改為6，則使用...
樂觀鎖以及樂觀鎖的實現
樂觀鎖介紹 樂觀鎖 optimistic locking 相對悲觀鎖而言，樂觀鎖假設認為資料一般情況下不會造成衝突，所以在資料進行提交更新的時候，才會正式對資料的衝突與否進行檢測，如果發現衝突了，則讓返回使用者錯誤的資訊，讓使用者決定如何去做。那麼我們如何實現樂觀鎖呢，一般來說有以下2種方式 1.使...
悲觀鎖樂觀鎖
1 悲觀鎖，正如其名，它指的是對資料被外界 包括本系統當前的其他事務，以及來自外部系統的事務處理 修改持保守態度，因此，在整個資料處理過程中，將資料處於鎖定狀態。悲觀鎖的實現，往往依靠資料庫提供的鎖機制 也只有資料庫層提供的鎖機制才能真正保證資料訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無...