支付宝架构师眼中的高并发

前言

高并发常常会发生在有大活跃用户量，用户高汇集的业务场景中，如：秒杀活动，定时领取红包等。

为了让业务能够流畅的运行而且给用户一个好的交互体验，咱们须要根据业务场景预估达到的并发量等因素，来设计适合本身业务场景的高并发处理方案。

在电商相关产品开发的这些年，我有幸的遇到了并发下的各类坑，这一路摸爬滚打过来有着很多的血泪史，这里进行的总结，做为本身的归档记录，同时分享给你们。

服务器架构

业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。 

一个能够支持高并发的服务少不了好的服务器架构，须要有均衡负载，数据库须要主从集群，nosql缓存须要主从集群，静态文件须要上传cdn，这些都是能让业务程序流畅运行的强大后盾。

服务器这块可能是须要运维人员来配合搭建，具体我就很少说了，点到为止。

大体须要用到的服务器架构以下：

• 服务器

• 均衡负载(如：nginx，阿里云SLB)

• 资源监控

• 分布式

• 数据库

• 主从分离，集群

• DBA 表优化，索引优化，等

• 分布式

• nosql

• 主从分离，集群

• 主从分离，集群

• 主从分离，集群

• redis

• mongodb

• memcache

• cdn

• html

• css

• js

• image

并发测试

高并发相关的业务，须要进行并发的测试，经过大量的数据分析评估出整个架构能够支撑的并发量。

测试高并发可使用第三方服务器或者本身测试服务器，利用测试工具进行并发请求测试，分析测试数据获得能够支撑并发数量的评估，这个能够做为一个预警参考，俗话说知己自彼百战不殆。

实战方案

通用方案

日用户流量大，可是比较分散，偶尔会有用户高聚的状况；

场景： 用户签到，用户中心，用户订单，等

场景中的这些业务基本是用户进入APP后会操做到的，除了活动日(618,双11，等)，这些业务的用户量都不会高汇集，同时这些业务相关的表都是大数据表，业务可能是查询操做，因此咱们须要减小用户直接命中DB的查询；优先查询缓存，若是缓存不存在，再进行DB查询，将查询结果缓存起来。

更新用户相关缓存须要分布式存储，好比使用用户ID进行hash分组，把用户分布到不一样的缓存中，这样一个缓存集合的总量不会很大，不会影响查询效率。

方案如：

• 用户签到获取积分

• 计算出用户分布的key,redis hash中查找用户今日签到信息

• 若是查询到签到信息，返回签到信息

• 若是没有查询到，DB查询今日是否签到过，若是有签到过，就把签到信息同步redis缓存。

• 若是DB中也没有查询到今日的签到记录，就进行签到逻辑，操做DB添加今日签到记录，添加签到积分(这整个DB操做是一个事务)

• 缓存签到信息到redis，返回签到信息

• 注意这里会有并发状况下的逻辑问题，如：一天签到屡次，发放屡次积分给用户。

• 用户订单

• 这里咱们只缓存用户第一页的订单信息，一页40条数据，用户通常也只会看第一页的订单数据

• 用户访问订单列表，若是是第一页读缓存，若是不是读DB

• 计算出用户分布的key,redis hash中查找用户订单信息

• 若是查询到用户订单信息，返回订单信息

• 若是不存在就进行DB查询第一页的订单数据，而后缓存redis，返回订单信息

• 用户中心

• 计算出用户分布的key,redis hash中查找用户订单信息

• 若是查询到用户信息，返回用户信息

• 若是不存在进行用户DB查询，而后缓存redis，返回用户信息

• 其余业务

• 上面例子可能是针对用户存储缓存，若是是公用的缓存数据须要注意一些问题，以下

• 注意公用的缓存数据须要考虑并发下的可能会致使大量命中DB查询，可使用管理后台更新缓存，或者DB查询的锁住操做。

• 个人博文《大话Redis进阶》（http://blog.thankbabe.com/2016/08/05/redis-up/）对更新缓存问题和推荐方案的分享。

消息队列

