在并发数据库访问中如何选型锁机制：从悲观锁到分布式锁的实战指南

在并发数据库访问中如何选型锁机制：从悲观锁到分布式锁的实战指南

并发数据库访问在互联网应用中无处不在：秒杀系统、金融交易、实时数据分析、日志聚合……当大量请求同时触及同一数据时，数据一致性与系统性能之间的平衡成了设计的核心挑战。本文将带你从基础理论出发，结合丰富的 Python 代码示例和实战案例，深入剖析多种锁机制的应用场景与最佳实践，帮助你在项目中游刃有余地应对高并发带来的种种考验。

一、并发访问与锁机制的必要性

在单线程环境中，数据库读写按序执行，一次只处理一个操作，天然无冲突。但在多线程或分布式场景下，多个请求几乎同时到达数据库，如果缺少协调：

• 写—写冲突可能导致数据覆盖或丢失
• 读—写冲突可能读取到不一致的数据
• 幻读、可重复读等隔离性问题让业务逻辑无法预期

当数据库自身无法自动解决这些并发问题时，我们就需要借助“锁”（Lock）机制，在关键资源上加锁，保证同一时间只有符合条件的操作得以执行，从而维护数据完整性。

写锁、读锁、有悲观也有乐观；本地锁、全局锁又分单机与分布式。如何在性能与一致性之间权衡？文章将逐一拆解。

二、事务、隔离级别与锁的基础概念

在深入各种锁机制之前，理解数据库事务（Transaction）和隔离级别（Isolation Level）是前提。

• 事务：一组数据库操作的逻辑单元，要么全部成功提交，要么全部回滚，确保原子性
• 隔离级别：定义事务间可见性，SQL 标准将其分为 READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE 四档
• 锁类型：
  • 共享锁（Shared Lock，读锁）允许多个事务并发读取
  • 排他锁（Exclusive Lock，写锁）只允许单个事务写

不同隔离级别会触发不同的锁策略或 MVCC 行为，读者可以根据业务对一致性的要求，选择合适的隔离级别并配合锁机制优化性能。

三、悲观锁：安全至上，直接先上锁

悲观锁假设高冲突场景，所有可能冲突的操作都先加锁，常见于对数据绝对安全敏感的场景，如金融支付、库存扣减。

3.1 SELECT … FOR UPDATE（行级锁）

MySQL InnoDB、PostgreSQL 均支持：

BEGIN;
SELECT stock
  FROM product
 WHERE id = 42
   FOR UPDATE;

-- 检查并扣减库存
UPDATE product
   SET stock = stock - 1
 WHERE id = 42;

COMMIT;

• 行级锁定：只有 id=42 那一行被锁，极大释放并发度
• 阻塞等待：如果另一事务已锁同一行，后者须等待或超时

3.2 SQLAlchemy 中的悲观锁示例

from sqlalchemy import create_engine, Column, Integer
from sqlalchemy.orm import sessionmaker, scoped_session
from sqlalchemy.ext.declarative import declarative_base

Base = declarative_base()
engine = create_engine('mysql+pymysql://user:pass@localhost/db')
Session = scoped_session(sessionmaker(bind=engine))

class Product(Base):
    __tablename__ = 'product'
    id = Column(Integer, primary_key=True)
    stock = Column(Integer, nullable=False)

def deduct_stock(product_id, amount=1):
    session = Session()
    try:
        product = session.query(Product) \
                         .with_for_update