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的核心复杂度几乎都在存储这一块。数据如何分片，如何高效的存储，如何高效地读取，如何保证一致性，如何从错误中恢复，如何扩容再平衡……