前浪微博消息队列三个备选方案对比

承接[[排查法识别复杂度：用峰值TPS/QPS估算与后果严重性代替直觉判断]]中识别出的四点复杂度（高性能消息读取、高可用消息写入/存储/读取），”前浪微博”案例给出了三个备选方案，展示了备选方案设计三条准则的具体落地。方案一是直接采用开源的Kafka：Kafka本身功能强大、性能高、已被大公司广泛验证，是最省事、复用成熟方案的路线。方案二是”集群+MySQL存储”自建方案：单机高性能部分选择基于Netty（Java领域成熟的高性能网络库）自研，因为团队是Java背景，架构师判断没有必要为了语言性能优势让整个团队切换语言栈；由于单机QPS撑不住设计目标的13800，改用集群+轮询负载均衡来分摊压力；这个方案里最复杂的两块是”高可用存储”和”高可用读取”，架构师借助MySQL现成的主备复制能力来实现——集群按分组组织，每组一台主MySQL、一台备MySQL，组内主备数据复制、组间数据不同步，正常情况下主服务器对外提供读写服务，主服务器宕机时备服务器接管读服务。方案三是”集群+自研存储”：在方案二的基础上，把MySQL替换为参照Kafka思路自研的文件存储和复制方案，因为关系型数据库的特性和消息队列的数据特点本来就不太契合。三个方案的技术选型差异清晰可辨（开源直接用 vs 自建于关系型数据库之上 vs 自研专属存储引擎），但方案二和方案三在”单机高性能”这一层都收敛到了同一套基于Netty+Java的实现，恰恰印证了备选方案准则里”团队的技术背景会天然收窄备选范围”这一点——差异应该出现在真正有技术选型价值的地方（存储与复制机制），而不是被迫在团队根本不会用的语言/框架上硬造差异。

结构图：

flowchart TB
  A["前浪微博消息队列备选方案"]
  A --> B["方案一：直接采用开源Kafka<br/>成熟、性能高、已被大公司广泛验证"]
  A --> C["方案二：集群+MySQL存储自建"]
  C --> C1["单机高性能：基于Netty(Java)开发<br/>不为性能切换语言栈"]
  C --> C2["集群+轮询：应对单机QPS撑不住13800目标"]
  C --> C3["高可用存储/读取：借助MySQL主备复制<br/>分组主备，组内复制/组间不同步<br/>主宕机时备机接管读服务"]
  A --> D["方案三：集群+自研存储"]
  D --> D1["复用方案二的Netty集群架构"]
  D --> D2["存储层参照Kafka自研文件存储与复制<br/>因关系型数据库特性不契合消息队列数据特点"]