Kafka使用经验小结

本文尽量从一个使用者的角度去记录一些在实战当中使用Kfaka所需要关注的要点，这样可能会贴切更多的读者，本文并不会介绍太多的Kafka的一些架构层次设计的知识，因为网上已经有一大堆的重复搬运的资料任由你们学习参考。

明确Kafka在你的系统中的定位

众所周知，Kafka的可用性和数据可靠性相对其他的高可用的MQ来说会低一点，但是带来的却是更大更高性能的消息吞吐量的优势，因此要是你的系统需要的是金融级别的高可靠高可用就尽量选择其他的MQ产品。

Kafka比较适合那种容忍即使丢失一定量数据也不会带来较大影响的业务，比如数据采集监控系统等

关注Topic和Partions的关系

Topic决定了你的系统的消息数据的丰富度，Partions决定了你每个Topic的消费速度(并发消费)能力，通常不同的数据需要通过不同的Topic进行隔离，不同Topic的数据体量也会存在差异较大的情况，可以视情况而分配对应的Partitions数目

关注Kafka实例的各项指标监控

1、各个Partitions的消费进度

Consumer的消费进度决定了你的整个系统的时延程度，因此要监控消费不及时的异常情况，及时排查是不是消费进程出问题还是Kafka实例问题

2、整个Kafka实例的磁盘占据空间

需要设置数据的超时时间，不然长期堆积数据不消费会沾满磁盘空间，导致新增数据无法写入

开发编程纪要

生产端

1、尽可能用高并发的方式去写，这样会增加写入性能
2、可以通过 key，value的方式去写入，但是不能将他当作kv数据库消费，通常来说我们可以对key进行一些协议的设计，让他具备更多的业务属性。

消费端

1、要选择一个靠谱的Kafka开源客户端（不过发展到今天基本开源的都挺靠谱），项目使用什么语言就选择对应语言的客户端就是了
2、Consumer必须和Kafka建立起一个稳定的TCP长连接，因为频繁创建销毁Consumer连接实例会对整个Kafka的稳定性造成较大冲击，因为消费涉及到负载均衡，以及复杂的路由设置等，非常影响性能
3、Comsumer不能无限创建多个并发worker实例，比如某个Topic-A被你分配了3个Partitions，那就只能创建三个拉去的worker任务，再多的话是无法进行消费的
4、消费的worker账号最好都统一用一个id进行管理，不然容易造成消费的offset不可控