消息队列分类

点对点

消息生产者生产消息发送到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. Python基础10

    字符串大小写转换,除了upper,lower,还有一种方法,casefold( ) 方法 比较这两种方法的适用范围

  2. centOs6和Centos7开放/关闭端口区别

    #centos6启动防火墙 service iptables start #centos6停止防火墙/关闭防火墙  service iptables stop #centos6重启防火墙 servic ...

  3. 获取post传输参数

    1.获取post参数可以用 传输参数为 a=aa&b=bb这种 public static SortedDictionary<string, string> GetRequestP ...

  4. Cocos Creator 返回字符串长度(字符),汉字计数为2

    function strLength(str) { var a = 0; for (var i = 0; i < str.length; i++) { if (str.charCodeAt(i) ...

  5. jquery实现一些小动画一

    jquery实现小动画 <!DOCTYPE html> <html lang="en"> <head> <meta charset=&qu ...

  6. python测试开发django-72.删除表后如何重新生成表

    前言 在使用ORM建表的时候,由于需要对数据库表的重新设计,需要删除原表,并通过Django的ORM功能重新同步表. 删除表之后,发现用 makemigrations 和 migrate 无法生成新的 ...

  7. CodeForces 407E: k-d-sequence

    题目传送门:CF407E. 题意简述: 给定非负整数 \(k,d\) 和一个长度为 \(n\)(\(1\le n\le 2\times 10^5\))的整数序列 \(a\). 求这个序列中最长的一个连 ...

  8. RMP和YUM软件安装

    1.卸载RPM包 rpm -e rpm包的名称 2.安装rpm包 rmp -ivh xxx.rpm 3.查询yum服务器是否有需要安装的软件 yum list|grep xxx软件列表 4.yum安装 ...

  9. gitlab的搭建和使用(转)

    工作当中常用的GitHub比较好用,但是安全性不是太强,因为github完全开源的,安全性不高 有空搞一下,先记录几个博客 https://yq.aliyun.com/articles/44531 h ...

  10. 04-cmake语法-STREQUAL

    STREQUAL 用于比较字符串,相同返回 true .