推特最近把原本内部开发的Pub/Sub系统EventBus更换成Apache Kafka ，除了在成本上，当有许多用户都要转推发文的情况下（数据处理上称为fan-out），能节省高达75%的资源外，由于Kafka庞大社群的资源，修复错误和增加新功能更快，也更容易找到系统维护工程师人选。
Apache Kafka是一个开源分布式串流平台，能以高吞吐量低延迟方式传输数据。Ka
fka的核心是基于日志构建的Pub/Sub系统，具有可水平伸缩和容错性，是用来打造即时新闻系统的理想选择。但其实推特在几年前就已经使用过Kafka，推特发现当时Kafka 0.7版本，有几个不适合他们使用场景的缺点，主要是在追赶读取（Catchup Reads）期间的I/O操作数限制，也欠缺耐久性和复制功能。
由于当时使用Kafka的这些限制，推特基于Apache DistributedLog，打造了自己的Pub/Sub系统EventBus，以应对推特快速发布突发新闻、对用户提供相关广告，以及其他即时使用案例的需求。
时至今日，硬件和Kafka项目在经过时间的发展，推特之前遇到的问题，都已经获得解决。SSD的价格已经足够低廉，有助于解决之前在HDD上遇到随机读取先前I/O的问题，而且服务器NICs具有更大的带宽，使得EventBus的分割服务和存储层的好处消失。新版的Kafka现在还支持数据复制，提供推特需要的数据耐久性保证。推特表示，驱动他们把Pub/Sub系统从EventBus搬迁到Kafka上，主要是考察成本以及社群两个原因。
在推特决定要搬迁Pub/Sub系统到Kafka之前，团队花了数个月评价，他们在Kafka上运行相近于EventBus上的工作负载，包括耐久写入、长尾读取（Tailing reads）、追赶读取以及高扇出读取（High Hanout Reads），还有一些灰色故障的场景。从数据串流消费者读取信息的时间戳差异来衡量，无论吞吐量如何，Kafka的延迟都明显较低，推特提到，这可以归因成三个原因，第一个，由于在推特原本使用的EventBus，服务层和存储层是分离的，因此产生额外的跳跃（Hop），而Kafka只用一个程序处理存储和请求服务。
第二个原因，EventBus明显地阻止对fsync（）调用写入，但是Kafka却依赖操作系统背景进行fsync（）调用。第三个原因是，Kafka使用零复制（Zero-copy）。因此从成本的角度来看，EventBus需要服务层和存储层的硬件，分别针对高网络吞吐量和硬盘进行优化，但Kafka只需要使用单一主机，推特提到，显然EventBus需要更多的机器才能达到和Kafka相同的工作负载。
单一数据串流消费者的使用案例，Kafka可以节省68%的资源，当有多个用户发文并转推给他们所有友人时的fan-out情况下，推特估计，则能节省高达75%的资源。推特表示，由于他们使用案例fan-out效应不够极端，在实例中不值得分离服务层，特别是考虑到现代硬件上的可用带宽，否则在理论上EventBus应该更有效率。
除了成本上的考察，Kafka庞大的支持社群也是一大优势。在推特中，维护EventBus系统的只有8名工程师，但是Kafka项目现在却有数百人进行维护，帮忙修复错误和增加新功能。推特预计在EventBus增加的新功能，像是串流函数库、至少一次HDFS工作管线以及一次性处理都已经在Kafka中具备了。
此外，在客户端或是服务器发生问题时，开发人员可以参考其他团队的经验，快速的解决问题，而且也因为Kafka是一个热门项目，因此了解Kafka的工程师数量也比较多，方便招聘系统工程师。在接下来的几个月内，推特计划开始把用户从EventBus迁移到Kafka上，以降低运营成本，并且让用户获得Kafka提供的其他功能。