2019-11-271. Write-Back 的稳定性是靠中间件来处理的，kafka 是个不错的选择。
2 读缓存还是数据库，还有个常用套路就是先查依赖(通常依赖的消耗更小，例如只在存储引擎层就可以搞定)
3 画图工具不错。作者回复: 你好，能否进一步解释一下第 2 条？
1 1
2019-11-10请问下，Cache-Aside部分中，那个极小概率出现，设计中一般忽略的情形是怎样的？作者回复: R1 是读请求，R2 是更新请求：
1. R1 读缓存，发现已失效，就从数据库里读出旧值 Va；
2. R2 更新请求，将数据库里的值从 Va 更新为新值 Vb，并将缓存标记为失效；
3. R1 将 Va 写回缓存，于是缓存中就有了一个过期值 Va，而数据库中是 Vb。
我说这个情况极小概率出现的原因有这样几个：
1. 需要缓存自身过期和数据更新几乎同时发生；
2. 需要 R1 在读出旧值以后，R2 的更新操作全部完成，R1 才将旧值写入缓存，而众所周知从数据库中读数据并写入缓存的操作速度，通常情况下要远高于数据库更新并将缓存标记为失效的操作，因为写操作需要的要求更高，比如需要使用事务等等。当然，这说的是“通常情况”，并不是 说“一定”，不过出问题的概率是非常非常小的。 1 1
2019-11-25不知道自己想的对不对，高并发的时候会考虑用wirte-back（例如游戏中的某时刻抽奖） ，批量的时候用write/read through 等比较好作者回复: 就是 trade-off，write-back 带来高吞吐量的同事，会牺牲一定的一致性（数据库和缓存可能不一致）和持久性（可能存在掉电数据丢失），你说的“高并发的时候”，如果可以做出这样的牺牲，那么就可以考虑这个方法
- 2019-11-061. 在接下来的项目中会考虑用到 cache-aside 这种模式设计，cache 用的是 Redis，DB 用的是 MongoDB，感觉这种模式比较常见，相对来说不会那么复杂
2. 根据文中的分析，cache-aside 比较稳健些，导致数据不一致的风险也相对较低，但是对于更新和写操作来说的话，相对较慢，原因也很好解释，这里面涉及了 cache 的访问、DB 的更新、以及 cache 的更新；write-back 的话对于更新和写操作来说效率会更高，吞吐量也更大，但是数据不一致的风险较大。效率和安全，这里又是一个权衡的话题（有点类似 HTTP 和 HTTPS）。个人觉得这两种模式差别主要在更新和写操作上，这就需要根据业务来分析了，如果业务中 95% 以上都是读请求，并且也没有那么高的性能要求，那么其实 cache-aside 就完全够用了，但是对于某些写高于读的系统（比如日志系统），而且要求高性能，那么可以考虑使用 write-back 这种模式展开 
2019-10-28数据写入缓存故而这就是日志的问题啊：现在其实许多数据库模型同样宕机就OVER，纠其根本原因还是许多的不严谨；日志是灾难恢复的主要手段。
数据库内部查询同样是先看缓存是否有，没有再去重新查找；毕竟缓存速度>内存>磁盘。异步最大的难题是是事务性：这块非关系型数据库处理的都不好。 3