电子工业出版社-网上书店

本书讲解亿级流量系统架构的设计方法及实战经验，在内容结构上分为三大篇：架构知识篇（第1～3章），主要讲解海量用户应用后台的组成结构、高并发处理和服务可用性保障，首先讲解后台由哪些关键组件构成及机房搭建思路，然后讲解后台在应对高并发读请求和写请求时的通用处理手段，最后讲解通用的服务治理手段以保障后台高效运行。基础服务设计篇（第4～6章），主要讲解几个基础服务的架构设计，这里选取的基础服务几乎为所有互联网后台所需的专门系统，包括分布式唯一ID生成器、用户登录服务和海量消息推送系统；核心服务设计篇（第7～13章），主要讲解常见社交互动场景中所需的核心服务的架构设计，包括内容发布系统、通用计数系统、排行榜服务、用户关系服务、Timeline Feed服务、评论服务和IM服务。

架构知识篇
第1章  大型互联网公司的基础架构	2
1.1  引言：单机房的内部架构	2
1.2  客户端连接机房的技术1：DNS	5
1.2.1  DNS的意义	5
1.2.2  域名结构	6
1.2.3  域名服务器	6
1.2.4  域名解析过程	7
1.3  客户端连接机房的技术2：HTTP DNS	9
1.3.1  DNS存在的问题	9
1.3.2  HTTP DNS的原理	10
1.3.3  HTTP DNS实践	11
1.4  接入层的技术演进	12
1.4.1  Nginx	13
1.4.2  LVS	19
1.4.3  LVS+Nginx接入层的架构	25
1.5  服务发现	28
1.5.1  注册与发现	29
1.5.2  可用地址管理	30
1.5.3  地址变更推送	31
1.6  RPC服务	32
1.7  存储层技术：MySQL	35
1.7.1  关系型数据库	35
1.7.2  MySQL	37
1.7.3  高可用架构1：主从模式	37
1.7.4  高可用架构2：MHA	40
1.7.5  高可用架构3：MMM	41
1.7.6  高可用架构4：MGR	43
1.8  存储层技术：Redis	44
1.8.1  高可用架构1：主从模式	44
1.8.2  高可用架构2：哨兵模式	45
1.8.3  高可用架构3：集群模式	46
1.8.4  高可用架构4：中心化集群架构	50
1.9  存储层技术：LSM Tree	53
1.9.1  LSM Tree的原理	53
1.9.2  读/写数据流程	56
1.10  存储层技术：其他NoSQL数据库	57
1.11  消息中间件技术	61
1.11.1  通信模式与用途	62
1.11.2  Kafka	64
1.11.3  Kafka的高可用	67
1.12  多机房：主备机房	69
1.13  多机房：同城双活	71
1.13.1  存储层改造	71
1.13.2  灵活实施	73
1.13.3  分流与故障切流	74
1.13.4  两地三中心	77
1.14  多机房：异地多活	78
1.14.1  架构要点	78
1.14.2  MySQL DRC的原理	80
1.14.3  Redis DRC的原理	83
1.14.4  分流策略	84
1.14.5  数据复制链路	85
1.15  本章小结	86

