※ 引述《sean72 (.)》之銘言：
: 問題一
: 如果使用memcache
: 寫db的時候
: 1. 先invalidate cache 再寫db
: 2. 先寫db 再invaludate cache
: 3. update cache 然後 update db
: 4. update db 然後 update cache
: 問題二
: 還有一個問題，關於db consistency
: 如果用relational db, such as MySQL , Master Slave
: write to master,
: read from slave
: 寫到master之後(假設user update一個url link)，並且invalid cache
: 這時候replication還沒完成，假設有5秒的延遲
: 這個時候如果來了一個read，cache miss
: 按照邏輯，這時候應該slave read , 但這時候slave data是舊的
: 那我的client要怎麼處理?
其實你兩個問題是同一個問題
不管是 cache 或是 slave 甚至是 client-side 看到的狀態
只能說是其中一個 valid state 的值
不能當作之後 transaction 發生時候的當下值
想想看 ACID 在講什麼
A -> Atomic 每個一 transaction 都是不可分割的
I -> Isolated: Transaction 之間是互相隔離的。
而 cache 跟 slave 中讀到的資料
當作 transaction 中讀到的值
顯然都會不符合這些特性。
所以要怎麼做?
只有 master 發生的 transaction 才算數。
要更新資料的時候，用一個 transaction 包住所有的 read/write
至於 cache 跟 slave read 只是效能的輔助而已
不能當作最後參考的值
舉個例子，
如果要去網路銀行轉帳
假設目前看到餘額是10000元
過了一個小時再轉帳5000元，餘額一定夠嗎?
當然不一定，因為介面上看到的10000元只能說是曾經有10000元
如果客戶偷偷的去外面的 ATM 提款
再回到網銀去轉帳，
那裡面有可能餘額不足
合理後端作法是每一次的轉帳，都要在 transaction 中
去看戶頭是不是有那麼多錢
再決定是否這次交易成功
回到 1 的問題, 我是覺得 2 的答案比較好
至於 2 的問題不是問題，應用程式邏輯要在 transaction 再包一次 read
畢竟即使不是 master/slave，這個問題也是會出現