大话架构—深度展现最全的高并发

Hi ! 我是小小,今天是本周的第六篇,本月的最后一篇,你还好吗?我是小小,我们本周的内容是大话高并发架构

前言

高并发经常会发生在有大量用户量,用户高聚集的业务场景,例如秒杀活动,定时领取红包。
为了让业务可以在高并发的时候能够相当好的运行,并给用户一个良好的交互体验,所以,考虑各种高并发的场景,设计高并发架构。

服务器架构

业务从初期到成熟,从单一到集群,最后到分布式,需要有服务器的负载均衡,数据的主从复制,nosql的各种集群,静态文件上传cdn等等。
需要用到的服务器架构如下

服务器

负载均衡,如阿里云的slb 或者是nginx
资源监控
分布式

数据库

主从分离,集群
DBA表优化,索引优化
分布式

nosql

redis:主从分离,集群
mongodb: 主从分离,集群
memcache:主从分离,集群

cdn

html
css
js
image

并发测试

对于高并发业务,需要进行高并发的业务测试,通过大量的数据分析评估整个架构支撑的并发量。
测试并发使用的工具如下
阿里云性能测试
jmetter
visual studio 性能负载测试
Microsoft Web Application Stress Tool

实现方案

通用方案

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

场景

用户签到,用户中心,用户订单

服务器架构

说明

这些场景,基本都是用户进入app后会操作,这些用户不会高聚集,同时这些表又是大的数据表,业务很多,所以需要减少DB的查询,优先查询缓存,如果缓存不存在,再命中DB。
所以需要使用缓存,为了降低缓存,所以使用分布式的缓存,对DB实现hash分组,把用户分布到不同的缓存中,不会影响查询效率。

方案

用户签到

计算用户分布的key,redis hash中查找用户今日签到的消息
能查询到,返回查询的信息
如果没有查询到,DB查询今日是否抢到过,如果抢到过,信息同步redis
如果db也没有查询到,进行签到逻辑,db添加今日签到记录。这是一个事物
缓存签到信息到redis,返回签到信息

用户订单

这里只缓存第一页订单信息
用户访问订单列表,如果是第一页读缓存,如果不是读DB
计算出用户分布的key,redis hash中查找用户订单信息
如果能查询到用户订单信息,返回订单信息
如果不存在用户信息,就直接db查询第一页 订单数据,然后缓存redis,返回订单信息

用户中心

计算用户key,redis hash 中查找出用户订单信息
能查找到,返回用户信息
如果未找到,缓存redis,返回用户信息

以上的仅仅是一个相对于比较简单的并发架构

消息队列

用于缓存秒杀,活动,用户在一瞬间涌入产生的高并发的请求

场景:

定时领取红包。

架构

说明

场景中的定时领取是一个高并发的业务,秒杀活动会在一瞬间涌入。
这种业务会直接命中DB,会导致数据的崩溃。
设计这种业务的时候,需要使用消息队列,可以把参与的用户信息添加到消息队列中,然后缓慢的消耗。

方案

定时领取红包:
使用redis的list
当用户参与活动,用户信息push到队列中
书写多个线程去pop数据,进行发放红包的业务。

一级缓存

一级缓存就是使用站点服务器去缓存数据,只缓存部分请求量大的数据,并且数据量还需要控制,一级缓存需要设置秒为单位的过期时间,具体业务场景看业务场景而定,目的是有高并发的时候可以让数据获取命中到一级缓存,减少nosql的压力。

架构图

场景

APP首屏的数据接口

静态化数据

对于更新不频繁,并且数据允许短时间内的延迟,可以通过数据静态化成json,xml,html等数据文件上传cdn,然后拉取数据的时候优先拉取cdn,然后再缓存,最后数据库,用于减轻db的压力。

分层,分割,分布式

大型网站需要很好的支撑高并发,这需要很长的规划设计,主要需要如下

  1. 分层:
    系统在横向维度切分成几个部分,每个部门负责一部分相对简单并且单一的职责,然后通过上层,对下层的完整依赖形成一个完整的系统。
    例如把一个电商分为,应用层,服务层,数据层。
    应用层:网站首页,用户中心
    服务层:订单服务,用户管理服务
    数据层:关系型数据库,nosql数据库。
  2. 分割
    在纵向对业务进行切分
    例如,用户中心可以分割成为账户信息模块,订单模块,充值模块,提现模块,优惠券模块
  3. 分布式
    分布式应用和服务,把应用进行分布式部署。
    当业务达到一定用户量的时候,需要对服务器进行负载均衡,数据库,缓存主从集群
    分布式静态资源,静态资源上传cdn
    分布式计算,使用hadoop进行大数据分布式计算

集群

对于用户访问集中的服务器,搭建集群,通过负载均衡共同对外提供服务,当有更多的用户访问的时候,只需要加机器即可。

ngixn反向代理
slb
数据库的主从分离

异步

在高并发业务场景中,如果涉及到数据库操作,主要压力是在数据库服务器上,当连接数量达到最大值的时候,有其他连接数据库的请求操作的时候,就需要有空闲的连接。

场景

自动弹窗签到
双十一抢红包
双十一订单入库

设计

使用消息队列,把入库的内容放入到消息队列中,业务接口直接返回提示,高峰期延迟到账。
然后再写独立程序从消息队列中,读取进行入库操作,入库成功以后刷新缓存,如果入库失败,记录日志,方便查询反馈和重新持久化。

补充

其他场景,例如短信发送

面向服务

soa 面向服务架构设计
微服务更加细腻度的服务化。

例子

用户行为跟踪记录统计

说明

通过上报应用模块,操作事件,事件对象,等数据,记录用户操作行为。
例如用户在某个商品模块点击了某一件商品,或者看了某一件商品。

架构

node.js web 应用负载均衡
redis主从集群
mysql主从复制
nodejs + express + ejs + redis + mysql

冗余自动化

当高并发业务出现单击的时候,需要快速的有备用的替代,所以需要自动化执行这些操作

冗余

数据库备份
备份服务器

自动化

自动化监控
自动化报警
自动化降级

我是小小,一枚生于二线,活在一线城市的程序猿,我是小小,我们下期再见。


おすすめ

転載: blog.csdn.net/pisa8559/article/details/111044583