首先解釋下標(biāo)題，可能命名不是那么嚴(yán)謹(jǐn)吧，大致的定義如下：
sometimes you are in a situation where you want to read a record, check what is in it, and depending on that update the record. The problem is that between the time you read a row and perform the update, someone else might have updated the row, so your update might be based on outdated information.
摘要一下：進(jìn)程A讀取了某行R，進(jìn)行時(shí)間較長的計(jì)算操作，在這個(gè)計(jì)算過程中B對(duì)行R進(jìn)行了更改。A計(jì)算完畢后，若直接寫入，會(huì)覆蓋B的修改結(jié)果。此時(shí)應(yīng)令A(yù)寫入失敗。
以下的討論整理自下述兩個(gè)頁面，表示感謝！
http://www.ngdata.com/hbase-row-locks/
http://redis.io/topics/transactions
一個(gè)最簡單、直接的思路是：Transaction + Row Lock。類似于傳統(tǒng)DBMS的思路：首先開啟行鎖，新建一個(gè)Transaction，隨后進(jìn)行各種操作，最后commit，最最后解除行鎖。看似很簡單，也沒什么Bug，但注意，若計(jì)算時(shí)間較長，整個(gè)DB就掛起了，不能執(zhí)行任何操作。
BigTable的Paper中，對(duì)這類問題進(jìn)行了討論。
總體來說解決思路有三：
1、Rowlock，但是對(duì)于HBase來說，RegionLock更成熟。因?yàn)镽owLock會(huì)長時(shí)間（從Transction開始到更新）占用一個(gè)線程。當(dāng)并發(fā)量很大的時(shí)候，系統(tǒng)會(huì)掛掉。。。
2、ICV即HBase的incrementColumnValue()方法。
3、CAS即HBase的checkAndPut方法：在Put之前，先檢查某個(gè)cell的值是否和value一樣，一樣再Put。注意，這里檢查條件的Cell和要Put的Cell可以是不同的column，甚至是不同的row。。。
綜上在HBASE中，使用上述CAS方法是較好的解決方案。
上面說了HBase，再來看一個(gè)輕量級(jí)的Redis：
Redis也支持事務(wù)，具體見：http://redis.io/topics/transactions
通過MULTI開始一個(gè)事務(wù)，EXEC執(zhí)行一個(gè)事務(wù)。在兩者之間可以“執(zhí)行”多個(gè)命令，但并未被實(shí)際執(zhí)行，而是被Queue起來，直到EXEC再一起執(zhí)行。Redis保證：在一個(gè)事務(wù)EXEC的過程中，不會(huì)處理其他任何Client的請求（會(huì)被掛起）。注意這里是EXEC鎖，而不是整個(gè)MULTI鎖。所以并發(fā)性能還是有保障的。
為了支持Paper中CAS方案，Redis提供了WATCH命令：
So what is WATCH really about? It is a command that will make the EXEC conditional: we are asking Redis to perform the transaction only if no other client modified any of the WATCHed keys. Otherwise the transaction is not entered at all.
已經(jīng)很顯然了，更多具體的，讀上述網(wǎng)頁的文檔吧。