signal-cli-native高CPU占用与长接收延迟问题分析与解决

问题现象

在使用signal-cli-native（作为signal-cli-rest-api的包装）的三台服务器中，其中一台出现了异常表现：

1. 接收消息时CPU占用率达到100%并持续30秒以上
2. 响应延迟逐渐恶化至50+秒
3. 内存使用量从100MB激增至1600MB后立即回落
4. 其他两台服务器表现正常

技术分析

通过日志分析发现，系统在处理消息时频繁出现以下错误：

[libsignal]: rust/protocol/src/session_cipher.rs:220: 
Message from <ID> failed to decrypt; 
sender ratchet public key <ID> message counter 499
No current session

这表明系统正在反复尝试解密失败的消息。深入代码后发现，signal-cli-native默认会重试处理失败的消息（needsToRetryFailedMessages=true），特别是当接收方的身份密钥（安全号码）发生变化时。

解决方案

临时解决方案是将needsToRetryFailedMessages设置为false，这使接收时间恢复到10秒以内。但需要注意：

1. 重试机制的作用：该机制主要用于处理身份密钥变更后接收的消息，确保不会丢失重要通信
2. 长期影响：禁用重试可能导致某些特殊情况下的消息丢失
3. 替代方案：不建议简单地缩短重试时间窗口（如从30天改为24小时），这可能导致合法消息被错误丢弃

最佳实践建议

1. 对于高负载环境，建议监控消息解密失败率
2. 定期检查身份密钥变更情况
3. 考虑实现自定义的重试策略，平衡系统负载和消息可靠性
4. 保持signal-cli-native版本更新，以获取最新的性能优化

技术背景

Signal协议使用"安全号码"（身份密钥）来验证通信双方身份。当这些密钥变更时，系统需要特殊处理以确保通信连续性。signal-cli-native的重试机制正是为此设计，但不当使用可能导致严重的性能问题。

对于企业级部署，建议结合具体业务需求评估消息可靠性与系统性能的平衡点。