首先解釋下標題，可能命名不是那么嚴謹吧，大致的定義如下：
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.
摘要一下：進程A讀取了某行R，進行時間較長的計算操作，在這個計算過程中B對行R進行了更改。A計算完畢后，若直接寫入，會覆蓋B的修改結果。此時應令A寫入失敗。
以下的討論整理自下述兩個頁面，表示感謝！
http://www.ngdata.com/hbase-row-locks/
http://redis.io/topics/transactions
一個最簡單、直接的思路是：Transaction + Row Lock。類似于傳統(tǒng)DBMS的思路：首先開啟行鎖，新建一個Transaction，隨后進行各種操作，最后commit，最最后解除行鎖?？此坪芎唵危矝]什么Bug，但注意，若計算時間較長，整個DB就掛起了，不能執(zhí)行任何操作。
BigTable的Paper中，對這類問題進行了討論。
總體來說解決思路有三：
1、Rowlock，但是對于HBase來說，RegionLock更成熟。因為RowLock會長時間（從Transction開始到更新）占用一個線程。當并發(fā)量很大的時候，系統(tǒng)會掛掉。。。
2、ICV即HBase的incrementColumnValue()方法。
3、CAS即HBase的checkAndPut方法：在Put之前，先檢查某個cell的值是否和value一樣，一樣再Put。注意，這里檢查條件的Cell和要Put的Cell可以是不同的column，甚至是不同的row。。。
綜上在HBASE中，使用上述CAS方法是較好的解決方案。
上面說了HBase，再來看一個輕量級的Redis：
Redis也支持事務，具體見：http://redis.io/topics/transactions
通過MULTI開始一個事務，EXEC執(zhí)行一個事務。在兩者之間可以“執(zhí)行”多個命令，但并未被實際執(zhí)行，而是被Queue起來，直到EXEC再一起執(zhí)行。Redis保證：在一個事務EXEC的過程中，不會處理其他任何Client的請求（會被掛起）。注意這里是EXEC鎖，而不是整個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.
已經很顯然了，更多具體的，讀上述網頁的文檔吧。