逆流而上：阿里巴巴技术成长之路

适读人群：本书主要面向互联网技术从业人员和在校师生，使读者能够通过此书基本了解阿里在各技术领域的能力，学习在如此规模下可能出现

《逆流而上：Alibaba技术成长之路》是Alibaba集团荣耀背后的技术血泪史。本书通过分享业务运行过程中各个领域发生的典型“踩坑”案例，帮助大家快速提升自我及团队协作，学习到宝贵的处理经验及实践方案，为互联网生产系统的稳定共同努力。从基础架构、中间件、数据库、云计算、大数据等技术领域中不断积累经验，颠覆技术瓶颈，不断创新以适应不断增长的需求。

《逆流而上：Alibaba技术成长之路》主要面向互联网技术从业人员和在校师生，使读者能够通过此书基本了解阿里在各技术领域的能力，学习在如此规模下可能出现的问题以及解决方案的探讨和沉淀分享。

Alibaba集团成长集编委会

由Alibaba集团不同业务线及不同技术领域内的人员组成的虚拟组织。技术人员都知道软件开发过程中的八二原则，理解大多数问题发生在何处，发生的原因，如何解决，变得尤为重要。Alibaba集团业务飞速发展，技术人员积累了大量丰富的线上问题排查及解决的案例和经验。

成长集编委会从中挑选了一些优秀的技术案例，侧重于对问题的还原和分析。我们希望，曾经踩过的坑都能具有其意义和使命，而后来者通过学习前人的经验，防微杜渐，快速成长。

第1 章 基础架构高可用  

1.1 明察秋毫，域名解析排查技巧  

1.2 智能定位，网络端到端静默丢包点迅速锁定 

1.3 灵活调度，对接运营商网络流量的容灾策略  

1.4 抽丝剥茧，深挖云盘挂起背后的真相 

1.5 存储的底线，SSD 数据不一致  

第2 章 中间件使用常见隐患与预防 

2.1 高并发“热点”缓存数据快速“退火”  

2.2 自我保护，让系统坚如磐石  

2.3 机房容灾，VIPServer 软负载流量调度实例  

2.4 山洪暴发，高流量触发Tomcat bug 引起集群崩溃 

第3 章 数据库常见问题 

3.1 性能杀手，SQL 执行计划 

3.2 波谲云诡，数据库延迟 

3.3 风暴来袭，AliSQL 连接池调优  

3.4 防患于未然，ORM 规约变更案例  

3.5 云数据库，SQL 优化经典案例 

第4 章 业务研发经典案例 

4.1 幂等控制，分布式锁超时情况和业务重试的并发  

4.2 另类解法，分布式一致性  

4.3 大道至简，从故障模型的边界状态切换到原始状态  

4.4 疑案追踪，JSON 序列化不一致  

4.5 从现象到本质，不保证顺序的Class.getMethods JVM 实现 

4.6 破解超时迷局，浅析启动初期load 飙高问题  

4.7 洞悉千丝万缕，浅谈JIT 编译优化的误区  

第5 章 运行管理域稳定性建设  

5.1 洞若观火，让故障无处遁形  

5.2 体系化思考，高效解决运营商问题  

5.3 以战养兵，以故障演练提升系统稳定性 

序言：

2017年7月27日，阿里巴巴集团市值超越4040亿美元，成为亚洲。回首过去18年的历程，伴随着阿里业务从电商快速成长到覆盖金融、云计算、物流等众多行业，是阿里技术人在基础设施、操作系统、中间件、云等各个领域孜孜不倦的探索、创新和实践。

在每一个技术领域，我们尝试过业务问题多种不同的解法，无论是新技术还是成熟的解决方案，我们都充分验证，直至完全掌握。但在我们看来，宝贵的并不是我们终采用某种技术或方案的决定，而是大家在探索中遇到的问题以及解决办法，是对每种技术深入研究过程中积累的经验，是基于对技术深入理解的基础之上进行调优和定制的实践。

随着互联网的浪潮日益高涨，我们看到越来越多的技术人开始经历相似过程，因为单纯“拿来主义”的技术方案已经无法满足各个行业层出不穷的业务创新，唯有完全掌握技术才能使之贴合业务需求，更好的服务客户，而掌握技术的关键就在于解决它在实际应用中产生的问题。所以，我们把阿里落地各类技术过程中遇到过的问题以及解决方案分享给各位同行，希望对大家开阔思路、少走弯路能够有所帮助。

本书总结了阿里巴巴集团的技术团队在基础架构、中间件、数据库、业务开发以及运行管理等领域的经典实践，从采用的方案、遇到的问题、解决方法以及对未来的思考等方面，全面介绍技术实践的细节。在编写方面，本书注重实操，包含代码示例、排查思路及处理流程，以便于读者快速应用到自己的工作中。

非常感谢阿里各条业务线的技术同学，在百忙之中安排时间总结、整理并撰写案例，用他们的经验反哺技术同行，这也是阿里技术人为互联网技术不断的超越贡献的一点微薄之力。

沈乘黄(神庭)

阿里巴巴全球运行指挥中心总监

这本《逆流而上：阿里巴巴技术成长之路》总结了近年来阿里巴巴集团在重要领域中遇到的故障和排查方法。从故障中得到的教训，剖析出来的架构缺陷，折射出来的实现问题以及运维过程中的疏忽和错误都是很真实的，很具有说服力。他山之石，可以攻玉，希望为广大开发和运维工程师带来帮助。

