如何从零设计一款高并发架构

点击上方蓝色字体，选择“标星公众号”
优质文章，第一时间送达

-     前言    -

-     服务器架构    -

• 服务器
• 均衡负载(如：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进阶》对更新缓存问题和推荐方案的分享。

-     消息队列    -

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

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

-     一级缓存    -

-     静态化数据    -

其他方案

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

-     分层、分割、分布式    -

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

-     集群    -

• 应用服务器集群
• 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几秒
• 因为数据量会比较大，上报的数据表按天命名存储
• 接口：
• 上报数据接口
• 统计查询接口
• 上线跟进：
• 服务业务基本正常
• 每天的上报表有上千万的数据

-     冗余，自动化    -

• 冗余
• 数据库备份
• 备用服务器
• 自动化
• 自动化监控
• 自动化报警
• 自动化降级

-     总结    -

来源：网络