更多互联网新鲜资讯、工作奇淫技巧关注原创【飞鱼在浪屿】（日更新）
本文中讨论了较早的消息传递尝试，介绍Apache Kafka的概念和用例。
从前，计算机程序是一个整体。最简单地说，至少要输入一个参数和少量数据，并从同一系统确定地得出结果。
当程序需要相互通信并来回传递数据时，事情变得更加复杂。在这种情况下，将数据发送给接收应用程序，然后从理论上将其接收，然后对它执行某些操作，然后将其在本地得到输出，或者将结果传递回发送方。
事情继续发展，系统分布在数十亿机器和用户之间。状态更新，登录和状态等事件，以及有关上传的数据和其他用户活动，需要通过用户群跨整个系统实时处理。突然，需要数十亿的应用程序（和其他系统）相互通信。
复杂度指数化
想象一下这样一个系统的复杂性：大量独特的，分布式的实现，分布在各大洲，每个都有独特的需求，并且都在尝试交换数据，但是只有相关的东西才愿意这样做。每个程序都有单独的点对点交换机制吗？对于要交换的数据类型，每种传输机制会有所不同吗？
如果是这样，这将是有问题的。将如何构建，管理和维护这样的系统？毕竟，具有十亿个点对点通信的应用程序的系统的复杂性顺序是一个乘积：n * n。因此，从技术上讲，这是十亿个点应用程序以1：1进行通信可能达到了通信协议和实现的上限。
当然，有一种更简单的方法。如果通信是围绕通用接口构建的，而且，最好是应用程序可以订阅并仅接收所需的事件。答案就是输入pub-sub机制（发布-订阅、publish-subcribe）。
较早的消息传递尝试
首先，看一下解决此可伸缩性问题的早期工作。
弱耦合消息传递的早期工作是1998年出现的Java Messaging Service。与更紧密耦合的协议（例如TCP网络套接字或带有JMS的RMI）不同，中间组件能够间接地相互通信。通过发布和订阅或点对点模型。事实证明，JMS提供了许多后来成为Apache Kafka核心的功能，例如生产者，使用者，消息，队列和主题。
Pivotal的RabbitMQ和Apache ActiveMQ最终都成为JMS的提供程序实现，前者实现了高级消息队列协议（AMQP）并与多种语言兼容，后者提供了“企业功能”-包括多租户。
但是在某些情况下，这些解决方案都不够完美。例如，RabbitMQ将消息存储在DRAM中，直到DRAM被完全消耗为止，此时消息将被写入磁盘，从而严重影响性能。
而且，与Apache Kafka相比，AMQP的路由逻辑可能相当复杂。比如说，每个消费者只需决定在Kafka中读取哪些消息。
除了简化消息路由之外，在某些地方，开发人员和DevOps员工更喜欢Apache Kafka，因为它具有高吞吐量，可伸缩性，性能和耐用性。尽管，出于各种原因，开发人员仍然对这三个系统都表示满意。
因此，为了了解什么使Apache Kafka变得特别。
什么是Apache Kafka？
Apache Kafka由LinkedIn的Jay Kreps，Jun Rao和Neha Narkhede于2010年左右推出，是一种分布式，分区，复制的提交日志服务。它提供了消息传递系统的所有功能，但设计独特。
Kafka的可伸缩，容错，发布-订阅消息传递平台几乎遍布Spotify，LinkedIn，Square和Twitter等庞大的Internet网络。分区主题运行在代理服务器的集群上，在集群中作为仅追加日志分发，可以由软件使用者使用。
这种设计提供了容错能力，完全消除了复杂的生产者端路由规则，并使大规模的领先Apache Kafka能够补充或完全替代JMS和其他消息传递系统。
Apache Kafka的作用
Apache Kafka通过发布-订阅模型传递消息，在该模型中，称为生产者的软件组件将事件附加到称为主题的分布式日志中（概念上是带有记录的类别名称数据流）。
消费者配置为通过偏移量（主题中的记录号）与这些主题分开消费。后一种想法（即消费者决定他们将消费什么）消除了必须在生产者或系统的其他组件中配置复杂的路由规则的复杂性。
卡夫卡的常见功能
Apache Kafka体系结构的核心是提交日志，即仅按时间顺序附加的记录序列。日志映射到Kafka主题，并通过分区分发。
发布追加到日志的结尾。消费者订阅读取日志开始从指定的偏移，由左到右。偏移量描述了包含给定记录的日志中的位置。
这些也称为“预写日志”，“事务日志”或“提交日志”，它们的作用仅是一个目的-指定发生的情况和时间。当日志条目包含其自己的唯一时间戳（与任何物理时钟无关）时，分布式系统将能够更好地异步使用其指定的主题数据。
一些突出的用例
尽管使用日志作为主题组织和数据订阅的机制似乎是偶然的，并且似乎不直观，但是发布-订阅机制在速度和规模上都可以很好地支持各种异步消息传递，数据流和真实时间处理。
Kafka最初用于以低延迟从网站获取事件数据（例如登录和用户页面浏览量）。如今，Apache Kafka被用于各种功能，以传达许多消息传递和实时信息。
除了消息外，Apache Kafka还处理状态更新，用户消息，状态，各种内部工作等。但是，Kafka通常是更大系统（数据管道）的一部分。
例如，Comcast利用Kafka来支持Xfinity Home的IoT概念。作为成千上万个客户的家庭自动化和安全服务的数据骨干，Comcast的SLA要求“ ...群集必须保持高可用性，并在50ms的端到端时间内有98％的性能。”
OVO Energy使用 Kafka为其运营流程，数据科学应用程序提供动力，并收集所有必要的数据以进行报告和分析。OVO Energy使用Redis对Kafka进行了补充，以提供超快速的消息队列解决方案，然后使用InfluxDB和Grafana对其进行监视。
最后，OptioPay用Kafka，PostgreSQL和Elasticsearch，以简化有状态服务的运营和迁移，并在Microsoft Azure Germany上进行部署：这是唯一允许他们存储和处理个人数据的云。借助kafka的云灵活性和管理能力，OptioPay可以支出更少的操作时间，同时保持PSD2和GDPR的合规性。
使用Apache Kafka时的注意事项
Apache Kafka做了很多事情，以使其比其他发布-订阅消息实现更加高效和可扩展。例如，即使这些主题分布在各个分区中，Kafka也不保留其主题包含的消息的索引。
而且，由于使用者仅指定从其开始读取数据的偏移量，因此不需要混淆生产者端或通用路由规则。但是，Apache Kafka有许多潜在的痛点，缺点和陷阱。
首先，理论上，用于路由流量的消耗规则的简单性可以从整个系统中推送冗余或多余的数据，从而增加额外的负载，并影响性能。另一方面，消耗规则可能配置错误，因此不会消耗任何数据，因此，分布式组件会丢失重要的输入。
在TTL（生存时间）设置中配置的超时之前，Apache Kafka不会删除日志。这是通过.在broker的.properties文件设置log.retention完成。如果日志变得太大，则在写入调用磁盘交换时可能会影响性能/延迟。另一方面，如果日志删除得太早，则消费者将错过输入。
Kafka可以在内核IO中高效地流式传输消息，这比在用户空间中缓冲消息更有效。但是，在访问内核时，总是有可能引入潜在的灾难性故障，这些故障可能会导致整个或部分消息传递基础架构崩溃。
也许在构建系统时或在考虑以后可能需要提要的记录时查看某些日志以用于调试目的。如果是这种情况，topic不能有任何使用者，必须停用所有此类调试选项，以使你的系统最佳运行。
总而言之：上述所有参数以及更多参数都需要调整和配置。又如何在不首先使产品承受生产级负载而不影响您的业务的情况下知道系统的最佳配置？
架构注册表-使用或不使用
系统会发展壮大吗？如果是这样，您可能要考虑使用Confluent Schema Registry，它是一项出色的功能，可让您通过Kafka解耦集成的系统。
https://github.com/confluentinc/schema-registry
架构注册表可用于记录生产者以及消费者再次使用的数据架构，以解码和验证符合这些规则的数据。但是，如果你很可能会与Confluent的版本发行联系在一起仅此一项就使向前兼容性成为一个挑战。
设置陷阱
设置Apache Kafka的选项也很多，根据使用的是Confluent的免费版本还是付费版本（本机运行还是在Docker上运行）还是apache.org的发行版，它们的选择差异很大。
