一、为什么GSI无法原生保证唯一性？

与主键不同，DynamoDB的全局二级索引(GSI)在设计上不强制要求属性唯一性。这是NoSQL数据库的典型特性——通过牺牲约束能力来换取水平扩展性。当我们在业务中需要确保Email、手机号等字段唯一时，就需要通过组合方案实现。

笔者曾参与一个用户管理系统迁移项目，原MySQL中依靠唯一索引实现的手机号约束，在迁移到DynamoDB时遇到了挑战。经过多次PoC测试，最终形成了以下解决方案。

二、5种实现方案深度对比

方案1：条件写入+事务处理（推荐）

python

示例代码：原子性检查+写入

def createuserwithuniqueemail(userid, email):
try:
dynamodb.transactwriteitems(
TransactItems=[
{
‘Put’: {
‘TableName’: ‘Users’,
‘Item’: {‘PK’: userid, ’email’: email},
‘ConditionExpression’: ‘attributenotexists(PK)’
}
},
{
‘Put’: {
‘TableName’: ‘EmailGSI’,
‘Item’: {’email’: email, ‘userid’: userid},
‘ConditionExpression’: ‘attributenotexists(email)’
}
}
]
)
except dynamodb.exceptions.TransactionCanceledException:
raise DuplicateEmailError

优势：
– 真正的原子性保证
– 适用于高频写场景
代价：
– 消耗2倍WCU
– 需要维护影子表

方案2：GSI+条件表达式

sql
// 查询时附加条件
SELECT * FROM Users WHERE email = 'test@example.com'
AND attribute_not_exists(deleted_at)

适用场景：
– 低频修改场景
– 可接受最终一致性

其他方案对比表

| 方案 | 一致性 | 并发支持 | 实现复杂度 |
|———————|——–|———-|————|
| 乐观锁控制 | 强 | 中 | ★★★★ |
| 分布式锁 | 强 | 低 | ★★★★★ |
| 应用层校验 | 弱 | 高 | ★★ |

三、高并发场景下的实践建议

1. 冷热数据分离：将高频修改的字段（如用户状态）与需要唯一性的字段（如身份证号）拆分到不同表

2. 写入限流设计：python

   使用令牌桶控制并发

   ratelimiter = TokenBucket(capacity=100, refillrate=10)

   def writewithretry(item):
   while not rate_limiter.consume():
   time.sleep(random.uniform(0, 0.1))
   # 执行写入操作

3. 监控指标重点：

   • ConditionCheckFailedRequests
   • TransactionConflictExceptions
   • GSI ThrottlingEvents

四、真实案例：电商SKU唯一性保障

某跨境电商平台在商品中心迁移时，采用「事务写入+异步校验」的混合方案：
1. 先通过事务保证基本约束
2. 通过Kinesis流触发二次校验
3. 定期执行全量扫描任务

这种设计使系统在高峰期（黑五期间QPS>3000）仍能保持数据一致性，错误率低于0.001%。

五、未来演进方向

随着DynamoDB新功能发布，以下特性可能改变现有设计：
– 2023年新增的ETag支持（类似乐观锁）
– 不断增强的事务能力
– 与Lambda的深度事件集成

架构师思考：在NoSQL中实现关系型约束本质上是一种权衡。建议业务初期采用简单方案，随着规模扩大逐步引入复杂保障机制，避免过度设计。