kafaka 性能优化

Broker需要一个leader；主要工作就是分配partition，partition的迁移如果分区比较多的话，可以扩大并发度，producer不需要太多，如果太多的话，可能增加不同的partition的消息顺序不一致性；除非你的业务模型忽略顺序性问题
replication集合也会选举出leader，读写操作直接操作leader，副本都是从leader同步信息；有一个配置（request.required.acks）接收producer的消息后，需要同步多少个副本才进行ack回复；如果设置的值太大，影响生产者的效率；太少可能对可用性、安全性影响
生产者发消息可以进行消息压缩，解压可以在kafaka服务端解压，也可以再消费者消费消息时候解压；还可以在业务层进行解压。Message-Set 加 End-To-End策略
Kafka官方并不建议通过Broker端的log.flush.interval.messages和log.flush.interval.ms来强制写盘，认为数据的可靠性应该通过Replica来保证，而强制Flush数据到磁盘会对整体性能产生影响

可以通过调整/proc/sys/vm/dirty_background_ratio和/proc/sys/vm/dirty_ratio来调优性能

a. 脏页率超过第一个指标会启动pdflush开始Flush Dirty PageCache。
b. 脏页率超过第二个指标会阻塞所有的写操作来进行Flush。
c. 根据不同的业务需求可以适当的降低dirty_background_ratio和提高dirty_ratio。

不要建立太多的topic，kafak不适合太多的topic
Partition的数量尽量提前预分配，虽然可以在后期动态增加Partition，但是会冒着可能破坏Message Key和Partition之间对应关系的风险