kafka 的优缺点都有那些

Kafka 是由 Apache 软件基金会开发的一个开源流处理平台，由 Scala 和 Java 编写。Kafka 是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。

（1）优点：kafka 的优点非常多

• 高性能：单机测试能达到 100w tps；

• 低延时：生产和消费的延时都很低，e2e 的延时在正常的 cluster 中也很低；

• 可用性高：replicate + isr + 选举 机制保证；

• 工具链成熟：监控 运维 管理 方案齐全；

• 生态成熟：大数据场景必不可少 kafka stream.

（2）不足

• 无法弹性扩容：对 partition 的读写都在 partition leader 所在的 broker，如果该 broker 压力过大，也无法通过新增 broker 来解决问题；

• 扩容成本高：集群中新增的 broker 只会处理新 topic，如果要分担老 topic-partition 的压力，需要手动迁移 partition，这时会占用大量集群带宽；

• 消费者新加入和退出会造成整个消费组 rebalance：导致数据重复消费，影响消费速度，增加 e2e 延迟；

• partition 过多会使得性能显著下降：ZK 压力大，broker 上 partition 过多让磁盘顺序写几乎退化成随机写。

在了解了 kafka 的架构之后，你可以仔细想一想，为什么 kafka 扩容这么费劲呢？其实这本质上和 redis 集群扩容是一样的！当 redis 集群出现热 key 时，某个实例扛不住了，你通过加机器并不能解决什么问题，因为那个热 key 还是在之前的某个实例中，新扩容的实例起不到分流的作用。大数据培训kafka 类似，它扩容有两种：新加机器（加 broker）以及给 topic 增加 partition。

给 topic 新加 partition 这个操作，你可以联想一下 mysql 的分表。比如用户订单表，由于量太大把它按用户 id 拆分成 1024 个子表 user_order_{0..1023}，如果到后期发现还不够用，要增加这个分表数，就会比较麻烦。因为分表总数增多，会让 user_id 的 hash 值发生变化，从而导致老的数据无法查询。所以只能停服做数据迁移，然后再重新上线。

kafka 给 topic 新增 partition 一样的道理，比如在某些场景下 msg 包含 key，那 producer 就要保证相同的 key 放到相同的 partition。但是如果 partition 总量增加了，根据 key 去进行 hash，比如 hash(key) % parition_num，得到的结果就不同，就无法保证相同的 key 存到同一个 partition。

当然也可以在 producer 上实现一个自定义的 partitioner，保证不论怎么扩 partition 相同的 key 都落到相同的 partition 上，但是这又会使得新增加的 partition 没有任何数据。

其实你可以发现一个问题，kafka 的核心复杂度几乎都在存储这一块。数据如何分片，如何高效的存储，如何高效地读取，如何保证一致性，如何从错误中恢复，如何扩容再平衡……