上面例子多是针对用户存储缓存,如果是公用的缓存数据需要注意一些问题,如:公用的缓存数据需要考虑并发下的可能会导致大量命中DB查询,可以使用管理后台更新缓存,或者DB查询的锁住操作。
其他业务:
< div> 上面例子多是针对用户存储缓存,如果是公用的缓存数据需要注意一些问题,如:公用的缓存数据需要考虑并发下的可能会导致大量命中DB查询,可以使用管理后台更新缓存,或者DB查询的锁住操作。 以上例子是一个相对简单的高并发架构,并发量不是很高的情况可以很好的支撑,但是随着业务的壮大,用户并发量增加,我们的架构也会进行不断的优化和演变,比如对业务进行服务化,每个服务有自己的并发架构,自己的均衡 服务器,分布式 数据库,NoSQL主从集群,如:用户服务、订单服务。 2)消息队列 秒杀、秒抢等活动业务,用户在瞬间涌入产生高并发请求。 场景:定时领取红包等。 说明: 场景中的定时领取是一个高并发的业务,像秒杀活动用户会在到点的时间涌入,DB瞬间就接受到一记暴击,hold不住就会宕机,然后影响整个业务; 像这种不是只有查询的操作并且会有高并发的插入或者更新数据的业务,前面提到的通用方案就无法支撑,并发的时候都是直接命中DB; 设计这块业务的时候就会使用消息队列的,可以将参与用户的信息添加到消息队列中,然后再写个多线程程序去消耗队列,给队列中的用户发放红包; 方案如: 定时领取红包; 一般习惯使用 redis的 list; 当用户参与活动,将用户参与信息push到队列中; 然后写个多线程程序去pop数据,进行发放红包的业务; 这样可以支持高并发下的用户可以正常的参与活动,并且避免数据库 服务器宕机的危险。 附加:通过消息队列可以做很多的服务。 如:定时短信发送服务,使用sset(sorted set),发送时间戳作为排序依据,短信数据队列根据时间升序,然后写个程序定时循环去读取sset队列中的第一条,当前时间是否超过发送时间,如果超过就进行短信发送。 以上就是我们的今日分享,希望对大家有所帮助。