Kafka保证数据可靠性和一致性

Producer发送数据可靠性（Kafka高可用）

  Kafka 数据的可靠性可以分为Producter 往 Broker 发送消息、Topic 分区副本以及 Leader 选举几个角度。

Topic 分区副本

  为了保证数据的可靠性，Kafka 从 0.8.0 版本开始引入了分区副本，即每个分区可以人为的配置几个副本（比如创建主题的时候指定 replication-factor，也可以在 Broker 级别进行配置 default.replication.factor），一般会设置为3。
  Kafka 可以保证单个分区里的事件是有序的，分区可以在线（可用），也可以离线（不可用）。在众多的分区副本里面有一个副本是 Leader，其余的副本是 follower，所有的读写操作都是经过 Leader 进行的，同时 follower 会定期地去 leader 上复制数据。当 Leader 挂了的时候，其中一个 follower 会重新成为新的 Leader。通过分区副本，引入了数据冗余，同时也提供了 Kafka 的数据可靠性。
  Kafka 的分区多副本架构是 Kafka 可靠性保证的核心，把消息写入多个副本可以使 Kafka 在发生崩溃时仍能保证消息的持久性。

Kafka为什么不支持读写分离
  由于Kafka的使用场景决定，其读取数据时更关注数据的一致性。

1. 主从同步有一定的延迟，会出现主从节点数据不一致的情况
2. Kafka的每个topic下有多个partition，这些partition分担了读写的压力，就不再需要主写从读来分担主节点的压力

Kafka追随者副本不对外提供服务还有几点好处：

1. Read-your-wirtes“读自己所写”，指的是当生产者向Kafka成功写入消息后，消费者能立刻读到这条消息。因为Kafka的follower副本不会提供读服务，向leader副本发送的消息立刻就能在leader副本上读到。但是如果允许追随者副本提供读服务，由于副本之间是异步同步的，有可能追随者副本还没有拉取到最新的消息
2. Monotonic Reads单调读，对于一个消费者而言，在多次消费消息的时候，不会出现某条消息一会存在一会不存在的情况。比如某个partition下面有三个副本，分别是领导者副本Leader和两个追随者副本F1、F2。在追随者副本对外提供服务的情况下，就有可能出现F1拉取到新消息，而F2没有拉取到新消息的情况。如果这时候消费者先从F1消费消息，再从F2消费消息，就会看到这样的情况：第一次消费时拿到的消息在第二次消费的时候消失了，这就违背了单调读的要求

Producer 往 Broker 发送消息

  如果要往 Kafka 对应的主题发送消息，需要通过 Producer 完成。为了让用户设置数据可靠性， Kafka 在 Producer 里面提供了消息确认机制，即通过配置来决定消息发送到对应分区的几个副本才算消息发送成功。可以在定义 Producer 时通过 acks 参数指定。这个参数支持以下三种值：

• acks = 0：意味着如果生产者能够通过网络把消息发送出去，那么就认为消息已成功写入 Kafka 。在这种情况下还是有可能发生错误，比如发送的对象无能被序列化或者网卡发生故障，但如果是分区离线或整个集群长时间不可用，那就不会收到任何错误
• acks = 1：意味若 Leader 在收到消息并把它写入到分区数据文件（不一定同步到磁盘上）时会返回确认或错误响应。在这个模式下，如果发生正常的 Leader 选举，生产者会在选举时收到一个 LeaderNotAvailableException 异常，如果生产者能恰当地处理这个错误，它会重试发送悄息，最终消息会安全到达新的 Leader 那里。不过在这个模式下仍然有可能丢失数据，比如消息已经成功写入 Leader，但在消息被复制到 follower 副本之前 Leader发生崩溃
• acks = all：意味着 Leader 在返回确认或错误响应之前，会等待所有同步副本都