应用场景架构设计分析（一些思考不完整）

常见应用场景分析：

电商、本地生活
社交、微博
短视频/直播/音视频
游戏
数据分析、商业智能

电商，本地生活场景

特点： CA 有要求，P也有要求
常见场景：
减少库存
压力在哪里？这些是最核心的诉求
1 不希望每次减少库存操作都写DB（操作系统对于磁盘的操作是block的操作，还有磁盘对CPU的距离）
2 不希望每次读取库存都通过DB

库存服务，SKU 数量，读写都写内存，每次都写库存变更记录（DB，Redis，MQ，但必须持久化），通过Workers 批量写库存DB

关注点：
服务无状态
批量写入（关键点）
最终一致性

另一个关注点： redis 有自己的容灾机制，允许将操作记录下来，挂了会恢复，但不排除有情况会挂掉，工程师要有自己的数据预案，写灾难脚本，恢复数据状态，这样就非常依赖整体状态的日志，最简单的方法是依赖 redis 自己有自己的日志，来恢复自己的状态。

秒杀
下单，支付
对缓存的思考
单元化技术
灾备的一些处理方案

字节跳动亿级视频处理系统高可用架构实践

1 端侧生产：视频的创作者用手机或者其他设备拍摄一个视频，可以对视频做一些增强和编辑，通过上传 SDK，即可把这个视频上传到云端。

2 云端生产：在云端有两个比较核心的流程：视频处理和审核，这两个流程是并行执行的。

3 云端下发：当以上两个流程都执行完以后，一个视频也就可以给大家看了，接下来就进入云端下发的阶段。在这个阶段，点

4 播服务负责下发视频的播放地址（包括相关的 meta 信息），然后视频的内容是通过 CDN 下发。
视频播放：这个阶段由播放 SDK 进行端上视频的处理以及渲染

挑战：
1 大规模：目前，字节跳动每天处理的视频量级在亿级，因为每一个视频都会产生不同档位、不同格式的视频，实际生产出的是接近十亿量级的视频。这对计算和存储都是非常大的消耗，这么大体量的业务对系统整体的稳定性和性能也有非常高的要求。

2 多业务：字节跳动的视频业务非常多样，包括短视频、中视频、长视频，以及点播、直播、RTC 相关的一些业务，涉及教育、游戏等不同的垂直行业。

3 资源复杂：除了常规的 CPU 资源，还有很多弹性资源，以及 CPU/GPU/FPGA 等多种类型的资源，还有一些其他的硬件转码设备等。

4 业务高速增长，以及大型活动的峰值：到目前为止，每年处理的视频量级至少都是在翻倍地增长。每年又有很多大型的活动，给系统带来了非常巨大的考验。

具体内容参考：
https://mp.weixin.qq.com/s/YW0AwsG6xkTf8PLFWgzLDQ

实现微博关注关系

用冗余数据的办法来解决数据分片带来的问题，即将关注和粉丝分2个表存放。
1 用follower表存放粉丝
2 用following表存放关注

微博推送

主要难点：关系复杂，数据量大。一个人可以关注非常多的用户，一个大V可有可能有几千万的粉丝
先介绍最基本的方案：

推模式：推模式就是，用户A关注了用户 B，用户 B 每发送一个动态，后台遍历用户B的粉丝，往他们粉丝的 feed 里面推送一条动态。
拉模式：推模式相反，拉模式则是，用户每次刷新 feed 第一页，都去遍历关注的人，把最新的动态拉取回来。
一般采用推拉结合的方式，用户发送状态之后，先推送给粉丝里面在线的用户，然后不在线的那部分等到上线的时候再来拉取。

另外冷热数据分离，用户关系在缓存里面可以设置一个过期时间，比如七天。七天没上线的可能就很少用这个 APP。

秒杀

电商系统核心层分位：负载均衡层，应用层和持久层
预估下每一层的并发量。
1 假如负载均衡层使用的是高性能的Nginx，则我们可以预估Nginx最大的并发度为：10W+，这里是以万为单位。
2 假设应用层我们使用的是Tomcat，而Tomcat的最大并发度可以预估为800左右，这里是以百为单位。
3 假设持久层的缓存使用的是Redis，数据库使用的是MySQL，MySQL的最大并发度可以预估为1000左右，以千为单位。Redis的最大并发度可以预估为5W左右，以万为单位。

