并发控制与任务调度机制总结

本笔记总结了 乐观锁、悲观锁、Redis 分布式锁 和 队列 的区别与应用场景。

1. 乐观锁

乐观锁是一种假设 并发冲突概率较低 的并发控制机制。在进行数据更新时，不加锁，假设不会有冲突，等到提交时再检查是否有冲突。

• 原理：使用版本号或时间戳作为标识，在更新数据时先读取版本号，执行更新操作时再次检查版本号是否发生变化。如果发生变化，说明有其他事务修改过数据，则需要重试或抛出异常。
• 适用场景：适合读多写少的场景，冲突较少的并发环境，如用户评论、订单提交等不频繁更新的数据操作。
• 优点：高并发性能好，避免了频繁加锁的开销，不会造成锁竞争或资源阻塞。
• 缺点：当并发冲突较多时，可能需要反复重试，降低系统性能，不适用于高频更新的场景。
• 应用示例：数据库中的 UPDATE ... WHERE version = ? 语句，通过 version 字段确保数据只有在未被修改时才能更新成功。

2. 悲观锁

悲观锁是一种假设 并发冲突概率较高 的并发控制机制。在操作数据前，先加锁以避免其他事务修改同一数据，直到事务完成后释放锁。

• 原理：在读取数据时，直接对数据行或表加锁，防止其他事务进行修改或读取，等到事务完成后再释放锁。
• 适用场景：适合写多读少的场景，或并发冲突较多的场景，如库存管理、银行转账等需要保证强一致性的业务场景。
• 优点：确保数据强一致性，不会出现并发写入导致的数据不一致问题。
• 缺点：性能较低，因为需要加锁，可能会导致锁竞争和阻塞，容易引发死锁问题。
• 应用示例：数据库中的 SELECT ... FOR UPDATE 语句，在读取时加锁，防止其他事务对相同的数据进行操作。

3. Redis 分布式锁

Redis 分布式锁是一种用于解决分布式环境下并发控制问题的锁机制，利用 Redis 的原子性操作，确保多个进程或服务器之间对共享资源的 互斥访问。

• 原理：基于 Redis 的 SETNX（set if not exists）命令和过期时间机制，每个进程尝试在 Redis 中写入锁，如果成功，则表明该进程获得了锁；否则，需要等待或重试。过期时间可以避免死锁问题。
• 适用场景：适合分布式系统中多个节点需要互斥访问资源的场景，如集群中的订单处理、库存操作等。
• 优点：分布式环境支持，可以在多台服务器之间共享锁，保证互斥访问；性能较高，Redis 本身是高效的内存存储。
• 缺点：过期时间设置不当可能导致锁失效或过早释放；需要确保 Redis 的可靠性，否则锁机制可能失效。
• 应用示例：Redis 的 SETNX + EXPIRE 实现锁的原子操作，使用 Redis.lock() 来确保任务的唯一性。

4. 队列

队列是一种任务调度机制，用于处理异步任务。通过将任务放入队列并由工作者进程（worker）异步执行，可以实现任务的 解耦 和 异步处理。

• 原理：将任务推送到一个消息队列（如 Redis、RabbitMQ 等），工作者进程异步从队列中取出任务并执行。队列保证任务的顺序执行或优先级执行，任务可以按需重试或处理失败情况。
• 适用场景：适合需要异步处理、任务执行时间不定、需要并发处理的场景，如电子邮件发送、批量数据处理、生成报表等。
• 优点：异步处理，不阻塞主线程，可以处理长时间运行的任务；并发扩展性强，可以通过增加工作者数量来提高处理速度。
• 缺点：如果任务失败，可能需要复杂的重试和错误处理机制；需要处理任务堆积和系统压力问题。
• 应用示例：Laravel 队列系统中的 dispatch 方法，将任务推送到队列由工作者异步执行，队列可以基于 Redis、Beanstalkd 等实现。

总结区别

适用场景总结

• 乐观锁：适用于 高并发、低冲突 的环境，如订单提交、评论系统。
• 悲观锁：适用于需要 强一致性和写操作频繁 的场景，如库存管理、银行转账。
• Redis 分布式锁：适合分布式系统中的 资源共享和互斥访问，如并发处理订单、库存控制。
• 队列：适用于 异步任务和并发执行，如批量数据处理、异步通知、任务队列等。

根据实际需求和系统架构选择合适的机制，有助于提高系统的性能和稳定性。