kafka学习记录

*1.SOA架构：*

系统间的直接调用（RPC方案）

*2.消息队列，MQ模型*
sender ———> 消息队列 ——–> receiver
1.无侵入，接耦合
2.提高系统响应时间，异步执行

*3.消息队列类型：*
1.点对点 ①queue中不存储已经消费的消息，不持久化 ②有多个消费者，点对点只支持一个消费者
2.发布订阅 将消息发布到topic中，所有订阅该topic的消费者都能消费消息

*4.消息队列MQ对比*

RabbitMQ：支持的协议多，非常重量级消息队列，对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。

ZeroMQ：号称最快的消息队列系统，尤其针对大吞吐量的需求场景，擅长的高级/复杂的队列，但是技术也复杂，并且只提供非持久性的队列。

ActiveMQ：Apache下的一个子项，类似ZeroMQ，能够以代理人和点对点的技术实现队列 。

Redis：是一个key-Value的NOSql数据库，但也支持MQ功能，数据量较小，性能优于RabbitMQ，数据超过10K就慢的无法忍受

*5.kafka简介：*
1.分布式 2.可划分（patition）3.多订阅者 4.持久化 5.处理流式数据（实时数据）

*6.kafka是跟zk配套使用的*

*7.日志持久化*
1. 日志是存于topic中的，同时kafka会对topic分区，切分成若干个partition，类似于自己在数据库中创建一张表
2. 一个topic对应一个consumer group
*8.kafka逻辑架构图*

*9.kafka校验机制*
Kafka没有采用ack的机制，消息丢了就丢了，采用的是CRC校验机制

*10.kafka的消息状态记录*
消息状态记录是由zk来记录的。

*11.kafka的borker无状态机制*
1. Broker没有副本机制，一旦broker宕机，该broker的消息将都不可用。

1. Broker不保存订阅者的状态，由订阅者自己保存。

2. 无状态导致消息的删除成为难题（可能删除的消息正在被订阅），kafka采用基于时间的SLA(服务水平保证)，消息保存一定时间（通常为7天）后会被删除。

3. 消息订阅者可以rewind back到任意位置重新进行消费，当订阅者故障时，可以选择最小的offset(id)进行重新读取消费消息。

*12.partition的三个属性*
1. offset 对应类型 long
2. messagesize 对应类型 int32
3. data 是message的具体内容
**其中2和3是作为CRC机制校验规则的参数使用