Kafka

• 第一讲,kafka的基本抽象层次概念,也就是Why kafka do like this?,理解了一部分这么设计的优点
• 第二讲,kafka高可用:副本管理
• 第三讲,elk中的kafka:流式应用

broker与zookeeper

• broker: 运行中的kafka实例,一般来说一台服务器只开启一个kafka(也可以多个,就像一台服务器运行俩个mysql一样 监听不同端口即可)
• zookeeper: 集群信息管理者, broker上线之后需要向zk汇报自己的信息、维持心跳, 这样子其他broker才能发起连接,同步数据等

broker在启动的时候会汇报自己的地址信息，如果是通过容器启动的broker，可能会汇报成容器名，导致应用程序在使用的时候连接失败: djlakjklfjkjqr:9092 DNS解析错误，解决方法:手动设定汇报的IP地址

broker,Topic,分区,日志段

• broker：物理资源，一般一个broker指底层的一台物理服务器。
• topic：逻辑概念，用于联系Producer 和 Consumer的message生产和消费。Producer 生产的消息放入一个topic中，由Consumer通过对同一个topic的订阅进行消费。
• 分区：逻辑分区存储，用于将topic在不同的物理资源上进行存储。每个topic可以有多个分区，每个分区可以有多个副本（复制因子）。
• 日志段：物理文件存储，用于将分区中的消息按照时间顺序写入到磁盘上。每个分区由多个日志段组成，每个日志段是一个文件。Kafka Broker 可以通过参数log.segment.bytes设置日志段的大小，最大就是 1GB 。一个日志段文件满了，就自动开一个新的日志段文件来写入

kafka会将日志段的内容生成索引.index，用于加速定位数据在物理文件的存储位置(新文章展开讲kafka-索引)

为什么Topic分区存储?

• 分区可以提高Topic的并发能力，每个分区都是一个独立的日志文件，可以被不同的生产者和消费者并行读写。
• 分区可以实现负载均衡和水平扩展，通过合理的分区规则，可以将消息均匀地分布到不同的分区中（理论无限量扩展容量），从而利用多个Broker节点的存储和网络资源。

因为日志文件可以存在多个实例(机器)上，也就是可以读写多个硬盘，拥有多条带宽，对于消费进程来说，服务端的吞吐量就提高了

为什么分区还要拆分成多个日志段?

• 虽然kafka的设计是顺序读写，但是操作系统对于磁盘的管理是:将不连续的磁盘地址作为链表分配给一个文件, 所以日志文件如果过大,会把磁盘寻道的次数加多
• Kafka的日志段具有过期时间和可配置的大小限制，一旦一个日志段达到了过期时间或大小限制，就会被删除，所以日志段拆分开，对于数据的管理粒度会更合适
• 将一个分区划分为多个日志段可以增加消息的冗余度，使得即使一个Broker出现故障，数据也可以从其他Broker中恢复。并且恢复过程更优。假设:节点重启之后,需要同步最新的日志段,那么同步的文件过大就需要很长的时间

推拉模式的选择

• 生产者 --推–> Kafka
• 消费者 <–拉-- Kafka

生产者肯定是只能用推模式的，消费者为什么要用拉呢?: 更好控制消费机器的速率, 比如我有3台消费机器,性能不一样 如果都用推的话 Kafka控制不好每次推送的数量 推太多了导致消费机器挂了咋办

维护消费状态跟踪的方法

对于传统的消息中间件来说,任务是否被消费的状态管理是很重要的

不然的话会产生问题

• 任务没被消费，订单数据不完整
• 任务被重复消费，造成损失

Kafka 的 Topic 被分成了若干分区，并且设计每个分区在同一时间只被一个 consumer 消费。

这意味着每个分区被消费的消息在日志中的位置仅仅是一个简单的整数：offset。

这样就很容易标记每个分区消费状态，仅仅需要一个整数而已。消费状态的跟踪就很简单了。（记录一下当前被消费到哪里了）

这带来了另外一个好处：consumer 可以把 offset 调成一个较老的值，去重新消费老的消息。这对传统的消息系统来说看起来有些不可思议，但确实是非常有用的，谁规定了一条消息只能被消费一次呢？