方案：
（1）系统扩容

系统扩容包括垂直扩容和水平扩容，增加设备和机器配置，绝大多数的场景有效。

（2）缓存

本地缓存或者集中式缓存，减少网络IO，基于内存读取数据。大部分场景有效。

（3）读写分离

采用读写分离，分而治之，增加机器的并行处理能力。

秒杀业务特点：
流量突刺
1 限时，限量，限价
2 活动预热
3 持续时间短

（1）瞬时并发量非常高

大量用户会在同一时间抢购商品；瞬间并发峰值非常高。

（2）读多写少

系统中商品页的访问量巨大；商品的可购买数量非常少；库存的查询访问数量远远大于商品的购买数量。

在商品页中往往会加入一些限流措施，例如早期的秒杀系统商品页会加入验证码来平滑前端对系统的访问流量，近期的秒杀系统商品详情页会在用户打开页面时，提示用户登录系统。这都是对系统的访问进行限流的一些措施。

（3）流程简单

秒杀系统的业务流程一般比较简单；总体上来说，秒杀系统的业务流程可以概括为：下单减库存。

整体思路：

1）异步解耦

将整体流程进行拆解，核心流程通过队列方式进行控制。

（2）限流防刷

控制网站整体流量，提高请求的门槛，避免系统资源耗尽。

（3）资源控制

将整体流程中的资源调度进行控制，扬长避短。

由于应用层能够承载的并发量比缓存的并发量少很多。所以，在高并发系统中，我们可以直接使用OpenResty由负载均衡层访问缓存，避免了调用应用层的性能损耗。大家可以到https://openresty.org/cn/来了解有关OpenResty更多的知识。同时，由于秒杀系统中，商品数量比较少，我们也可以使用动态渲染技术，CDN技术来加速网站的访问性能。

如果在秒杀活动开始时，并发量太高时，我们可以将用户的请求放入队列中进行处理，并为用户弹出排队页面。

下单流程：

1.用户发起秒杀请求
在同步下单流程中，首先，用户发起秒杀请求。商城服务需要依次执行如下流程来处理秒杀请求的业务。

（1）识别验证码是否正确

商城服务判断用户发起秒杀请求时提交的验证码是否正确。

（2）判断活动是否已经结束

验证当前秒杀活动是否已经结束。

（3）验证访问请求是否处于黑名单

在电商领域中，存在着很多的恶意竞争，也就是说，其他商家可能会通过不正当手段来恶意请求秒杀系统，占用系统大量的带宽和其他系统资源。此时，就需要使用风控系统等实现黑名单机制。为了简单，也可以使用拦截器统计访问频次实现黑名单机制。

（4）验证真实库存是否足够

系统需要验证商品的真实库存是否足够，是否能够支持本次秒杀活动的商品库存量。

（5）扣减缓存中的库存

在秒杀业务中，往往会将商品库存等信息存放在缓存中，此时，还需要验证秒杀活动使用的商品库存是否足够，并且需要扣减秒杀活动的商品库存数量。

（6）计算秒杀的价格

由于在秒杀活动中，商品的秒杀价格和商品的真实价格存在差异，所以，需要计算商品的秒杀价格。

注意：如果在秒杀场景中，系统涉及的业务更加复杂的话，会涉及更多的业务操作，这里，我只是列举出一些常见的业务操作。

2.提交订单
（1）订单入口

将用户提交的订单信息保存到数据库中。

（2）扣减真实库存

订单入库后，需要在商品的真实库存中将本次成功下单的商品数量扣除。

如果我们使用上述流程开发了一个秒杀系统，当用户发起秒杀请求时，由于系统每个业务流程都是串行执行的，整体上系统的性能不会太高，当并发量太高时，我们会为用户弹出下面的排队页面，来提示用户进行等待。

此时的排队时间可能是15秒，也可能是30秒，甚至是更长时间。这就存在一个问题：在用户发起秒杀请求到服务器返回结果的这段时间内，客户端和服务器之间的连接不会被释放，这就会占大量占用服务器的资源。

