消息队列分类

点对点

消息生产者生产消息发送到queue中,然后消息消费者从queue中取出并且消费消息。这里要注意:

  • 消息被消费以后,queue中不再有存储,所以消息消费者不可能消费到已经被消费的消息。
  • Queue支持存在多个消费者,但是对一个消息而言,只会有一个消费者可以消费。

发布/订阅

消息生产者(发布)将消息发布到topic中,同时有多个消息消费者(订阅)消费该消息。和点对点方式不同,发布到topic的消息会被所有订阅者消费。

kafka介绍

kafka是一个分布式的、分区的、多副本的、多订阅者的日志系统(分布式消息队列)。可同时支持点对点模式的消息队列和发布/订阅模式的消息队列。

kafka架构说明

kafka角色术语:

  • Broker:一台kafka服务器就是一个broker。一个集群由多个broker组成
  • Topic:消息队列,不同的消息会被发送至不同的队列当中
  • Producer:消息生产者,就是向kafka broker发消息的客户端
  • Consumer:消息消费者,从kafka broker取消息的客户端
  • Consumer Group(CG):这是kafka用于实现一个topic消息广播(发给所有的consumer)和单播(发给某一个consumer)的手段。一个topic可以有多个CG,topic的每一条消息都会发送给每个CG,但CG只会把消息发送给该CG中的一个consumer。如果需要实现广播,只要将每个consumer配置一个独立的CG即可。而要实现单播则只要将所有的consumer放至同一个CG即可。用CG还可以将consumer进行自由的分组而不需要producer多次发送消息到不同的topic
  • Partition:Partition是物理上的概念。为了实现扩展性,一个非常大的topic可以分布到多个broker上,一个topic可以分为多个partition,每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id(offset)。kafka只保证按一个partition的顺序将消息发给consumer,不保证一个topic的整体顺序
  • Offset:kafka的存储文件都是按照offset.kafka来命名,用offset做名字的好处是方便查找。例如你想找2049的位置,只要找到2048.kafka文件即可。第一个位置为00000000000.kafka

kafka特性:

  • 提供数据持久化,消息顺序写入磁盘,提升机械盘的读写性能
  • 高吞吐量:即使是非常普通的硬件kafka也可以支持每秒数十万的消息
  • 通过多副本的方式防止消息丢失
  • 支持消息的同步和异步发送
  • 消费状态保存在客户端
  • 数据迁移、扩容对用户透明
  • 定期删除机制,支持设定partitions的segment file保留时间。

kafka支持消息持久化存储,持久化数据保存在kafka的日志文件中,在生产者生产消息后,kafka不会直接把消息传递给消费者,而是先要在broker中进行存储,为了减少磁盘的写入次数,broker会将消息暂时缓存起来,当消息的个数或尺寸、大小达到一定阈值时,再统一写到磁盘上。通过这种方式以提高kafka的执行效率,并减少磁盘IO的调用次数。kafka中的每条消息写到partition中,是顺序写入磁盘的,这可进一步保证写入效率。

Topic与Partition的关系

Kafka中的topic是以partition的形式存放的,每个topic都可以设置它的partition数量,推荐partition的数量要大于同时运行的consumer的数量,也建议partition的数量大于集群broker的数量,这样消息数据就可以均匀的分布在各个broker中。

在存储结构上,每个partition在物理上对应一个文件夹,该文件夹下存储这个partition的所有消息和索引文件。parition命名规则为topic名称+序号,每一个partition序号从0开始,序号最大值为partitions数量减1。

每个partition中有多个大小相等的segment数据文件,每个segment的大小是相同的,但每个消息的大小可能不同,因此segment数据文件中消息的数量可能不相等。segement数据文件有两部分组成,分别为index file和data file,此两个文件是一一对应,对成出现,后缀分别为".index"和".log"。

每个patition有自己的replica,每个replica分布在不同的broker节点上,多个partition需要选举出leader partition,leader负责读写,并由zk负责fil over。

