查看原文

本文是 Trello 的工程博客，讲述为什么他们停止使用用了三年的 RabbitMQ, 而改用 Kafka。

Trello 线上使用 15 个 RabbitMQ 示例承接 WebSockets 的推送更新。后端服务把数据推到 RabbitMQ，然后 WebSockets 的服务端应用处理连接，从队列中拉数据下来，给出响应推给浏览器端。

后端服务推数据时，通过一个 3 实例的 rabbitmq-inbound cluster 把数据 shard 到 16 个队列中。WebSockets 服务端程序订阅所有队列拉取所需的数据。

问题主要出在 Sharding 的时候，当 Cluster 坏掉或者出现脑裂，复制的数据可能会不一致，从而导致奇怪的客户端行为。额外的问题是，Rabbit 新建和删除 Queue Bindings 比较慢，当所有 WebSockets 掉线重连就会发生一波向 Rabbit 的 DDos（他们通过加 Jitter 暂时解决第二个问题，第一个还是不太好解决）。

文中给出了一张 Alternative 的表格，蛮有参考价值。说结论，他们选了 Kafaka。

新架构：Socket servers 使用 Master-Client 架构。Master 增量订阅所有 Topic；Client 处理用户连接，向 Master 注册要订阅的 Topic；Master 得到增量数据后根据本地注册表将数据转发给 Client，Client 再转发给用户。

好处：监控更多，事故貌似更少了，消耗的资源变少了。

衍生思考：Trello 的对队列 Sharding 一致性的使用场景比较高，RabbitMQ 无法达到要求。Kafaka 尽管没有完全达到所有需求，但是一致性和可用性都很高。