网上很多介绍如何实现秒杀系统的文章都是采用的这种方式，那么，这种方式能做秒杀系统吗？答案是可以做，但是这种方式支撑的并发量并不是太高。此时，有些网友可能会问：我们公司就是这样做的秒杀系统啊！上线后一直在用，没啥问题啊！我想说的是：使用同步下单方式确实可以做秒杀系统，但是同步下单的性能不会太高。之所以你们公司采用同步下单的方式做秒杀系统没出现大的问题，那是因为你们的秒杀系统的并发量没达到一定的量级，也就是说，你们的秒杀系统的并发量其实并不高。

所以，很多所谓的秒杀系统，存在着秒杀的业务，但是称不上真正的秒杀系统，原因就在于他们使用的是同步的下单流程，限制了系统的并发流量。之所以上线后没出现太大的问题，是因为系统的并发量不高，不足以压死整个系统。

异步下单流程：

既然同步下单流程的秒杀系统称不上真正的秒杀系统，那我们就需要采用异步的下单流程了。异步的下单流程不会限制系统的高并发流量。

1.用户发起秒杀请求
用户发起秒杀请求后，商城服务会经过如下业务流程。

（1）检测验证码是否正确

用户发起秒杀请求时，会将验证码一同发送过来，系统会检验验证码是否有效，并且是否正确。

（2）是否限流

系统会对用户的请求进行是否限流的判断，这里，我们可以通过判断消息队列的长度来进行判断。因为我们将用户的请求放在了消息队列中，消息队列中堆积的是用户的请求，我们可以根据当前消息队列中存在的待处理的请求数量来判断是否需要对用户的请求进行限流处理。

例如，在秒杀活动中，我们出售1000件商品，此时在消息队列中存在1000个请求，如果后续仍然有用户发起秒杀请求，则后续的请求我们可以不再处理，直接向用户返回商品已售完的提示。

所以，使用限流后，我们可以更快的处理用户的请求和释放连接的资源。

（3）发送MQ

用户的秒杀请求通过前面的验证后，我们就可以将用户的请求参数等信息发送到MQ中进行异步处理，同时，向用户响应结果信息。在商城服务中，会有专门的异步任务处理模块来消费消息队列中的请求，并处理后续的异步流程。

在用户发起秒杀请求时，异步下单流程比同步下单流程处理的业务操作更少，它将后续的操作通过MQ发送给异步处理模块进行处理，并迅速向用户返回响应结果，释放请求连接。

2.异步处理
我们可以将下单流程的如下操作进行异步处理。

（1）判断活动是否已经结束

（2）判断本次请求是否处于系统黑名单，为了防止电商领域同行的恶意竞争可以为系统增加黑名单机制，将恶意的请求放入系统的黑名单中。可以使用拦截器统计访问频次来实现。

（3）扣减缓存中的秒杀商品的库存数量。

（4）生成秒杀Token，这个Token是绑定当前用户和当前秒杀活动的，只有生成了秒杀Token的请求才有资格进行秒杀活动。

这里我们引入了异步处理机制，在异步处理中，系统使用多少资源，分配多少线程来处理相应的任务，是可以进行控制的。

3.短轮询查询秒杀结果
这里，可以采取客户端短轮询查询是否获得秒杀资格的方案。例如，客户端可以每隔3秒钟轮询请求服务器，查询是否获得秒杀资格，这里，我们在服务器的处理就是判断当前用户是否存在秒杀Token，如果服务器为当前用户生成了秒杀Token，则当前用户存在秒杀资格。否则继续轮询查询，直到超时或者服务器返回商品已售完或者无秒杀资格等信息为止。

采用短轮询查询秒杀结果时，在页面上我们同样可以提示用户排队处理中，但是此时客户端会每隔几秒轮询服务器查询秒杀资格的状态，相比于同步下单流程来说，无需长时间占用请求连接。

此时，可能会有网友会问：采用短轮询查询的方式，会不会存在直到超时也查询不到是否具有秒杀资格的状态呢？答案是：有可能！这里我们试想一下秒杀的真实场景，商家参加秒杀活动本质上不是为了赚钱，而是提升商品的销量和商家的知名度，吸引更多的用户来买自己的商品。所以，我们不必保证用户能够100%的查询到是否具有秒杀资格的状态。

4.秒杀结算
（1）验证下单Token

客户端提交秒杀结算时，会将秒杀Token一同提交到服务器，商城服务会验证当前的秒杀Token是否有效。

（2）加入秒杀购物车

商城服务在验证秒杀Token合法并有效后，会将用户秒杀的商品添加到秒杀购物车。

5.提交订单
（1）订单入库

