狂砍Kafka

发布订阅模式和观察者模式有什么区别

观察者模式中，观察者和主题都知道对方的存在；而在发布与订阅模式中，生产者与消费者不知道对方的存在，它们之间通过频道进行通信。
观察者模式是同步的，当事件触发时，主题会调用观察者的方法，然后等待方法返回；而发布与订阅模式是异步的，生产者向频道发送一个消息之后，就不需要关心消费者何时去订阅这个消息，可以立即返回。

kafka的基本组件

为什么 Kafka 不像 MySQL 那样允许追随者副本对外提供读服务？
答：因为mysql一般部署在不同的机器上一台机器读写会遇到瓶颈，Kafka中的领导者副本一般均匀分布在不同的broker中，已经起到了负载的作用。即：同一个topic的已经通过分区的形式负载到不同的broker上了，读写的时候针对的领导者副本，但是量相比mysql一个还实例少太多。

Kafka的线上部署方案

操作系统 磁盘 磁盘容量 带宽
一般选择Linux操作系统，Kafka底层使用的是Java的selector，selector在Linux上的实现机制是epoll，而windows上的实现机制是select；同时linux操作系统可以使用零拷贝机制优化Kafka数据传输。

Kafka关键参数配置

Broker端参数
log.dirs：指定了Broker需要使用的若干个文件路径
zookeeper.connect

Kafka生产者消息分区机制原理

Kafka为什么分区
提供负载均衡能力，不同的分区能够被放置在不同的机器上，读写操作都是针对分区这个粒度进行的，这样每个节点的机器都能独立地执行各自分区的读写请求处理
Kafka都有哪些分区策略
轮询策略
随机策略
按消息键保序策略
Kafka 允许为每条消息定义消息键，简称为 Key。我们可以将具有相同Key 的消息发送到相同的分区中。
基于地理位置的分区策略

Kafka压缩算法

Producer 端压缩、Broker 端保持、Consumer 端解压缩。
但是如果Producer端和Broker端使用不同的压缩算法或者消息格式，那么在Broker端依然需要进行解压缩。
何时启用压缩： CPU资源充足，带宽资源有限
压缩算法参数：压缩比；压缩/解压缩吞吐量

无消息丢失配置

Kafka只对已提交的消息做有限度的持久化保证
生产者程序丢失数据
解决方式：使用带有回调通知的API，也就是说不要使用 producer.send(msg)，而要使用 producer.send(msg, callback).
消费者程序丢失数据
解决此问题，维持先消费消息（阅读），再更新位移（书签）的顺序即可，但是这样有可能造成重复消费。对于多线程异步处理消费消息，Consumer程序不要开启自动提交位移，而是要应用程序手动提交位移。

幂等生产者和事物生产者

至少一次
最多一次
精确一次
幂等性 （保证单分区单会话的幂等性）
某些操作可以执行多次，其结果并不会改变，比如乘法中的乘1操作就是幂等的
enable.idempotence 被设置成 true 后，Producer 自动升级成幂等性 Producer，其他所有的代码逻辑都不需要改变。在 Broker 端多保存一些字段。当 Producer 发送了具有相同字段值的消息后，Broker 能够自动知晓这些消息已经重复了，于是可以在后台默默地把它们“丢弃”掉。
Kafka事务（保证多分区多会话的幂等性）
生产者的事务能够保证一条消息仅仅会保存在kafka的某一个分区上，不会出现在多个分区上，另外，能够保证多条消息原子性的发送到多个分区。也就是说它只保证了从producer端到broker端消息不丢失不重复。但对于consumer端，由于偏移量的提交和消息处理的顺序有前有后，依然可能导致重复消费或者消息丢失消费，如果要实现消费者消费的精确一次，还需要通过额外机制在消费端实现偏移量提交和消息消费的事务处理。

消息队列的可靠性保证

发送端的可靠性发送端完成操作后一定能将消息成功发送到消息队列中。
在本地数据库建一张消息表，将消息数据与业务数据保存在同一数据库实例里，这样就可以利用本地数据库的事务机制。事务提交成功后，将消息表中的消息转移到消息队列中，若转移消息成功则删除消息表中的数据，否则继续重传。
接收端的可靠性接收端能够从消息队列成功消费一次消息。
保证接收端处理消息的业务逻辑具有幂等性：只要具有幂等性，那么消费多少次消息，最后处理的结果都是一样的。
保证消息具有唯一编号，并使用一张日志表来记录已经消费的消息编号。如果再次收到日志中编号的消息，则直接丢弃不作处理。

消息队列顺序性保证

消息有序指的是可以按照消息的发送顺序来消费。
解决办法：保证生产者 - MQServer - 消费者是一对一对一的关系
缺陷：并行度就会成为消息系统的瓶颈（吞吐量不够）
更多的异常处理，比如：只要消费端出现问题，就会导致整个处理流程阻塞，我们不得不花费更多的精力来解决阻塞的问题。