Aeron开发团队由3名成员组成：Todd Montgomery是一个组播和可靠协议专家，Richard Warburton是一个编译器优 化专家，而Martin Thompson则是一个性能优化高手。这个团队由一个非常明确的目标，旨在让Aeron的吞吐量超越该领域的所有产品，并让其 延时上可以达到领域内最好商业工具的90%。Aeron的性能非常突出，它可以在1秒内推送600万个40字节大小的消息。 本文是HighScalability创始人Todd Hoff总结Martin在Strangeloop上名为“Aeron: Open-source high-performance messaging”的演讲。 以下为摘译：
Martin的团队是非常令人羡慕的，不仅因为他们有一个需要打造Aeron这样产品才能支撑的客户端，也因为他们愿意支撑Aeron项目的发展并将它开源（Aeron的GitHub开源页）。值得注意的是，Aeron当下仍然处于初期阶段，还面临着大量的优化。 对比以前，世界已经发生了翻天覆地的变化，而时至今日，连终端都需要进行前所未有的扩展。当下，一切都变得多重化，multi-core、 multi-socket、multi-cloud，甚至是multi-billion终端用户计算系统，通信可谓是无时无刻不在。海量的消费者定期打开 通道从同一个发布者接收信息，从而导致锁争用、队列阻塞，随之而来的是吞吐量和延时飙升。 因此，这个新的世界需要一个全新的消息库，而向微服务的架构转变也加强了这个需求：当系统迁移到微服务架构，我们需要通信有一个非常低和可预测的延时，同时USL（The Universal Scalability Law）相关组件的设计将非常困难。 Aeron简单而专注。在基于大量的基准测试，我们发现使用Aeron，吞吐量和延时可以得到进一步改善。同时值得关注的是，用户并不需要做吞吐量和延时的取舍。Aeron在最小化吞吐量的同时可以最大化的提高吞吐量，直到饱和。 “许多消息系统都像把瑞士军刀，而Aeron更像把手术刀，”Martin如是说。这句话用来解释Aeron非常准确。区别于你之前使用的产品，比 如Kafka，Aeron的功能可以说非常单一。Aeron并不支持消息的持久化，不支持保证传送，也不支持聚集与话题（topics）。Aeron不会 去探知一个客户端是否崩溃，因此它也不会去为客户端同步历史锚点之类的事情，也就更谈不上使用历史记录重新初始化一个客户端。 因此，Aeron的使用场景可能就是TCP的面向消息替代，在上面编写更高级的服务。Todd Montgomery解释了这个观点： Aeron作为一个ISO传输层协议，它提供了许多消息系统不可能完成的特性，同时它也失去许多消息系统可以拥有的特性。如果你觉得这么说毫无意义的话，那么我们首先从一些常见的系统看起。 从某些情况来说，Aeron比较适合TCP用例，它是一个更可靠的组播选项。虽然在设计上Aeron也存在着一些限制，但是它可以比TCP完成更多的东西。下面将做一些具体的说明： Aeron的核心是一个“replicated persistent log of messages”。通过特殊的设计，在Aeron中，从发布到接收，贯穿整过程消息的处理都是无等待和零备份的。这样一来，用户无疑将得到一个很低的延 时，同时这个响应时间是完全可预知的。 同时，Aeron是非常可靠的。它由一个经验丰富的团队建立，使用了其他项目中久经验证的设计准则，其使用的技术超出许多工具。在Aeron设计中，所有理念都是经过深思熟虑的，它们必须具备简洁、高性能、高并发等特性。 更多关于Aeron的设计可访问原文： Aeron: Do we really need another messaging system? |
