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

用户订单：

• 这里我们只缓存用户第一页的订单信息,一页40条数据,用户一般也只会看第一页的订单数据
• 用户访问订单列表,如果是第一页读缓存,如果不是读DB
• 计算出用户分布的key,hash中查找用户订单信息
• 如果查询到用户订单信息,返回订单信息
• 如果不存在就进行DB查询第一页的订单数据,然后缓存redis,返回订单信息

用户中心：

• 计算出用户分布的key,Redis hash中查找用户订单信息
• 如果查询到用户信息,返回用户信息
• 如果不存在进行用户DB查询,返回用户信息

其他业务：

• 上面例子多是针对用户存储缓存,如果是公用的缓存数据需要注意一些问题,如：公用的缓存数据需要考虑并发下的可能会导致大量命中DB查询,可以使用管理后台更新缓存,或者DB查询的锁住操作.

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

2)消息队列

场景：定时领取红包等.

服务器架构图：

说明：

• 场景中的定时领取是一个高并发的业务,像秒杀活动用户会在到点的时间涌入,DB瞬间就接受到一记暴击,hold不住就会宕机,然后影响整个业务；
• 像这种不是只有查询的操作并且会有高并发的插入或者更新数据的业务,前面提到的通用方案就无法支撑,并发的时候都是直接命中DB；
• 设计这块业务的时候就会使用消息队列的,可以将参与用户的信息添加到消息队列中,然后再写个多线程程序去消耗队列,给队列中的用户发放红包；

方案如：

• 定时领取红包；
• 一般习惯使用 redis的 list；
• 当用户参与活动,将用户参与信息push到队列中；
• 然后写个多线程程序去pop数据,进行发放红包的业务；
• 这样可以支持高并发下的用户可以正常的参与活动,并且避免数据库服务器宕机的危险.

附加：?通过消息队列可以做很多的服务.
如：定时短信发送服务,使用sset(sorted set),发送时间戳作为排序依据,短信数据队列根据时间升序,然后写个程序定时循环去读取sset队列中的第一条,当前时间是否超过发送时间,如果超过就进行短信发送.

3)一级缓存

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

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

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

比如APP首屏商品数据接口,这些数据是公共的不会针对用户自定义,而且这些数据不会频繁的更新,像这种接口的请求量比较大就可以加入一级缓存；

服务器架构图：

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

4)静态化数据

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

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

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

5)其他方案

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

（编辑：ASP站长网）