Kafka消息容量控制

Kafka作为一款磁盘级存储引擎的MQ，其存储容量能够满足大部分业务场景。
一般的业务也就GB级别的需求，2~3天的存储需求，500G已经算是比较大的场景了。
但是不可避免的，某个时刻某些业务的存储容量可能超过预先估计的容量，当占用较多时，可能造成磁盘空间不足，进而影响整体服务的质量。
因为必须了解有哪些预防措施或者紧急措施能够将超出的消息进行清理掉。
Kafka提供了消息保留时间、消息分区大小*分区数、精确位移的方式进行消息大小的合理控制。

1. log.retention.ms 消息时间
   Kafka通常根据时间决定数据可以保留多久。默认使用log.retention.hours参数配置时间，默认值是168小时，也就是一周。除此之外，还有其他两个参数，log.retention.minutes和log.retention.ms，这三个参数作用是一样的，都是决定消息多久以会被删除，不过还是推荐使用log.retention.ms，如果指定了不止一个参数，Kafka会优先使用最小值的那个参数。

2. log.retention.bytes 消息大小
   通过保留的消息字节数来判断小是否过期，它的值通过参数log.retention.bytes来指定，作用在每一个分区上，也就是说如果一个包含8个分区的主题，并且log.retention.bytes被设置为1GB，那么这个主题最多可以保留8GB的数据，所以，当主题的分区个数增加时，整个主题可以保留的数据也随之增加。
   如果同时指定了两个参数没只要任意一个参数得到满足，消息就会被删除。例如，假设log.retention.ms为86400000（也就是一天），log.retention.bytes的值设置为1GB，如果消息字节总数在不到一天的时间就超过了1GB，那么堆出来的部分就会被删除，相反，如果消息字节总数小与1GB，那么一天之后这些消息也会被删除，尽管分区的数据总量小于1GB

3. 还有一种少为人知的精确删除的方式，可以根据offset进行删除
   ./kafka-delete-records.sh --bootstrap-server 10.100.141.139:9092 --offset-json-file testResize.json
   执行结果
   Executing records delete operation
   Records delete operation completed:
   partition: mario-th-th-xxx-0 low_watermark: 4434214
   其中，testResize.json的内容为：
   {"partitions":[{"topic": "mario-th-xxx", "partition": 0,"offset": 3000}],"version":1}

下面给大家提一个问题，配了消息保留策略，这三种分别是多久生效呢？我们后续揭晓答案