为何需要Kafka Broker/服务器/节点？它解决了生产者与消费者的哪些问题？

生产者与消费者直接交互的核心问题 #

如果跳过Broker直接让生产者给消费者发消息，会碰到一系列致命问题：

• 强耦合绑定：生产者必须掌握所有消费者的网络地址，一旦消费者扩容、缩容或更换地址，生产者就得同步修改配置，完全做不到独立迭代
• 消息无保障：要是消费者临时离线或者处理速度跟不上，生产者发出去的消息会直接丢失，没有中间环节暂存消息
• 负载失衡：面对多个消费者时，生产者得自己实现消息分发逻辑，很容易出现部分消费者过载、部分空闲的情况，没法做到合理的负载均衡
• 无回溯能力：消息一旦发送给消费者，生产者就无法留存，消费者如果需要重新读取历史消息（比如故障恢复后重新处理），根本没有办法实现
• 多消费场景受限：如果多个系统需要消费同一份消息，生产者得重复发送多份，不仅浪费带宽，还容易出现消息不一致的问题

Kafka Broker解决的关键问题 #

Kafka Broker作为生产者和消费者之间的中介，完美解决了上述所有痛点，同时还提供了更多核心能力：

• 彻底解耦生产与消费：生产者只需要把消息发送到Broker的指定Topic，消费者只需要从Broker订阅Topic，两者完全不用感知对方的存在，各自独立扩容、升级都不会影响彼此
• 持久化存储消息：Broker会将消息持久化到磁盘（结合内存缓存优化性能），消息的留存时长可配置，就算消费者离线几天，上线后依然可以消费这段时间的消息
• 智能负载均衡与有序消费：Broker会将Topic划分为多个分区，消费者组内的消费者会自动分配分区，每个分区的消息保证有序消费，Broker会根据消费者数量动态调整分区分配，避免负载不均
• 支持灵活的消息回溯：消费者可以通过指定offset，从任意位置开始消费消息，不管是实时消费最新消息，还是回溯几天前的历史数据，都能轻松实现
• 高可用与水平扩展：多个Broker组成集群后，Topic的分区会被复制到多个Broker上，就算某个Broker故障下线，其他Broker会接管它的分区，保证服务不中断；同时可以通过新增Broker节点，轻松提升整个集群的消息处理吞吐量
• 多消费组隔离：同一个Topic可以被多个消费者组同时订阅，不同组的消费进度完全独立，互不干扰，满足多系统共享同一份消息的需求

内容的提问来源于stack exchange，提问作者Sam Pa