—— 阿里云资深总监 吴结生

古语说：前人栽树，后人乘凉。本书创作旨在让历史的经验传承下去，帮助到更多的人。它汇集了阿里巴巴集团各个BU技术人员在日常工作中所遇到的典型踩坑案例，这些案例全部来自线上生产实践，涉及基础设施、中间件、数据库、业务开发以及稳定性建设，基本涵盖了阿里巴巴所有的技术兵种，这是一本非常全面的技术踩坑实践书，具有很重要的参考意义。

—— 阿里云研究员 褚霸

阿里巴巴的技术人员日常的研发运维过程，就是不断和新问题斗智斗勇的过程，我们会鼓励把遇到的挑战和问题总结出来，所以在这个过程中积累了大量的总结资料，这些资料有些总结到了产品里，成为架构、系统的一部分，有些不断被学习变成了其他更多同事的新能力。

—— 中间件技术部研究员 小邪

在我带领阿里巴巴GOC（全球运行指挥中心）团队期间，天天面对不断发生的大小故障，尤其是重复发生的故障。而此书恰恰是在这种思考之下所采取的行动之一。成功难以模仿，教训可以学习。每篇文章的背后都是血淋淋的教训，值得每一个技术人员好好阅读。

—— 菜鸟资深专家 王乐

第1 章

基础架构高可用

互联网、电子商务、云计算、大数据等领域都离不开基础设施建设，基础设施的建设包含从服务器到IDC、网络等一系列的过程。技术日新月异变化的过程，也给基础设施的建设带来了巨大的挑战。如何用研发能力解决基础设施稳定性是基础架构不断提升核心竞争力的关键。本章从线上案例入手，从基础架构角度介绍了问题排查思路和创新设计概念，希望给读者带来启迪。

1.1 明察秋毫，域名解析排查技巧

背景

网站服务是现在众多互联网服务中应用广泛的服务之一，而且中国的网络环境更为复杂，几乎每个应用都会使用到域名。域名在互联网应用中是非常重要的一环，万一出现问题可能会导致整个网站无法访问，并且由于各地DNS（Domain Name System，域名系统）缓存，有时候恢复解析所需时间会比较长。本节针对几种典型的域名解析问题，做了简单的排查

思路介绍，以期与读者交流。域名解析的过程

用户使用终端（电脑、手机、Pad 等）上网时，电脑会设置一组DNS（即缓存DNS，又叫Local DNS）作为一层“代理”、“缓存”，为当地局域

网或其他用户提供高性能的解析迭代查询。这个缓存DNS 一般是在用户连上网时自动分配的， 不需要手工配置。当用户访问网站时， 如www.example.com，会向缓存 DNS 发送example 对应的地址的查询请求。当缓存DNS 收到请求后，如果其有相应的缓存且没过期，则直接响应；否则，向根DNS、域DNS、主域名对应的权威DNS 或更下级的权威DNS

进行查询，直到查询到终的地址，然后返回给客户端。对网站管理者（更准确地说，是域名的管理者）来说，需要为域名设置解析，将域名指向自己的网络服务器。购买了域名，一般会使用注册商的DNS（即将注册商提供的DNS 服务器作为购买的域名的权威DNS 服务

器），或者使用第三方的DNS。如果使用注册商的DNS，设置解析的流程会比较便捷；但如果使用第三方的DNS，需要在第三方添加域名、解析记录，然后在注册商处修改域名的DNS 作为第三方提供的DNS 名字。

在上述描述域名解析的过程中，有两种DNS 的角色：

（1）缓存DNS，又叫Local DNS 或Cache DNS，一般是由网络接入服务提供商在近上网用户端做的缓存DNS 服务器，主要用于迭代查询的缓存，其中的数据均来自向上级的查询得到，本身并无实际的权威数据，这既增加了解析速度，又减少了对权威DNS 的查询数量，

就好比是数据库中的Memcache。

（2）权威DNS，又叫Authority DNS。由域名管理者负责管理，或委托其他DNS 服务提供商进行管理，其中的记录均是由负责本域的管理员添加进来的。权威DNS 是由上到下一级级授权的，如根DNS（ROOT DNS）将各个后缀授权到各个后缀管理机构的域DNS

（即注册局的DNS），而各个域DNS 中又有指向下级域对应的DNS。

如何判断是否是解析异常

网站无法访问有多种原因，如网络异常、服务器异常、网站配置不正确、代理服务器异常等。

当你访问网站时，如果打开的页面内容和预期的不同，或报错信息中含有“resolve”相关字样，或提示“找不到网站服务器”时，就应该怀疑是不是解析方面的问题了。排查解析问题用到的基本方法是用dig（或nslookup，本文以dig 为例来说明，nslookup 相关命令请参考其对应的帮助文档）看能否正常解析到终的IP。__如果无法获取到终的IP，或者获取到终的IP 不是网站的实际IP（这个由域名网站管理员判断），就是解析异常了。如下是一个正常的解析（部分域名用example.com/bar.com/bar.net 等指代，部分IP 地址使用1.1.1.1、2.1.1.1、2.2.2.2 等代替，后续类同）。