秒杀、秒抢等活动业务，用户在瞬间涌入产生高并发请求

场景：定时领取红包，等

场景中的定时领取是一个高并发的业务，像秒杀活动用户会在到点的时间涌入，DB瞬间就接受到一记暴击，hold不住就会宕机，而后影响整个业务；

像这种不是只有查询的操做而且会有高并发的插入或者更新数据的业务，前面提到的通用方案就没法支撑，并发的时候都是直接命中DB；

设计这块业务的时候就会使用消息队列的，能够将参与用户的信息添加到消息队列中，而后再写个多线程程序去消耗队列，给队列中的用户发放红包；

方案如：

• 定时领取红包

• 通常习惯使用 redis的 list

• 当用户参与活动，将用户参与信息push到队列中

• 而后写个多线程程序去pop数据，进行发放红包的业务

• 这样能够支持高并发下的用户能够正常的参与活动，而且避免数据库服务器宕机的危险

附加： 

经过消息队列能够作不少的服务。 

如：定时短信发送服务，使用sset(sorted set)，发送时间戳做为排序依据，短信数据队列根据时间升序，而后写个程序定时循环去读取sset队列中的第一条，当前时间是否超过发送时间，若是超过就进行短信发送。

一级缓存

高并发请求链接缓存服务器超出服务器可以接收的请求链接量，部分用户出现创建链接超时没法读取到数据的问题；

所以须要有个方案当高并发时候时候能够减小命中缓存服务器；

这时候就出现了一级缓存的方案，一级缓存就是使用站点服务器缓存去存储数据，注意只存储部分请求量大的数据，而且缓存的数据量要控制，不能过度的使用站点服务器的内存而影响了站点应用程序的正常运行，一级缓存须要设置秒单位的过时时间，具体时间根据业务场景设定，目的是当有高并发请求的时候可让数据的获取命中到一级缓存，而不用链接缓存nosql数据服务器，减小nosql数据服务器的压力

好比APP首屏商品数据接口，这些数据是公共的不会针对用户自定义，并且这些数据不会频繁的更新，像这种接口的请求量比较大就能够加入一级缓存

静态化数据

高并发请求数据不变化的状况下若是能够不请求本身的服务器获取数据那就能够减小服务器的资源压力。

对于更新频繁度不高，而且数据容许短期内的延迟，能够经过数据静态化成JSON，XML,HTML等数据文件上传CDN，在拉取数据的时候优先到CDN拉取，若是没有获取到数据再从缓存，数据库中获取，当管理人员操做后台编辑数据再从新生成静态文件上传同步到CDN，这样在高并发的时候可使数据的获取命中在CDN服务器上。

CDN节点同步有必定的延迟性，因此找一个靠谱的CDN服务器商也很重要

分层，分割，分布式

大型网站要很好支撑高并发，这是须要长期的规划设计 

在初期就须要把系统进行分层，在发展过程当中把核心业务进行拆分红模块单元，根据需求进行分布式部署，能够进行独立团队维护开发。

• 分层

• 将系统在横向维度上切分红几个部分，每一个部门负责一部分相对简单并比较单一的职责，而后经过上层对下层的依赖和调度组成一个完整的系统

• 好比把电商系统分红：应用层，服务层，数据层。(具体分多少个层次根据本身的业务场景)

• 应用层：网站首页，用户中心，商品中心，购物车，红包业务，活动中心等，负责具体业务和视图展现

• 服务层：订单服务，用户管理服务，红包服务，商品服务等，为应用层提供服务支持

• 数据层：关系数据库，nosql数据库 等，提供数据存储查询服务

• 分层架构是逻辑上的，在物理部署上能够部署在同一台物理机器上，可是随着网站业务的发展，必然须要对已经分层的模块分离部署，分别部署在不一样的服务器上，使网站能够支撑更多用户访问

• 分割

• 在纵向方面对业务进行切分，将一块相对复杂的业务分割成不一样的模块单元

• 包装成高内聚低耦合的模块不只有助于软件的开发维护，也便于不一样模块的分布式部署，提升网站的并发处理能力和功能扩展

