sunxiaojian commented on PR #6219:
URL: https://github.com/apache/rocketmq/pull/6219#issuecomment-1455378609
> >
2.创建topic时增加delete.deletion.ms属性，设置空消息的清除时间，不在合并中直接清除的直接原因，主要是担心消息发送和压缩过程太近，造成客户端还未消费到就被清除，实际应用中可能造成客户端无法更新本地数据
>
> 个人感觉这个属性`delete.retention.ms`名字可能会导致混淆，被认为是正常消息过期删除的时间；
另外对于一个类kv系统，我觉得delete之后就应该get不到，我们应该缩短这个耗时，而不是增加这个耗时，compaction
topic的正确使用应该是消费到消息之后，在本地先compaction一次，也就是说null消息在客户端本地就应该把之前相同key的消息删除(覆盖)，从而达到一个**实时**效果，如果需要消费到中间数据，顺序消息是不是能更好的满足需求。
>
> > 3.增量compaction时，没有新增文件也会继续进行compact，主要是为了清除body为 null的消息
>
>
个人感觉这个过程，代价有点高，当compaction类型的topic/partition比较多时，这块占用资源会很高，当然如果基于上面说的，是否不需要这个过程
虽说是个kv系统，但不应该完全按照一个kv系统看待，实际的的kv系统是个共享存储，直接远程获取的，所以正常的Kv系统是数据更新即可见；而compact
topic 更多的场景是初始化加载全量，然后增量订阅变更（最大区别），客户端一般也不会直接去broker获取key相关的信息，
这个特性造成了，存储->订阅更新完成 有个过程， 直接删除null消息就会出现客户端订阅不到变更的问题，也就无法感知删除了；
其次，【在本地先compaction一次】，只适用于单client的情况下，应该对于分布式环境不适用【若在应用中再附以共享存储，那就没必要使用compaction
topic了】
对于topic/partition比较多时，可能占用资源较高，这个还需要测试来分析，但我个人任务，compaction频率不需要太频繁，目前的默认值还是有点频繁的；
也可以将 开启删除 作为一个可配置的功能加入，若不开启，则保持原逻辑不变
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