第2章  通用的高并发架构设计	88
2.1  高并发架构设计的要点	88
2.1.1  形成高并发系统的必要条件	88
2.1.2  高并发系统的衡量指标	89
2.1.3  高并发场景分类	90
2.2  高并发读场景方案1：数据库读/写分离	91
2.2.1  读/写分离架构	91
2.2.2  读/写请求路由方式	91
2.2.3  主从延迟与解决方案	92
2.3  高并发读场景方案2：本地缓存	93
2.3.1  基本的缓存淘汰策略	93
2.3.2  W-TinyLFU策略	94
2.3.3  缓存击穿与SingleFlight	95
2.4  高并发读场景方案3：分布式缓存	100
2.4.1  分布式缓存选型	100
2.4.2  如何使用Redis缓存	101
2.4.3  缓存穿透	102
2.4.4  缓存雪崩	103
2.4.5  缓存更新	103
2.5  高并发读场景总结：CQRS	105
2.5.1  CQRS的简要架构与实现	106
2.5.2  更多的使用场景	107
2.5.3  CQRS架构的特点	108
2.6  高并发写场景方案1：数据分片之数据库分库分表	108
2.6.1  分库和分表	109
2.6.2  垂直拆分	109
2.6.3  水平拆分	111
2.6.4  水平拆分规则	113
2.6.5  扩容方案	117
2.6.6  其他数据分片形式	120
2.7  高并发写场景方案2：异步写与写聚合	120
2.7.1  异步写	121
2.7.2  写聚合	122
2.8  本章小结	122
第3章  通用的服务可用性治理手段	124
3.1  微服务架构与网络调用	124
3.2  重试	126
3.2.1  幂等接口	126
3.2.2  重试时机	130
3.2.3  重试风险与重试风暴	130
3.2.4  重试控制：不重试的请求	131
3.2.5  重试控制：重试请求比	132
3.3  熔断与隔离	132
3.3.1  服务雪崩	133
3.3.2  Hystrix熔断器	134
3.3.3  Resilience4j和Sentinel熔断器	136
3.3.4  共享资源与舱壁隔离	137
3.3.5  舱壁隔离的实现	138
3.4  限流	139
3.4.1  频控	140
3.4.2  单机限流1：时间窗口	141
3.4.3  单机限流2：漏桶算法	143
3.4.4  单机限流3：令牌桶算法	144
3.4.5  全局限流	146
3.5  自适应限流	148
3.5.1  服务与等待队列	149
3.5.2  基于请求排队时间	150
3.5.3  基于延迟比率	151
3.5.4  其他方案	152
3.6  降级策略	155
3.6.1  服务依赖度降级	155
3.6.2  读请求降级	158
3.6.3  写请求降级	159
3.7  本章小结	160

