Apache Kafka、Amazon Kinesis、Microsoft Event Hubs 和 Google Pub/Sub 等分布式日志技术在过去几年中已经成熟，并且在为某些用例移动数据时添加了一些很棒的新型解决方案。
据IT Jobs Watch称，自去年以来，使用[url=https://www.itjobswatch.co.uk/jobs/uk/kafka.do]Apache Kafka[/url]的项目的职位空缺增加了 112%；与去年同期相比， 使用Active MQ发布的职位减少了 43%。Rabbit MQ是传统消息代理的更现代版本，并有效地实现了 AMQP，但在招聘广告方面仅增加了 22%。我怀疑实际上许多传统消息代理服务不佳的用例已经非常迅速地转移到分布式日志技术，并且许多传统使用的技术（如 Active MQ）的新开发已经转移到了 Rabbit MQ。
Kafka与传统消息代理区别
虽然分布式日志技术表面上看起来与传统的代理消息传递技术非常相似，但它们在架构上存在显着差异，因此具有非常不同的性能和行为特征。
传统的消息代理系统（例如符合 JMS 或 AMQP 的系统）往往具有直接连接到代理的进程和直接连接到进程的代理。因此，对于从一个进程到另一个进程的消息，它可以通过代理进行路由。这些解决方案倾向于针对灵活性和可配置的交付保证进行优化。
最近出现了 Apache Kafka 等技术，或者俗称的分布式提交日志技术，可以起到与传统代理消息系统类似的作用。它们针对不同的用例进行了优化，但是它们并没有专注于灵活性和交付保证，而是倾向于专注于可扩展性和吞吐量。
在分布式提交日志架构中，发送和接收进程更加分离，并且在某些方面发送进程并不关心接收进程。消息会立即保存到分布式提交日志中。交付保证通常在分布式提交日志中的消息倾向于仅保留一段时间的上下文中查看。一旦时间到期，分布式提交日志中的旧消息就会消失，无论保证如何，因此通常适合数据可能到期或将在特定时间处理的用例。
分布式提交日志技术的选择
在本文中，我们将比较四种最流行的分布式日志技术。以下是每个的高级摘要：
- Apache Kafka
Kafka是一个分布式流媒体服务，最初由LinkedIn开发。API允许生产者将数据流发布到主题。一个主题是一个分区的记录日志，每个分区都是有序和不可改变的。消费者可以订阅主题。Kafka可以运行在一个由经纪人组成的集群上，其分区在集群节点之间分割。因此，Kafka旨在实现高度的可扩展性。然而，Kafka可能需要用户付出额外的努力来根据需求进行配置和扩展。
- 亚马逊Kinesis
Kinesis是一个基于云的实时处理服务。Kinesis生产者可以在数据被创建后立即推送到流中。Kenesis将数据流分成不同的分片（类似于分区），由你的分区密钥决定。每个分片对每秒的交易数和数据量都有一个硬性限制。如果你超过这个限制，你需要增加分片的数量。大部分的维护和配置对用户是隐藏的。AWS允许用户轻松扩展，只需为他们使用的内容付费。
- 微软Azure事件中心
事件集线器将自己描述为一个事件采集器，能够每秒接收和处理数百万个事件。生产者通过AMQP或HTTPS将事件发送到事件中心。事件集线器也有分区的概念，使特定的消费者能够接收流的一个子集。消费者通过AMQP连接。消费者组被用来允许消费的应用程序对事件流有一个单独的看法。Event Hubs是一个完全可管理的服务，但用户必须预先购买以吞吐量为单位的容量。
- 谷歌Pub/Sub
Pub/Sub提供可扩展的基于云的消息传递。发布者应用程序将消息发送到一个主题，消费者订阅到一个主题。消息在被确认之前一直保存在一个消息存储中。发布者和拉动订阅者是可以提出Google API HTTPS请求的应用程序。通过在各数据中心之间分配负载来实现自动扩展。用户按数据量收费。
在这篇文章中，不可能对每项技术进行详细的研究。然而，作为一个例子，我们将在下面的章节中更多地探讨Apache Kafka。
分布式提交日志技术有什么用？
虽然我不会比较和对比传统消息代理的所有用例，当与分布式日志技术相比较时（我们将留到另一篇博客），但如果我们暂时比较一下Active MQ和Apache Kafka设计背后的驱动力，我们就能感受到它们的好处。
Apache Kafka是在LinkedIn建立的，以提供一种方法来扩展他们的更新并最大化吞吐量。可扩展性是对延迟和消息传递保证的首要关注。在可扩展性的要求下，需要简化配置、管理和监控。
分布式日志技术有几个真正擅长的用例，它们通常有以下特点。
- 数据有一个自然的到期时间--比如股票或股份的价格。
- 数据量很大--因此吞吐量和可扩展性是关键的考虑因素。
- 数据是一个自然流--回溯到流中的某些点或向前穿越到某个给定的点可能有价值。
因此，在金融服务领域，Kafka被用于。
- 价格反馈
- 事件溯源采购
- 将数据从OLTP系统送入数据湖
分布式日志技术的属性
在选择分布式日志技术时，应该考虑一些属性，这些属性包括：
- 信息传递保证
- 排序保证
- 吞吐量
- 延迟
- 可配置的持久性周期
- 持久存储
- 分区
- 消费者群体
信息传递保证
消息传递系统通常在传递消息时提供特定的保证。有些保证是可配置的。保证的类型有。
- 最多一次--有些消息可能会丢失，没有消息会被交付一次以上。
- 精确一次--每条消息保证只被传递一次，不多也不少。
- 至少一次--每条消息都保证被送达，但在某些情况下可能被多次送达。
排序保证
对于分布式日志技术，可以有以下排序保证
- 无--绝对不保证任何消息以与它们进来的顺序相关的任何顺序出来。
- 在一个分区内--在任何给定的分区内，顺序是绝对保证的，但是在不同的分区之间，信息可能会出现顺序错误。
- 跨越分区--跨分区的排序是有保证的。这是很昂贵的，而且会减慢速度，使扩展变得更加复杂。
吞吐量
在设定的时间内可处理的信息量。
延迟
一条消息放在队列中后被处理的平均速度。值得注意的是，有时你可以通过批处理事情来牺牲延迟以获得吞吐量（反之，通过在数据创建后立即发送来改善延迟，会牺牲吞吐量）。
可配置的持久化时间
消息将被保存的时间段。一旦过了这个时间，消息就会被删除，即使没有消费者消费过该消息。
如何选择使用哪一种？
在选择分布式提交日志技术时，你可以问自己几个大问题（在下面的一个简单的决策流程图中捕获）。你是在寻找一个托管解决方案还是一个管理服务解决方案？虽然Kafka可能是所有技术中最灵活的，但它也是操作和管理最复杂的。你在工具上节省的成本，可能会在支持和开发人员的运行和管理上用掉。
所有分布式提交日志技术的共同点是，消息传递的保证往往至少是一次处理。这意味着消费者需要防止多次收到消息。
与Apache Spark这样的流处理引擎相结合，可以给消费者提供精确的一次处理，并消除用户应用程序处理重复消息的需要。
更多点击标题