背景：设计一个抢购活动，活动提前创建并设定了固定开始时间，活动开始后用户才可以报名，每个用户限制一次机会，若用户报名失败可以重新报名。根据实际情况，依靠已有资源设计一个可用的抢购活动框架。
分析：这类活动的痛点是突发性、短时性，平时流量可能较低并且比较恒定，但是活动开始前后短时间内就会有大量用户同时进入，流量突然增大很多；优点是活动提前创建的能够提前做些准备。
实现
1.实现流程
- 首先，通过codis集群保证高可用，利用key的自减原子操作实现活动库存管理，保证不超卖，并控制流量入口，有库存时才允许用户进入后续报名流程，否则直接返回名额已满。
- 随后进行用户校验，通过校验的写事务表，保证事务的最终一致性。
- 事务表写成功后写kafka消息队列，消息发送成功的返回状态报名中，消息队列待异步任务消费。这里为了保证消息的不丢失，可设置ack=-1保证kafka消息所有副本都已收到。
- 报名成功的记录redis缓存，不能二次报名，实现请求幂等性。
- 异步任务获取用户信息、活动信息，做费用扣减、读写报名表等较重操作，这里才是真正报名流程。流程结束后将报名结果更新到用户的redis缓存，并更新事务表等db，若中途出现错误直接回滚，不提交消息消费确认，待二次消费。
-
用户在报名页面可以刷新查询报名状态，也可以让页面过几秒刷一次更新报名状态。
抢购-活动.png
2.潜在问题
- 扩展性：流量进一步上升后，需要扩容支持更高的访问量，服务器和数据库都需要一定扩展性。垂直扩展主要是提高单机服务能力，扩展能力有限，主要还是考虑支持水平扩张。kafka消息队列已经具有良好水平扩展性，剩下的就是前端服务器和后台异步任务服务的扩展，这两部分可通过web服务的扩容完成。
- 数据库扩容：随着并行访问量的增加，事务表等数据库操作将成为瓶颈。通过shardingsphere等分库分表方案对数据库进行拆分，并配置读写分离，提高数据库并发访问量。
- 缓存问题：为了应对突发大量并发请求，整个业务中用到较多缓存，需要考虑缓存一致性、穿透、击穿等。参考redis缓存一致性、穿透、击穿、雪崩问题。另外像活动对象等不会变动的热点数据，可以通过guava cache配置本地缓存，设置一定的过期时间。
- 限流：当并发请求过大时，数据库依然会处理不过来，占用了大量连接，导致其他业务不可用。可以通过guava的Semaphore限流，控制访问量。
- 监控：业务流程中添加监控，记录报名人数变化，剩余库存等业务数据，可以通过micrometer+prometheus+grafana实现。另外将报名失败、报名异常数据等记录日志文件，方便后续对账处理。
网友评论