系统设计面试题：10万台自动售货机同时更新同表的设计缺陷分析

全球共有10万台自动售货机，需要将补货、技术故障等维护活动数据更新到数据库，所有机器均在午夜同时执行更新操作，更新完成后会运行batch system生成维护任务工单。请问该设计存在哪些问题？

核心设计缺陷 #

你提到的几个问题已经覆盖了大部分核心风险，还有一些容易忽略的问题补充如下：

• 瞬时写入压力击穿风险：10万级并发写入同时打向数据库，会直接引发严重的写冲突，行锁、表页锁争抢严重，大量事务超时回滚，极端情况下会直接打垮数据库实例。一旦数据库宕机，不仅当时的更新数据丢失，故障恢复后还要处理重复写入、数据一致性的问题，恢复成本极高。
• 重试雪崩风险：如果售货机端配置了超时重试策略，第一次请求大面积超时后，短时间内会有数倍的重复请求再次打向服务端，形成雪崩效应，即使临时扩容服务和数据库也很难扛住这种级别的突发流量。
• 全链路业务阻塞：服务端带宽、CPU、内存资源被峰值上报流量占满后，正常的实时业务请求（比如用户购买、实时故障报警）都会被排队阻塞，甚至直接返回错误，直接影响售货机的正常营收。
• 流程依赖缺陷：如果要求全量上报完成后才触发批处理任务，要么需要持续轮询数据库判断上报进度，浪费资源；要么会因为个别机器上报延迟、上报失败，导致批处理任务迟迟无法触发，或者生成的工单缺漏数据。
• 全球时区适配问题：全球范围的售货机统一按本地午夜上报，会导致不同时区的上报流量分散到24小时不同时段，部分区域的上报时间正好落在业务高峰，反而加剧服务压力；如果统一按UTC午夜上报，同样会有部分区域撞上业务高峰的问题。
• 批处理性能风险：全量10万台数据一次性入库后立刻执行批处理，如果批处理逻辑没有做分片优化，很容易出现内存溢出、执行超时，同时批处理的查询请求会占用大量数据库资源，和写入请求争抢资源进一步降低性能。
• 数据丢失风险：上报请求没有做前置缓冲，直接打到数据库的话，一旦数据库不可用，上报的数据会直接丢失，如果售货机本地没有留存上报记录，对应的维护数据会彻底消失无法回溯。
• 资源浪费问题：服务端和数据库需要按峰值流量规格预留资源，其余99%的时间资源都处于闲置状态，基础设施成本极高。

可行优化思路 #

• 流量削峰：给售货机的上报时间增加随机偏移，比如允许在午夜前后1~2小时内随机选择时间上报，把10万级QPS的峰值摊平到小时级，峰值压力可以降低数十倍。也可以引入消息队列做上报数据的缓冲，先把所有上报请求接收下来，再异步消费写入数据库，避免流量直接打垮存储层。
• 重试与幂等优化：售货机端配置指数退避的重试策略，同时服务端对每个上报请求做幂等校验，避免重复写入导致的数据不一致。
• 批处理逻辑优化：不需要等全量机器上报完成再触发批处理，可以按区域、分组分片执行，对应分片的机器上报完成就触发该分片的工单生成任务，也可以按固定时间窗口分批生成工单，避免等待少数异常机器。
• 高可用优化：数据库做读写分离，写入请求打到主库，批处理的查询请求打到从库，避免读写资源争抢；同时要求售货机本地缓存上报数据，上报失败后本地留存，后续自动重试补报，避免数据丢失。

内容的提问来源于stack exchange，提问作者nolimits