为无为，事无事，味无味。

Proxy 根据配置的目标集群执行流量切换操作。通过管理平台为目标消费组（groupId）设置需要重置的 Offset，会同步等待 Proxy 加载到最新元数据且断开与 Broker 的连接后，触发重置的命令，一旦重置成功后，移除 groupId，Proxy 会重新加载到最新元数据。若发现请求与响应不匹配，或者遇到其他异常情况，则断开 客户端->Proxy 以及 Proxy->Broker 的连接，迫使客户端重新连接，断开连接并重新建立连接是一种保障系统稳定运行的机制，确保数据传输的连续性和准确性。

我们都知道 Kafka 是基于磁盘进行存储的，但 Kafka 官方又称其具有高性能、高吞吐、低延时的特点，其吞吐量动辄几十上百万。在座的靓仔和靓女们是不是有点困惑了，一般认为在磁盘上读写数据是会降低性能的，因为寻址会比较消耗时间。那 Kafka 又是怎么做到其吞吐量动辄几十上百万的呢？Kafka 通过无锁轻量级 offset 的设计，实现了高性能、高吞吐和低延时的目标。其 Reactor I/O 网络模型、磁盘顺序写入、内存映射文件、零拷贝、数据压缩和批量处理等技术，为 Kafka 提供了强大的

实现partitioner接口切记分区是实现负载均衡以及高吞吐量的关键，所以一定要在生产者这一端就要考虑好合适的分区策略，避免造成消息数据的“倾斜”，使得某些分区成为性能瓶颈，从而导致下游数据消费的性能下降的问题。

而且其实每个副本都是有角色之分的，它们会选取一个副本作为 leader，而其余的作为follower，我们的生产者在发送数据的时候，是直接发送到 leader partition 里面，然后follower partition 会去 leader 那里自行同步数据，消费者消费数据的时候，也是从leader那去消费数据的。但是kafka用的是顺序写，追加数据是追加到末尾，磁盘顺序写的性能极高，在磁盘个数一定，转数达到一定的情况下，基本和内存速度一致随机写的话是在文件的某个位置修改数据，性能会较低。

Google 的粗粒度锁服务 Chubby 的设计开发者 Burrows 曾经说过：“所有一致性协议本质上要么是 Paxos 要么是其变体”。Paxos 虽然解决了分布式系统中，多个节点就某个值达成一致性的通信协议。但是还是引入了其他的问题。由于其每个节点，都可以提议提案，也可以批准提案。当有三个及以上的 proposer 在发送 prepare 请求后，很难有一个 proposer 收到半数以上的回复而不断地执行第一阶段的协议，在这种竞争下，会导致选举速度变慢。