分布式事务与分布式锁

分布式事务与分布式锁的区别

一、分布式事务

定义 分布式事务是指在分布式系统中，为了保证跨服务或跨数据库操作的原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），即ACID属性而进行的一种事务管理机制。

应用场景

• 如果我们的一套业务流设计了多个服务的数据存储，这个时候每个服务的变化都要成功才算整个业务流的成功，只要有一个失败了，则整体算做失败，这时候就需要使用分布式事务来解决数据的ACID特性。

主要挑战

1. 网络延迟：由于涉及多节点通信，网络延迟会增加事务处理的时间。
2. 故障恢复：在分布式环境中，任何节点都可能随时出现故障，如何保证事务的一致性和可恢复性是一个难题。
3. 性能开销：为了保证事务的一致性，通常需要额外的通信和协调，这会带来性能上的开销。

实现技术

• 两阶段提交（2PC, Two-Phase Commit）：参与者向协调者报告是否准备好，由协调者决定是否提交。这种机制能够保证一致性，但可能会导致性能瓶颈和单点故障。
• 三阶段提交（3PC, Three-Phase Commit）：在两阶段提交的基础上增加了预准备阶段，减少了阻塞的可能性。
• Saga事务：将长事务分解为一系列短事务，并通过补偿操作来回滚失败的部分。
• TCC（Try-Confirm-Cancel）：类似于Saga，但更侧重于服务端的设计模式，确保Try、Confirm和Cancel操作的原子性。

二、分布式锁

定义 分布式锁是一种在分布式系统中实现资源互斥访问的机制。它用于防止并发访问同一资源时出现的竞争条件。

应用场景

• 当多个服务尝试同时修改同一个资源时，如更新数据库中的某条记录，需要确保只有一个服务可以执行修改操作。

主要挑战

1. 死锁：如果锁的获取顺序不当，可能导致两个或多个进程相互等待对方释放锁。
2. 性能：频繁地获取和释放锁可能会引入额外的性能开销。
3. 异常处理：如果持有锁的服务发生异常而未能释放锁，可能导致其他服务无法继续执行。

实现技术

• 基于数据库的乐观锁：利用版本号或者时间戳等字段来检测并发冲突。
• 基于消息队列：利用消息队列的特性实现资源的独占访问。
• 基于Zookeeper：利用Zookeeper提供的顺序节点和临时节点特性实现分布式锁。
• Redis分布式锁：利用Redis的setnx命令和超时机制实现简单的分布式锁。

三、区别

1. 目标不同
   • 分布式事务旨在保证跨服务操作的ACID属性，确保所有操作要么全部成功，要么全部失败。
   • 分布式锁旨在解决并发访问共享资源的问题，保证资源的互斥访问。
2. 实现机制不同
   • 分布式事务通常涉及到多个服务之间的协调和通信，可能需要使用复杂的协议来达成一致。
   • 分布式锁则更加关注于资源访问的控制，通常通过锁的获取和释放来实现。
3. 应用场景不同
   • 分布式事务适用于需要跨服务进行数据一致性的场景。
   • 分布式锁适用于保护单一资源免受并发访问的场景。

总结

分布式事务和分布式锁都是为了解决分布式系统中的数据一致性问题，但它们关注的是不同的层面和场景。分布式事务更侧重于跨服务的数据一致性，而分布式锁则侧重于解决单一资源的并发访问问题。