※ 引述《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，这个问题也是会出现