高并发架构

高并发架构

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

 服务器架构

　　从业务的单一发展到成熟，服务器架构也是从相对单一到集群，再到分布式服务。一个可以支持高并发的服务少不了好的服务器架构，需要有均衡负载，数据库需要主从集群，nosql缓存需要主从集群，静态文件需要上传cdn，这些都是能让业务程序流畅运行的强大后盾。需要用到的服务器架构：服务器架构：均衡负载、资源监控、分布式；数据库分为主从分离，集群、DBA 表优化，索引优化、分布式；nosql：主从分离、集群、redis、mongodb；cdn：html、css、js。

 并发测试

　　高并发相关的业务，需要进行并发的测试，通过大量的数据分析评估出整个架构可以支撑的并发量。测试高并发可以使用第三方服务器或者自己测试服务器，利用测试工具进行并发请求测试，分析测试数据得到可以支撑并发数量的评估。

 第三方服务

　　性能测试

 并发测试工具

　　Apache JMeter

　　Visual Studio性能负载测试

 通用方案（举例：淘宝）

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

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

 方案：

　　用户签到获取积分

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

　　　　如果查询到签到信息，返回签到信息。

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

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

　　　　缓存签到信息到redis，返回签到信息。

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

　　用户订单

　　　　这里我们只缓存用户第一页的订单信息，一页40条数据

　　　　用户访问订单列表，如果是第一页读缓存，如果不是读DB，计算出用户分布的key,redis hash中查找用户订单信息。

　　　　如果查询到用户订单信息，返回订单信息。

　　　　如果不存在就进行DB查询第一页的订单数据，然后缓存redis，返回订单信息。

　　用户中心

　　　　计算出用户分布的key,redis hash中查找用户订单信息。

　　　　如果查询到用户信息，返回用户信息。

　　　　如果不存在进行用户DB查询，然后缓存redis，返回用户信息。

 　　参考：原文章