大数据技术基础复习3【分布式消息队列】

大数据技术基础复习3【分布式消息队列】

目录

• 背景与目的
• • 生产者与消费者直接通信的问题：
  • 目的
• Kafka的作用
• Kafka的特点
• Kafka VS Flume
• Kafka的基本架构
• • Producer
  • Broker
  • Consumer
  • Kafka中的zookeeper
  • push-pull架构的好处
• Kafka的关键技术
• • 可控制的可靠性级别
  • 数据多副本
  • 高效的持久化机制
  • 数据传输优化
  • • 批处理技术
    • zero-copy
• 可控的消息传递语义
• Kafka典型使用场景
• ELK（了解）

背景与目的 生产者与消费者直接通信的问题：

• 生产者与消费者耦合度过高
  每增加一种新的消费者，所有的生产者都需要修改，数据流水线的扩展性极差。

• 生产者与消费者数据处理速度不对等
  生产者过快，可能会淹没消费者

• 大量并发的网络连接对后端消费者不友好
  大量生产者直接与消费者通信，给消费者过大的网络并发压力，成为系统扩展中潜在的性能瓶颈；
  大量生产者同时写入后端，可能产生大量小文件，对Hadoop等分布式文件系统造成过大压力（HDFS不适合存储大量小文件）。

目的

消息队列是生产者和消费者之间的中间件，将两者解耦（使得扩展和伸缩变得更容易），平衡两者处理能力的不对等

Kafka的作用

消息中间件
解耦生产者和消费者
消息队列
缓冲生产者的数据，消费者可以重复消费历史数据；
平滑两者处理能力的不对等。
发布订阅系统
消费者可以订阅某类主题的数据，从而快速获取新增数据；
随时增加新的消费者而无需进行系统层面的修改。
消息总线
所有收集的数据流经Kafka，由它分流后再进入各个消费者系统。

Kafka的特点

高性能（吞吐率高），扩展性好（分布式架构，数据分片后写入多个节点，突破单节点的处理瓶颈同时实现容错），数据持久性（均会持久化到磁盘，多副本策略，防止丢失）

Kafka VS Flume

K：

• 数据不丢
• 数据能暂存一段时间
• 生产者和消费者均需用户使用API自己编写，仅提供了少量与外部系统继承的组件，使用较复杂

F：

• 数据有可能丢失
• 发送成功之后立即删除数据
• 由大量Source和link实现，使用方便。

Kafka的基本架构

数据被分区保存，每个分区又被保存成3份以提高可靠性。
三类组件:Producer,Broker,Consumer
Broker和Consumer通过Zookeeper协调。
每条数据被称为“消息”，每条消息由如下三元组组成：

Producer

• 同步/异步地将数据写入Broker（push）。
• 发送消息时不需要指定所有Broker的地址，只需要给出一个或几个初始化Broker的地址；
• 通过指定的Broker就可以获取其他所有Broker的地址，并自动完成负载均衡。

Broker

• Producer和Consumer之间的缓冲区（解耦）。
• 以追加方式将消息持久化到磁盘。
• 多个Broker构成一个可靠的分布式消息存储系统，避免数据丢失。
• Broker中的消息被划分成若干topic，同一个topic可以被划分到不同的Broker上。
• 同一个topic的所有数据根据key被分成多个partition（分区）：为了负载均衡和数据并行处理。
• 每个partition有3个副本，副本中有一个leader负责响应外界读写请求，其余为follower，平时只负责同步leader中的消息。当leader失效，重新选举出新的leader。
• 由于只有leader负责读写，kafka的负载均衡实际上是对leader partition的负载均衡——保证leader partition 在各个broker上的数目尽可能接近
• partition内部是有序的，但是同一个topic的不同partition之间不保证全局有序——读取同一个topic的多个partition时可能得到和写入顺序不一致的序列（可利用缓存立刻重排）

Consumer

• 从Broker读取数据（pull）
• consumer负责维护已读取消息的offset，减轻Broker的压力。
• 允许多个Consumer构成一个Group，读取同一个topic的数据，并自动为它们实现负载均衡，从而提高读取效率。

Kafka中的zookeeper

broker和consumer直接依赖zookeeper实现工作。
broker向zookeeper注册，便于consumer发现它；
broker和consumer通过zookeeper得故障节点，并自动分摊故障节点的负载；
consumer向zookeeper写入最近获取消息的offset，以便故障重启后接着读取数据。

push-pull架构的好处

consumer可以按照自己的需要进行读取，避免了传统push-push方式收到的压力。
consumer负责维护已读取消息的offset，减轻Broker的压力。

Kafka的关键技术 可控制的可靠性级别

Producer通过控制消息应答方式（即同步或是异步向Broker发送消息）在写性能与可靠性之间平衡。

数据多副本

采用了强一致的数据复制策略

高效的持久化机制

写入磁盘时顺序写入，使用基于offset的数据组织方式：高效的读写速度

数据传输优化 批处理技术

多条消息组装在一起发给consumer：较少Broker在组装消息时的开销
统一设计了数据格式：减少格式转换带来的开销。

zero-copy

存在磁盘上的数据要发送出去
普通方式：内存readBuffer（内核态）----1次拷贝：磁盘到内存
applicationBuffer（用户态）----2次coppy
SocketBuffer（内核态）----3次
NICbuffer（内核态）----4次
zero-copy：内存readBuffer（内核态）----1次拷贝：磁盘到内存
SocketBuffer（内核态）----2次
NICbuffer（内核态）----3次
相比普通方式，zero-copy不需要处理器进行状态切换，不用使用系统调用，减少了拷贝次数，大大提高了数据发送效率。

可控的消息传递语义

根据接收者可能受到重复消息的次数，将消息传递语义分为：

• at least once
  发送者需要接收者确认，否则一直发送
• at most once
  发送者发送后立刻返回，不关心接收者是否收到
• exactly once
  同一条消息接收者会且只会处理一次。

Kafka典型使用场景

• 消息队列

• 流式计算框架（Spark Streaming,Storm）的数据源
  因为“at least once”的数据发送语义要求数据不丢失，数据源中需要使用一个高性能的消息队列。从而形成了分布式消息队列+分布式流式计算框架的实时计算架构。

• 分布式日志收集系统中的Source或者Sink
  与日志收集组件（如Flume）组合使用，Flume提供可配置化的Source和Sink，Kafka提供分布式高可用的消息系统。形成的组合系统在吞吐率和扩展性方面都非常优秀。

• Lambda Architecture中的Source
  Kafka同时为批处理和流式处理两条流水线提供数据源。

ELK（了解）

均由Elastic公司开发的三个开源产品。
E——ElasticSearch：分布式搜索日志
L——LogStash：日志存储
K——Kibana：可视化