电商系统里的神奇事务魔法 —— ACID中的原子性（4-1）

深夜的紧急求助：电商系统的原子性危机

"叔，您可算来了！"小张一边扒拉着泡面，一边把老张拽到电脑前。屏幕上电商系统后台的异常数据闪烁不停："今天下午连续三单出问题！有客户显示订单已生成，但没扣库存，迟迟发不了货，客户现在追着问发货！"

老张推了推眼镜，端起保温杯："先看代码。"小张昨天刚改的购物流程代码展开：选购商品、生成订单、扣减库存三步顺序执行。

"这流程像极了我年轻时写银行转账代码，"老张笑言，"以为按顺序扣款入账就没事，结果网络波动导致钱扣了没到账，被客户堵门骂了半小时。"

小张耳尖发红："我的问题也出在顺序执行？"

原子性崩塌：订单生成，库存没扣减

老张用鼠标圈住生成订单和扣库存的代码："这两步是绑定操作。假设订单生成成功后突然断电，系统怎么处理？就像自动贩卖机扣钱却不出货，还无法退款，用户能不气？"

问题代码（伪代码）：

python 复制代码

# 生成订单（独立操作）
db.execute("INSERT INTO order (user_id, product_id) VALUES (%s, %s)", (user_id, product_id))
# 扣减库存（独立操作）
db.execute("UPDATE stock SET count = count - 1 WHERE product_id = %s", product_id)

小张点头："昨天就是订单生成了，但库存没减，没生成发货单，仓库无法发货，被投诉了。"

"这是事务原子性缺失，"老张在纸上画圈，"生成订单与扣库存未形成不可分割的整体。生成订单后，系统异常库存扣减失败，会导致订单生成但库存未变，形成脏数据状态。"

老张的诊断：原子性缺失的三大病灶

无事务边界 ：两步操作独立执行，缺乏BEGIN TRANSACTION和COMMIT包裹。
无回滚机制：扣减库存失败时，生成订单无法撤销。
顺序依赖风险：先生成订单后扣库存，后者失败导致前者成为"孤立订单"。

解决方案：用事务打造原子性保险箱

老张改写代码，加入事务管理：

python 复制代码

def create_order(user_id, product_id):
    try:
        # 开启事务（操作暂存，未真正提交）
        db.begin_transaction()
        
         # 1. 生成订单（关键操作）
        db.execute("INSERT INTO order (user_id, product_id) VALUES (%s, %s)", (user_id, product_id))

        # 2. 扣减库存（仅修改内存数据，未持久化）
        db.execute("UPDATE stock SET count = count - 1 WHERE product_id = %s", product_id)
        
        # 3. 校验库存有效性（业务前置校验）
        result = db.execute("SELECT count FROM stock WHERE product_id = %s", product_id).fetchone()
        if result.count < 0:
            raise Exception("库存不足，操作失败")
    
        # 所有操作成功，提交事务（库存和订单永久生效）
        db.commit_transaction()
        return "订单生成成功"
    
    except Exception as e:
        # 异常触发回滚（库存恢复至操作前状态）
        db.rollback_transaction()
        print(f"事务回滚：{str(e)}")
        return "订单生成失败，库存已恢复"

核心原理：

事务如同"操作保险箱"，所有操作要么全部生效（COMMIT），要么全部回退（ROLLBACK）。
库存扣减和订单生成被包裹在同一事务中，确保"同生共死"。
前置库存校验避免无效操作，提升事务成功率。

小张的笔记：原子性保障三板斧

开启事务 ：BEGIN TRANSACTION标记原子操作起点。
包裹核心操作：将强关联操作（如扣库存+生成订单）放入事务块。
自动回滚机制 ：通过TRY-CATCH捕获异常，调用ROLLBACK撤销未提交变更。

关键改进：

事务生命周期 ：明确BEGIN→操作→COMMIT/ROLLBACK流程，避免"半完成"状态。
异常全覆盖：捕获SQL错误、主键冲突、资源不足等各类异常。
业务校验前置：先验证库存有效性，再执行订单生成，减少无效事务。

小张的追问：单条SQL需要事务吗？

小张指着代码里的UPDATE stock问："单条扣库存的SQL语句，本身是不是原子的？"

"问得好！"老张笑道，"单条SQL语句（比如UPDATE或INSERT）在数据库层面是原子的，就像你拧一个乐高螺丝，要么拧进去，要么没拧。但业务逻辑中的多个操作必须用事务包裹。比如你要删除用户和他的所有订单，必须保证两者同时成功或失败，否则就会留下'孤儿订单'，就像人走了但行李还在传送带上。"

老张的提醒：事务的双刃剑

"事务虽能保障原子性，但会阻塞并发操作，影响性能，"老张强调，"避免将非核心操作纳入事务，如发送短信、记录日志等。"

优化示例：

python 复制代码

def create_order_optimized(user_id, product_id):
    try:
        # 使用上下文管理器简化事务操作
        with db.transaction():  
            db.execute("INSERT INTO order...")
            db.execute("UPDATE stock...")
    except:
        db.rollback()
    
    # 非核心操作（移出事务）
    send_sms(user_id, "您的订单正在处理中...")

最佳实践：

事务仅包裹强一致性需求的核心操作（如库存变更+订单生成）。
非核心逻辑（如通知、日志）异步处理，减少事务锁竞争。