回答几个网友提出的问题，不清楚的能够看上一篇内容。
1、 kafka的删除策略应该怎么配置？为了提升性能。我是不是应该1小时删除一次消费过的数据。
全然能够依据磁盘大小配置。仅仅要磁盘足够用，全然不是必需删除的那么着急。Kafka的吞吐量不会由于数据量的增长而减少。由于读写数据时，kafka全然是顺序的，仅仅记录offset。时间复杂度是O（1）。我以前測试过上T的数据，全然不受影响。
反倒是数据删除的太快，easy造成数据丢失。
2、 消息发送一直失败。到达了指定重试次数怎么处理？
client能够设置重试次数和重试间隔时间，由于一般kafka是以集群形式存在的。一直重试都不能成功，并不多见，常见的情况是应用和kafka集群断网。实际上在重试的过程中，假设应用挂掉。这个消息就丢失了，假设要避免此种情况发生，须要持久化消息，当然能够选择本地持久化和远程持久化，选择本地持久化也不是很安全。由于如今的应用server很有可能是虚拟机或者容器。远程持久化相对安全。
可是远程意味着须要网络。假设恰巧远程持久化也失败，该怎么办？解决此类问题。最后的救命稻草就是日志。
这类问题并不仅仅是在mq中，入库也是一样。分布式场景中很常见。可是由于发生的概率不大，通常都被开发者忽略。这也就是做结算的永远都不能把账算平的原因所在。通常要权衡处理这种小概率事件是不是值得。
重要的系统通常有定时检查的功能。作为小概率事件的事后补偿机制。
3、 假设总副本数为f，最多同意丢失多少副本？
最多同意丢失f-1个副本，也就是仅仅要有一个副本就没问题。当然这和broker的配置有关。
从服务端角度，怎样尽快将更新后的数据分布到整个系统，减少达到终于一致性的时间窗体，是提高系统的可用度和用户体验很重要的方面。对于分布式数据系统：
a) N — 数据复制的份数
b) W — 更新数据是须要保证写完毕的节点数
c) R — 读取数据的时候须要读取的节点数
不论什么一个分布式系统，在服务端。要想保持强一致性。必须符合W+R>N。也就是说，如果一共同拥有3个节点。写数据的时候，三个节点都写入成功才返回，仅仅要有一个节点存活，就能保证数据是最新的。
4、 Kafka是有顺序的吗？
在同一个partition全然是有顺序的。生产者能够设置分区策略，能够自己定义分区策略，这样就能够依据业务分区。
举个样例，假设是跟用户相关的。全然能够依据用户id进行分区，同样用户的全部操作都进入同一个分区。也就达到了顺序性。
当然，有顺序也是有害处的，有顺序就意味着堵塞。假设消费一条消息一直失败。消费过程会受到堵塞，灵活的处理方式是重试到一定次数，把这条消息持久化到远端，跳过这条消息继续消费。
也就意味着失去了顺序。