建设网站地图临平做网站电话
阿伟开始学Kafka
概述
人生若只如初见，阿伟心里回想起了第一次和Kafka见面的场景，记忆虽然已经有些模糊，但是感觉初次见面是美好的。积累了一些实战经验之后，阿伟感觉不能再是面对百度开发了，于是决心系统的学习一下Kafka。本文将作为开篇开启Kafka系列学习心得总结文章。
一、基本概念
本节将汇总讲解一下Kafka的核心概念，对于初学者来说，学习一项技术先要做一些整体的了解，于是阿伟对Kafka核心概念进行了梳理.
核心概念
1、Topic
Kafka根据topic对消息进行归类，发布到Kafka集群的每条消息都需要指定一个topic
2、Parition
物理上的概念，一个topic可以分为多个partition，每个partition的内部时有序的
3、Broker
消息中间件处理节点，一个Kafka节点就是一个broker，一个或者多个Broker可以组成一个Kafka集群
4、ConsumerGroup
每个Consumer属于一个特定的ConsumerGroup，一条消息可以被多个不同的ConsumerGroup消费，到那时一个ConsumerGroup中只能有一个Consumer能够消费该消息
5、Consumer
消息消费者，从Broker读取消息的客户端
6、Producer
消息生产者，向Broker发送消息的客户端
消息类型
普通消息、顺序消息、延时消息
消费模式
集群消费、广播消费
二、市面上流行的消息中间件特性对比
如下将市面上流行的几款消息中间件Kafka、RocketMQ、RabbitMQ进行了多维度的对方分析：
三、Kafka难题
1、为什么要对topic下数据进行分区存储?
1.commit log文件会受到所在机器的文件系统大小的限制，分区之后可以将不同的分区放在不同的机器上，相当于对数据做了分布式存储，理论上一个topic可以处理任意数量的数据
2.提高并行度
2、如何在多个partition中保证顺序消费?
方案一:首先将需要保证顺序的消息收集起来，然后交给一个consumer去进行处理，然后内部维护一个线程池，让其中某一个线程去顺序执行这些消息eg:用户下单流程，支付成功消息 -> 库存消息
方案二:让多个消息构造一个特殊结构的顺序消息,当consumer收到时，在一个线程中依次进行消费
3、消息丢失
1、生产者
1.1、acks=0,表示producer不需要等待任何broker确认收到消息的回复，就可以发送下一条消息，性能最高，但是最容易丢消息大数据统计报表场景，对性能要求很高，对数据丢失不敏感的情况可以用这种
1.2、acks=1,表示至少要等待leader已经成功将数据写入本地log,但是不需要等待所有follower是否成功写入，就可以继续发送下一条消息，这种情况下，如果follower没有成功备份数据，而此时leader又挂掉，则消息会丢失
1.3、ack=-1或者all,这意味着leader需要等待所有备份(min.insync.replicas配置的备份个数)都成功写入日志，这种策略会保证只要由一个备份存活就不会丢失数据，这是最强的数据保证，一般除非是金融级别，或跟钱打交道的场景才会使用这种配置，当然如果min.insync.replicas配置的是1则也可能丢消息，跟acks=1情况类似
2、消费者
如果消费这边配置的是自动提交，万一消费到数据还没处理完，就自动提交offset了，但是此时consumer直接宕机了未处理完的数据丢失了，下次也消费不到了
4、消费重复
1、生产者
发送消息如果配置了重试机制，比如网络抖动事件过长导致发送端发送超时，实际broker可能已经接收到消息，但发送方会重新发送消息
2、消费者
如果消费这边配置的是自动提交，刚拉取了一批数据处理了一部分，但还没来得及提交，服务挂了，下次重启又会拉取相同的一批数据重复处理一般消费端都是要做消息幂等处理的
5、消息乱序
1、如果发送端配置了重试机制，Kafka不会等之前那条消息完全成功了才去发送下一条消息，这样就可能出现发送了1，2，3条2消息，第一条超时了，后面两条发送成功，再重试发送第一条消息，这时消息在broker端的顺序就是2，3，1了，所以，是否一定要配置重试要根据业务情况而定。也可以用同步发送的模式取发消息，当然acks不能设置为0，这样也能保证消息从发送端到消费端全链路有序，kafka保证全链路消息顺序消费，需要从发送端开始，将所有有序消息发送到同一个分区，然后用一个消费者去消费，但是这种性能比较低，可以在消费者端接收到消息后将需要保证顺序消费的几条消息发到内存队列(可以多搞几个)，一个内存队列开启一个线程顺序消费处理。
2、一个parition同一时刻在一个consumer group中只能有一个consumer实例在消费
,从而保证消费顺序。consumer group中的consumer数量不能比一个topic中的partion数量还要多，否则多出来的consumer消费不到消息。Kafka只在parition的范围内保证消息消费的局部顺序性，不能在同一个topic中的多个partition中保证总的消费性如果有在总体上保证消费顺序的需求，那么我们可以通过将topic的partition数量设置为1，将consumer group中的consumer instance数量也设置为1，但是这样会影响性能，所以kafka的顺序消费很少用。
6、消息积压
1.线上有时因为发送方发送消息速度过快，或者消费放处理消息过慢，可能会导致broker挤压大量未消费消息，此种情况如果挤压了上百万未消费消息需要紧急处理，可以修改消费端程序，让其将收到地消息快速转发到其他topic(可以设置很多分区),然后再启动多个消费者同时消费新主题地不同分区。
2.由于消息数据格式变动或者消费者程序有bug，导致消费者一直消费不成功，也可能导致broker积压大量未消费消息.此种情况可以将这些消费不成功地消息转发到其他队列里去(类似死信队列),后面再慢慢分析死信队列里地消息处理问题。
总结
本文阿伟结合自己的理解从几个方面梳理了Kafka，其中讲到了基本概念，市面上消息中间件的对比，以及Kafka在实际应用中会遇到一些问题点和处理思路。