Gary_Tam的博客

大家好，我是徒手敲代码。在分布式系统当中，确保数据的一致性是一项至关重要的任务。作为分布式事务处理的核心机制之一，它主要用于解决分布式环境中多个节点间的数据同步和一致性问题，确保事务的原子性——即事务中的所有操作要么全部成功，要么全部失败。这个机制的两个阶段，指的是准备阶段和提交/回滚阶段。准备阶段在这个阶段，系统中的一个协调者组件，会扮演着指挥官的角色，它向所有涉及事务的参与者发送请求。每个参与者接收到请求后，会进行一系列的检查，比如确保本地资源能够满足事务提交的需求。

但是一般在使用 Redis 的时候，都会采用主从集群 + 哨兵的方式去部署，这样做可以保证 Redis 服务的高可用，即使主节点挂了，也可以在从节点里面再选一个出来，作为主节点。举个例子，客户端在某个 Redis 实例加锁成功，但是因为网络问题，一直没有返回成功的信息，导致客户端误认为这个实例加锁失败，如果最后这个锁没有被释放，那么锁将一直残留在这个 Redis 实例当中。的值是否小于锁的过期时间，也就是判断，在后面的实例成功加锁之后，前面加的锁有没有过期，如果没过期，那么就认为加锁成功。

大家好，我是徒手敲代码。今天来介绍一下分布式锁。首先思考下这些问题：为什么需要分布式锁？基于 Redis 如何实现分布式锁？单纯使用setNx命令来加锁，会存在什么问题？经常听到的RedLock，是百分百完美的方案吗？除了 Redis，还有其他的解决方案吗？因为篇幅问题，本文主要解决前三个问题。

大家好，我是徒手敲代码。上篇文章中，我们介绍了CAP定理，也知道在分布式系统当中，三个特性只能同时满足两个：分区容错性 + 一致性或可用性。想要一致性，就必须舍弃可用性，反之亦然。想象一下，当我们在网上购物的时候，希望看到的库存数量总是准确无误，这是一致性；而无论何时点击购买都能顺利完成交易，这是可用性。那么如何满足如此苛刻的要求呢？对此，大佬们提出了一个叫做的东西，这是一个更加实际的解决方案。它代表了三个原则：基本可用（Basically Available）软状态（Soft State）

大家好，我是徒手敲代码。写完设计模式之后，就断更了将近两个星期。可能是一直下雨，湿气太重的原因，睡眠质量不太好，导致精神状态也比较低迷。（总要找个借口推脱一下）接下来会更新专题相关的文章，发表自己的一些见解，如果有错误的地方，欢迎各位指出。所谓的分布式系统，就是多个节点分工合作，就算某一个节点挂了，也只会影响其中的一些服务，而不至于成个系统都崩溃。此外，在遇到性能瓶颈的时候，还可以比较容易的做出扩展，比如增加更多的节点，而不至于要重构整个系统。