高并发设计方案一

╰+攻爆jí腚メ 2023-10-18 18:22 5阅读 0赞

**设计思路：**

<code>（1） 服务器：
 均衡负载(如：nginx，阿里云SLB)
 资源监控
 分布式
 （2） 数据库
 主从分离，集群
 DBA 表优化，索引优化，等
 分布式
 （3） nosql
 redis 铭记：Redis只放热数据
 主从分离，集群
 mongodb
 主从分离，集群
 memcache
 主从分离，集群
 （4） cdn
 html
 css
 js
 image</code>

**1、通用方案**

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

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

服务器架构图：  
![这里写图片描述][20160926150253736]  
说明：

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

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

**使用场景：**

（1） 用户签到获取积分

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

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

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

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

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

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

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

（2） 用户订单

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

用户访问订单列表，如果是第一页读缓存，如果不是读DB

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

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

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

<code>如上所示，缓存用户第一页的订单数据进redis，那如果用户又添加了一个订单，这缓存的第一页数据如何更新呢？
 
 两种方案：
 1.当用户有新订单的时候删除缓存，等到用户进入订单列表时优先读缓存，缓存无数据时就从DB读出最新的订单缓存到Redis中。
 2.将需要更新订单的用户加入【更新订单用户队列】中，然后多线程程序去消耗队列，更新用户订单缓存。
 根据你的实际的业务情景去选择吧</code>

（3） 用户中心

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

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

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

（4） 其他业务

上面例子多是针对用户存储缓存，如果是公用的缓存数据需要注意一些问题，如下

注意公用的缓存数据需要考虑并发下的可能会导致大量命中DB查询，可以使用管理后台更新缓存，或者DB查询的锁住操作。

我的博文[\[大话Redis进阶\]][Redis]对更新缓存问题和推荐方案的分享。

以上例子是一个相对简单的高并发架构，并发量不是很高的情况可以很好的支撑，但是随着业务的壮大，用户并发量增加，我们的架构也会进行不断的优化和演变，比如对业务进行服务化，每个服务有自己的并发架构，自己的均衡服务器，分布式数据库，nosql主从集群，如：用户服务、订单服务；

**消息队列**

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

**场景：定时领取红包，等**

服务器架构图：  
![这里写图片描述][20160926152012182]  
说明：

场景中的定时领取是一个高并发的业务，像秒杀活动用户会在到点的时间涌入，DB瞬间就接受到一记暴击，hold不住就会宕机，然后影响整个业务；

像这种不是只有查询的操作并且会有高并发的插入或者更新数据的业务，前面提到的通用方案就无法支撑，并发的时候都是直接命中DB；

设计这块业务的时候就会使用消息队列，可以将参与用户的信息添加到消息队列中，然后再写个多线程程序去消耗队列，给队列中的用户发放红包；

方案如：

**定时领取红包**

一般习惯使用 redis的 list

当用户参与活动，将用户参与信息push到队列中

然后写个多线程程序去pop数据，进行发放红包的业务

这样可以支持高并发下的用户可以正常的参与活动，并且避免数据库服务器宕机的危险

附加：

通过消息队列可以做很多的服务。

如：定时短信发送服务，使用sset(sorted set)，发送时间戳作为排序依据，短信数据队列根据时间升序，然后写个程序定时循环去读取sset队列中的第一条，当前时间是否超过发送时间，如果超过就进行短信发送。

**一级缓存**

高并发请求连接缓存服务器，超出服务器能够接收的请求连接量，部分用户出现建立连接超时无法读取到数据的问题；

因此需要有个方案当高并发时候时候可以减少命中缓存服务器；

这时候就出现了一级缓存的方案，一级缓存就是使用站点服务器缓存去存储数据，注意只存储部分请求量大的数据，并且缓存的数据量要控制，不能过分使用站点服务器的内存，从而影响了站点应用程序的正常运行，一级缓存需要设置秒单位的过期时间，具体时间根据业务场景设定，目的是当有高并发请求的时候可以让数据的获取命中到一级缓存，而不用连接缓存nosql数据服务器，减少nosql数据服务器的压力；

比如**APP首屏商品数据接口**，这些数据是公共的，不会针对用户自定义，而且这些数据不会频繁的更新，像这种接口的请求量比较大就可以加入一级缓存；  
服务器架构图：  
![这里写图片描述][20160926152436059]

合理和规范使用nosql缓存数据库，根据业务拆分缓存数据库的集群，这样基本可以很好支持业务，一级缓存毕竟是使用站点服务器缓存，所以还是要善用。

**静态化数据**

高并发请求数据不变化的情况下，如果可以不请求自己的服务器获取数据，那就可以减少服务器的资源压力。

对于更新频繁度不高，并且数据允许短时间内的延迟，可以通过数据静态化成JSON、XML、HTML等数据文件上传CDN，在拉取数据的时候优先到CDN拉取，如果没有获取到数据再从缓存数据库中获取，当管理人员操作后台编辑数据再重新生成静态文件上传同步到CDN，这样在高并发的时候可以使数据的获取命中在CDN服务器上。

CDN节点同步有一定的延迟性，所以找一个靠谱的CDN服务器商也很重要

对于单页面访问量巨大的可以将其专门做成静态页面

**主从分离、分库分表**

读写分离是大家看到的第二个高并发的架构了，也很常规，因为一般情况下读比写要多得多，所以数据库的主库写，从库们提供读操作，一下就把数据库的并发性能提高了。

如果还不够，那么分库分表把，把数据分到各个数据库的各个机器上，进一步的减少单台机器的压力，从而达到高并发的目的。

如果是分库分表，有时候使用的就是哈希技术了，以某个字段哈希一下然后来分库分表，读写分离的读操作，基本也是通过哈希技术把读落到不同的机器上去减轻单机压力。

[http://blog.csdn.net/u013372487/article/details/51612161][http_blog.csdn.net_u013372487_article_details_51612161]

**合理数据结构->优化代码->外部通用方法**

解决性能问题，首先要有合理的数据结构，之后要优化代码，只有在最优化之后再考虑外部通用方法如缓存等，因为一开始使用了缓存等方法以后就没有太多进一步优化空间了。

**其他方案**

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

**代码才是关键，架构都是锦上添花的东西，既然是锦上添花的，必然坑多，没有什么捷径。**

**来源:**[https://blog.csdn.net/u013372487/article/details/52670635][https_blog.csdn.net_u013372487_article_details_52670635]

[20160926150253736]: https://img-blog.csdn.net/20160926150253736
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzA5ODM5MDU3MA==&mid=2650862038&idx=1&sn=42fa92e2ff9f61a10af6ef7b360e94b9&chksm=8b661693bc119f85a265ec4ad2de599c5268adc9f694631a6946e3287dfa713b5fc2702a1ff7&scene=21#wechat_redirect
[Redis]: https://segmentfault.com/q/1010000006222395
[20160926152012182]: https://img-blog.csdn.net/20160926152012182
[20160926152436059]: https://img-blog.csdn.net/20160926152436059
[http_blog.csdn.net_u013372487_article_details_51612161]: http://blog.csdn.net/u013372487/article/details/51612161
[https_blog.csdn.net_u013372487_article_details_52670635]: https://blog.csdn.net/u013372487/article/details/52670635