Kafka 和 RabbitMQ 都是流行的消息中间件系统，他们各自都有一些优势和适用场景。以下是 Kafka 相对于 RabbitMQ 的一些比较明显的优势： 分布式架构： Kafka 是为大规模分布式流处理而设计的，具有高度可伸缩性。RabbitMQ 虽然也支持分布式架构，但相对而言，Kafka
在Kafka中，Topic和Partition是两个密切相关的概念。 Topic是Kafka中消息的逻辑分类，可以看作是一个消息的存储类别。它是按照不同的主题对消息进行分类，并且可以用于区分和筛选数据。每个Topic可以有多个Partition，每个Partition都是Topic的一个子集，包含了
Kafka 是一个分布式流处理平台，最初由LinkedIn开发并开源，后来成为Apache软件基金会的一个顶级项目。它被设计用于高吞吐量、持久性、分布式的数据流处理。 Kafka 实现了一套非常高效的订阅-发布模型，应用场景非常广泛。比如 日志聚合：Kafka 通常用于收集和聚合分布式系统中产生的日
Zookeeper集群的数据同步过程如下： 集群启动时，会先进行领导者选举，确定哪个节点是Leader，哪些节点是Follower和Observer。 Leader会和其他节点进行数据同步，采用发送快照和发送Diff日志的方式。 集群在工作过程中，所有的写请求都会交给Leader节点来进行处理，从节
Zookeeper 必须集群部署，推荐配置不少于 3 个节点。Zookeeper 自身也要保证当一个节点宕机时，其他节点会继续提供服务。 如果是一个 Follower 宕机，还有 2 台服务器提供访问，因为 Zookeeper 上的数据是有多个副本的，数据并不会丢失。 如果是一个 Leader 宕机
Zookeeper保证事务的顺序一致性是通过两个机制实现的：事务的严格串行化和锁定机制。 事务的严格串行化：在Zookeeper中，所有的写操作都必须经过一个称为“提交”（commit）的阶段。在一个事务还没有被提交之前，任何客户端都无法读取该事务。 这种机制确保了所有事务按照严格的顺序执行，保证了
Zookeeper的机制可以感知某些事件的发生，并将这些事件通知给客户端。这种通知机制是异步的，也就是说，当事件发生时，Zookeeper会选择一种方式将事件通知给客户端，而不需要等待客户端的回应。 具体来说，Zookeeper允许客户端向服务端的某个Znode注册一个Watcher监听，当这个Zn
ZAB协议（Zookeeper Atomic Broadcast）是Zookeeper中用于实现分布式一致性的协议。该协议旨在确保分布式系统中的数据一致性和可靠性，并具有以下特点： 支持崩溃恢复和消息广播：ZAB协议能够在Leader节点崩溃或因其他原因导致Leader缺失时，自动进入崩溃恢复模式，
zookeeper集群中服务器被划分为以下四种状态： LOOKING：寻找Leader状态。处于该状态的服务器会认为集群中没有Leader，需要进行Leader选举； FOLLOWING：跟随着状态，说明当前服务器角色为Follower； LEADING：领导者状态，表明当前服务器角色为Leader
Zookeeper集群的数目一般为奇数个，主要是出于以下两方面的考虑： 防止脑裂。如果Zookeeper集群的节点数为偶数个，那么在集群发生脑裂并分成两个均等子集群的情况下，可能导致整个Zookeeper集群都无法正常工作。而如果集群节点数为奇数个，则即使发生脑裂并分成两个子集群，每个子集群都至少会