• 好比用户中心能够分割成：帐户信息模块，订单模块，充值模块，提现模块，优惠券模块等

• 分布式

• 分布式应用和服务,将分层或者分割后的业务分布式部署，独立的应用服务器，数据库，缓存服务器

• 当业务达到必定用户量的时候，再进行服务器均衡负载，数据库，缓存主从集群

• 分布式静态资源，好比：静态资源上传cdn

• 分布式计算，好比：使用hadoop进行大数据的分布式计算

• 分布式数据和存储,好比：各分布节点根据哈希算法或其余算法分散存储数据

集群

 

对于用户访问集中的业务独立部署服务器，应用服务器，数据库，nosql数据库。 核心业务基本上须要搭建集群，即多台服务器部署相同的应用构成一个集群，经过负载均衡设备共同对外提供服务， 服务器集群可以为相同的服务提供更多的并发支持，所以当有更多的用户访问时，只须要向集群中加入新的机器便可, 另外能够实现当其中的某台服务器发生故障时，能够经过负载均衡的失效转移机制将请求转移至集群中其余的服务器上，所以能够提升系统的可用性

 

• 应用服务器集群

• nginx 反向代理

• slb

• … …

• (关系/nosql)数据库集群

• 主从分离，从库集群

异步

在高并发业务中若是涉及到数据库操做，主要压力都是在数据库服务器上面，虽然使用主从分离，可是数据库操做都是在主库上操做，单台数据库服务器链接池容许的最大链接数量是有限的 

当链接数量达到最大值的时候，其余须要链接数据操做的请求就须要等待有空闲的链接，这样高并发的时候不少请求就会出现connection time out 的状况 

那么像这种高并发业务咱们要如何设计开发方案能够下降数据库服务器的压力呢？

• 如：

• 自动弹窗签到，双11跨0点的时候并发请求签到接口

• 双11抢红包活动

• 双11订单入库

• 等

• 设计考虑：

• 逆向思惟，压力在数据库，那业务接口就不进行数据库操做不就没压力了

• 数据持久化是否容许延迟？

• 如何让业务接口不直接操做DB，又可让数据持久化？

• 方案设计：

• 像这种涉及数据库操做的高并发的业务，就要考虑使用异步了

• 客户端发起接口请求，服务端快速响应，客户端展现结果给用户，数据库操做经过异步同步

• 如何实现异步同步？

• 使用消息队列，将入库的内容enqueue到消息队列中，业务接口快速响应给用户结果(能够舒适提示高峰期延迟到帐)

• 而后再写个独立程序从消息队列dequeue数据出来进行入库操做，入库成功后刷新用户相关缓存，若是入库失败记录日志，方便反馈查询和从新持久化

• 这样一来数据库操做就只有一个程序(多线程)来完成，不会给数据带来压力

• 补充：

• 消息队列除了能够用在高并发业务，其余只要有相同需求的业务也是可使用，如：短信发送中间件等

• 高并发下异步持久化数据可能会影响用户的体验，能够经过可配置的方式，或者自动化监控资源消耗来切换时时或者使用异步，这样在正常流量的状况下可使用时时操做数据库来提升用户体验

• 异步同时也能够指编程上的异步函数，异步线程，在有的时候可使用异步操做，把不须要等待结果的操做放到异步中，而后继续后面的操做，节省了等待的这部分操做的时间

缓存

高并发业务接口多数都是进行业务数据的查询，如：商品列表，商品信息，用户信息，红包信息等，这些数据都是不会常常变化，而且持久化在数据库中

高并发的状况下直接链接从库作查询操做，多台从库服务器也抗不住这么大量的链接请求数（前面说过，单台数据库服务器容许的最大链接数量是有限的）

那么咱们在这种高并发的业务接口要如何设计呢？

• 设计考虑：

• 仍是逆向思惟，压力在数据库，那么咱们就不进行数据库查询

• 数据不常常变化，咱们为啥要一直查询DB？

• 数据不变化客户端为啥要向服务器请求返回同样的数据？

• 方案设计：

