超大流量分布式系统架构解决方案：人人都是架构师2.0

每一章都是重点，每一章都是解决方案

1、货真价实的大型网站架构演变过程中核心技术难题的解决方案；

2、全书所有的解决方案分享均来自作者真实的一线亲身经历；

3、大规模服务化场景下，企业实施服务治理的相关难点、痛点问题全面剖析；

4、大规模线上全链路压测落地方案剖析，寻找系统薄弱环节，有指导的在大促前进行容量规划和性能化，让系统坚如磐石；

5、大流量限流/削峰案例全面剖析，尽可能将用户流量挡在系统上游，避免对交易系统产生较大冲击；

6、深度剖析大促抢购场景下，爆款商品、热点数据的读/写优化案例；

7、数据库Sharding案例全面剖析，为大家深入讲解如何有效提升RDBMS的并行处理能力和检索效率；

7、线上故障排查经验分享，Sandbox源码剖析；

8、全书所有解决方案均可结合实际的业务场景来进行落地；

9、全书少理论，重实操；

10、大型网站架构一定是简单和清晰的，而不是炫技般的复杂化，解决问题采用直接的方式直击要害才是真正见效的。

本书共5章，每一章的内容几乎都是独立的，大家完全可以有选择性地阅读。第1章以大规模服务化架构作为全书的开篇，主要介绍了分布式系统架构的演变过程，以及在大规模服务调用场景下，如何实施服务治理。第2章重点介绍了在大促前夕，如何在线上实施全链路压测，以及有指导性地进行容量规划和性能优化，让系统坚如磐石。第3章重点介绍了如何有效地对流量实施管制，若采用合理且有效的方式管制住峰值流量，使其井然有序地对系统进行访问，则在任何情况下，系统就都能稳定运行。第4章重点介绍了在大促抢购的场景下，如何解决高并发读和高并发写等核心技术难题。第5章详细地介绍了关系型数据库的架构演变过程，还重点介绍了在实际的订单业务场景下，如何保证数据的最终一致性。

云集基础架构负责人，技术委员会委员，经历了云集架构从0到1的蜕变，见证了云集业务的井喷式增长，拥有大量高并发、大流量，以及海量数据处理的实战经验，负责云集基础技术平台的架构设计和中间件研发等工作，热衷于开源技术，常年游走在GitHub上。

大型网站技术发展了这么多年，各种资料和书籍层出不穷、屡见不鲜，但是，这本关于超大流量分布式系统架构的书，会让大家眼前一亮。本书从高并发的网站架构实践案例和大家关心的典型技术场景出发，将作者及其团队实践中的思考、心得与方法，完整地呈现出来。本书可以帮助大家解决大型网站架构演变过程中遇到的诸多技术难题。
李智慧 《大型网站技术架构：核心原理与案例分析》作者

本书融入了作者多年的经验和积累，实践和理论并重。本书不仅从宏观视角带大家领略了互联网系统架构的演进过程，而且点出大家在超大流量分布式系统架构中必然会遇到的诸多痛点，如服务治理、全链路压测、流量管控、大促抢购、分库分表等，更是深入各个具体业务，给出详尽的解决方案。书中讲述的每个解决方案不仅包含了经验的提炼和思考，而且均可直接指导线上生产。这是一本值得研读和收藏的书，相信大家读后会受益匪浅。
陈斯 某上市电商企业CTO

