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

并发测试工具：

• Apache JMeter
• Visual Studio性能负载测试
• Microsoft Web Application Stress Tool

1)通用方案

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

服务器架构图：?

说明：

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

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

方案如：

用户签到获取积分：

• 计算出用户分布的key,Redis,hash中查找用户今日签到信息
• 如果查询到签到信息,返回签到信息
• 如果没有查询到,DB查询今日是否签到过,如果有签到过,就把签到信息同步Redis缓存.
• 如果DB中也没有查询到今日的签到记录,就进行签到逻辑,操作DB添加今日签到记录,添加签到积分(这整个DB操作是一个事务)
• 缓存签到信息到Redis,返回签到信息
• 注意这里会有并发情况下的逻辑问题,如：一天签到多次,发放多次积分给用户.

（编辑：网站开发网_盐城站长网 ）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!