程序猿眼里的高并发架构.docxVIP

程序猿眼里的高并发架构 2021-01-09 前言 高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中，如：秒宰活动，定时领取红包等。 为了让业务可以流畅的运转并且给用户一个好的交互体验，我们需要依据业务场景预估达到的并发量等因素，来设计适合本人业务场景的高并发处理方案。 服务器架构 业务从进展的初期到渐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。 一个可以支持高并发的服务少不了好的服务器架构，需要有均衡负载，数据库需要主从集群，nosql缓存需要主从集群，静态文件需要上传cdn，这些都是能让业务程序流畅运转的强大后盾。 服务器这块多是需要运维人员来协作搭建，具体我就不多说了，点到为止。 大致需要用到的服务器架构如下： 服务器 均衡负载(如：nginx，阿里云SLB) 资源监控 分布式 数据库 主从分别，集群 DBA 表优化，索引优化，等 分布式 nosql redis主从分别，集群 mongodb主从分别，集群 memcache主从分别，集群 cdn html css js image 并发测试 高并发相关的业务，需要进行并发的测试，通过大量的数据分析评估出整个架构可以支撑的并发量。 测试高并发可以使用第三方服务器或者本人测试服务器，利用测试工具进行并发恳求测试，分析测试数据得到可以支撑并发数量的评估，这个可以作为一个预警参考，俗话说知己自彼百战不殆。 第三方服务: 阿里云功能测试 并发测试工具： Apache JMeter Visual Studio功能负载测试 Microsoft Web Application Stress Tool 实战方案 通用方案 日用户流量大，但是比较分散，间或会有用户高聚集的情况； 场景： 用户签到，用户中心，用户订单，等 服务器架构图： 说明： 场景中的这些业务基本是用户进入APP后会操作到的，除了活动日(618，双11，等)，这些业务的用户量都不会高聚集，同时这些业务相关的表都是大数据表，业务多是查询操作，所以我们需要削减用户直接命中DB的查询；优先查询缓存，假如缓存不存在，再进行DB查询，将查询结果缓存起来。 更新用户相关缓存需要分布式存储，比如使用用户ID进行hash分组，把用户分布到不同的缓存中，这样一个缓存集合的总量不会很大，不会影响查询效率。 方案如： 用户签到猎取积分 计算出用户分布的key,redis hash中查找用户今日签到信息 假如查询到签到信息，前往签到信息 假如没有查询到，DB查询今日能否签到过，假如已经签到过，就把签到信息同步redis缓存。 假如DB中也没有查询到今日的签到记录，就进行签到规律，操作DB添加今日签到记录，添加签到积分(这整个DB操作是一个事务) 缓存签到信息到redis，前往签到信息 留意这里会有并发情况下的规律问题，如：一天签到多次，发放多次积分给用户。 用户订单 这里我们只缓存用户第一页的订单信息，一页40条数据，用户一般也只会看第一页的订单数据 用户访问订单列表，假如是第一页读缓存，假如不是读DB 计算出用户分布的key,redis hash中查找用户订单信息 假如查询到用户订单信息，前往订单信息 假如不存在就进行DB查询第一页的订单数据，然后缓存redis，前往订单信息 用户中心 计算出用户分布的key,redis hash中查找用户订单信息 假如查询到用户信息，前往用户信息 假如不存在进行用户DB查询，然后缓存redis，前往用户信息 其他业务 上面例子多是针对用户存储缓存，假如是公用的缓存数据需要留意一些问题，如下 留意公用的缓存数据需要考虑并发下的可能会导致大量命中DB查询，可以使用管理后台更新缓存，或者DB查询的锁住操作。 我的博文[大话Redis进阶]对更新缓存问题和推举方案的共享。 以上例子是一个相对简约的高并发架构，并发量不是很高的情况可以很好的支撑，但是随着业务的壮大，用户并发量添加，我们的架构也会进行不断的优化和演化，比如对业务进行服务化，每个服务有本人的并发架构，本人的均衡服务器，分布式数据库，nosql主从集群，如：用户服务、订单服务； 消息队列 秒宰、秒抢等活动业务，用户在霎时涌入产生高并发恳求场景：定时领取红包，等 服务器架构图： 说明： 场景中的定时领取是一个高并发的业务，像秒宰活动用户会在到点的时间涌入，DB霎时就接遭到一记暴击，hold不住就会宕机，然后影响整个业务； 像这种不是只要查询的操作并且会有高并发的插入或者更新数据的业务，前面提到的通用方案就无法支撑，并发的时候都是直接命中DB； 设计这块业务的时候就会使用消息队列，可以将参与用户的信息添加到消息队列中，然后再写个多线程程序去消耗队列，给队列中的用户发放红包； 方案如： 定时领取红包 一般习惯使用 redis