1. DynamoDB GSI唯一性约束的原理
1.1 全局二级索引的特性与局限
DynamoDB 的全局二级索引（GSI）本质上是一个独立视图，它拥有自己的分区键和可选的排序键，用于按不同的属性开展查询。但GSI 并不提供跨项的全局唯一性约束，也就是说同一值的组合可能在不同的主表项之间重复出现。理解这一点，是设计唯一性约束方案的前提。只有主表的主键才具备严格的全局唯一性，而 GSI 只是一个索引视图，对主键之外的字段提供二次索引能力。
在高并发场景下，直接依赖 GSI 的唯一性会带来冲突风险，因为写入到主表和 GSI 的过程需要原子一致性才能确保没有重复。没有原子性保障，可能出现主表写入成功但 GSI 中产生重复键的情况，反而破坏业务模型的唯一性约束。
1.2 原子性与一致性的关键点
要实现跨表或跨索引的原子性，必须借助 DynamoDB 的事务能力，也就是 TransactWriteItems 这类原子性写操作。通过一个原子事务，可以同时写入主表和用于唯一性约束的辅助表（或同一表的不同分区键组合），确保要么全部成功要么全部回滚，避免出现不一致的状态。
事务写可以附带条件表达式，如 attribute_not_exists，用于在写入前检查目标键是否已经存在，若存在则事务失败，从而实现“一对一”的唯一性校验。
为了降低对业务吞吐的耦合，可将唯一性约束放在独立的锁表中处理，通过事务将主表写入与锁表的唯一性写入绑定在同一个原子操作里，以确保全局唯一性的一致性。
2. 实现唯一性约束的实战方案
2.1 通过事务写实现原子性约束
最常见的做法是，使用一个独立的“唯一性锚点”表来记录需要保持唯一性的键值，例如唯一的引用号或外部唯一字段。通过一次事务写入，将主表的关键字段写入与该唯一性锚点表的写入绑定在一起，确保两个写入要么同时成功要么同时回滚，从而实现跨表的原子性唯一性。
关键点在于在事务内使用条件表达式，如 attribute_not_exists(unique_value) 来确保同一个唯一键值在项目写入前不存在。若已经存在，该分支会触发回滚，业务端可据此明确冲突来源并给出合理处理。
# Python示例：使用 boto3 的事务写来实现主表+唯一性锚点表的一致性写入
import boto3
from botocore.exceptions import ClientErrordynamodb = boto3.client('dynamodb')order_id = 'ORD-1001'
user_id = 'USER-123'
order_ref = 'REF-ABC-987' # 需要在系统中保持唯一try:response = dynamodb.transact_write_items(TransactItems=[{'Put': {'TableName': 'Orders','Item': {'order_id': {'S': order_id},'user_id': {'S': user_id},'order_ref': {'S': order_ref},'status': {'S': 'NEW'}},'ConditionExpression': 'attribute_not_exists(order_id)'}},{'Put': {'TableName': 'UniqueConstraints','Item': {'unique_value': {'S': order_ref},'type': {'S': 'ORDER_REF'}},'ConditionExpression': 'attribute_not_exists(unique_value)'}}])print("Transaction 成功执行")
except ClientError as e:if e.response['Error']['Code'] == 'ConditionalCheckFailedException':print("遇到唯一性冲突：该唯一值已存在")else:print("其他写入错误:", e)
对现有结构的影响需要评估，若主表字段与唯一性锚点之间需要额外映射，应确保 GSI 的设計与主表字段对齐，防止索引视图出现延迟或数据不一致的问题。
2.2 使用锁表（仅写锁）实现辅助唯一性
除了事务写，另一种实践是引入一个“锁表”或“约束表”，专门用于存放需要全局唯一的键。写入时，先尝试在锁表中扣留一个锁（插入一条唯一键的记录，使用 attribute_not_exists 作为条件），成功后再写入主表，最后再将锁的状态刷新为合法状态，整个过程通过简单的条件检查确保静态唯一性。
该方案的优点是实现简单、易于扩展到多种唯一性场景，但需要额外的写入成本和锁管理逻辑，适用于对原子性要求不是极端严格的场景。
# Python示例：先在锁表中投放锁，再写主表
import boto3
dynamodb = boto3.client('dynamodb')lock_key = 'ORDER_REF#REF-XYZ-123'
order = {'order_id': {'S': 'ORD-2002'}, 'user_id': {'S': 'USER-456'}, 'order_ref': {'S': 'REF-XYZ-123'}}try:# 第一步：尝试在 UniqueLocks 表中创建锁dynamodb.put_item(TableName='UniqueLocks',Item={'lock_key': {'S': lock_key}, 'created': {'S': 'true'}},ConditionExpression='attribute_not_exists(lock_key)')# 第二步：写入主表dynamodb.put_item(TableName='Orders',Item=order)print("锁与主表写入成功")
except Exception as e:print("锁写入失败或主表写入失败，需要回滚/处理", e)
3. 实战技巧与注意事项
3.1 幂等性设计与重试策略
在分布式写入中，幂等性是避免重复创建的关键，建议在主表或唯一性锚点表的条目中加入幂等性标识，例如请求唯一的 client_request_id。若写入失败后重试，应以幂等的方式再次执行，否则可能造成重复数据或冲突。
同时，使用幂等键可以帮助在多次重试中稳定地反映最终状态，降低重复写入导致的错误概率。务必要在代码层面捕获条件冲突异常，并将冲突场景映射到友好的业务结果。
3.2 错误处理与冲突分支
在事务写中遇到 ConditionalCheckFailedException 时，通常意味着目标唯一键已存在。这是一个可预期的冲突信号，应将其转化为业务层的“已存在的唯一值”提示，而非无谓地继续执行。合理的分支策略能够提升体验并降低重复写入的成本。
建议将冲突原因记录到审计日志或告警系统中，以帮助运维快速定位问题并调整唯一性方案，例如调整唯一键的域、增设新的唯一性字段或调整并发策略。
3.3 成本、性能与可扩展性考量
使用事务写虽然强大，但会带来额外的写入成本与抖动风险，尤其在高并发场景下。需要衡量写入单位（WCU/WPU）配额，确保事务写的峰值不会引发吞吐瓶颈。必要时可以通过分区策略和幂等设计来平滑峰值。
另外，确保唯一性锚点表与主表的写入分布均匀，避免热点键导致的热点分区问题。对唯一性键进行合适的哈希分布或使用多分区的锚点表可以提升并发能力。
3.4 GSI的更新与一致性注意
在实现唯一性约束时，GSI 的键值应与主表字段保持一致或有明确映射关系，以确保查询时能够正确反映唯一性状态。GSI 的最终一致性模式并非强制，但在需要严格一致性的场景中应依赖事务写来保障，避免因索引更新延迟导致的误判。
另外，在设计阶段就规划好如何回滚与补偿，若事务回滚，需要确保主表与锚点表的状态回到初始状态，避免残留的锁或伪造的唯一性记录影响后续写入。
