kafka分布式消息系统入门

Posted 2021-05-02 XDMonkey

　最近看到公司在使用kafka消息系统，之后就发现了其实身边有蛮多kafka的资讯，原来已经这么火了但是自己还是浑然不知，满满的负罪感，是不是已经脱离工业界太久了。

---

更新记录

• 2017.7.8 完成初稿

kafka是什么

---

　　kafka是由Linkedln开发的用scala编写的一个分布式的发布（producer）/订阅（consumer）消息系统，原本是用过Linkedln的活动六和运营数据处理管道的基础。现在已经被多家公司作为多种类型的数据管道和消息系统使用

kafka解决了什么问题

---

　　实际上发布/订阅的消息系统已经存在非常多了，kafka也只是其中一种，那么kafka作为其中一员，有什么独特的地方？

kafka的设计目标

---

• 以常数级的方式提供消息持久化的能力，即使对TB级以上的数据也能保证常数级别时间复杂度的访问性能；

• 高吞吐率，即使在非常廉价的机器上也能做到对单机支持每秒100K以上的消息传输；

• 支持消息分区以及分布式消费，同时保证各个分区（partition）内的消息传递顺序；

• 同时支持实时和离线两种数据处理方式；

• Scale out,支持在线水平拓展

kafka中的概念简介

---

　　topic：主题，可以理解成是一个消息队列，是一个纯逻辑概念，实际上是指的是kafka处理的不同消息源（feeds of message，据一些网上其他的文档表示，feeds在计算机领域里更多的指一种用户从数据源接受消息的机制）的不同分类。
　　producer：生产者，表示向kafka的一个topic发布消息到broker的进程。
　　consuemr：消费者，订阅topic，并且负责从对应topic获取数据的进程。
　　consumer group：每个消费者都属于一个特定的consumer group，我们可以为每一个consumer指定group name。
　　broker：kafka集群中的一台或者多台服务器，我们将这个服务器称之为broker，一个broker指的就是一个这样的服务器。
　　partition：分区，是一个物理上的概念，我们的每个topic都包含有一个或者多个的partition。

topic和partition

---

　　为了提高kafka的吞吐率，kafka中将一个topic分成一个或者多个partition来保存。每个partition是一个排序好的，不可变的消息序列，新的消息不断追加到序列的尾部，每个partition在物理上都对应一个文件夹，在该文件夹下存储有该partition的所有消息和索引文件，举个例子如果我们创建topic1和topic2两个topic，而且分别有13和19两个分区，那么整个集群上就会有32个对应的文件夹。
　　每一个分区中的消息，都有一个名叫offset的顺序编号，作为这条消息在partition中的标识，指明了这条消息的起始位置。

　　kafka中每条消息都被append到partition的末尾，属于顺序写磁盘，因此效率非常之高，经过验证，顺序写入磁盘的效率甚至比随机写入内存的效率还要高，这也是kafka高吞吐率的一个保证。
　　kafka集群将在设定的时间范围内，保存所有被发布的消息，不论该消息是否被处理完成。例如，如果一个日志被设置为保存2天，那么在它发布的两天之内，它都是可以被处理的，而在2天之后，它就会被系统销毁并释放掉。
　　topic有一个参数叫replication factor，我们在创建topic的时候如果是这样指明参数的：–replication-factor 1 –partitions 2，即表明该topic的日志文件有一份拷贝，同时放了两个分区存储。举个例子，下面这张图中，就表明的是有2个备份，4个partition的。

　那么通过上面这个图，就可以看到每个broker上存储的数据量是比全量的数据要少的，但是每一份数据都是有冗余的。我们一般指定复制因子的大小要根据自己的broker cluster的大小来合理指定。

topic为什么要分区

　　实际上分区更多的是为了水平拓展的必要性考虑，在我们进行了分区之后，单个的机器中可能并没有完整的topic日志文件，而反观在分区之前，显然我们的一个broker上就会有该topic上完整的信息，那么单个的broker可能就会成为将来水平拓展的性能瓶颈，这种瓶颈不仅仅是存储方面的，也可能是性能上的，比如如果我们将单台机器上存储了完整的topic，那么将来就可能单台机器的访问量过大，设计partition的话将同一个topic的内容分布在多台机器上，可以分摊服务器压力，因此设计partition是出于综合的考虑。
　　实际上在producer发送消息到broker中的时候，会根据partition机制选择将其存储到哪一个partition中，如果partition机制设置合理，所有消息可以均匀分布到不同的Partition里，这样就实现了负载均衡。如果一个Topic对应一个文件，那这个文件所在的机器I/O将会成为这个Topic的性能瓶颈，而有了Partition后，不同的消息可以并行写入不同broker的不同Partition里，极大的提高了吞吐率。

consumer group

---

　　这里特别要提一下，kafka提供了两种consumer api，一种是high level consumer api，另外一种是low level consumer api，实际的学习中，发现基于hign level consumer api的比较多一些。因此这里的介绍也是基于hign level consumer api中的consumer api的。
在使用high level consumer api的时候，同一个topic中的一条消息只能被同一个consumer group内的一个consumer消费，但是多个consumer group可以同时消费这一个消息。