当功能标志重试可能触及发布切换端点时，请使用持久的幂等性回执；否则，应采用只读的标志评估方式，以避免产生重复写入。简而言之：后端必须将一个由调用方生成的密钥与一个操作绑定，并在状态变更的同时提交回执；重试时应恢复该已记录的结果，而不是再次执行写入操作。
标志本身并不构成事务。
在写入边界记录不变量
我的架构决策是在拥有可变状态的后端内部强制实施幂等性。调用方在首次尝试之前创建一个操作密钥，在每次重试时发送相同的密钥和操作，并且绝不在重试循环中生成新的密钥。后端将该密钥与请求变更的稳定摘要绑定。如果该密钥和摘要已被提交，则返回存储的结果。如果该密钥存在但关联的摘要不同，则将此集成错误作为冲突拒绝。状态变更和回执必须属于同一个事务，因为两次单独的提交会产生一个时间间隔，在此期间状态显示“已完成”，而回执却没有任何记录。
我将该不变量表述如下：在一个文档化的范围内，一个幂等性密钥标识一个逻辑操作；一个已提交的操作对应一个持久的结果。可辩护的主张是该范围内的“有效一次”变更，而非“精确一次”交付。 客户端、消息队列、代理和部署控制器都可能重复尝试，因此交付次数并不是一个有用的正确性边界。
我测试了三个故障边界。响应可能在提交后消失，两个工作进程可能在同一密钥上发生竞争，以及标志决策可能在多次尝试之间发生变化。第一种情况需要重放存储的结果。第二种情况需要唯一性约束，而非“先检查后插入”的序列。第三种情况需要将评估后的决策与操作一起持久化；在恢复期间重新评估标志可能会使一个逻辑请求变成两个不同的历史含义。
数据保留是一个实际的权衡问题。保留回执的时间应长于最长的可信重试窗口，但不要假设无限期保留是免费的：密钥、负载摘要和序列化响应会消耗存储空间，并可能带来数据治理义务。具体情况因系统而异，因此我将范围和过期行为作为端点契约的一部分进行文档化，而不是让它们成为数据库中的非正式惯例。
功能标志重试应如何避免重复写入和后端集成错误？
将策略评估与状态变更分离。针对发布对象一次性评估功能标志，将该决策冻结到请求的操作中，创建密钥，然后调用切换端点。传输超时会使结果未知；这并不能证明失败。下一次尝试必须携带相同的操作数据，以便如果第一次尝试已提交，后端可以根据其回执进行响应。
这正是可观测性必须描述逻辑工作而不仅仅是流量的地方。我将 request_id（请求ID）、idempotency_key（幂等性密钥）、rollout_id（发布ID）、decision（决策）、attempt（尝试次数）和 outcome（结果）记录为结构化字段。我分别统计尝试次数、唯一已提交密钥数、重放次数、负载冲突数和策略拒绝数。原始请求量可能会因为恢复机制正常工作而上升，而已提交的操作数量保持平稳。合并这两个计数的仪表盘会掩盖我需要看到的确切状况。
我曾因忽视这种区别而遭遇过一次成本意外：一份分析账单金额达到了我预估的3.2倍，因为重试的工作进程在每次尝试时都发出了一个新事件，而分析存储区保留了这些重复的行，尽管事务
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