目录
第 1 章 大系统小做――大规模服务化架构 1
1．1 分布式系统的架构演变过程 1
1．1．1 单机架构 3
1．1．2 集群架构 4
1．1．3 垂直拆分业务子系统 6
1．1．4 服务化架构演进 8
1．1．5 服务化与微服务架构的区别 9
1．1．6 集群与分布式的区别 10
1．1．7 前后端分离架构演进 11
1．1．8 API 网关服务 14
1．1．9 分布式多活数据中心架构演进 17
1．2 服务治理需求 20
1．2．1 服务化与 RPC 协议 20
1．2．2 基于服务治理框架 Dubbo 实现服务化 22
1．2．3 警惕因超时和重试引起的系统雪崩 26
1．2．4 为什么需要实施服务治理 28
1．2．5 关于服务化后的分布式事务问题 31
1．2．6 注册中心性能瓶颈方案 32
1．2．7 分布式多活架构下的服务就近调用方案 34
1．3 服务治理之调用链 35
1．3．1 Google 的 Dapper 论文简介 36
1．3．2 调用链的实现方案 38
1．3．3 基于非侵入式运行期 AOP 方案实现数据采集上报 48
1．3．4 调配采样率 57
1．4 本章小结 58
第 2 章 大促备战核弹――全链路压测 59
2．1 为什么要在线上实施全链路压测 60
2．2 业务系统如何区分压测流量 63
2．2．1 压测流量打标方案 63
2．2．2 在链路上下文信息中传递压测标记 65
2．2．3 外部第三方接口走 Mock 67
2．2．4 压测数据的隔离方案 68
2．3 如何发起大规模的压测流量 69
2．3．1 数据构造平台 69
2．3．2 自研全链路压测军演系统的一些经验分享 71
2．4 本章小结 74
第 3 章 削峰填谷――流控方案 75
3．1 为什么需要限流 76
3．2 限流方案 79
3．2．1 常见的限流算法 80
3．2．2 基于 Guava 实现平均速率限流 83
3．2．3 接入层限流方案 86
3．2．4 应用层限流――限时抢购限流方案 89
3．3 基于时间分片的削峰方案 92
3．3．1 活动分时段进行实现削峰 93
3．3．2 通过答题验证实现削峰 93
3．4 基于消息队列的解耦、削峰、最终一致性方案 94
3．4．1 基于消息队列实现解耦 95
3．4．2 常见消息中间件的使用 96
3．4．3 基于消息队列的一些典型案例 113
3．5 本章小结 116
第 4 章 大促抢购核心技术难题――读/写优化方案 117
4．1 缓存技术简介 118
4．1．1 本地缓存 119
4．1．2 本地缓存的痛点 121
4．1．3 神秘的 off-heap 技术 122
4．2 高性能分布式缓存 Redis 127
4．2．1 基于 Jedis 客户端操作 Redis 128
4．2．2 基于 RedisCluster 模式实现 Sharding 129
4．3 同一热卖商品高并发读难题 133
4．3．1 多级缓存方案 135
4．3．2 缓存穿透思考 139
4．3．3 RedisCluster 模式下的读/写分离方案 140
4．4 同一热卖商品高并发写难题 143
4．4．1 InnoDB 引擎的行锁问题 143
4．4．2 基于 Redis 乐观锁的库存扣减方案 145
4．4．3 嵌入 Lua 脚本的库存扣减方案149
4．4．4 基于 AliSQL 数据库提升并发写性能 155
4．5 本章小结 161
第 5 章 星罗棋布――分库分表方案 162
5．1 关系数据库的架构演变 163
5．1．1 数据库读/写分离 163
5．1．2 数据库垂直分库 164
5．1．3 数据库水平分库与水平分表 165
5．1．4 MySQL Sharding 与 MySQL Cluster 的区别166
5．2 Sharding 中间件 167
5．2．1 常见的 Sharding 中间件对比 167
5．2．2 Shark 简介 169
5．2．3 Shark 的架构模型 170
5．2．4 使用 Shark 实现分库分表后的数据路由任务 171
5．2．5 分库分表后所带来的影响 178
5．2．6 全局唯一 SequenceID 解决方案 179
5．2．7 基于 Solr 满足多维度的复杂条件查询 182
5．2．8 关于分布式事务 183
5．3 数据库的 HA 方案 184
5．3．1 基于配置中心实现主备切换 185
5．3．2 基于 Keepalived 实现主备切换 186
5．3．3 保障主备切换过程中的数据一致性 188
5．4 订单业务冗余表需求 190
5．4．1 冗余表的实现方案 190
5．4．2 数据最终一致性方案 192
5．5 本章小结 195
附录 196
后记223

云集在成立的 4 年多时间里，业务飞速发展，经常上演各种脉冲式销量神话，比如，一个单品单日销售额达 3 亿多元。对我们的技术团队而言，这是一个快速成长、颇具挑战的机会。翔龙是一个非常热爱技术且沉醉于技术的人，其带领的基础架构团队，在应对高并发、大流量等方面发挥了很大的作用，也积累了宝贵的一线经验。本书的所有

内容，并不是对架构理论的泛泛而谈，而是云集技术架构从 0 到 1 演变的宝贵实践经验。我崇尚技术，也推崇技术，业务能够推动技术迅速成长，技术反过来也能推动业务加速增长。

我从本书的内容中感受到：超大流量分布式系统的架构必然是简单和清晰的，是需要不断 PDCA（计划、执行、查验与行动）的，也在不断的迭代、演进中。我相信，本书所呈现的宝贵实战经验对大家大有裨益，会为大家的实际工作带来诸多帮助。

肖尚略

云集 CEO

前言

本书的创作初衷

