大话程序猿眼里的高并发架构

（点击 上方蓝字 ，快速关注我们)

来源：SFLYQ

网址： blog.thankbabe.com/2016/09/14/high-concurrency-scheme/#top

前言

高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中，如：秒杀活动，定时领取红包等。

为了让业务可以流畅的运行并且给用户一个好的交互体验，我们需要根据业务场景预估达到的并发量等因素，来设计适合自己业务场景的高并发处理方案。

在电商相关产品开发的这些年，我有幸遇到了并发下的各种坑，这一路摸爬滚打过来有着不少的血泪史，这里做的总结，作为自己的归档记录，同时分享给大家。

服务器架构

业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。

一个可以支持高并发的服务少不了好的服务器架构，需要有均衡负载，数据库需要主从集群，nosql缓存需要主从集群，静态文件需要上传cdn，这些都是能让业务程序流畅运行的强大后盾。

服务器这块多是需要运维人员来配合搭建，具体我就不多说了，点到为止。

大致需要用到的服务器架构如下：

• 服务器

  
  

1. 均衡负载(如：nginx，阿里云SLB)

2. 资源监控

3. 分布式

• 数据库

  
  

1. 主从分离，集群

2. DBA 表优化，索引优化，等

3. 分布式

• nosql

  
  

1. redis
   主从分离，集群

2. mongodb
   主从分离，集群

3. memcache
   主从分离，集群

   
   

• cdn

  
  

1. html

2. css

3. js

4. image

并发测试

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

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

第三方服务:

• 阿里云性能测试

并发测试工具：

• Apache JMeter

• Visual Studio性能负载测试

• Microsoft Web Application Stress Tool

实战方案

通用方案

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

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

服务器架构图：

说明：

场景中的这些业务基本是用户进入APP后会操作到的，除了活动日(618，双11，等)，这些业务的用户量都不会高聚集，同时这些业务相关的表都是大数据表，业务多是查询操作，所以我们需要减少用户直接命中DB的查询；优先查询缓存，如果缓存不存在，再进行DB查询，将查询结果缓存起来。

更新用户相关缓存需要分布式存储，比如使用用户ID进行hash分组，把用户分布到不同的缓存中，这样一个缓存集合的总量不会很大，不会影响查询效率。

方案如：

• 用户签到获取积分

  
  

1. 计算出用户分布的key,redis hash中查找用户今日签到信息

   
   

2. 如果查询到签到信息，返回签到信息

   
   

3. 如果没有查询到，DB查询今日是否签到过，如果已经签到过，就把签到信息同步redis缓存。

   
   

4. 如果DB中也没有查询到今日的签到记录，就进行签到逻辑，操作DB添加今日签到记录，添加签到积分(这整个DB操作是一个事务)

   
   

5. 缓存签到信息到redis，返回签到信息

   
   

6. 注意这里会有并发情况下的逻辑问题，如：一天签到多次，发放多次积分给用户。

   
   

7. 我的博文《 大话程序猿眼里的高并发 》有相关的处理方案。