支付宝架构师眼中的高并发架构，真是绝了！

最新推荐文章于 2024-06-20 15:45:04 发布

Android失眠夜

最新推荐文章于 2024-06-20 15:45:04 发布

阅读量1k

点赞数 9

分类专栏： Java程序员文章标签：架构

本文链接：https://blog.csdn.net/m0_61418075/article/details/136817555

版权

Java程序员专栏收录该内容

8 篇文章 0 订阅

订阅专栏

文章讨论了高并发环境下的测试方法，包括使用第三方服务、并发测试工具，以及针对用户签到、订单等场景的具体解决方案，涉及分布式存储、消息队列、一级缓存和CDN等技术。同时，还强调了随着业务增长和复杂性的增加，架构优化和分布式技术的重要性。

摘要由CSDN通过智能技术生成

cdn
html
css
js
image

并发测试

高并发相关的业务，需要进行并发的测试，通过大量的数据分析评估出整个架构可以支撑的并发量。

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

第三方服务：

阿里云性能测试

并发测试工具：

Apache JMeter
Visual Studio性能负载测试
Microsoft Web Application Stress Tool

实战方案

通用方案

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

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

服务器架构图：

图片

说明：

场景中的这些业务基本是用户进入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查询的锁住操作。

以上例子是一个相对简单的高并发架构，并发量不是很高的情况可以很好的支撑，但是随着业务的壮大，用户并发量增加，我们的架构也会进行不断的优化和演变，比如对业务进行服务化，每个服务有自己的并发架构，自己的均衡服务器，分布式数据库，nosql主从集群，如：用户服务、订单服务；

消息队列

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

场景：定时领取红包，等

服务器架构图：

图片

说明：

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

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

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

方案如：

定时领取红包
一般习惯使用 redis的 list
当用户参与活动，将用户参与信息push到队列中
然后写个多线程程序去pop数据，进行发放红包的业务
这样可以支持高并发下的用户可以正常的参与活动，并且避免数据库服务器宕机的危险

附加：

通过消息队列可以做很多的服务。

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

一级缓存

高并发请求连接缓存服务器超出服务器能够接收的请求连接量，部分用户出现建立连接超时无法读取到数据的问题；

因此需要有个方案当高并发时候时候可以减少命中缓存服务器；

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

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

服务器架构图：

图片

合理的规范和使用nosql缓存数据库，根据业务拆分缓存数据库的集群，这样基本可以很好支持业务，一级缓存毕竟是使用站点服务器缓存所以还是要善用。

静态化数据

高并发请求数据不变化的情况下如果可以不请求自己的服务器获取数据那就可以减少服务器的资源压力。

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

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

其他方案

对于更新频繁度不高的数据，APP,PC浏览器，可以缓存数据到本地，然后每次请求接口的时候上传当前缓存数据的版本号，服务端接收到版本号判断版本号与最新数据版本号是否一致，如果不一样就进行最新数据的查询并返回最新数据和最新版本号，如果一样就返回状态码告知数据已经是最新。减少服务器压力：资源、带宽等.

分层，分割，分布式

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

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

分层
将系统在横向维度上切分成几个部分，每个部门负责一部分相对简单并比较单一的职责，然后通过上层对下层的依赖和调度组成一个完整的系统
比如把电商系统分成：应用层，服务层，数据层。(具体分多少个层次根据自己的业务场景)
应用层：网站首页，用户中心，商品中心，购物车，红包业务，活动中心等，负责具体业务和视图展示
服务层：订单服务，用户管理服务，红包服务，商品服务等，为应用层提供服务支持
数据层：关系数据库，nosql数据库等，提供数据存储查询服务
分层架构是逻辑上的，在物理部署上可以部署在同一台物理机器上，但是随着网站业务的发展，必然需要对已经分层的模块分离部署，分别部署在不同的服务器上，使网站可以支撑更多用户访问
分割
在纵向方面对业务进行切分，将一块相对复杂的业务分割成不同的模块单元
包装成高内聚低耦合的模块不仅有助于软件的开发维护，也便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展
比如用户中心可以分割成：账户信息模块，订单模块，充值模块，提现模块，优惠券模块等
分布式
分布式应用和服务,将分层或者分割后的业务分布式部署，独立的应用服务器，数据库，缓存服务器
当业务达到一定用户量的时候，再进行服务器均衡负载，数据库，缓存主从集群
分布式静态资源，比如：静态资源上传cdn
分布式计算，比如：使用hadoop进行大数据的分布式计算
分布式数据和存储,比如：各分布节点根据哈希算法或其他算法分散存储数据

图片

网站分层-图1来自网络

集群

–

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