如何减少Cassandra处理失败消息表删除数据产生的tombstone问题？

• 替换全表扫描逻辑，按时间分区粒度查询
  你当前使用的SELECT * FROM <table_name>全表查询会遍历所有历史分区的SSTable，是触发tombstone超限的直接原因。基于你的表以timestamp为分区键的设计，每次调度时仅查询最近2天（和gc_grace_seconds配置对齐）的时间分区即可，通过SELECT * FROM <table_name> WHERE timestamp IN (?, ?, ...)的方式按分区查询，避免扫描已经完成清理的旧分区，从根源上减少读取到的tombstone数量。
• 更换压缩策略为TimeWindowCompactionStrategy（TWCS）
  你的场景属于典型的时间序列数据场景，TWCS会按固定时间窗口分组管理SSTable，当整个窗口内的SSTable所有数据都已过期（对应你的TTL7天配置）或被标记为删除时，Cassandra会直接删除整个SSTable文件，不需要执行合并操作来清理tombstone，大幅降低tombstone带来的查询开销。
• 优化删除逻辑，减少单行tombstone生成
  你可以将时间分区的粒度调整为1小时/3小时一个分区，等单个分区内的所有消息都处理完成后，直接执行DELETE FROM <table_name> WHERE timestamp = ?删除整个分区，分区删除仅会生成1个范围tombstone，远少于批量单行删除产生的大量独立tombstone。如果业务允许，也可以新增is_processed布尔列，处理成功后更新该列为true，查询时新增过滤条件WHERE is_processed = false配合ALLOW FILTERING（仅在分区内查询时使用，无额外性能开销），避免直接删除产生tombstone，同时可给is_processed列设置和gc_grace_seconds对齐的TTL，自动清理历史处理标记。
• 配置层面加快tombstone清理
  可以适当调低tombstone_threshold参数（默认0.2，即SSTable内tombstone占比达到20%就会触发合并清理），让含有大量tombstone的SSTable更快被合并。如果你的集群副本同步正常，无长期离线节点，也可以适当调低gc_grace_seconds到1天，加快tombstone的可清理时间，注意调整后要定期执行nodetool repair避免僵尸数据复生。
• 查询时新增分页和限制条件
  每次查询时加上LIMIT限制单次拉取的消息数量，同时记录上次查询的最大timestamp和message_name聚类键值，下一次查询用WHERE timestamp > ? AND message_name > ?的方式分页查询，避免单次查询扫描过多数据，降低遇到tombstone超限的概率。

内容的提问来源于stack exchange，提问作者CKP