原文地址;
高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等。
为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己业务场景的高并发处理方案。
服务器架构
业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务。
一个可以支持高并发的服务少不了好的服务器架构,需要有均衡负载,数据库需要主从集群,nosql缓存需要主从集群,静态文件需要上传cdn,这些都是能让业务程序流畅运行的强大后盾。
服务器这块多是需要运维人员来配合搭建,具体我就不多说了,点到为止。
大致需要用到的服务器架构如下:
-
服务器
-
均衡负载(如:nginx,阿里云SLB)
-
资源监控
-
分布式
-
-
数据库
-
主从分离,集群
-
DBA 表优化,索引优化,等
-
分布式
-
-
nosql
-
主从分离,集群
-
主从分离,集群
-
主从分离,集群
-
redis
-
mongodb
-
memcache
-
-
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,返回用户信息
-
-
以上例子是一个相对简单的高并发架构,并发量不是很高的情况可以很好的支撑,但是随着业务的壮大,用户并发量增加,我们的架构也会进行不断的优化和演变,比如对业务进行服务化,每个服务有自己的并发架构,自己的均衡服务器,分布式数据库,nosql主从集群,如:用户服务、订单服务;