亿级流量系统架构设计与实战

本书涵盖了亿级用户应用后台核心技术和系统架构设计思路，在内容结构上分为三大篇：架构知识篇（第1～3章），作为全书的基础知识篇，首先介绍后台的关键组件构成以及机房的搭建思路，然后介绍后台在应对高并发的读/写请求时通用的处理手段，最后介绍如何通过通用的服务治理手段来保障后台的高质量运行；基础服务设计篇（第4～6章），主要讲解基础服务的架构设计，这里选取的基础服务几乎是所有互联网后台都需要的专门系统，包括唯一ID生成器、用户登录服务和海量推送系统；核心服务设计篇（第7～13章），主要讲解在常见的社交互动场景中所需核心服务的架构设计，包括内容发布系统、通用计数系统、排行榜服务、用户关系服务、Timeline Feed服务、评论服务和IM服务。

本书的适用人群包括计算机相关专业的学生、希望寻求大厂软件开发工程师岗位的求职者，以及各信息技术类公司的后台研发工程师、架构师和技术管理人员。

李琛轩

资深后台研发工程师，拥有8年互联网后台研发经验，现任某全球社交产品后台子方向负责人。从事互联网社交产品领域的研发与架构设计工作多年，从业以来负责过多个知名产品的后台开发工作，相继深耕于消息队列、服务发现系统、服务治理、分布式事务、高并发架构设计、全球多活等技术领域。

亿级用户应用

如今市面上的互联网应用几乎都在追求用户规模，这不仅仅是因为只有用户规模庞大才能让产品扬名立万，更重要的是对于应用出品方来说，亿级用户会为公司带来巨大收益。

◎ 广告收入：亿级用户应用拥有巨大的“人口红利”，在应用内投放产品广告非常容易带来极大的产品曝光量和极高的产品转化率，所以会有非常可观的广告收入。

◎ 商业价值：亿级用户意味着应用的品牌拥有巨大的影响力，会天然吸引其他企业，促成联名合作。

◎ 产品带动：一旦公司拥有用户量级巨大的产品，就可以非常方便地借助它为新产品做引流和推广，以进一步扩大公司的产品规模。

鉴于亿级用户为公司带来了极高的实用价值和商业价值，针对亿级用户进行应用架构设计的工程师备受市场青睐。亿级用户意味着高并发，很多公司会在工程师招聘要求中注明“有高并发系统设计经验”，或者在面试过程中频繁考查候选人的高并发系统设计能力。所以，对于研发工程师来说，拥有高并发系统设计的知识体系是十分必要的技术素养。

本书主题

如果你是大厂的研发工程师，那么你可能每天都要面对系统怎样才能服务好亿级用户的问题；如果你所在的公司目前尚未拥有亿级用户，那么你可能会想象，若公司产品有更多用户使用的话，需要应用什么技术，或者你希望拿到大厂 Offer，却焦虑于自己没有高并发系统设计经验；如果你是计划成为研发工程师的学生，那么你可能虽然认真做了很多课程设计，但仍会好奇自己的作品对应的工业级设计应该是怎样的。

如此种种，笔者决定编写一本涵盖亿级用户应用后台常见系统设计的书，希望将自己的经验与你分享。那么，亿级用户应用后台的通用技术是什么？无非就是如何构建机房、使用哪些技术栈、如何高效处理高并发请求和如何保证后台服务的高可用等。

亿级用户应用后台有哪些通用系统（或称服务）？我们只需看那些拥有数亿名用户的应用都有哪些相似功能就能轻易得出结论，比如国民级应用或知名应用：微信、淘宝、微博、抖音、快手、小红书、百度贴吧、bilibili、爱奇艺、网易云音乐、知乎、钉钉等。这些应用的用户活跃度极高，它们几乎都支持这些功能：用户注册与登录、通知消息、用户发帖、对内容点赞、关注与粉丝、评论、私信与群聊、排行榜等，每个功能都与专门的后台服务相对应，所以这些服务都是非常通用的。

本书会详细讲解以上罗列的种种内容。

内容概要

本书在内容结构上可以分为三大篇。

架构知识篇（第1～3章）：作为全书的基础知识篇，首先介绍后台的关键组件构成以及机房的搭建思路，然后介绍后台在应对高并发的读/写请求时通用的处理手段，最后介绍如何通过通用的服务治理手段来保障后台的高质量运行。

基础服务设计篇（第4～6章）：主要讲解基础服务的架构设计，这里选取的基础服务几乎是所有互联网后台都需要的专门系统，包括唯一ID生成器、用户登录服务和海量推送系统。

