就问题一的部分
从文章中的描述看起来是需要 strong data consistency
面对这种状况有种可行的做法是采用 distributed lock
(可参考 https://redis.io/topics/distlock)
但负面效益是会降低 throughput
流程大概是
1. user1 抢 write lock
(放把 key 在 cache 内做 distributed write lock，表明该值正在异动)
2. user1 清除 cache & 更新 db
3. user2 发现 write lock 存在，用 watch 或 polling 方式
等待该 lock 消失 (设定 timeout)，若消失就 r/w cache & db
4. user1 步骤 2
成功: db, cache 更新后，撤销 write lock
失败: 撤销 write lock 或 retry
由于无法假定步骤 4 一定会成功，因此要看错误状况来决定处理方式
目前想到两种可能作法
1. 撤销 write lock，让 user2 拿到旧资料。user1 返回错误看 application
怎么处理。这种状况以抢票例子来说，就是 user2 买到票而 user1 哭哭
2. 持续 retry 但设定 timeout，至少其他使用者不必持续等待
3. 若非 db 或 schema 异常，retry 直到成功为止。
但通常这种做法蛮糟糕的，会让多数使用者一直等待导致不耐
这边要看 business 选哪种做法对公司影响较小，没有绝对优劣
但通常在微服务架构(分布式系统)通常会采用 2
以上是个人经验，相信版上有其他更资深的大大有更好的观点可以讨论
※ 引述《sean72 (.)》之铭言：
: 问题一
: 如果使用memcache
: 写db的时候
: 1. 先invalidate cache 再写db
: 2. 先写db 再invaludate cache
: 3. update cache 然后 update db
: 4. update db 然后 update cache
: 我以为这个动作有标准做法，但是问了在亚马和snapchat的朋友
: 也看了几个tech talk 竟然答案不同，请问大家怎么分析?
: 我上了一个网络课程的课，他说2是最佳解
: case3 & 4 如果某一个update fail都会造成cache里面脏数据的情况
: case1:
: user1 invalidate cache, while updating db(未完成)
: user2 此时读资料，cache miss，去读数据库，得到旧数据，
: 并用旧数据update cache
: user1 完成db更新
: 此时cache存著旧数据，db新数据，cache脏数据
: case2:
: user1 update db (未完成)
: user2 此时读资料，在cache读了旧资料，离开
: user1 finish db and update cache
: 以后的user都可以读到最新数据，只有user2读了旧数据，但仅只一次，无伤大雅
: 问题二
: 还有一个问题，关于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要怎么处理?
: reddit founder 他说当初他们碰到这情况
: 很多slave里面的link都是404 very bad user experience
: 所以他写db的时候，同时写到cache
: https://youtu.be/cDL7ny_hvio?t=50s
: 但如果同时写DB & cache 如果其中一个操作失败了，那就造成脏数据了，不是吗?
: 又如果
: 我采用问题一的方式 先写db 然后invalidate cache,
: write to master db , 5 sec replication time
: 这时候一个read进来, cache miss, read from slave取得旧数据
: 顺便update cache
: 五秒后slave完成replica，但这时候也造成了数据不一致。
: replication latency的问题该怎么解决呢?
: 感谢