3.9 KiB
3.9 KiB
08 数据一致性边界：数据库保证什么？应用层还需要保证什么？
本节的目的：把“责任边界”讲清楚，避免团队误以为数据库已经覆盖了所有一致性问题。
1. 数据库层已经显式保证的内容（来自脚本）
1.1 约束（Constraints）保证
- 枚举合法性：大量使用
CHECK (status IN (...))- 例：
ml_products.status、ml_orders.order_status/payment_status/shipping_status
- 例：
- 唯一性：
order_no UNIQUEcoupon_code UNIQUEml_shopping_cart UNIQUE(user_id, product_id, sku_id)ml_shops.merchant_id UNIQUE（一商家一店）ml_delivery_tasks.order_id UNIQUE（一订单一配送任务）
1.2 触发器保证
updated_at自动维护：避免应用层漏写- 默认地址唯一：
ensure_single_default_address() - SKU → SPU 库存汇总：
update_product_stock() - 订单状态副作用（complete 脚本）：
handle_order_status_change()自动写时间戳，并累计销量
1.3 RLS（行级安全）保证
- 用户私有数据仅可访问自己的行（档案/地址/购物车/收藏/浏览/券等）
- 订单允许买家/卖家访问
- 商品公开查询仅限上架
2. 数据库层“目前未完全覆盖”的一致性问题（需要显式补齐）
以下并不意味着当前设计不好，而是典型电商系统里必须明确“谁来保证”。
2.1 下单扣库存、防超卖
脚本可见“库存汇总”，但没有看到：
- 下单时对
ml_product_skus.stock的原子扣减 - 订单取消/超时未支付的库存回补
- 库存冻结（预占）机制
风险：并发下单可能超卖。
建议补齐方案（按复杂度递增）：
- 方案 A（最小补齐）：提供一个原子扣减函数
update ml_product_skus set stock = stock - :qty where id=:sku_id and stock >= :qty;- 受影响行数为 1 表示扣减成功，否则失败
- 方案 B（常见电商）：引入“冻结库存”
- SKU 增加
reserved_stock或独立冻结表 - 下单冻结、支付确认扣减、取消释放
- SKU 增加
- 方案 C（审计与对账）：引入库存流水
- 每次扣减/回补记录流水，便于审计
2.2 支付对账与幂等
脚本中订单有 payment_status/paid_amount，但未见：
- 支付流水表（第三方支付回调存证）
- 支付回调幂等键
- 退款流水/退款幂等
建议：补交易流水表（或在应用层引入专门支付子系统）并明确幂等策略。
2.3 优惠券核销一致性
当前有 ml_user_coupons.status/used_at/order_id，但未见：
- “同一张券只能用一次”的强事务保证（除非应用层做 CAS 更新）
- 与订单金额计算的强一致校验
建议：
- 用条件更新核销：
where status=1确保并发只成功一次 - 关键核销与订单创建在同一事务内
2.4 统计字段回滚
脚本在订单完成时累计 sale_count，但未看到：
- 退款/取消是否回滚
sale_count
建议：
- 明确统计字段口径：
sale_count是“累计成交量”还是“累计下单量”
- 若需可回滚：要补对应触发器/作业，或使用流水聚合。
3. 建议的边界划分（团队共识）
- 数据库层：
- 基础合法性（约束/唯一性）
- 关键自动维护字段（updated_at、默认地址唯一、库存汇总、SEO 等）
- 访问控制（RLS）
- 应用层：
- 复杂事务（下单扣库存、支付幂等、退款）
- 业务规则组合（优惠叠加、分摊、拆单、风控）
- 跨域协调（订阅与订单的统一计费/对账）
4. 推荐补充的“最小一致性清单”（可用于评审）
- 下单扣减库存是否原子？
- 未支付关闭订单是否回补库存？
- 支付回调是否幂等？
- 退款回调是否幂等？
- 优惠券核销是否并发安全？
- 统计字段口径是否明确、是否需要回滚？