基础服务设计篇
第4章  唯一ID生成器	164
4.1  分布式唯一ID	164
4.1.1  全局唯一与UUID	164
4.1.2  唯一ID生成器的特点	165
4.1.3  单调递增与趋势递增	167
4.2  单调递增的唯一ID	168
4.2.1  Redis INCRBY命令	168
4.2.2  基于数据库的自增主键	171
4.2.3  高可用架构	172
4.3  趋势递增的唯一ID：基于时间戳	174
4.3.1  正确使用时间戳	174
4.3.2  Snowflake算法	175
4.3.3  Snowflake算法的灵活应用	175
4.3.4  分配服务实例ID	177
4.3.5  时钟回拨问题与解决方案	179
4.3.6  最终架构	179
4.4  趋势递增的唯一ID：基于数据库的自增主键	180
4.4.1  分库分表架构	181
4.4.2  批量缓存架构	182
4.5  美团点评开源方案：Leaf	183
4.5.1  Leaf-segment方案	183
4.5.2  Leaf-snowflake方案	185
4.6  本章小结	187
第5章  用户登录服务	189
5.1  用户账号	189
5.2  用户登录服务的功能要点	190
5.3  密码保护	192
5.3.1  使用HTTPS通信	192
5.3.2  非对称加密	193
5.3.3  密码加密存储	194
5.4  手机号登录和邮箱登录	194
5.4.1  数据表设计	195
5.4.2  用户注册	195
5.4.3  用户登录	196
5.4.4  手机号一键登录	197
5.5  第三方登录	199
5.5.1  OAuth 2标准	200
5.5.2  客户端接入第三方登录	201
5.5.3  服务端接入第三方登录	202
5.5.4  第三方登录的完整流程总结	203
5.6  登录态管理	204
5.6.1  存储型方案：Session	205
5.6.2  计算型方案：令牌	207
5.6.3  长短令牌方案	208
5.7  扫码登录	210
5.7.1  二维码	210
5.7.2  扫码登录的场景介绍	211
5.7.3  扫码登录的技术实现	211
5.8  本章小结	213
第6章  海量推送系统	215
6.1  分布式长连接服务的技术要素分析	216
6.1.1  WebSocket协议简介	216
6.1.2  长连接服务器	217
6.1.3  分布式推送服务器	218
6.1.4  路由算法	219
6.2  海量推送系统设计	220
6.2.1  整体架构设计	220
6.2.2  长连接的建立过程	221
6.2.3  消息格式设计	222
6.2.4  消息推送接口	223
6.2.5  单点消息推送的细节	224
6.2.6  全局消息推送的细节	225
6.2.7  多点消息推送的细节	226
6.2.8  pusher平滑升级的问题	227
6.2.9  pusher扩容的问题	236
6.3  本章小结	237
核心服务设计篇
第7章  内容发布系统	240
7.1  内容发布系统的设计背景	240
7.2  内容存储设计	241
7.2.1  内容数据的存储	241
7.2.2  内容元信息的存储	243
7.2.3  内容主体的存储选型	244
7.2.4  音视频转码	245
7.3  内容审核设计	246
7.3.1  内容审核的必要性	246
7.3.2  内容的审核时机策略	246
7.3.3  如何审核内容	247
7.3.4  审核中心的对外交互	249
7.4  内容的全生命周期管理设计	250
7.4.1  内容的创建设计	250
7.4.2  内容的修改设计	252
7.4.3  内容审核结果处理与版本控制设计	254
7.4.4  内容的删除与下架设计	256
7.5  内容分发设计	256
7.5.1  内容分发渠道	256
7.5.2  何时通知分发渠道	257
7.5.3  将内容投递到分发渠道	257
7.6  内容展示设计	258
7.6.1  内容数据的特点	259
7.6.2  使用CDN加速静态资源访问	259
7.6.3  使用缓存和多副本支撑高并发读取	260
7.6.4  内容展示流程设计	263
7.7  完整架构总览	265
7.8  本章小结	267
第8章  通用计数系统	268
8.1  计数的常见用途	268
8.2  如何存储计数数据	269
8.2.1  计数数据的特点	269
8.2.2  关系型数据库的困境	270
8.2.3  是否要使用关系型数据库	270
8.2.4  使用Redis存储计数数据	271
8.3  海量计数服务设计	272
8.3.1  Redis数据类型	272
8.3.2  计数累计与读取的示例	274
8.3.3  优化内存的调研	274
8.3.4  优化内存：定制化Redis	276
8.3.5  冷热数据分离	279
8.3.6  应对过热数据	280
8.3.7  计数服务架构图	281
8.3.8  计数服务的适用范围	282
8.4  本章小结	283
第9章  排行榜服务	284
9.1  排行榜的应用场景	284
9.2  排行榜技术的特点	285
9.3  使用Redis实现排行榜	285
9.3.1  使用Redis ZSET	286
9.3.2  幂等更新	287
9.3.3  同积分排名处理	289
9.3.4  服务设计	291
9.3.5  关于大Key的问题	295
9.4  粗估排行榜的实现	296
9.4.1  线段树	296
9.4.2  粗估排名的实现	299
9.5  精确排名与粗估排名结合	306
9.6  本章小结	309

