【middleware】kafka & elasticsearc
客户端应用是否需要跟kafka集群的zookeeper集群做交互？
在Kafka集群中，通常会有一个Zookeeper集群。Zookeeper被用于管理和协调Kafka集群的状态信息和元数据。它负责监控Kafka节点的健康状况、领导选举以及分配分区等任务。Zookeeper还提供了可靠的分布式协调服务，确保Kafka集群的稳定运行。
Zookeeper集群由多个Zookeeper服务器组成，这些服务器通过选举机制来选择一个Leader服务器进行操作。其他服务器则充当Follower角色，与Leader保持同步。当Leader服务器出现故障时，Follower之间将进行新一轮的选举，选择一个新的Leader。
Kafka和Zookeeper是紧密相关的，因为Kafka依赖于Zookeeper来存储集群的元数据和配置信息。
因此，在搭建Kafka集群时，必须先搭建好Zookeeper集群，并确保其正常运行。
在Kafka的新版本（0.9及以后）中，Kafka客户端应用程序不再需要直接连接到Zookeeper集群。
在这些版本中，Kafka引入了一个新的元数据管理机制，称为Kafka Metadata Quorum。
在旧版本的Kafka中，Zookeeper被用来存储和管理Kafka集群的元数据，包括主题（topics）、分区（partitions）和消费者组（consumer groups）等信息。Kafka客户端应用程序通过与Zookeeper进行交互来获取这些元数据，并与Kafka集群进行通信。
然而，在新版本的Kafka中，元数据的管理已经转移到了Kafka自身的Broker中。
Kafka Broker会负责将元数据存储在内部的系统主题中，并对外提供元数据查询的API。
因此，Kafka客户端应用程序只需要连接到Kafka Broker，即可通过Broker获取所需的元数据信息，而无需直接连接到Zookeeper集群。
这种改变带来了一些好处，例如降低了Kafka客户端对Zookeeper的依赖性，简化了配置和部署过程，并提升了整体性能和可伸缩性。
但需要注意的是，仍然需要确保Zookeeper集群正常运行，因为Kafka Broker仍然需要与Zookeeper进行一些间接的交互，例如选举Kafka Controller等操作。
Elasticsearch集群中的9200 和9300 端口作用分别是什么？
在Elasticsearch集群中，9200端口和9300端口具有不同的作用：
-
9200端口：此端口是Elasticsearch的HTTP REST API默认侦听端口。
通过该端口，可以使用HTTP协议与Elasticsearch进行通信，执行各种索引、搜索、文档管理等操作。使用9200端口可以发送RESTful请求，并以JSON格式接收响应。 -
9300端口：此端口是Elasticsearch的内部传输层端口，用于节点之间的相互通信和数据传输。
Elasticsearch使用9300端口来构建集群中的节点之间的通信通道。该端口使用自定义的二进制协议进行通信，这种协议能够高效地传输大量的数据并进行分布式处理。
总结起来，9200端口主要用于与Elasticsearch进行RESTful API交互，而9300端口则用于节点之间的内部通信和数据传输。请注意，这些端口的作用是默认设置，可以根据需要进行配置和更改。
为什么有些客户端应用配置文件中会有 9300 端口相关配置，客户端应用也需要跟es集群的9300端口交互吗？
客户端应用程序中配置9300端口的相关配置是因为它们需要直接与Elasticsearch集群的节点进行通信。虽然Elasticsearch的HTTP REST API通常使用9200端口，但某些特定的客户端库或工具可能选择通过9300端口与集群进行交互。
9300端口是Elasticsearch的内部传输层端口，主要用于节点之间的相互通信和数据传输。
通过该端口，客户端应用程序可以直接连接到Elasticsearch集群中的任何一个节点，并与节点进行通信。
这种直接连接在某些情况下可以提供更高效和灵活的交互方式，例如在进行复杂的搜索、索引管理或集群监控等特定操作时。
需要注意的是，直接使用9300端口与Elasticsearch集群进行交互需要使用Elasticsearch官方提供的Java客户端或其他支持该协议的客户端库。
对于大多数普通的应用程序和开发者来说，使用9200端口的REST API就足够满足大部分的需求，而无需直接使用9300端口。
