swadian2008的博客

尽管提交阶段时间很短，但这仍是一段明确存在的危险期，如果协调者在发出准备指令后，根据收到各个参与者发回的信息确定事务状态是可以提交的，协调者会先持久化事务状态，并提交自己的事务，如果这时候网络忽然断开，无法再通过网络向所有参与者发出Commit指令的话，就会导致部分数据（协调者的）已提交，但部分数据（参与者的）未提交，且没有办法回滚，产生数据不一致的问题。TCC 事务具有较强的隔离性，避免了“超售”的问题，而且其性能一般来说是本篇提及的几种柔性事务模式中最高的，但它仍不能满足所有的场景。

远程服务将计算机程序的工作范围从单机扩展至网络，从本地延伸至远程，是构建分布式系统的首要基础。//远程服务调用（Remote Procedure Call，RPC）

1、Redisson简介Redis 是最流行的 NoSQL 数据库解决方案之一，而 Java 是世界上最流行（注意，没有说“最好”）的编程语言之一。虽然两者看起来很自然地在一起“工作”，但是要知道，Redis 其实并没有对 Java 提供原生支持。相反，作为 Java 开发人员，我们若想在程序中集成 Redis，必须使用 Redis 的第三方库。而 Redisson 就是用于在 Java 程序中操作 Redis 的库，它使得我们可以在程序中轻松地使用 Redis。Redisson 在 java.ut

目录1、业务场景引入2、基础环境准备3、Redis实现分布式锁4、分布式锁测试1、业务场景引入模拟一个电商系统，服务器分布式部署，系统中有一个用户下订单的接口，用户下订单之前需要获取分布式锁，然后去检查一下库存，确保库存足够了才会给用户下单，然后释放锁。由于系统有一定的并发，所以会预先将商品的库存保存在redis中，用户下单的时候会更新redis的库存。2、基础环境准备2.1.1.准备库存数据库-- ------------------------------ Ta

首先，为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件：互斥性。在任意时刻，只有一个客户端能持有锁。 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。 具有容错性。只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。下边是代码实现，首先我们要通过Maven引入Jedis开源组件，在pom.xml文件加入下面的代码：<dependenc

一、引入业务场景业务场景一商品下单如果是分布式部署的，多个用户同时购买同一个商品时，就可能导致商品出现库存超卖 (数据不一致) 现象。业务场景二小T在压测时，发现个小问题，因为在终端设备上跟鹅厂有紧密合作，调用他们的接口时需要获取到access_token，但是这个access_token过期时间是2小时，过期后需要重新获取。压测时发现当到达过期时间时，日志看刷出来好几个不一样的access_token，因为这个服务也是分布式部署的，多个节点同时发起了第三方接口请求导致。虽然以最后一