之前在《 》中我们分析了服务器端的可靠性和一致性的配置。即使在服务器端做了很强的一致性配置，也不能保证不丢消息。假如在Broker那边的配置是：
<code>replication.factor
=3
// 有1
个主节点，2
个从节点min.insync.replicas
=2
// 要保证2
个同步的节点unclean.leader.election.enable
=false
// 不允许out-of-sync的节点当选lead/<code>
我们来看看生产者producer的哪些配置也会影响可靠性。
确认成功 acks
"acks"，需要多少从节点确认收到时，才认为成功送达消息。有三个选项：
- acks=0，那么客户端只要把消息发出去，不等broker的响应就认为发送成功了。如果是客户端本地的网卡有问题，或者序列化失败，那么客户端会有异常抛出。否则就认为成功。万一在客户端这边刚发到broker那边，broker就挂了。客户端是不知道的。这样客户端就认为丢消息了。
- acks=1，那么broker的主分区节点只要收到消息就会返回给客户端成功消息。如果刚返回，还没有来得及复制到从节点去，主节点就挂了，那么客户端以为成功了，其实这个消息也丢了。
- acks=all，那么客户端如果得到broker的成功消息，就代表broker已经提交（commit）了消息，除了主节点，另外的一个或者两个从节点都复制好了。这时候就算lead挂了，也还有一个从节点包含这个消息。这是最安全的配置，同时也是最慢的配置。
重发次数 retries
任何外部的IO都需要考虑retry，因为任何外部服务都有可能临时不可用。broker有可能在换主，有可能临时连不上，这个时候客户端最安全的是无限的从发。直到broker恢复正常。默认的值是2147483647。
这个是producer客户端内部的实现。但是，只有broker返回的是可重试（retriable）的错误时（比如换主是返回LEADER_NOT_AVAILABLE），producer才会自动重发。如果是不可重试（nonretriable）的错误（比如INVALID_CONFIG），那么客户端再怎么重试也没用。
需要客户端处理的错误
- 发送之前就出错，比如序列化失败，客户端需要自己处理。
- 如果可以重试的错误kafka producer会处理。但是对于不可重试（nonretriable）的错误，就需要客户端来处理。
- 如果客户端设置的retries比较小（比如10），那么客户端需要自己处理重试10次以后还不成功的情况。
下次我们继续看在消费者那边有哪些配置会影响一致性的保证。
分享到:
