Kafka特性
————————————————————————————————————————————————
【关键原理】
1.消息文件存储(消息堆积能力)
2.消息topic分区
3.消息顺序的保证
4.拉模型(消费者水平扩展)
————————————————————————————————————————————————
【关键概念】
Producer :消息生产者,就是向kafka broker发消息的客户端。
Consumer :消息消费者,向kafka broker取消息的客户端
Topic :咋们可以理解为一个队列。
Consumer Group (CG):这是kafka用来实现一个topic消息的广播(发给所有的consumer)和单播(发给任意一个consumer)的手段。一个topic可以有多个CG。topic的消息会复制(不是真的复制,是概念上的)到所有的CG,但每个CG只会把消息发给该CG中的一个consumer。如果需要实现广播,只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。
Broker :一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。
Partition:为了实现扩展性,一个非常大的topic可以分布到多个broker(即服务器)上,一个topic可以分为多个partition,每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id(offset)。kafka只保证按一个partition中的顺序将消息发给consumer,不保证一个topic的整体(多个partition间)的顺序。
Offset:kafka的存储文件都是按照offset.kafka来命名,用offset做名字的好处是方便查找。例如你想找位于2049的位置,只要找到2048.kafka的文件即可。当然the first offset就是00000000000.kafka
————————————————————————————————————————————————
处理大量数据。Kafka主要的设计约束是吞吐量而不是功能。(活跃的流式数据实时处理)
分布式应用间的通信。
基于拉的消费模型让消费者以自己的速度处理消息
如果处理消息时出现了异常,消费者始终可以选择再消费该消息。
【kafka设计目标】
高吞吐量是其核心设计之一。
数据磁盘持久化:消息不在内存中cache,直接写入到磁盘,充分利用磁盘的顺序读写性能。
zero-copy:减少IO操作步骤。
支持数据批量发送和拉取。
支持数据压缩。
Topic划分为多个partition,提高并行处理能力。
【特征】
严格的消息顺序、丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力。
【kafka特性】
通过O(1)的磁盘数据结构提供消息的持久化,这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。
高吞吐量:即使是非常普通的硬件kafka也可以支持每秒数十万的消息。
支持同步和异步复制两种HA
Consumer客户端pull,随机读,利用sendfile系统调用,zero-copy ,批量拉数据
消费状态保存在客户端
消息存储顺序写
数据迁移、扩容对用户透明
支持Hadoop并行数据加载。
支持online和offline的场景。
持久化:通过将数据持久化到硬盘以及replication防止数据丢失。
scale out:无需停机即可扩展机器。
定期删除机制,支持设定partitions的segment file保留时间。
【应用场景】
日志异步记录:高吞吐量+低一致性要求。
顺序同步:MySQL binlog复制。
消息广播。(消息推送)
分布式消息路由。
【消息分发的可靠性】
kafka(MQ)要实现从producer到consumer之间的可靠的消息传送和分发。
传统的MQ系统通常都是通过broker和consumer间的确认(ack)机制实现的,并在broker保存消息分发的状态。即使这样一致性也是很难保证的。
kafka的做法是由consumer自己保存状态,也不要任何确认。这样虽然consumer负担更重,但其实更灵活了。
因为不管consumer上任何原因导致需要重新处理消息,都可以再次从broker获得。
————————————————————————————————————————————————