一个Topic配置多个patition可以将消息内容分散存放到多个broker上,这样就可以避免文件尺寸达到单机磁盘的上限,同时还可以保证消息存储、消费的效率,因为更多的patitions可以容纳更多的consumer,可有效提升kafka的吞吐率。

partition复制机制

  • 在kafka中,复制策略是基于partition,而不是topic。kafka将每个partition数据复制到多个server上,任何一个partition有一个leader和0到多个follower,副本的数量可以通过broker配置文件定义。
  • leader处理所有的读写请求,follower需要与leader保持同步。Follower就像一个consumer,消费消息并保存至本地日志中。leader负责跟踪所有的follower状态,如果follower落后太多或者失效,leader将会把它从同步列表中删除。它会继续从leader从获取数据,直至数据足够新,然后再次加入到同步列表当中。
  • kafka不会更换replicas宿主,因为同步列表中的replicas需要足够快,才能保证producer发布消息时接受到ACK的延迟较小。
  • 当所有follower都将一条消息保存成功,此消息才被认为是"committed",那么此时consumer才能消费它,这种同步策略要求follower和leader之间必须具有良好的网络环境。
  • 即使只有一个replica实例存活,仍然可以保证消息的正常发送和接收,只要zk存活即可(这一点相较于其它分布式存储要求多数存活的方式不同)。
  • 当leader失效时,需要在follower当中选取新的leader。kafka中leader的选举并没有采用多数投票的算法。因为这种算法对于网络稳定性、投票者的数量等条件有要求。对于kafka而言,每个partition中所有的replicas信息都可以在zk中获得,因此选取leader对它来讲是一件很容易的事情。

Consumer与Topic的关系

kafka作为分布式的消息系统支持多个producer和多个consumer,producer可以将消息分布到集群中不同节点的不同patition上,consumer也可以消费多个节点上的多个patition。在写消息时允许多个producer写到同一个partition中,但是读消息时,一个partition只允许被一个consumer group中的一个consumer所消费。而一个consumer可以消费多个patition。也就是说同一个consumer group下的consumer对partition是互斥的,而不同consumer group之间则是共享的。

通常情况下,一个group中会包含多个consumer,这样不仅可以提高topic中消息的并发消费能力,而且还能提高"故障容错"性,如果group中的某个consumer失效,那么其消费的partitions将会有其他consumer自动接管。而对于一个topic,同一个group中不能有多于partitions个数的consumer同时消费,否则将意味着某些consumer将无法得到消息

