高阶面试-写缓存

场景

超低价预约大型线上活动，在某天9:00~9:15期间，用户可以前往详情页半价预约抢购一款热门商品。根据市场部门的策划方案，这次活动的运营目标是几十万左右的预约量。

设计目标

设计的目标是：用户1分钟内就完成90%的预约量，即90万预约。那么推算出目标的TPS（吞吐量）就是9万/60=1.5万

原来预约就是个简单的功能，并没有做高并发设计。对它做了一次压力测试，结果最大的TPS是2200左右，与需求值差距较大。

思路

写缓存的思路是后台服务接收到用户请求时，如果请求校验没问题，数据并不会直接落库，而是先存储在缓存层中，缓存层中写请求达到一定数量时再进行批量落库。利用写缓存比数据库高几个量级的吞吐能力来承受洪峰流量，再匀速迁移数据到数据库

写请求和批量落库是同步还是异步

优缺点比较

同步

• 优点：用户预约成功后，可在“我的预约”页面立即看到预约数据
• 缺点：用户提交预约后，还需要等待一段时间才能返回结果，且这个时间不定

异步：

• 优点：用户能快速知道提交结果
• 缺点：用户提交完成后，如果查看“我的预约”页面，可能会出现没有数据的情况

复杂度：

同步：写请求提交数据时，写请求的线程被堵塞或者等待，待批量落库完成后再发送信号给写请求的线程，这个线程获得落库完成的信号后，返回预约成功提示给用户

会引申出一系列问题

• 用户要等多久，需要设置时间窗，比如100ms批量落库一次
• 批量落库超时怎么处理 设置写请求阻塞的超时时间
• 批量落库失败 是否重试，重试几次

异步不需要考虑 超时处理、重试，更合适

用户体验优化：预约成功，进入预