淘汰还是更新？先操作谁？架构怎么优？——一切的起点
缓存设计三连问：淘汰还是更新？先操作谁？架构怎么优？（1/14）
淘汰还是更新？先操作谁？架构怎么优？——一切的起点
标签： 缓存实践
缓存架构与实践系列（14 篇）：缓存设计三连问、Cache Aside Pattern、缓存一致性、redis/memcache 内核、无锁缓存——从原理到工程实战。
缓存，究竟是淘汰，还是修改？（2/14）
修改 value 的成本，对比一次 cache miss 的代价——三个案例算到底
修改 value 的成本，对比一次 cache miss 的代价——三个案例算到底
究竟先操作缓存，还是数据库？（3/14）
两个方向、两种原子性破坏场景，推演到最后有标准答案
两个方向、两种原子性破坏场景，推演到最后有标准答案
Cache Aside Pattern：旁路缓存的行业最佳实践（4/14）
读实践、写实践、两个为什么——固化下来的模式，照着用就完了
读实践、写实践、两个为什么——固化下来的模式，照着用就完了
主从延时导致缓存不一致：缓存双淘汰（5/14）
主从同步延时的间隙里，脏数据总会悄悄入缓存——那就异步地再淘汰一次
主从同步延时的间隙里，脏数据总会悄悄入缓存——那就异步地再淘汰一次
数据库与缓存不一致，怎么办？（6/14）
引入缓存后不一致会被放大——订阅 binlog，在从库同步完成后再淘汰一次
引入缓存后不一致会被放大——订阅 binlog，在从库同步完成后再淘汰一次
余额并发扣减，能用 redis 事务吗？（7/14）
WATCH/MULTI/EXEC 本质是乐观锁 CAS——比 MySQL 没有额外优势，高性能的代价是数据易失
WATCH/MULTI/EXEC 本质是乐观锁 CAS——比 MySQL 没有额外优势，高性能的代价是数据易失
选 redis 还是 memcache？源码怎么说（8/14）
业务需求决定技术选型——了解「所以然」比「选择谁」更重要
业务需求决定技术选型——了解「所以然」比「选择谁」更重要
memcache 内核：slab、chunk 与懒淘汰（9/14）
从知其然到知其内核：slab 分级、chunk 分配、hash 扩容与懒淘汰
从知其然到知其内核：slab 分级、chunk 分配、hash 扩容与懒淘汰
进程内 KV 存储选型：LevelDB（10/14）
Google 出品的进程内 KV 存储库：特点、局限与性能数据
Google 出品的进程内 KV 存储库：特点、局限与性能数据