电商那些年，我摸爬打滚出的高并发架构实战精髓(2)

以下我所知道的：

1. 服务器代理nginx,做服务器的均衡负载,把压力均衡到多台服务器；
2. 部署集群MySQL数据库,Redis服务器,或者MongoDB服务器,把一些常用的查询数据,并且不会经常的变化的数据保存到其他NoSQL DB服务器中,来减少数据库服务器的压力,加快数据的响应速度；
3. 数据缓存,Cache；
4. 在高并发接口的设计中可以使用具有高并发能力的编程语言去开发,如：nodejs做web接口；
5. 服务器部署,图片服务器分离,静态文件走CDN；
6. DBA数据库的优化查询条件,索引优化；
7. 消息存储机制,将数据添加到信息队列中(redis list),然后再写工具去入库
8. 脚本合理控制请求,如,防止用户重复点击导致的ajax多余的请求,等等.

1. Apache JMeter
2. Microsoft Web Application Stress Tool
3. Visual Studio 性能负载

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

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

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

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

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

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

服务器：

• 均衡负载(如：nginx,阿里云SLB)
• 资源监控
• 分布式

数据库：

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

NoSQL：

• Redis

  主从分离,集群

• MongoDB

  主从分离,集群

• memcache

  主从分离,集群

CDN：

• html
• css
• js
• image

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

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

第三方服务:

• 阿里云性能测试

并发测试工具：

• Apache JMeter
• Visual Studio性能负载测试
• Microsoft Web Application Stress Tool

1)通用方案

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

服务器架构图：?

说明：

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

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

方案如：

用户签到获取积分：

• 计算出用户分布的key,Redis,hash中查找用户今日签到信息
• 如果查询到签到信息,返回签到信息
• 如果没有查询到,DB查询今日是否签到过,如果有签到过,就把签到信息同步Redis缓存.
• 如果DB中也没有查询到今日的签到记录,就进行签到逻辑,操作DB添加今日签到记录,添加签到积分(这整个DB操作是一个事务)
• 缓存签到信息到Redis,返回签到信息
• 注意这里会有并发情况下的逻辑问题,如：一天签到多次,发放多次积分给用户.

（编辑：ASP站长网）