credentialScope 的终止字符串(tc3_request)是随便填的吗?,
AuthFailure.SignatureFailure这个错误如何着手去排错?Please check your signature is correct.\"},\"RequestId\":\"8313bcb1-0a3d-4027-a12b-75ba3a46300e\"}}"
目前推演的方案是:把事件 ID 插入带唯一索引的去重表,与账本变更放在同一个 MySQL 事务中,事务提交后再 ACK。这样可以覆盖提交成功但 ACK 前断连的窗口。尚未验证的边界是:去重记录若只保留 30 天,之后再重放较早的死信,原事件 ID 就可能被当作新事件。30 天只是拟定的存储清理策略,不是产品默认值。
1.在允许人工死信重放的前提下,主队列的消息 TTL 能否作为去重表清理依据?还需要约束哪些重投递或重放路径,才能定义可靠的最大重复窗口?
2.如果没有可强制执行的最大重放期限,是不是应把事件 ID 的唯一约束保