共计 1235 个字符，预计需要花费 4 分钟才能阅读完成。
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 的外围复杂度简直都在存储这一块。数据如何分片，如何高效的存储，如何高效地读取，如何保障一致性，如何从谬误中复原，如何扩容再均衡……