消息传递中的挑战和限制
消息传递是应用程序和数据存储之间传输数据的一个相当简单的范例。但是，存在与它相关的多种挑战：
- 由于代理成为瓶颈，可伸缩性有限。
- 由于消息大小较大，消息代理紧张。
- 消费者能够以合理的速率使用消息。
- 消费者通过确保使用的消息不会永远消失来表现出非容错。
由于：
高容量
消息应用程序托管在单个主机或节点上。因此，由于单个主机或本地存储，代理有可能成为瓶颈。
此外，如果订阅服务器使用数据缓慢，或者没有使用数据，则代理或发布者可能会停机，这可能会导致完全拒绝服务。
应用程序故障
订阅服务器逻辑中可能存在 Bug。因此，数据可能会处理错误、中毒或掺假。如果订阅服务器中的 Bug 已修复，则必须有一种方法来获取旧数据进行处理。如果订阅服务器存储了数据，这将很有帮助。
修复 Bug 后，我们也可能必须重新处理所有邮件。
中间件逻辑
充当发布者订阅者的不同应用具有要写入代理的自定义逻辑。它们中的每一个都有不同的错误处理。在这种情况下，保持数据一致性可能很困难。
卡夫卡如何解决这些问题？
- 为以 TB 或更远的大量数据提供高吞吐量。
- 是水平可扩展的，因此可以通过添加计算机来无缝共享负载来横向扩展。
- 提供可靠性，因此在发生故障时不会丢失任何数据。
- 发布者与使用者松散耦合，因此它们只参与数据交换。
- 它使用 Pub-Sub 消息传递语义，因此独立的应用程序会发送有关主题的数据，感兴趣的订阅服务器可以使用该主题上的数据。
让我们按照这个视频教程了解如何：
- 设置阿帕奇卡夫卡集群。
- 设置动物园管理员和经纪人。
- 在主题上生成一些消息。
- 使用来自同一主题的消息。
下面列出了上述视频教程的步骤：
Step 1 - cd /../kafka_2.12-2.3.0
Step 2 - Start Zookepeer
bin/zookeeper-server-start.sh config/zookeeper.properties
Step 2 - Kafka Broker
bin/kafka-server-start.sh config/server.properties
Step 3 - Create Topic
bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1 --topic Demo
Step 4 - List the created Topics
bin/kafka-topics.sh --list --bootstrap-server localhost:9092
Step 5 - Start the Producer
bin/kafka-console-producer.sh --broker-list localhost:9092 --topic Demo
Step 6 - Start the Consumer
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic Demo --from-beginning