• kafka分布式消息队列 — 基本概念介绍


    【http://www.inter12.org/archives/818】

    这个应该算是之前比较火热的词了,一直没时间抽出来看看。一个新东西出来,肯定是为了解决某些问题,不然不会有它的市场。先简单看下。
    官方介绍:分布式、分区、支持复制的日志提交系统
    适用场景:顾名思义,特别适合用于系统日志的异步记录,对于数据稳定性、一致性、可靠性要求不高的场景,追求的是高吞吐量。非传统的MQ产品!


    核心模型抽象:
      topics:某种消息的高层抽象
      producers:消息的生产者
      consumers:消息的消费者
      broker:集群中的每一个节点服务器,多个broker组成一个集群

    整体结构图


    topic:
    1.kafka集群会将每个topic进行分区,每个分区都是一个排序且不可改变的队列,新的消息会进入队尾并分配一个唯一ID,官方称之为偏移量(offset)
    2.无论消息是否被消费,集群都会保留消息,有一个配置的时间(过期时间),超过这个时间后,消息会被清除
    3.消费端唯一记录的元信息就是自己在topic中的位置(offset),
    4.分布式的原因:第一集群可以容纳大量的数据 第二:可以并行的处理

    分布式
      1.每一份数据都会复制到不同的服务器上,以便与容错处理
      2.每一个topic的分区都会有一个leader,并有零个或是多个follower,所有的读写请求都会经过leader来进行分发,若是leader发生错误的话,那么就会有一个follower上位成为leader


    生产者
      Producers会将数据发送消息到topic,发送的目的地可以根据轮训策略或是到指定的分区策略


    消费者
      消息一般有两种模式,其一是队列,另一种是发布订阅。
      队列:有很多消费者,每一个消费者从队列中获取其中一个数据,一个数据只被消费一次。
      发布订阅模式:将一个消费广播到所有的消费者,一个数据会被消费N次。

    kafka对于消费者提供了一种简单的抽象 — 消费组。每一个消费者都会有一个消费组的名称,一个消费会发布到一个topic上,同时递送到订阅了这个消息的消费组下的所有消费者。具体如下图所示:

    若是所有的消费者都是相同的消费组,那么就是一个队列模式。

    若是消费者有不同的组,那么就是发布订阅模式,那么消费就会递送到所有的消费者。


    通过对于消费组的名称不同来区分了队列和发布订阅模式


    每一个topic都会有一定数量的消费组,每个消费组(逻辑订阅者)包含了多个消费者,这样就可以保证可伸缩性金额容错。这样订阅者就是一个集群而不是单个实例。保证单点故障问题。
    在强一致性上kafka同传统的MQ也在靠近。
    传统的队列是将消息按照存储时候的顺序进行发送,但是有多个消费者的时候,有可能发生到底每个消费者的顺序不一定,一是导致无法并行,二是导致消费的顺序不一致。为了解决这个问题,通常的手段是只有一个消费者来保证顺序。

    针对上面两个问题,kafka有自己的解决方案。解决并行是将多个分区分别指定对应的消费者,这样就保证了并行,同时保证了消息消费的顺序,限制是消费者的数量不能多于分区数目(通过配置指定).


    但是这样就只能保证一个分区中的消息是保证顺序,无法保证不同分区的消息的顺序一致性。在大多数应用场景下,这样是能满足要求的,若是你要求非常强烈的一致性话,就只能单消费者了。


    一致性
    1.topic接受到消息并保存到队列中,若是收到M1,M2两个消息,那么在队列中M1的偏移量会小于M2
    2.消费者看到消息的顺序就是在保存到日志上的顺序
    3.一个topic的复制因子是N,那么消息会被复制到N-1服务器上,保证消息的不丢失


    一些常见的使用场景
    1.作为消息处理系统
    作用:解耦消息的生产和处理、缓存消息以缓解对于后端处理承受的压力
    可以比较的类似产品是ActiveMQ or RabbitMQ.


    2.网页行为记录
    一个用户的行为记录的消费者一般是多个,可能是实时处理系统,也可能是离线处理系统,同时吞吐量非常的大,kafka就非常的适合


    3.监控 对于一些监控数据的处理


    4.日志聚合方案
    这个是kafka最常用的地方,用于分散到多个地方的日志做一个聚合,以便于后续的分析处理


    5.流式处理
    官方的说法是也可以把kafka当做类似Strom或Samza的流式处理框架来用,至于效果如何就未知


    6.事件驱动架构
    这种架构风格中的候选者之一
    消息框架的出现解决了很多问题,例如解耦消息的生产和处理、缓存消息以缓解对于后端处理承受的压力(提升性能.不同框架的设计决定了它的适用场景,kafka的topic分区并行设计决定了它的高吞吐量,但是不保证顺序一致性,对于feed类就不友好

    其他:
    1.支持批量发布
    2.基于TCP协议,传输层协议,不需要任何的语义
    3.有不同客户端实现


    参考资料:
    http://kafka.apache.org/documentation.html#introduction
    http://www.zhihu.com/question/22480085

  • 相关阅读:
    外部类和内部类的创建调用实例2个
    构造函数实例化
    前端学习(二十三)DOM操作,事件(笔记)
    前端学习(二十二)css3(笔记)
    前端学习(二十一)初识h5(笔记)
    前端学习(二十)jquery属性(笔记)
    前端学习(十九)jquery(笔记)
    前端学习(十八)js的json(笔记)
    前端学习(十七)js数组(笔记)
    前端学习(十六)字符串(笔记)
  • 原文地址:https://www.cnblogs.com/lsx1993/p/4627465.html
Copyright © 2020-2023  润新知