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的外围复杂度简直都在存储这一块。数据如何分片，如何高效的存储，如何高效地读取，如何保障一致性，如何从谬误中复原，如何扩容再均衡……