任何一本书，都是一个用于承载和传递知识的载体，读者可以从中探寻自己想要的答案。对我而言，书本就是带我领略奇妙计算机世界的最快途径。之所以想创作一本与大型网站架构相关的书籍，是因为最近几年我在实际的开发过程中经历了太多的技术难题，每当我和我的技术团队尝试解决这些问题之前，都会先尝试从市面上现有的技术书籍中寻求解决方案；但事与愿违，目前市面上高歌架构理论的读物居多，真正讲解大型网站架构解决方案的书籍却寥寥无几。对于这块领域的空白，我想尝试着去创作，把我这些年的经历和经验写出来，让更多人受益，毕竟架构是需要落地的，否则便是一纸空谈。

本书内容重点

本书一共 5 章，而每一章的内容几乎都是独立的，大家完全可以有选择性地进行阅读。在第 1 章中，笔者特意选择了以服务化架构作为全书的开篇，结合笔者多年来的实践经验，从 0 到 1 为大家讲解了大型网站架构的演变过程，以及在大规模服务化场景下企业应该如何实施服务治理。

验证系统所能够承受的最大负载是否接近于预期，是否经得住大流量的冲击，绝非是一件易事。有过分布式系统开发经验的同学都应该非常清楚，简单对某个接口、子系统进行压测，并不能够准确探测出系统整体的容量水位，这是由分布式系统与生俱来的复杂性决定的，并且对环境、目标都有着极为严苛的要求。近些年，全链路压测似乎备受追捧，基本上各大互联网企业，比如，阿里、京东等都会在大促前夕利用自研的“军演系统”在线上进行压测实战演练，其目的就是确保大促来临时核心链路的整体稳定。在第 2 章中，笔者重点为大家介绍了如何在大促前夕对

线上环境实施全链路压测，以及如何做到有指导地在大促前进行容量规划和性能优化，让系统坚如磐石。

像天猫这种级别的大型电商网站，主要的技术挑战是来自庞大的用户规模所带来的大流量、高并发，以及海量数据，在“双 11”“双 12”等大促场景下尤为明显。如果不对流量进行合理管制，肆意放任大流量冲击系统，那么将会导致一系列的问题出现，比如一些可用的连接资源被耗尽、分布式缓存的容量被撑爆、数据库吞吐量降低，最终必然会导致系统产生雪崩效应。在第 3 章中，笔者重点讲解了如何有效地对流量实施管制，只要我们能够采用合理且有效的方式管制住峰值流量，使其井然有序地对系统进行访问，那么无论在任何情况下，系统都能够稳定运行。

热点数据的大并发读/写操作，可谓是秒杀、限时抢购等场景下最核心的 2 个技术难题。针对热点数据的大并发读操作，尽管我们可以通过分布式缓存来提升系统的 QPS，但是缓存系统的单点容量还是存在上限的，一旦超过临界水位，分布式缓存容易被瞬间击穿。而热点数据的大并发写操作，势必会下潜至数据库，那么这就会引起大量的线程相互竞争 InnoDB 的行锁，并发越大时，等待的线程就越多，这会严重影响数据库的 TPS，导致 RT 线性上升，最终导致系统发生雪崩。在第 4 章中，笔者会重点为大家讲解大促抢购核心技术难题的一系列解决方案。

在第 5 章中，笔者详细为大家讲解了在互联网场景下关系型数据库的架构演变过程。当大家清楚为什么关系型数据库需要进行分库分表后，笔者又实战演示了如何使用 Shark 中间件来完成数据路由，以及业务实施分库分表后的诸多注意事项和数据库的 HA 方案等。最后，还结合了实际的订单业务场景为大家重点讲解了如何保证数据的最终一致性。

本书面向的读者

本书适用于任何对大型网站架构感兴趣的架构师、开发人员，以及运维人员。我尽量用通俗易懂的文字描绘书中的各章知识点，更是结合了实际的业务场景引入了大量的真实案例，相信阅读完本书后你将能有所裨益。

读者讨论

由于能力有限，书中难免会出现一些错误或者不准确的地方，大家可以通过邮件 gao_xianglong@sina.com 将问题反馈给我，我会及时予以答复。

致谢

首先我要感谢我的妻子，是你的支持和鼓励才让我有了继续创作的勇气。每当我头痛欲裂思绪全无时，你的陪伴点燃了我在每个凌晨的斗志，我爱你。

其次，本书的顺利出版离不开孙学瑛老师及博文视点团队的共同努力，感谢你们的辛苦付出。最后，还要感谢那些一路支持我的读者朋友们，谢谢你们。