摘要：第四篇打算作为系列最后一篇，这里尝试谈谈缓存的一些并发交互场景，包括与数据库（特指 RDBMS）交互，和一些独立的高并发场景相关补充处理方案（若涉及具体应用同样将主要以Redis举例）。 另见：分布式系统之缓存的微观应用经验谈（三）（数据分片和集群篇） （https://yq.aliyun.com/u/autumnbing） （https://www.cnblogs.com/bsfz/） 一、简单谈下缓存和数据库的交互流程 为了便于后面的相关讨论，这里约定文中的数据库（Database）均指传统的 RDBMS，使用DB标识，同时需区别于缓存（Cache）里的DB划分空间。 我在早前一篇缓存设计细节的文章里，有阐述关于 Cache 自身 CURD 时的一些具体细节，而这里将结合DB，就 DB 和 Cache 之间的并行 CURD 操作进行一些讨论。当然，这里面在交互层面上是一定会涉及到分布式事务（Distributed Transaction）相关的一致性话题，但为了避免表述出现模糊和不必要的边界放大，这里我尽可能剥离开来 阅读全文

摘要：第三篇这里尝试谈谈缓存的数据分片（Sharding）以及集群（Cluster）相关方案（具体应用依然以Redis 举例）另见：分布式系统之缓存的微观应用经验谈（二） 【主从和主备高可用篇】（ https://www.cnblogs.com/bsfz/） 一、先分析缓存数据的分片（Sharding） 缓存在很多时候同 RDBMS类似，解决数据的分布式存储的基础理念就是把整个数据集按照一定的规则（切分算法）映射到多个节点（node）中，每个 node负责处理整体数据的一个子集。给缓存作 Sharding 设计，围绕基础数据的存储、通信、数据复制和整合查询等，很多时候比较类似 RDBMS中的水平分区（Horizontal Partitioning），事实上很多点在底层原理上是保持一致的。在缓存的分区策略中，最常见的是基于哈希的各种算法。 阅读全文

摘要：第二篇这里尝试聊聊缓存的主从（Master-Slave），以及相关的高可用实现（High-Availability）（具体应用依然以Redis 举例） 1.1 关于主从分离的取舍观点 是否采用主从分离（这里特指读写分离），个人目前的观点是，它在很多场景里，并不是一个很好的方案。 我更想说的是，甚至任何涉及数据同步的环节，包括DB读写分离、缓存数据复制等等，如果没有特殊场景强制要求，那么尽量规避。 虽然在互联网的一些应用场景里，读远大于写，也演变了一套看似完整的读写实践方案，大体归为“主写从读”、“一写多读”、“多读多写”。但本质上，在大多数环境下，均存在一定缺陷，无论是基于服务底层的数据同步延迟，还是开发中的逻辑切换，都带来了一些可能本末倒置的隐患和生硬。同时，在集群模式下读写分离成本实在过高，不仅仅是一致性问题，必须慎重考虑和权衡。 阅读全文

摘要：前言 近几个月一直在忙些琐事，几乎年后都没怎么闲过。忙忙碌碌中就进入了2018年的秋天了，不得不感叹时间总是如白驹过隙，也不知道收获了什么和失去了什么。最近稍微休息，买了两本与技术无关的书，其一是Yann Martel 写的《The High Mountains of Portugal》（葡萄牙的高山），发现阅读此书是需要一些耐心的，对人生暗喻很深，也有足够的留白，有兴趣的朋友可以细品下。好了，下面回归正题，尝试写写工作中缓存技术相关的一些实战经验和思考。 正文 在分布式Web程序设计中，解决高并发以及内部解耦的关键技术离不开缓存和队列，而缓存角色类似计算机硬件中CPU的各级缓存。如今的业务规模稍大的互联网项目，即使在最初beta版的开发上，都会进行预留设计。但是在诸多应用场景里，也带来了某些高成本的技术问题，需要细致权衡。本系列主要围绕分布式系统中服务端缓存相关技术，也会结合朋友间的探讨提及自己的思考细节。文中若有不妥之处，恳请指正。 第一篇这里尝试尽可能详细的谈谈缓存自身的基础设计应用，以及相关的操作细节等（具体应用主要以Redis 举例）。 阅读全文