第10章  用户关系服务	310
10.1  用户关系服务的职责	310
10.2  基于Redis ZSET的设计	311
10.3  基于数据库的设计	312
10.3.1  最初的想法	312
10.3.2  应对分库分表	313
10.3.3  Following表的索引设计	314
10.3.4  Follower表的索引设计	316
10.3.5  进阶：回表问题与优化	316
10.3.6  关注数和粉丝数	317
10.4  缓存查询	318
10.4.1  缓存什么数据	318
10.4.2  缓存的创建与更新策略	319
10.4.3  本地缓存	321
10.4.4  缓存与数据库结合的最终方案	321
10.5  基于图数据库的设计	323
10.5.1  实现用户关系	323
10.5.2  应用权衡	327
10.6  本章小结	328
第11章  Timeline Feed服务	330
11.1  Feed流的分类	330
11.2  Timeline Feed流的功能特性	331
11.3  拉模式与用户发件箱	331
11.4  推模式与用户收件箱	333
11.5  推拉结合模式	334
11.5.1  结合思路	334
11.5.2  区分活跃用户	335
11.6  实现Timeline Feed服务的关键技术细节	336
11.6.1  内容与用户收件箱的交互	336
11.6.2  推送子任务	338
11.6.3  收件箱保存什么数据	339
11.6.4  读请求参数	340
11.6.5  使用数据库实现收件箱	340
11.6.6  使用Redis ZSET实现收件箱	343
11.6.7  通过推拉结合模式构建Timeline Feed数据	348
11.6.8  收尾工作	355
11.7  本章小结	356
第12章  评论服务	357
12.1  评论功能	357
12.2  评论列表模式	358
12.3  评论服务设计的初步想法	361
12.4  单级模式服务设计	361
12.4.1  数据表的初步设计	361
12.4.2  读/写接口与索引	362
12.4.3  数据库的最终设计	363
12.4.4  高并发问题	364
12.5  盖楼模式服务设计	366
12.5.1  数据库方案：递归查询	366
12.5.2  数据库方案：保存完整楼层	368
12.5.3  图数据库方案	369
12.6  二级模式服务设计	370
12.6.1  数据特点	371
12.6.2  时间顺序：数据库方案	371
12.6.3  时间顺序：图数据库方案	373
12.6.4  评论审核与状态	376
12.6.5  按照热度排序	377
12.6.6  高并发处理	381
12.6.7  架构总览	385
12.7  本章小结	386
第13章  IM服务	388
13.1  IM的意义与核心能力	388
13.2  IM相关概念	389
13.3  消息投递	390
13.3.1  存储消息：读扩散与写扩散	390
13.3.2  接收消息：拉模式与推模式	393
13.4  存储初探	395
13.5  消息的有序性保证	396
13.5.1  消息乱序	396
13.5.2  客户端发送消息	396
13.5.3  服务端存储消息	397
13.5.4  服务端推送消息与客户端补偿	398
13.6  会话管理与命令消息	401
13.6.1  创建单聊会话	402
13.6.2  创建群聊会话	402
13.6.3  命令消息	403
13.7  消息回执	404
13.7.1  上报已读消息	404
13.7.2  记录已读消息	404
13.8  阶段性汇总：存储设计	405
13.9  高并发架构	408
13.9.1  发送消息	409
13.9.2  数据缓存	409
13.9.3  消息分级	410
13.9.4  直播间弹幕模式	411
13.10  本章小结：最终架构	413

前  言



海量用户应用

如今市面上的互联网应用几乎都在追求用户规模，这不仅是因为用户规模庞大才能让产品扬名立万，更重要的是从应用出品方公司来说，海量用户会为公司带来多方面的巨大的收益：
	广告收入：坐拥海量用户的应用拥有巨大的“人口红利”，在应用内投放某产品的广告非常容易带来巨大的曝光度和产品转化率，所以会有非常客观的广告收入。
	商业价值：海量用户意味着应用的品牌拥有巨大的影响力，会天然吸引其他企业促成联名合作。
	产品带动：公司在坐拥一个用户量级巨大的产品后，非常方便借助它为公司的新产品做引流和推广，可以进一步扩大公司产品规模。
鉴于海量用户对公司带来了极高的实用价值和商业价值，所以针对海量用户进行架构设计的工程师备受市场青睐，海量用户意味着高并发，很多公司会在工程师招聘要求中注明“有高并发系统设计经验”，或者在面试过程中频繁考察候选人的高并发系统设计能力，所以对研发工程师来说，拥有高并发系统设计的知识体系是很必要的技术素养。
本书主题

如果你是大厂的开发工程师，你可能每天都要处理系统怎样才能服务好海量用户的问题；如果你所在公司目前尚未拥有海量用户，你可能会想象公司产品如果有更多用户使用的话需要应用什么技术，或者你希望拿到大厂Offer却焦虑于自己没有高并发系统设计经验；如果你是一位计划成为开发工程师的学生，你虽然认真做了很多课程设计，但可能会很好奇你的作品对应的工业级的设计应该是怎样的。
如此种种，笔者决定撰写一部涵盖了海量用户应用后台常见系统设计的图书，希望能够将笔者的经验与你分享。本书的题目是《海量用户应用架构：后台通用系统设计实战》，其内容涵盖了在面向海量用户应用的后台中常见的通用技术和通用系统的架构设计思路。那么海量用户应用后台常见的通用技术有什么？通用的系统有哪些？
首先，海量用户应用后台的通用技术有什么？无非就是大型互联网公司如何构建机房、使用哪些技术栈、怎么高效处理高并发请求和怎么保证后台服务可用性。
其次，海量用户应用有哪些通用系统（或称服务）？我们只需要看那些作用亿万用户的应用都有哪些相似功能就能轻易得到结论，就来看那些国民级应用或知名应用：微信、淘宝、微博、抖音、快手、小红书、百度贴吧、bilibili、爱奇艺、网易云音乐、知乎、钉钉等，这些应用都有极高的用户活跃度，它们几乎都清一色地支持这些功能：用户注册与登录、通知消息、用户发帖、对内容点赞、关注与粉丝、评论、私信与群聊、排行榜等，每个功能都与专门的后台服务对应，所以这些服务就是非常通用的服务。
以上罗列的种种内容都是本书中会做详细讲解的话题。
内容概要

