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