这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。

发现现状与问题

入职第一天

周一早上，我准时到达公司。老张把我带到技术部，指着一张乱糟糟的桌子：「这是你的位置。」

桌子上有两台显示器，一把机械键盘。旁边堆着几本技术书，是前一个同事留下的——他写的代码只有他自己能看懂。

老王（技术负责人）走过来：「来，我给你介绍一下通知系统的现状。」

旧系统是一个脚本，每分钟通过 crontab 执行一次：查询待发送通知，发送，标记已发送。

我问了第一个问题：「这个脚本每分钟执行一次？那如果一分钟内发送不完 1000 条呢？」

「应该……能发完吧？」

问题就在这：如果推送服务响应慢或网络抖动，脚本执行时间可能超过一分钟。crontab 又会启动新的进程——两个进程同时处理，可能重复发送。

接下来查看数据库表结构。我执行了 EXPLAIN，发现问题：全表扫描。

查询目标是快速定位状态、任务或资源——避免在关键路径上做大范围扫描。

「每条通知都永久存储？数据量会越来越大。」

「用户可能需要查看历史通知……」老王说。

「查看历史通知和待发送通知，是两个不同的需求，应该分开处理。」

「如果推送失败怎么办？」

「状态设为 failed 就不管了。」

「那这些失败的通知就永远发不出去了？」

没有重试机制，失败即永久丢失。

旧通知系统的问题可以归纳为四点：并发重复、查询低效、无限增长、无重试。这四点是后面所有设计要解决的第一层问题。