核心服务设计篇（第7～13章）：主要讲解在常见的社交互动场景中所需核心服务的架构设计，包括内容发布系统、通用计数系统、排行榜服务、用户关系服务、Timeline Feed服务、评论服务和IM服务。

特别要说明的是，本书不会专门对具体的存储系统如MySQL、Redis等的原理进行深入剖析，而是会在行文中用到它们的地方再做介绍，以便在采用相应的技术解决问题时实现理论与实践的良好结合，使读者加深对理论知识的理解。

适用人群

本书的适用人群包括计算机相关专业的学生、希望寻求大厂软件开发工程师岗位的求职者，以及各信息技术类公司的后台研发工程师、架构师和技术管理人员。希望读者通过对本书内容的学习，逐渐掌握亿级用户应用后台的设计思路和方法，提高架构设计能力和高并发意识，最终设计出性能更高、更稳定的高可用系统。

必要声明

必须承认，本书介绍的内容与笔者所在公司深耕的技术方向是比较匹配的。对于本书介绍的每一个服务，笔者所在公司都具备优秀的服务设计，并积累了服务于数亿名用户的架构经验。不过，基于保护公司知识产权与机密的原则，笔者在每章的服务设计要素中都回避了公司的独创性设计，只提供了业界公开或公认的设计思路。你在仔细推敲细节的过程中可能会发现个中内容并不能展示全貌，这是因为不同的公司对这些内容有不同的技术处理方式，笔者只能在大方向上做一些思路指引，还望各位读者主动思考，并请见谅。

另外，笔者不希望为了凑篇幅而贴上大段累赘的代码和无意义的系统配置过程，所以在内容编写上会屏蔽系统配置，只在适当的环境下贴上代码，致力于使每段文字都只聚焦于读者真正在意的干货。

架构知识篇

第1章 大型互联网公司的基础架构

1.1 引言：单机房的内部架构

1.2 客户端连接机房的技术1：DNS

1.2.1 DNS的意义

1.2.2 域名结构

1.2.3 域名服务器

1.2.4 域名解析过程

1.3 客户端连接机房的技术2：HTTP DNS

1.3.1 DNS存在的问题

1.3.2 HTTP DNS的原理

1.3.3 HTTP DNS实践

1.4 接入层的技术演进

1.4.1 Nginx

1.4.2 LVS

1.4.3 LVS+Nginx接入层的架构

1.5 服务发现

1.5.1 注册与发现

1.5.2 可用地址管理

1.5.3 地址变更推送

1.6 RPC服务

1.7 存储层技术：MySQL

1.7.1 关系型数据库

1.7.2 MySQL的优势

1.7.3 高可用架构1：主从模式

1.7.4 高可用架构2：MHA

1.7.5 高可用架构3：MMM

1.7.6 高可用架构4：MGR

1.8 存储层技术：Redis

1.8.1 高可用架构1：主从模式

1.8.2 高可用架构2：哨兵模式

1.8.3 高可用架构3：集群模式

1.8.4 高可用架构4：中心化集群架构

1.9 存储层技术：LSM Tree

1.9.1 LSM Tree的原理

1.9.2 读/写数据的流程

1.10 存储层技术：其他NoSQL数据库

1.11 消息中间件技术

1.11.1 通信模式与用途

1.11.2 Kafka的重要概念和原理

1.11.3 Kafka的高可用

1.12 多机房：主备机房

1.13 多机房：同城双活

1.13.1 存储层改造

1.13.2 灵活实施

1.13.3 分流与故障切流

1.13.4 两地三中心

1.14 多机房：异地多活

1.14.1 架构要点

1.14.2 MySQL DRC的原理

1.14.3 Redis DRC的原理

1.14.4 分流策略

1.14.5 数据复制链路

1.15 本章小结

第2章 通用的高并发架构设计

2.1 高并发架构设计的要点

2.1.1 形成高并发系统的必要条件

2.1.2 高并发系统的衡量指标

2.1.3 高并发场景分类

2.2 高并发读场景方案1：数据库读/写分离

2.2.1 读/写分离架构

2.2.2 读/写请求路由方式

2.2.3 主从延迟与解决方案

2.3 高并发读场景方案2：本地缓存

2.3.1 基本的缓存淘汰策略

2.3.2 W-TinyLFU策略

2.3.3 缓存击穿与SingleFlight

2.4 高并发读场景方案3：分布式缓存

2.4.1 分布式缓存选型

2.4.2 如何使用Redis缓存

2.4.3 缓存穿透

2.4.4 缓存雪崩

2.4.5 缓存更新

2.5 高并发读场景总结：CQRS

