微博异地多活的技术选型演进：从MytriggerQ失败到MCQ的WMB方案

微博做异地多活（微博内部称”多机房部署”）最早的动机是2010年微博高速发展、准备扩大广州机房规模，第一版跨机房消息同步方案采用自研的MytriggerQ——借助MySQL从库的触发器把INSERT/UPDATE/DELETE等事件转成消息。这个方案的优点是跨机房消息同步直接借助MySQL主从完成、成熟度高，但缺点是致命的：微博同一个业务往往拆在好几张表里，每张表的信息又不完整，导致发一条微博会先后产生多条消息、造成明显的时序问题，缓存因此经常”花”（脏数据）。第一套方案没能成功上线，但这次失败让团队认清了跨机房消息同步的核心问题——不能依赖底层数据库的变更事件反推业务语义，而应该让业务本身直接产生完整、有序的消息。于是团队转向基于业务写消息到MCQ（MemcacheQ，新浪自研的类Memcache协议消息队列）的方案：业务在写入数据的同时，主动把完整的消息写进MCQ，而不是靠底层触发器去拼凑；2011年底微博平台化完成后，团队在MCQ基础上开发出跨机房消息同步组件WMB（Weibo Message Broker），经过与相关团队的共同努力，终于在2012年5月完成Weibo.com在广州机房的上线，实现了”异地双活”。这条演进路径揭示的一般性原理是：跨机房数据同步的可靠性，很大程度上取决于”消息的完整性和语义清晰度”，而不是同步机制本身的技术复杂度——依赖数据库层的变更捕获（如触发器）看似省事，但因为数据库层拿不到完整的业务上下文，反而更容易在跨表、跨操作的场景里丢失或错乱语义；让产生数据的业务代码直接负责生成完整、有序的同步消息，虽然需要更多业务侧的改造工作，却从根本上避免了底层技术方案难以弥补的语义缺失问题。