※ 引述《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，這個問題也是會出現 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.228.228.205 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1533476410.A.1B4.html