将用户提交的订单信息保存到数据库中。

（2）删除Token

秒杀商品订单入库成功后，删除秒杀Token。

这里大家可以思考一个问题：我们为什么只在异步下单流程的粉色部分采用异步处理，而没有在其他部分采取异步削峰和填谷的措施呢？

这是因为在异步下单流程的设计中，无论是在产品设计上还是在接口设计上，我们在用户发起秒杀请求阶段对用户的请求进行了限流操作，可以说，系统的限流操作是非常前置的。在用户发起秒杀请求时进行了限流，系统的高峰流量已经被平滑解决了，再往后走，其实系统的并发量和系统流量并不是非常高了。

所以，网上很多的文章和帖子中在介绍秒杀系统时，说是在下单时使用异步削峰来进行一些限流操作，那都是在扯淡！因为下单操作在整个秒杀系统的流程中属于比较靠后的操作了，限流操作一定要前置处理，在秒杀业务后面的流程中做限流操作是没啥卵用的。

高并发“黑科技”与致胜奇招
假设，在秒杀系统中我们使用Redis实现缓存，假设Redis的读写并发量在5万左右。我们的商城秒杀业务需要支持的并发量在100万左右。如果这100万的并发全部打入Redis中，Redis很可能就会挂掉，那么，我们如何解决这个问题呢？接下来，我们就一起来探讨这个问题。

在高并发的秒杀系统中，如果采用Redis缓存数据，则Redis缓存的并发处理能力是关键，因为很多的前缀操作都需要访问Redis。而异步削峰只是基本的操作，关键还是要保证Redis的并发处理能力。

解决这个问题的关键思想就是：分而治之，将商品库存分开放。

暗度陈仓
我们在Redis中存储秒杀商品的库存数量时，可以将秒杀商品的库存进行“分割”存储来提升Redis的读写并发量。

例如，原来的秒杀商品的id为10001，库存为1000件，在Redis中的存储为(10001, 1000)，我们将原有的库存分割为5份，则每份的库存为200件，此时，我们在Redia中存储的信息为(10001_0, 200)，(10001_1, 200)，(10001_2, 200)，(10001_3, 200)，(10001_4, 200)。

此时，我们将库存进行分割后，每个分割后的库存使用商品id加上一个数字标识来存储，这样，在对存储商品库存的每个Key进行Hash运算时，得出的Hash结果是不同的，这就说明，存储商品库存的Key有很大概率不在Redis的同一个槽位中，这就能够提升Redis处理请求的性能和并发量。

分割库存后，我们还需要在Redis中存储一份商品id和分割库存后的Key的映射关系，此时映射关系的Key为商品的id，也就是10001，Value为分割库存后存储库存信息的Key，也就是10001_0，10001_1，10001_2，10001_3，10001_4。在Redis中我们可以使用List来存储这些值。

在真正处理库存信息时，我们可以先从Redis中查询出秒杀商品对应的分割库存后的所有Key，同时使用AtomicLong来记录当前的请求数量，使用请求数量对从Redia中查询出的秒杀商品对应的分割库存后的所有Key的长度进行求模运算，得出的结果为0，1，2，3，4。再在前面拼接上商品id就可以得出真正的库存缓存的Key。此时，就可以根据这个Key直接到Redis中获取相应的库存信息。

移花接木
在高并发业务场景中，我们可以直接使用Lua脚本库（OpenResty）从负载均衡层直接访问缓存。

这里，我们思考一个场景：如果在秒杀业务场景中，秒杀的商品被瞬间抢购一空。此时，用户再发起秒杀请求时，如果系统由负载均衡层请求应用层的各个服务，再由应用层的各个服务访问缓存和数据库，其实，本质上已经没有任何意义了，因为商品已经卖完了，再通过系统的应用层进行层层校验已经没有太多意义了！！而应用层的并发访问量是以百为单位的，这又在一定程度上会降低系统的并发度。

为了解决这个问题，此时，我们可以在系统的负载均衡层取出用户发送请求时携带的用户id，商品id和秒杀活动id等信息，直接通过Lua脚本等技术来访问缓存中的库存信息。如果秒杀商品的库存小于或者等于0，则直接返回用户商品已售完的提示信息，而不用再经过应用层的层层校验了。针对这个架构，我们可以参见本文中的电商系统的架构图（正文开始的第一张图）。