※ 引述《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/cn.aspx?n=bbs/Soft_Job/M.1533476410.A.1B4.html