存储空间不足问题可通过四步解决：一、配置RocksDB TTL与压缩策略；二、手动清理过期日志文件；三、限制SOFA MQ客户端缓存上限；四、启用日志分片与对象存储归档。
如果您在使用 SOFAStack 或 SOFAJRaft 相关组件时发现存储空间不足，日志中频繁出现磁盘写入失败、RocksDB 报错或 OutOfMemory、Disk space exhausted 等提示，则很可能是底层 LogStorage（默认基于 RocksDB）的持久化目录持续写入未清理所致。以下是解决此问题的步骤：
一、调整 RocksDB 日志压缩与 TTL 策略
RocksDB 默认不会自动删除过期日志，需显式配置压缩触发条件与数据生存周期，以限制磁盘占用增长速度。该方法直接作用于 SOFAJRaft 的 LogStorage 层，适用于长期运行且日志堆积严重的节点。
1、定位 SOFAJRaft 配置文件（如 raft-config.properties 或代码中 LogManager 初始化处）；
2、添加或修改 RocksDB 选项参数：options.setTtl(86400)（单位秒，示例设为 1 天）；
3、启用后台压缩：options.setEnableBackgroundCompaction(true)；
4、设置最大日志保留数量：logStorage.setMaxLogIndexRetention(100000)（根据业务吞吐量调整，避免无限追加）；
5、重启 SOFAJRaft 节点使配置生效。
二、手动清理过期 Raft 日志文件
当磁盘已满且服务不可用时，可临时进入 RocksDB 存储路径，安全删除已提交并复制完成的旧日志段文件。SOFAJRaft 的日志按 log_0000000001、log_0000000002 等命名，仅允许删除末尾索引远小于当前 committed index 的文件。
1、通过 JMX 或 SOFAJRaft Admin API 查询当前 lastCommittedIndex 值；
2、进入 RocksDB 数据目录（默认路径如 /data/sofa-jraft/log）；
3、列出所有 log_* 文件，按数字后缀升序排列；
4、删除后缀编号 ≤ lastCommittedIndex - 50000 的 log 文件（预留安全冗余）；
5、执行 ls -la 确认磁盘空间释放，再观察服务是否恢复写入能力。
三、限制客户端消息缓存上限（针对 SOFAMQ 场景）
若问题出现在 SOFAMQ 消费端（如 ons-client），内存不足常由客户端本地缓存消息过多引发，间接导致 JVM Full GC 频繁、磁盘 swap 占用飙升，表现为“存储空间不足”的假象。需主动约束单个 Group ID 的缓存容量。
1、确认应用使用的 ons-client 版本 ≥ 2.4.0（支持 MAX_CACHED_MESSAGE_SIZE_IN_MI_B 参数）；
2、在 ConsumerBean 初始化前，注入系统属性：-Dcom.alipay.sofa.sofamq.client.PropertyKeyConst.MAX_CACHED_MESSAGE_SIZE_IN_MI_B=256；
3、若使用 Spring XML 配置，添加
4、重启消费者应用，检查 /{user.home}/logs/sofamq.log 中是否不再出现 OutOfMemory 关键字。
四、启用日志分片与归档外迁
对高吞吐、长生命周期的 Raft 集群，建议将历史日志从 RocksDB 主目录剥离，转存至低成本对象存储（如 OSS/S3），仅保留在线热日志。SOFAJRaft 支持自定义 LogStorage 实现，可对接外部归档服务。
1、继承 com.alipay.sofa.jraft.storage.LogStorage 接口；
2、重写 getFirstLogIndex() 和 getLastLogIndex() 方法，区分本地热区与远程冷区索引范围；
3、在 getEntry(long index) 中判断索引归属，热区走 RocksDB，冷区走 HTTP/OSS 下载；
4、实现定时任务，将 index 的日志段上传并本地删除；
5、将新 LogStorage 实现类注册到 RaftGroupService 构建流程中。
