架构设计

问题不是“限流”，而是“谁被限” 多租户系统里，单一全局令牌桶会让大租户挤压小租户，最终演变成“有流量的客户拿走全部容量”。 分层限流模型 全局桶：保护系统总容量。 租户桶：保证最小公平份额。 接口桶：关键路径优先级保护。 动态配额 基础配额按套餐或 SLA 分层。 空闲配额可借用，但需可回收。 通过窗口统计识别恶意突刺流量。 小结 限流策略是否成功，不看是否拦截，而看是否在拥塞时仍然维持“可预期的租户体验”。

风险根源 基于时间戳的 ID 方案在时钟回拨时可能生成重复 ID，影响去重、排序和分库分表路由。 治理策略 本地单调时钟优先，墙钟只用于校准。 发现回拨后进入保护模式：阻塞、切序列段或切机房位。 强制 NTP 漂移告警与节点摘除。 业务层补偿 关键写入加唯一约束兜底。 为 ID 冲突暴露独立错误码，支持快速定位。 小结 ID 生成器不是纯算法组件，它是时间系统的一部分。时钟治理做不好，任何高并发优化都会失效。

先回答三个问题 新写对象是否读后可见？ 覆盖写是否存在短暂旧读？ 跨地域复制的延迟窗口是多少？ 业务协议建议 写入时带版本号（ETag/VersionId）。 读取时声明期望版本，不满足则重试或降级。 删除采用 tombstone 而非立即硬删。 典型流程 PUT(v2) -> 返回version=v2 -> GET(if-match=v2) -> 成功 多地域策略 强一致需求走单主写入。 多主写入必须引入冲突解决策略（LWW 或 CRDT）。 对外暴露“可见性延迟”SLO，避免误判故障。 小结 对象存储的一致性不是文档注释，而是业务协议的一部分。把版本语义显式化，读写行为才可预测。