分布式 ID 设计需平衡全局唯一性、性能、 业务连续性。核心方案包括：自增主键（单库场景）、uuidv7（跨系统时间有序）、Snowflake（64位结构，需解决workerId冲突和时钟回拨）、号段模式（数据库批量分配+本地缓存，适合容器化系统）。关键决策因素：服务规模（单节点、多实例）决定是否使用自增或号段；敏感业务（日志ID）可选用uuidv7或Snowflake；高并发微服务优先考虑号段模式，需双缓冲机制与数据库 transactions 协调。核心注意事项：①时钟回拨必须做逻辑时间校验；②不强制连续防空洞；③不编码敏感字段防泄露；④64位ID前端统一转为字符串存储。推荐落地方案按场景排序：单库优先自增主键；常规微服务选成熟Snowflake实现；容器弹性扩缩容场景用号段模式；跨系统资源标识可考虑uuidv7。

在分布式系统中，重复提交和重复下单的因果关系及防御策略要点如下：重复提交源于用户行为、网络重试等原因，导致重复下单。幂等性需分层防御——前端防抖减少冗余请求；Token机制（如Redis存储唯一Token）确保请求一致性；业务层用分布式锁（分片设计）或唯一标识（如用户ID+商品ID）管控并发；数据库唯一索引作为兜底防线，冲突时返回已有订单而非失败。常见陷阱包括：单方案失效（某电商因索引冲突导致锁竞争瘫痪）、业务状态未校验引发扣款、锁过期设置不合理造成并发问题，需采用2-3倍耗时设置或自动续期机制。分层防御体系（防重→Token→锁→唯一索引/消息去重）可降低重复率至0.002%，年省损失千万级。核心结论：幂等性需多层级组合方案，避免依赖单一机制，特别是高并发场景需同时使用Token和业务锁。数据库唯一索引可作为最终兜底，但更新操作需结合状态机校验当前状态。

在互联网行业中，我们经常会听到这样的话： “我们的系统做到三个9” “金融系统一般要求四个9” “运营商追求五个9” 那么，“几个9”究竟是什么意思？ 它和服务器性能有什么关系？又为什么互联网公司如此重视它？ 本文尝试用比较中性的方式，聊聊“高可用”背后的含义。 什么是高可用（High Availa