本书从内容结构上可以分为三大版块：
第一个版块是“架构知识篇”，此版块作为全文的基础知识篇，你将学习到一个海量用户应用后台由哪些组件组成、包括每个组件的原理和用途、以及应该怎样设计服务于全国乃至全球的多机房架构，你还会掌握系统面对高并发请求的通用处理思路和保障服务可用性的通用技术手段。
基础服务设计篇（第4～6章）：这一版块正式开始对几个基础服务做架构设计，这里选取的基础服务均为几乎所有互联网后台所需的专门系统，包括分布式唯一ID生成器、用户登录服务和海量消息推送系统。
核心服务设计篇（第7～13章）：这一版块主要讲述对常见社交互动向场景所需的核心服务的架构设计，包括内容发布服务、计数服务、排行榜服务、关注服务、Timeline信息流服务、评论服务和即时通信服务。
特别要说明的是，本书不会对具体的存储系统如MySQL、Redis等专门做深入的原理性剖析，而是会在行文中用到它们的地方再做穿插介绍，以便理论与实际能在用相应技术解决问题的时候做到良好结合，加深对理论的理解。
适用人群

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

必须承认，本书介绍的内容与本人工作的公司所深耕的技术方向是比较匹配的，我司在本书介绍的每个服务都具备优秀的服务设计，并积累了服务于数亿名用户的架构经验，不过受限于保护知识产权与公司机密的原则，笔者在每章的服务设计要素中都回避了公司的独创性设计，而只提供了业界公开的或公认的设计思路，所以你在仔细推敲细节的过程中可能会发现个中内容并不能展示全貌，这是因为不同公司对这些内容有不同的技术处理方式，笔者无有渠道或是无有权利去获取这些技术知识，故而只能在大方向上做一些思路指导，还望各位读者见谅与主动思考。
另外，本书不希望出现广为吐槽的为了凑篇幅而大段贴上不知所云的代码和无意义的系统配置过程，所以内容编写上会屏蔽系统配置、和只在适当时机贴出代码，本质上希望每段文字都只聚焦于读者真正在意的干货。
职业生涯感受

从业多年以来，笔者对作为软件开发工程师的工作最大的感受就是：作为一名技术人，不应该把自己视为“我是X公司的打工人”一般如机器人一样循规蹈矩完成自己应该做的工作就心安理得，而是应该时刻思考自己的未来要达到什么目的，无论你有成为某领域顶级专家、或者CTO的理想，还是有去更好的公司的想法，在达成目的的过程中最值得去做的事就是要保证自己在时刻进步。进步的核心是持续学习，学习从来不只是为了考试的学生的职责，也是我们工作更上一层楼的必要条件。对于开发工程师职业生涯来说，如果你是大厂中负责一个很小系统的所谓“螺丝丁”，那你可以不局限自己在工作职责、积极搜索公司内公开的资源去学习如何“造火箭”；如果你是小厂工程师或者是未入社会的学生，你依然可以多去发达的互联网或品目繁多的图书中获取自己目前接触不到的经验与知识，总之，请你的视野上升到更高层面，去学习、去吸纳能让你进步的知识与技巧。
现在，请你假设自己是某互联网产品的技术负责人，随着本书开始一场面向海量用户应用的架构设计之旅吧。

本书配套资源下载

对不起，暂无音视频资源！

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