目录
- MQ的模型
- 点对点:
- 消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。
- 注意：
- 消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。
- Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。
- 发布/订阅:
消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。
- RabbitMQ：支持的协议多，非常重量级消息队列，对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。
- ZeroMQ：号称最快的消息队列系统，尤其针对大吞吐量的需求场景，擅长的高级/复杂的队列，但是技术也复杂，并且只提供非持久性的队列。
- ActiveMQ：Apache下的一个子项，类似ZeroMQ，能够以代理人和点对点的技术实现队列 。
- Redis：是一个key-Value的NOSql数据库，但也支持MQ功能，数据量较小，性能优于RabbitMQ，数据超过10K就慢的无法忍受
- Kafka简介
Kafka 是分布式发布-订阅消息系统。它最初由 LinkedIn 公司开发，使用 Scala语言编写,之后成为 Apache 项目的一部分。Kafka 是一个分布式的，可划分的，多订阅者,冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。
- Kafka的特点
- 同时为发布和订阅提供高吞吐量。据了解，Kafka 每秒可以生产约 25 万消息（50 MB），每秒处理 55 万消息（110 MB）。
- 可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如 ETL，以及实时应用程序。通过将数据持久化到硬盘以及 replication 防止数据丢失。
- 分布式系统，易于向外扩展。所有的 producer、broker 和 consumer 都会有多个，均为分布式的。无需停机即可扩展机器。
- 消息被处理的状态是在 consumer 端维护，而不是由 server 端维护。当失败时能自动平衡。
- 支持 online 和 offline 的场景。
- Kafka的逻辑架构
- Kafka的核心概念
- Producer 特指消息的生产者
- Consumer 特指消息的消费者
- Consumer Group 消费者组，可以并行消费Topic中partition的消息
- Broker：缓存代理，Kafa 集群中的一台或多台服务器统称为 broker。
- Topic：特指 Kafka 处理的消息源（feeds of messages）的不同分类。
- Partition：Topic 物理上的分组，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。partition 中的每条消息都会被分配一个有序的 id（offset）。
- Message：消息，是通信的基本单位，每个 producer 可以向一个 topic（主题）发布一些消息。
- Producers：消息和数据生产者，向 Kafka 的一个 topic 发布消息的过程叫做 producers。
- Consumers：消息和数据消费者，订阅 topics 并处理其发布的消息的过程叫做 consumers。
- Kafka的Producers
- 消息和数据生产者，向 Kafka 的一个 topic 发布消息的过程叫做 producers。
- Producer将消息发布到指定的Topic中,同Producer也能决定将此消息归属于哪个partition;比如基于"round-robin"方式或者通过其他的一些算法等.
- 异步发送
批量发送可以很有效的提高发送效率。Kafka producer的异步发送模式允许进行批量发送，先将消息缓存在内存中，然后一次请求批量发送出去。
- Kafka的Broker
- Broker：缓存代理，Kafka 集群中的一台或多台服务器统称为 broker。
- Message在Broker中通Log追加的方式进行持久化存储。并进行分区（patitions)
- 为了减少磁盘写入的次数,broker会将消息暂时buffer起来,当消息的个数(或尺寸)达到一定阀值时,再flush到磁盘,这样减少了磁盘IO调用的次数。
- Kafka的Broker无状态机制
1. Broker没有副本机制，一旦broker宕机，该broker的消息将都不可用。
2. Broker不保存订阅者的状态，由订阅者自己保存。
3. 无状态导致消息的删除成为难题（可能删除的消息正在被订阅），kafka采用基于时间的SLA(服务水平保证)，消息保存一定时间（通常为7天）后会被删除。
4. 消息订阅者可以rewind back到任意位置重新进行消费，当订阅者故障时，可以选择最小的offset(id)进行重新读取消费消息。
- Kafka的Message组成
- Message消息：是通信的基本单位，每个 producer 可以向一个 topic（主题）发布一些消息。
- Kafka中的Message是以topic为基本单位组织的，不同的topic之间是相互独立的。每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定的)，每个partition存储一部分Message。
- partition中的每条Message包含了以下三个属性：
offset 对应类型：long
MessageSize 对应类型：int32
data 是message的具体内容
- Kafka的Partitions分区的目的
- kafka基于文件存储.通过分区,可以将日志内容分散到多个server上,来避免文件尺寸达到单机磁盘的上限,每个partiton都会被当前server(kafka实例)保存;
- 可以将一个topic切分多任意多个partitions,来消息保存/消费的效率.
- 越多的partitions意味着可以容纳更多的consumer,有效提升并发消费的能力.
- Kafka的Consumers
- 消息和数据消费者，订阅 topics 并处理其发布的消息的过程叫做 consumers。
- 在 kafka中,我们 可以认为一个group是一个“订阅者”,一个Topic中的每个partions,只会被一个“订阅者”中的一个consumer消费,不过一个 consumer可以消费多个partitions中的消息（消费者数据小于Partions的数量时）
- 注： kafka的设计原理决定,对于一个topic,同一个group中不能有多于partitions个数的consumer同时消费,否则将意味着某些consumer将无法得到消息.
- Kafka的持久化
- 数据持久化：
发现线性的访问磁盘，很多时候比随机的内存访问快得多
传统的使用内存做为磁盘的缓存
Kafka直接将数据写入到日志文件中
- 日志数据持久化特性：
写操作：通过将数据追加到文件中实现
读操作：读的时候从文件中读就好了
- 优势：读操作不会阻塞写操作和其他操作，数据大小不对性能产生影响；
没有容量限制（相对于内存来说）的硬盘空间建立消息系统；
线性访问磁盘，速度快，可以保存任意一段时间！
- 一个Topic可以认为是一类消息，每个topic将被分成多partition(区),每个partition在存储层面是append log文件。任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量）,partition是以文件的形式存储在文件系统中。
- Logs文件根据broker中的配置要求,保留一定时间后删除来释放磁盘空间。
Partition：
Topic 物理上的分组，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。 partition 中的每条消息都会被分配一个有序的 id（offset）。
- 为数据文件建索引：稀疏存储，每隔一定字节的数据建立一条索引。
下图为一个partition的索引示意图：
- Kafka的分布式实现
- Kafka的通讯协议
- Kafka的Producer、Broker和Consumer之间采用的是一套自行设计基于TCP层的协议，根据业务需求定制，而非实现一套类似Protocol Buffer的通用协议。
- 基本数据类型：
- 定长数据类型：int8,int16,int32和int64，对应到Java中就是byte, short, int和long。
- 变长数据类型：bytes和string。变长的数据类型由两部分组成，分别是一个有符号整数N(表示内容的长度)和N个字节的内容。其中，N为-1表示内容为null。bytes的长度由int32表示，string的长度由int16表示。
- 数组：数组由两部分组成，分别是一个由int32类型的数字表示的数组长度N和N个元素。
- Kafka通讯的基本单位是Request/Response
- 基本结构：
- RequestOrResponse => MessageSize (RequestMessage | ResponseMessage)
| 名称 | 类型 | 描述 |
| MessageSize | int32 | 表示RequestMessage或者ResponseMessage的长度 |
| RequestMessage ResponseMessage | — | 表示Request或者Response的内容 |
- 通讯过程：
客户端打开与服务器端的Socket
往Socket写入一个int32的数字(数字表示这次发送的Request有多少字节)
服务器端先读出一个int32的整数从而获取这次Request的大小
然后读取对应字节数的数据从而得到Request的具体内容
服务器端处理了请求后，也用同样的方式来发送响应。
- RequestMessage结构:
- RequestMessage => ApiKey ApiVersion CorrelationId ClientId Request
| 名称 | 类型 | 描述 |
| ApiKey | int16 | 表示这次请求的API编号 |
| ApiVersion | int16 | 表示请求的API的版本，有了版本后就可以做到后向兼容 |
| CorrelationId | int32 | 由客户端指定的一个数字唯一标示这次请求的id，服务器端在处理完请求后也会把同样的CorrelationId写到Response中，这样客户端就能把某个请求和响应对应起来了。 |
| ClientId | string | 客户端指定的用来描述客户端的字符串，会被用来记录日志和监控，它唯一标示一个客户端。 |
| Request | - | Request的具体内容。 |
- ResponseMessage结构:
- ResponseMessage => CorrelationId Response
| 名称 | 类型 | 描述 |
| CorrelationId | int32 | 对应Request的CorrelationId。 |
| Response | - | 对应Request的Response，不同的Request的Response的字段是不一样的。 |
- Kafka采用是经典的Reactor(同步IO)模式，也就是1个Acceptor响应客户端的连接请求，N个Processor来读取数据，这种模式可以构建出高 性能的服务器。
- Message:Producer生产的消息,键-值对
- Message => Crc MagicByte Attributes Key Value
| 名称 | 类型 | 描述 |
| CRC | int32 | 表示这条消息(不包括CRC字段本身)的校验码 |
| MagicByte | int8 | 表示消息格式的版本，用来做后向兼容，目前值为0 |
| Attributes | int8 | 表示这条消息的元数据，目前最低两位用来表示压缩格式 |
| Key | bytes | 表示这条消息的Key，可以为null |
| Value | bytes | 表示这条消息的Value。Kafka支持消息嵌套，也就是把一条消息作为Value放到另外一条消息里面。 |
- MessageSet:用来组合多条Message，它在每条Message的基础上加上了Offset和MessageSize
- MessageSet => [Offset MessageSize Message]
| 名称 | 类型 | 描述 |
| Offset | int64 | 它用来作为log中的序列号，Producer在生产消息的时候还不知道具体的值是什么，可以随便填个数字进去 |
| MessageSize | int32 | 表示这条Message的大小 |
| Message | - | 表示这条Message的具体内容，其格式见上一小节。 |
- Request/Respone和Message/MessageSet的关系：
| Request/Response是通讯层的结构，和网络的7层模型对比的话，它类似于TCP层。 |
| Message/MessageSet定义的是业务层的结构，类似于网络7层模型中的HTTP层。Message/MessageSet只是Request/Response的payload中的一种数据结构。 |
- 备注：Kafka的通讯协议中不含Schema，格式也比较简单，这样设计的好处是协议自身的Overhead小，再加上把多条Message放在一起做压缩，提高压缩比率，从而在网络上传输的数据量会少一些。
- at most once: 最多一次,这个和JMS中"非持久化"消息类似.发送一次,无论成败,将不会重发.
- at least once: 消息至少发送一次,如果消息未能接受成功,可能会重发,直到接收成功.
- exactly once: 消息只会发送一次.
- at most once: 消费者fetch消息,然后保存offset,然后处理消息;当client保存offset之后,但是在消息处理过程中出现了异常,导致部分消息未能继续处理.那么此后"未处理"的消息将不能被fetch到,这就是"at most once".
- at least once: 消费者fetch消息,然后处理消息,然后保存offset.如果消息处理成功之后,但是在保存offset阶段zookeeper异常导致保存操作未能执行成功,这就导致接下来再次fetch时可能获得上次已经处理过的消息,这就是"at least once"，原因offset没有及时的提交给zookeeper，zookeeper恢复正常还是之前offset状态.
- exactly once: kafka中并没有严格的去实现(基于2阶段提交,事务),我们认为这种策略在kafka中是没有必要的.
- 注：通常情况下"at-least-once"是我们首选.(相比at most once而言,重复接收数据总比丢失数据要好).
- Kafka安装
- 下载
http://kafka.apache.org/downloads.html
- 解压
tar -zxvf kafka_2.10-0.8.1.1.tgz
- 启动服务
首先启动zookeeper服务
bin/zookeeper-server-start.sh config/zookeeper.properties
启动Kafka
bin/kafka-server-start.sh config/server.properties >/dev/null 2>&1 &
- 创建topic
创建一个"test"的topic，一个分区一个副本
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test
- 查看主题
bin/kafka-topics.sh --list --zookeeper localhost:2181
- 查看主题详情
bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic test
- 删除主题
bin/kafka-run-class.sh kafka.admin.TopicCommand --delete --topic test --zookeeper 192.168.1.161:2181
- Kafka客户端操作
- 创建生产者 producer
bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
- 创建消费者 consumer
bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test --from-beginning
- 参数使用帮组信息查看：
生产者参数查看：bin/kafka-console-producer.sh
消费者参数查看：bin/kafka-console-consumer.sh
- kafka集群安装
- 安装zk集群
- 修改配置文件详情
broker.id： 唯一，填数字
host.name：唯一，填服务器
zookeeper.connect=192.168.40.134:2181,192.168.40.132:2181,192.168.40.133:2181
- 生产者
- 消费者
- pom依赖
<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka_2.10</artifactId>
<version>0.8.2.0</version>
</dependency>
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