2.5.1 CQRS的简要架构与实现

2.5.2 更多的使用场景

2.5.3 CQRS架构的特点

2.6 高并发写场景方案1：数据分片之数据库分库分表

2.6.1 分库和分表

2.6.2 垂直拆分

2.6.3 水平拆分

2.6.4 水平拆分规则

2.6.5 扩容方案

2.6.6 其他数据分片形式

2.7 高并发写场景方案2：异步写与写聚合

2.7.1 异步写

2.7.2 写聚合

2.8 本章小结

第3章 通用的服务可用性治理手段

3.1 微服务架构与网络调用

3.2 重试

3.2.1 幂等接口

3.2.2 重试时机

3.2.3 重试风险与重试风暴

3.2.4 重试控制：不重试的请求

3.2.5 重试控制：重试请求比

3.3 熔断与隔离

3.3.1 服务雪崩

3.3.2 Hystrix熔断器

3.3.3 Resilience4j和Sentinel熔断器

3.3.4 共享资源与舱壁隔离

3.3.5 舱壁隔离的实现

3.4 限流

3.4.1 频控

3.4.2 单机限流1：时间窗口

3.4.3 单机限流2：漏桶算法

3.4.4 单机限流3：令牌桶算法

3.4.5 全局限流

3.5 自适应限流

3.5.1 服务与等待队列

3.5.2 基于请求排队时间

3.5.3 基于延迟比率

3.5.4 其他方案

3.6 降级策略

3.6.1 服务依赖度降级

3.6.2 读请求降级

3.6.3 写请求降级

3.7 本章小结

基础服务设计篇

第4章 唯一ID生成器

4.1 分布式唯一ID

4.1.1 全局唯一与UUID

4.1.2 唯一ID生成器的特点

4.1.3 单调递增与趋势递增

4.2 单调递增的唯一ID

4.2.1 Redis INCRBY命令

4.2.2 基于数据库的自增主键

4.2.3 高可用架构

4.3 趋势递增的唯一ID：基于时间戳

4.3.1 正确使用时间戳

4.3.2 Snowflake算法的原理

4.3.3 Snowflake算法的灵活应用

4.3.4 分配服务实例ID

4.3.5 时钟回拨问题与解决方案

4.3.6 最终架构

4.4 趋势递增的唯一ID：基于数据库的自增主键

4.4.1 分库分表架构

4.4.2 批量缓存架构

4.5 美团点评开源方案：Leaf

4.5.1 Leaf-segment方案

4.5.2 Leaf-snowflake方案

4.6 本章小结

第5章 用户登录服务

5.1 用户账号

5.2 用户登录服务的功能要点

5.3 密码保护

5.3.1 使用HTTPS通信

5.3.2 非对称加密

5.3.3 密码加密存储

5.4 手机号登录和邮箱登录

5.4.1 数据表设计

5.4.2 用户注册

5.4.3 用户登录

5.4.4 手机号一键登录

5.5 第三方登录

5.5.1 OAuth 2标准

5.5.2 客户端接入第三方登录

5.5.3 服务端接入第三方登录

5.5.4 第三方登录的完整流程总结

5.6 登录态管理

5.6.1 存储型方案：Session

5.6.2 计算型方案：令牌

5.6.3 长短令牌方案

5.7 扫码登录

5.7.1 二维码

5.7.2 扫码登录的场景介绍

5.7.3 扫码登录的技术实现

5.8 本章小结

第6章 海量推送系统

6.1 分布式长连接服务的技术要素分析

6.1.1 WebSocket协议简介

6.1.2 长连接服务器

6.1.3 分布式推送服务器

6.1.4 路由算法

6.2 海量推送系统设计

6.2.1 整体架构设计

6.2.2 长连接的建立过程

6.2.3 消息格式设计

6.2.4 消息推送接口

6.2.5 单点消息推送的细节

6.2.6 全局消息推送的细节

6.2.7 多点消息推送的细节

6.2.8 pusher平滑升级的问题

6.2.9 pusher扩容的问题

6.3 本章小结

核心服务设计篇

第7章 内容发布系统

7.1 内容发布系统的设计背景

7.2 内容存储设计

7.2.1 内容数据的存储

7.2.2 内容元信息的存储

7.2.3 内容主体的存储选型

7.2.4 音视频转码

7.3 内容审核设计

7.3.1 内容审核的必要性

7.3.2 内容审核的时机策略

7.3.3 如何审核内容

7.3.4 审核中心的对外交互

7.4 内容的全生命周期管理设计

7.4.1 内容的创建设计

7.4.2 内容的修改设计

