服务器架构与高并发性能测试实战方案(二)

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

 3.实战方案

 

002UASMrzy7605pjKJv15&690.jpg
1)通用方案
 
日用户流量大,但是比较分散,偶尔会有用户高聚的情况;
 
场景: 用户签到,用户中心,用户订单等。
 
说明:
 
场景中的这些业务基本是用户进入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,返回用户信息
 

免责声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,也不承认相关法律责任。如果您发现本社区中有涉嫌抄袭的内容,请发送邮件至:operations@xinnet.com进行举报,并提供相关证据,一经查实,本站将立刻删除涉嫌侵权内容。

免费咨询获取折扣