u013938578的博客

lock调用tryLock方法，参数为获取的超时时间与单位，线程在超时时间内，获取锁操作将自旋在那里，直到该自旋锁的保持者释放了锁。

在加锁的时候把当前的线程 ID 当做value，并在删除之前验证 key 对应的 value 是不是自己线程的 ID。但是，这样做其实隐含了一个新的问题，get操作、判断和释放锁是两个独立操作，不是原子性。对于非原子性的问题，我们可以使用Lua脚本来确保操作的原子性。（1）setnx 和 expire 不是原子性的操作，假设某个线程执行setnx 命令，成功获得了锁，但是还没来得及执行expire 命令，服务器就挂掉了，这样一来，这把锁就没有设置过期时间了，变成了死锁，别的线程再也没有办法获得锁了。

本文介绍了基于数据库实现分布式锁的三种方案，分别是利用数据库自带的表锁或行锁实现的悲观锁、通过版本号或时间戳实现的乐观锁以及数据库唯一索引。优点是简单上手快，不需要引入额外的中间件。但缺点也是不可忽视的，缺点如下：悲观锁：当加锁顺序有误时，容易出现死锁问题；乐观锁：存在一些额外的系统消耗，可能需要重试几次才能成功；

Lock4j是一个分布式锁组件，它提供了多种不同的支持以满足不同性能和环境的需求；它基于Spring AOP，支持RedisTemplate、Redisson、Zookeeper作为底层。属性说明name需要锁住的key名称executorlock 执行器，可以使用该参数自定义设置keys需要锁住的keys名称，可以是多个expire锁过期时间，主要是用来防止死锁可以理解为排队等待时长，超过这个时长就退出排队，并排除获取锁超时异常是否自动释放锁，默认为true/**

在选择分布式唯一ID生成的方法时，需要根据系统的具体需求和环境来决定。使用Redis的方法提供了高性能和易于扩展的解决方案，而使用数据库分段的方法则在减少数据库交互的同时，保证了ID的唯一性。在选择合适的分布式ID生成策略时，应考虑系统的规模、性能需求、ID的顺序性和唯一性要求，以及对网络的依赖程度。不同的方法各有优势和局限，应根据具体的应用场景和需求进行选择。

他的基本特性和持久节点是一致的，额外的特性表现在顺序性上。在ZooKeeper中，每个父节点都会为他的第一级子节点维护一份顺序，用于记录下每个子节点创建的先后顺序。基于这个顺序特性，在创建子节点的时候，可以设置这个标记，那么在创建节点过程中，ZooKeeper会自动为给定节点加上一个数字后缀，作为一个新的、完整的节点名。另外需要注意的是，这个数字后缀的上限是整型的最大值。ZooKeeper中为数据节点引入了版本的概念，每个数据节点都具有三种类型的版本信息，对数据节点的任何更新操作都会引起版本号的变化。

Redis是一个高性能的键值数据库，它可以用于生成分布式唯一标识符。需要注意的是Redis实现ID可以用，这也是很多公司的选择。但是在redis服务器宕机的情况下，他也可能会出现重复生成ID的情况。

Tinyid 是滴滴用 Java 开发的一款分布式 id 生成系统，基于数据库号段算法实现，Tinyid 扩展了 leaf-segment 算法，支持了多db(master)，同时提供了 java-client(sdk) 使 id 生成本地化，获得了更好的性能与可用性。Tinyid 在滴滴客服部门使用，均通过 tinyid-client 方式接入，每天生成亿级别的 id。

Leaf的snowflake模式依赖于ZooKeeper，不同于原始snowflake算法也主要是在workId的生成上，Leaf中workId是基于ZooKeeper的顺序Id来生成的，每个应用在使用Leaf-snowflake时，启动时都会都在Zookeeper中生成一个顺序Id，相当于一台机器对应一个顺序节点，也就是一个workId。该模式依赖于数据库，所以受限于数据库的高可用和数据库的性能，数据库可能成为性能瓶颈。该模式依赖于zk，所以受限于zk的高可用和跟zk的交互网络稳定性也是有一定的影响。

UidGenerator会在集成用它生成分布式ID的实例启动的时候，往这个表中插入一行数据，得到的id值就是准备赋给workerId的值。epoch时间就是指集成UidGenerator生成分布式ID服务第一次上线的时间，可配置，也一定要根据你的上线时间进行配置，因为默认的epoch时间可是2016-09-20，不配置的话，会浪费好几年的可用时间。当前时间，相对于时间基点"2016-05-20"的增量值，单位：秒，最多可支持约8.7年。每秒下的并发序列，13 bits可支持每秒8192个并发。

这种方案大致来说是一种以划分命名空间（UUID也算，由于比较常见，所以单独分析）来生成ID的一种算法，这种方案把64-bit分别划分成多段，分开来标示机器、时间等，比如在snowflake中的64-bit分别表示如下图（图片来自网络）所示：41-bit的时间可以表示（1L

在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。如在美团点评的金融、支付、餐饮、酒店、猫眼电影等产品的系统中，数据日渐增长，对数据分库分表后需要有一个唯一ID来标识一条数据或消息，数据库的自增ID显然不能满足需求；特别一点的如订单、骑手、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。

目前LCN版本已经升级为4.0了，但是官方没有SpringCloud2.0的demo案例。因为LCN本身是开源的，有些大神对LCN框架源码做修改，可以支持SpringCloud2.0版本。

订单服务（发起方）使用对应的事务分组id，通知给TxManager事务协调者，让后TxManager事务协调者在根据该事务分组id，通知给所有的参与方提交事务。2.订单服务（发起方）调用库存服务接口（参与方）之前会向TxManager事务协调者创建一个事务的分组id。3.订单服务（发起方）调用库存服务接口（参与方）的时候，会在请求头中存放该事务的分组id，给库存服务。订单服务（发起方）调用库存服务接口（参与方）之后，如果订单服务（发起方）执行没有问题的下，5.参与方在什么时候提交事务。

传统项目中，比如项目中使用到多数据源的时候大多数采用jta+Atomikos解决分布式事务问题，jta+Atomikos底层是基于XA协议的两阶段提交方案。

如果每个参与者明确返回准备成功，则协调者向参与者发送提交指令，参与者释放锁定的资源，如何任何一个参与者明确返回准备失败，则协调者会发送中指指令，参与者取消已经变更的事务，释放锁定的资源。准备阶段：协调者向参与者发起指令，参与者评估自己的状态，如果参与者评估指令可以完成，则会写redo或者undo日志，让后锁定资源，执行操作，但并不提交。但是两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。缺点：如果协调者宕机，参与者没有协调者指挥，则会一直阻塞。

Seata（Simple Extensible Autonomous Transaction Architecture，简单可扩展自治事务框架）是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。Seata 开源半年左右，目前已经有接近一万 star，社区非常活跃。我们热忱欢迎大家参与到 Seata 社区建设中，一同将 Seata 打造成开源分布式事务标杆产品。https://1.1 Seata 产品模块如下图所示，Seata 中有三大模块，分别是 TM、RM 和 TC。

最后总结一下：undo log 记录更新前数据，用于保证事务原子性redo log 记录更新后数据，用于保证事务的持久性redo log有自己的内存buffer，先写入到buffer，事务提交时写入磁盘redo log持久化之后，意味着事务是可提交的1.3.分布式事务分布式事务，就是指不是在单个服务或单个数据库架构下，产生的事务：跨数据源的分布式事务跨服务的分布式事务综合情况1）跨数据源随着业务数据规模的快速发展，数据量越来越大，单库单表逐渐成为瓶颈。

为什么分布式系统下，事务的ACID原则难以满足？这得从CAP定理和BASE理论说起。

一、基本思想Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。不太严格的讲，对于海量数据的数据库，如果是因为表多而数据多，这时候适合使用垂直切分，即把关系紧密（比如同一模块）的表切分出来放在一个server上。如果表并不多，但每张表的数据非常多，这时候适合水平切分，即把表的数据按某种规则（比如按ID散列）切分到多个数据库(...