目录一、先认识这位"大管家"：Tair 是什么，又不是什么（一）一句话定位与三个基本概念1、从淘宝内部缓存到云上产品的演进2、存储引擎：一套集群框架，三种仓内陈设3、namespace、version、expire：三把钥匙（二）使用场景：哪里该用，哪里慎用1、适合使用的场景2、不适合使用的场景3、只从缓存和存储角度给出的选型建议（三）与 Redis 的区别二、基本局限性：在承诺之前先读免责条款（一）一致性边界：复制与迁移都有窗口1、异步复制的丢写窗口2、迁移与切表的时间窗3、对业务意味着什么（二）查询能力与数据模型的限制（三）容量与热度：扩容治不了热点1、单节点容量有上限2、单 key 热度扩容无效（四）运维与生态成本1、迁移与维护复杂2、社区与生态有限三、Java 中的使用：从能跑通到能上线（一）引入客户端并创建实例1、引入客户端依赖2、创建客户端实例（二）执行数据操作1、存储键值对2、获取键值对3、删除键值对4、错误处理和异常处理5、关闭 Tair 客户端（三）一个可以上线的封装：SafeCache1、读路径：区分结果，有限重试2、写路径：用版本号守住并发3、对照表过期：客户端如何被纠正四、实现原理：一本对照表撑起的分布式（一）基本架构：四个角色1、ConfigServer：轻量的账房2、DataServer：真正的粮仓3、Client：按账取粮的伙计4、InvalidServer：敲锣的驿卒（二）数据存储和读取1、一次 get 的完整旅程2、对照表的结构3、引擎内部：MDB 与 LDB 的仓内陈设（三）数据的复制和迁移1、复制2、迁移的两种触发3、迁移的过程（四）分布式架构实现1、负载均衡：建表的三条规矩2、分布式处理：为什么是虚拟桶（五）系统可用性（六）系统可靠性（七）解决数据同步与迁移时的一致性问题1、只拷全量就切表2、追 redo 日志后切表3、客户端持有旧表（八）系统可扩展性（九）处理热点数据1、DataServer 上的热点统计过程2、读热点方案2.1 服务端设计2.2 客户端设计3、写热点方案3.1 服务端设计3.2 客户端设计五、对照与延展：从开源 Tair 到今天的工程实践（一）路由思想的三种形态1、客户端分片2、中心化对照表3、去中心化槽位与代理（二）热点治理的五层防线（三）一份上线前检查清单1、接入与配置2、编码与容错3、演练与监控六、总结参考文章与链接干货分享，感谢您的阅读！大促零点前的半小时，绝对是一个技术团队最安静也最紧张的时刻。商品详情、库存、会话、限购计数，这些数据在平日里被数据库稳稳托住，可一旦流量翻上几十倍，数据库就像一口被饥饿怪兽围住的井——再深也经不起所有人同时来打水。于是几乎所有大型业务都会在数据库前面再放一层"高速存储"：它要足够快，快到毫秒以内；要足够大，大到能装下整个热数据集；还要足够稳，稳到某台机器倒下时业务几乎无感。阿里巴巴的 Tair，就是在这样的压力下长出来的一套分布式键值存储。它最早服务于淘宝内部，后来开源，再后来演变成云上兼容 Redis 协议的企业级内存数据库。很多人对它的印象停留在"阿里版 Redis"上，这其实只说对了一小半。真正值得琢磨的，是它用"一本账"管住"千座仓"的设计：一张由 ConfigServer 维护的对照表，决定了每一个 key 落在哪个桶、每个桶住在哪台 DataServer；扩容、宕机、迁移、热点，几乎所有分布式难题，最后都要回到这本账上来解决。这次我们想做的，是把 Tair 从"会用"讲到"讲得清"。我们先认清它的定位、适用边界以及与 Redis 的差别，再老老实实读一遍它的"免责条款"；然后写一套能上线的 Java 接入代码，把返回码、超时、重试、版本号这些容易被示例代码略过的细节补齐；接着深入实现原理——对照表怎么建、数据怎么复制和迁移、迁移时怎么保证一致、热点怎么识别和打散；最后把开源 Tair 放到今天的云上 Tair 与 Redis 生态中做一次对照。文中的数字都来自随文附带的三
)