kafka原理篇的更多相关文章

  1. [转帖]Kafka 原理和实战

    Kafka 原理和实战 https://segmentfault.com/a/1190000020120043 两个小时读完... 实在是看不完... 1.2k 次阅读  ·  读完需要 101 分钟 ...

  2. Cesium原理篇:5最长的一帧之影像

    如果把地球比做一个人,地形就相当于这个人的骨骼,而影像就相当于这个人的外表了.之前的几个系列,我们全面的介绍了Cesium的地形内容,详见: Cesium原理篇:1最长的一帧之渲染调度 Cesium原 ...

  3. Cesium原理篇:3最长的一帧之地形(2:高度图)

           这一篇,接着上一篇,内容集中在高度图方式构建地球网格的细节方面.        此时,Globe对每一个切片(GlobeSurfaceTile)创建对应的TileTerrain类,用来维 ...

  4. Cesium原理篇:7最长的一帧之Entity(下)

    上一篇,我们介绍了当我们添加一个Entity时,通过Graphics封装其对应参数,通过EntityCollection.Add方法,将EntityCollection的Entity传递到DataSo ...

  5. Esfog_UnityShader教程_遮挡描边(原理篇)

    咳咳,有段时间没有更新了,最近有点懒!把不少精力都放在C++身上了.闲言少叙,今天要讲的可和之前的几篇有所不同了,这次是一个次综合应用.这篇内容中与之前不同主要体现在下面几点上. 1.之前我们写的都是 ...

  6. 【如何快速的开发一个完整的iOS直播app】(原理篇)

    原文转自:袁峥Seemygo    感谢分享.自我学习 目录 [如何快速的开发一个完整的iOS直播app](原理篇) [如何快速的开发一个完整的iOS直播app](播放篇) [如何快速的开发一个完整的 ...

  7. iOS:app直播---原理篇

    [如何快速的开发一个完整的iOS直播app](原理篇) 转载自简书@袁峥Seemygo:http://www.jianshu.com/p/7b2f1df74420   一.个人见解(直播难与易) 直播 ...

  8. Kakfa揭秘 Day1 Kafka原理内幕

    Spark Streaming揭秘 Day32 Kafka原理内幕 今天开始,会有几天的时间,和大家研究下Kafka.在大数据处理体系中,kafka的重要性不亚于SparkStreaming.可以认为 ...

  9. 如何快速的开发一个完整的iOS直播app(原理篇)

    目录 [如何快速的开发一个完整的iOS直播app](原理篇) [如何快速的开发一个完整的iOS直播app](播放篇) [如何快速的开发一个完整的iOS直播app](采集篇) 前言 大半年没写博客了,但 ...

随机推荐

  1. Java集合Collection基本方法

    jdk1.7 api中的方法摘要: 参考java集合大全图:https://www.cnblogs.com/xkzhangsanx/p/10889114.html Collection为List.Se ...

  2. 微服务架构 ------ 插曲 hikari连接池的配置

    开胃菜:据说hikari连接池很快,快到让另一个连接池的作者抛弃对自己连接池的维护,并且强烈推荐使用hikari 连接池目前我们项目使用的有两个 一个是Druid , 一个是 Hikari, 其中Dr ...

  3. ES6的强大变量声明

    ES6是javascript的新特性,今天来说说声明变量 过去我们声明变量,都是一个一个声明,现在有了一种新的声明方式,它可以将一个多个变量同时声明,声明后变量同时存在一个集合中,集合的数据类型是对象 ...

  4. fatal error C1189: #error : Building MFC application with /MD[d] (CRT dll version) requires MFC

    出现如下错误: fatal error C1189: #error : Building MFC application with /MD[d] (CRT dll version) requires ...

  5. leetcode之有效的括号(20)

    题目: 给定一个只包括 '(',')','{','}','[',']' 的字符串,判断字符串是否有效. 有效字符串需满足: 左括号必须用相同类型的右括号闭合. 左括号必须以正确的顺序闭合. 注意空字符 ...

  6. ubuntu16.04 共享文件夹之后 /mnt/hgfs目录下没有显示共享的文件夹

    root权限执行: apt-get install open-vm-tools vmhgfs-fuse .host:/ /mnt/hgfs

  7. Python实现斐波那契数列,九九乘法表,金字塔方法。

    斐波那契数列普通函数实现 #普通函数 def fb(max): a,b=0,1 while a<max: print(a) a,b=b,a+b fb(100) 递归实现方法1 def fb1(m ...

  8. Java精通并发-Condition编程模式详解与分析

    继续上一次https://www.cnblogs.com/webor2006/p/11890688.html的Condition接口说明进行阅读: 上面这个程序会在之后手动来实现一下,说实话这种写法在 ...

  9. Kubernetes安全策略

    Kubernetes CIS Benchmark 见kube-bench 1.安全策略 1.1 使用宿主节点的命名空间 命名空间分 网络命名空间 PID命名空间 IPC命名空间 Pod使用主机的网络命 ...

  10. this指向问题(改变它的指向)

    这个问题倒不是面向对象的,而是今天遇到js面向对象的时候一个例子的时候突然遇到了,call()方法,然后自己突然发现竟然忘记了,查了之后整理如下: xxx.call((对象名),参数a,参数b) xx ...