• 数据不常常变化，咱们能够把数据进行缓存，缓存的方式有不少种，通常的：应用服务器直接Cache内存，主流的：存储在memcache、redis内存数据库

• Cache是直接存储在应用服务器中，读取速度快，内存数据库服务器容许链接数能够支撑到很大，并且数据存储在内存，读取速度快，再加上主从集群，能够支撑很大的并发查询

• 根据业务情景，使用配合客户端本地存，若是咱们数据内容不常常变化，为啥要一直请求服务器获取相同数据，能够经过匹配数据版本号，若是版本号不同接口从新查询缓存返回数据和版本号，若是同样则不查询数据直接响应

• 这样不只能够提升接口响应速度，也能够节约服务器带宽，虽然有些服务器带宽是按流量计费，可是也不是绝对无限的，在高并发的时候服务器带宽也可能致使请求响应慢的问题

• 补充：

• 缓存同时也指静态资源客户端缓存

• cdn缓存，静态资源经过上传cdn，cdn节点缓存咱们的静态资源，减小服务器压力

面向服务

• SOA面向服务架构设计

• 微服务更细粒度服务化，一系列的独立的服务共同组成系统

使用服务化思惟，将核心业务或者通用的业务功能抽离成服务独立部署，对外提供接口的方式提供功能。

最理想化的设计是能够把一个复杂的系统抽离成多个服务，共同组成系统的业务，优势：松耦合，高可用性，高伸缩性，易维护。

经过面向服务化设计，独立服务器部署，均衡负载，数据库集群，可让服务支撑更高的并发

• 服务例子：

• 用户行为跟踪记录统计

• 说明：

• 经过上报应用模块，操做事件，事件对象，等数据，记录用户的操做行为

• 好比：记录用户在某个商品模块，点击了某一件商品，或者浏览了某一件商品

• 背景：

• 因为服务须要记录用户的各类操做行为，而且能够重复上报，准备接入服务的业务又是核心业务的用户行为跟踪，因此请求量很大，高峰期会产生大量并发请求 

• 架构：

• nodejs WEB应用服务器均衡负载

• redis主从集群

• mysql主

• nodejs+express+ejs+redis+mysql

• 服务端采用nodejs,nodejs是单进程（PM2根据cpu核数开启多个工做进程），采用事件驱动机制，适合I/O密集型业务，处理高并发能力强 

• 业务设计：

• 并发量大，因此不能直接入库，采用：异步同步数据,消息队列

• 请求接口上报数据，接口将上报数据push到redis的list队列中

• nodejs写入库脚本，循环pop redis list数据，将数据存储入库，并进行相关统计Update，无数据时sleep几秒

• 由于数据量会比较大，上报的数据表按天命名存储 

• 接口：

• 上报数据接口

• 统计查询接口

• 上线跟进：

• 服务业务基本正常

• 天天的上报表有上千万的数据

冗余，自动化

当高并发业务所在的服务器出现宕机的时候，须要有备用服务器进行快速的替代，在应用服务器压力大的时候能够快速添加机器到集群中，因此咱们就须要有备用机器能够随时待命。 最理想的方式是能够经过自动化监控服务器资源消耗来进行报警，自动切换降级方案，自动的进行服务器替换和添加操做等，经过自动化能够减小人工的操做的成本，并且能够快速操做，避免人为操做上面的失误。

• 冗余

• 数据库备份

• 备用服务器

• 自动化

• 自动化监控

• 自动化报警

• 自动化降级

经过GitLab事件，咱们应该反思，作了备份数据并不表明就万无一失了，咱们须要保证高可用性，首先备份是否正常进行，备份数据是否可用，须要咱们进行按期的检查，或者自动化监控， 还有包括如何避免人为上的操做失误问题。(不过事件中gitlab的开放性姿态，积极的处理方式仍是值得学习的）

总结

高并发架构是一个不断衍变的过程，冰洞三尺非一日之寒，长城筑成非一日之功 。打好基础架构方便之后的拓展，这点很重要。

原文连接：https://mp.weixin.qq.com/s/g0hUrgVZZ8iv3cDCxDZxpw