点击上方 Java后端,选择 设为星标
作者 | sflaqiu
链接 | http://blog.thankbabe.com
高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等。
为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己业务场景的高并发处理方案。
在电商相关产品开发的这些年,我有幸的遇到了并发下的各种坑,这一路摸爬滚打过来有着不少的血泪史,这里进行的总结,作为自己的归档记录,同时分享给大家。
服务器架构
业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务。
一个可以支持高并发的服务少不了好的服务器架构,需要有均衡负载,数据库需要主从集群,nosql缓存需要主从集群,静态文件需要上传cdn,这些都是能让业务程序流畅运行的强大后盾。
服务器这块多是需要运维人员来配合搭建,具体我就不多说了,点到为止。
大致需要用到的服务器架构如下:
服务器
均衡负载(如:nginx,阿里云SLB)
资源监控
分布式
数据库
主从分离,集群
DBA 表优化,索引优化,等
分布式
nosql
主从分离,集群
主从分离,集群
主从分离,集群
redis
mongodb
memcache
cdn
html
css
js
image
并发测试
-
阿里云性能测试
-
Apache JMeter -
Visual Studio性能负载测试 -
Microsoft Web Application Stress Tool
实战方案
通用方案
日用户流量大,但是比较分散,偶尔会有用户高聚的情况;
-
用户签到获取积分 -
计算出用户分布的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/
消息队列
秒杀、秒抢等活动业务,用户在瞬间涌入产生高并发请求
-
定时领取红包 -
一般习惯使用 redis的 list -
当用户参与活动,将用户参与信息push到队列中 -
然后写个多线程程序去pop数据,进行发放红包的业务 -
这样可以支持高并发下的用户可以正常的参与活动,并且避免数据库服务器宕机的危险
-
一级缓存
静态化数据
其他方案
-
对于更新频繁度不高的数据,APP,PC浏览器,可以缓存数据到本地,然后每次请求接口的时候上传当前缓存数据的版本号,服务端接收到版本号判断版本号与最新数据版本号是否一致,如果不一样就进行最新数据的查询并返回最新数据和最新版本号,如果一样就返回状态码告知数据已经是最新。减少服务器压力:资源、带宽等.
分层,分割,分布式
-
分层 -
将系统在横向维度上切分成几个部分,每个部门负责一部分相对简单并比较单一的职责,然后通过上层对下层的依赖和调度组成一个完整的系统 -
比如把电商系统分成:应用层,服务层,数据层。(具体分多少个层次根据自己的业务场景) -
应用层:网站首页,用户中心,商品中心,购物车,红包业务,活动中心等,负责具体业务和视图展示 -
服务层:订单服务,用户管理服务,红包服务,商品服务等,为应用层提供服务支持 -
数据层:关系数据库,nosql数据库 等,提供数据存储查询服务 -
分层架构是逻辑上的,在物理部署上可以部署在同一台物理机器上,但是随着网站业务的发展,必然需要对已经分层的模块分离部署,分别部署在不同的服务器上,使网站可以支撑更多用户访问
-
-
分割 -
在纵向方面对业务进行切分,将一块相对复杂的业务分割成不同的模块单元 -
包装成高内聚低耦合的模块不仅有助于软件的开发维护,也便于不同模块的分布式部署,提高网站的并发处理能力和功能扩展 -
比如用户中心可以分割成:账户信息模块,订单模块,充值模块,提现模块,优惠券模块等
-
-
分布式 -
分布式应用和服务,将分层或者分割后的业务分布式部署,独立的应用服务器,数据库,缓存服务器 -
当业务达到一定用户量的时候,再进行服务器均衡负载,数据库,缓存主从集群 -
分布式静态资源,比如:静态资源上传cdn -
分布式计算,比如:使用hadoop进行大数据的分布式计算 -
分布式数据和存储,比如:各分布节点根据哈希算法或其他算法分散存储数据
-
网站分层-图1来自网络
集群
-
应用服务器集群 -
nginx 反向代理 -
slb -
… …
-
-
(关系/nosql)数据库集群 -
主从分离,从库集群
-
异步
-
如: -
自动弹窗签到,双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几秒 -
因为数据量会比较大,上报的数据表按天命名存储
-
-
接口: -
上报数据接口 -
统计查询接口
-
-
上线跟进: -
服务业务基本正常 -
每天的上报表有上千万的数据
-
冗余,自动化
-
冗余 -
数据库备份 -
备用服务器
-
-
自动化 -
自动化监控 -
自动化报警 -
自动化降级
-
总结
【END】