Lightning Network Daemon (LND) 日志优化：支付请求扫描的性能改进

背景与问题分析

在Lightning Network Daemon（LND）的支付处理模块中，当系统扫描大量未完成支付（inflight payments）时，会产生大量冗余的调试日志。这些日志不仅包含支付ID、金额和创建时间等基本信息，还会以十进制数组形式完整打印支付请求（payment_request），导致日志文件迅速膨胀。

这种设计存在三个主要问题：

1. 日志信息冗余：支付请求的十进制数组表示法对人类阅读不友好且占用大量空间
2. 缺乏进度指示：没有清晰的扫描进度百分比显示
3. 更新频率过高：每处理1000笔支付就记录一次，对于大型节点可能产生数百万条日志

技术实现细节

在LND的支付处理流程中，系统会定期扫描数据库中的未完成支付记录。原始实现采用固定批处理大小（1000条记录）的扫描方式，并在每次完成一个批次后记录详细日志。这种设计虽然有利于调试，但在生产环境中会产生过多噪音。

支付请求的十进制数组实际上是字节数组的默认Go语言打印格式，每个数字代表支付请求字符串中对应字符的ASCII码值。这种表示法虽然完整保留了原始数据，但对日志分析几乎没有实用价值。

优化方案

经过技术评估，建议采用以下改进措施：

1. 日志内容简化：

   • 移除支付请求的完整打印
   • 保留支付ID、金额和创建时间等关键元数据
   • 添加更有意义的进度指示

2. 日志频率控制：

   • 引入时间间隔阈值（如30秒）
   • 采用动态批处理大小调整机制
   • 对于无法获取总记录数的旧KV存储方案，优先使用时间间隔控制

3. 进度显示优化：

   • 实现基于时间或处理量的智能节流
   • 显示已处理记录数和最后处理的支付信息
   • 对于支持总数查询的新存储方案，可添加百分比进度

实现考量

在具体实现时需要考虑以下技术因素：

• 向后兼容性：确保改进不影响现有支付处理流程
• 性能影响：日志记录不应成为系统瓶颈
• 调试需求：在简化生产日志的同时，保留足够的调试信息
• 存储效率：减少日志体积以降低长期运行成本

预期效果

优化后的日志系统将：

• 显著减少日志文件大小
• 提高日志可读性和实用性
• 保持足够的调试能力
• 降低系统I/O压力

这种改进特别有利于运行大规模节点或长期不重启节点的用户，能够有效解决日志膨胀问题，同时保持系统的可观测性。