前浪微博消息队列详细设计：从粗粒度方案到可落地设计

[[前浪微博消息队列的最终决策：多方分歧与三原则逐一回应]]选定的”集群+MySQL存储”方案，在备选方案阶段只是一个粗粒度的技术路线，还不足以指导开发人员真正动手实现，必须经过[[详细方案设计阶段的技术选型是轻量级的：按适用场景匹配即可]]描述的细化过程才能真正落地。案例给出的细化维度覆盖了一个消息队列系统从数据结构到通信协议的完整链条：数据库表设计上拆分出”日志表”（消息写入时先快速落盘，写成功即代表消息发布成功）和”消息表”（每个队列一张表，后台线程再从日志表异步搬运消息内容进去），日志表定期清理已搬运的数据、消息表只保留30天数据；数据复制上直接复用MySQL主从复制机制，但只同步消息存储表、不同步日志表；主备切换上引入ZooKeeper做主备决策，主备服务器各自在ZooKeeper上建立临时节点（EPHEMERAL类型），备机监听主机节点状态，一旦发现主机节点断连就自行切换为对外提供服务；业务服务器写入消息时，通过SDK按轮询算法把写请求发给某台主服务器，遇到无响应或报错就自动改发下一台；业务服务器读取消息时，SDK轮流向所有服务器发起读请求，服务端为每个消费者维护独立的消费进度（当前已读到哪条消息），每次请求返回该消费者尚未读取的下一条消息；业务服务器与消息队列服务器之间的通信协议选用TCP传输、ProtocolBuffer作为数据格式，考虑的是未来可能要对接多种编程语言编写的系统，这个选择本身就兼顾了协议层面的跨语言兼容性。这个案例的核心示范意义不在于这几条具体设计本身放到别的系统里是否适用，而在于展示了详细方案设计到底要把粒度做细到什么程度——从”用集群+MySQL”这样一句话，一路展开到表结构字段、复制范围、主备切换的节点路径规则、客户端SDK的重试策略、通信协议的选型理由，每一个环节都要有明确、可执行的答案，而不能留下”细节到时候再说”的空白。