7.4.3 内容审核结果处理与版本控制设计

7.4.4 内容的删除与下架设计

7.5 内容分发设计

7.5.1 内容分发渠道

7.5.2 何时通知分发渠道

7.5.3 将内容投递到分发渠道

7.6 内容展示设计

7.6.1 内容数据的特点

7.6.2 使用CDN加速静态资源访问

7.6.3 使用缓存和多副本支撑高并发读取

7.6.4 内容展示流程设计

7.7 完整架构总览

7.8 本章小结

第8章 通用计数系统

8.1 计数的常见用途

8.2 如何存储计数数据

8.2.1 计数数据的特点

8.2.2 关系型数据库的困境

8.2.3 是否要使用关系型数据库

8.2.4 使用Redis存储计数数据

8.3 海量计数服务设计

8.3.1 Redis数据类型

8.3.2 计数累计与读取的示例

8.3.3 优化内存的调研

8.3.4 优化内存：定制化Redis

8.3.5 冷热数据分离

8.3.6 应对过热数据

8.3.7 计数服务架构图

8.3.8 计数服务的适用范围

8.4 本章小结

第9章 排行榜服务

9.1 排行榜的应用场景

9.2 排行榜技术的特点

9.3 使用Redis实现排行榜

9.3.1 使用Redis ZSET

9.3.2 幂等更新

9.3.3 同积分排名处理

9.3.4 服务设计

9.3.5 关于大Key的问题

9.4 粗估排行榜的实现

9.4.1 线段树

9.4.2 粗估排名的实现

9.5 精确排名与粗估排名结合

9.6 本章小结

第10章 用户关系服务

10.1 用户关系服务的职责

10.2 基于Redis ZSET的设计

10.3 基于数据库的设计

10.3.1 最初的想法

10.3.2 应对分库分表

10.3.3 Following表的索引设计

10.3.4 Follower表的索引设计

10.3.5 进阶：回表问题与优化

10.3.6 关注数和粉丝数

10.4 缓存查询

10.4.1 缓存什么数据

10.4.2 缓存的创建与更新策略

10.4.3 本地缓存

10.4.4 缓存与数据库结合的最终方案

10.5 基于图数据库的设计

10.5.1 实现用户关系

10.5.2 应用权衡

10.6 本章小结

第11章 Timeline Feed服务

11.1 Feed流的分类

11.2 Timeline Feed流的功能特性

11.3 拉模式与用户发件箱

11.4 推模式与用户收件箱

11.5 推拉结合模式

11.5.1 结合思路

11.5.2 区分活跃用户

11.6 实现Timeline Feed服务的关键技术细节

11.6.1 内容与用户收件箱的交互

11.6.2 推送子任务

11.6.3 收件箱保存什么数据

11.6.4 读请求参数

11.6.5 使用数据库实现收件箱

11.6.6 使用Redis ZSET实现收件箱

11.6.7 通过推拉结合模式构建Timeline Feed数据

11.6.8 收尾工作

11.7 本章小结

第12章 评论服务

12.1 评论功能

12.2 评论列表模式

12.3 评论服务设计的初步想法

12.4 单级模式服务设计

12.4.1 数据表的初步设计

12.4.2 读/写接口与索引

12.4.3 数据库的最终设计

12.4.4 高并发问题

12.5 盖楼模式服务设计

12.5.1 数据库方案：递归查询

12.5.2 数据库方案：保存完整楼层

12.5.3 图数据库方案

12.6 二级模式服务设计

12.6.1 一级评论和二级评论

12.6.2 时间顺序：数据库方案

12.6.3 时间顺序：图数据库方案

12.6.4 评论审核与状态

12.6.5 按照热度排序

12.6.6 高并发处理

12.6.7 架构总览

12.7 本章小结

第13章 IM服务

13.1 IM的意义与核心能力

13.2 IM相关概念

13.3 消息投递

13.3.1 存储消息：读扩散与写扩散

13.3.2 接收消息：拉模式与推模式

13.4 存储初探

13.5 消息的有序性保证

13.5.1 消息乱序

13.5.2 客户端发送消息

13.5.3 服务端存储消息

13.5.4 服务端推送消息与客户端补偿

13.6 会话管理与命令消息

13.6.1 创建单聊会话

13.6.2 创建群聊会话

13.6.3 命令消息

13.7 消息回执

13.7.1 上报已读消息

13.7.2 记录已读消息

13.8 阶段性汇总：存储设计

13.9 高并发架构

13.9.1 发送消息

13.9.2 数据缓存

13.9.3 消息分级

13.9.4 直播间弹幕模式

13.10 本章小结：最终架构