刘皇叔说Java的博客

幂等性是数学和计算机科学中的一个概念。在HTTP/1.1规范中，它对幂等性的定义是：核心思想：一个方法（或接口），无论被调用多少次，其产生的最终副作用（对系统状态的影响）都应与第一次调用时相同。简单比喻：按一下开关，灯会亮。你再按多少次，灯都还是亮着的状态（而不是闪烁不定），这就是幂等。setOn()这个操作就是幂等的。方案原理适用操作优点缺点Token机制一次性的令牌POST（创建）通用性强，有效防重需两次交互，需维护Token状态唯一索引数据库唯一约束POST（创建）简单可靠，成本低。

特性脑裂（Split-Brain）假死（False Death）本质多个节点同时认为自己是主节点卡顿/延迟被误判为宕机原因网络分区、仲裁错误GC、IO阻塞、网络抖动危害多主 → 数据不一致节点被错误剔除，触发误切换场景Redis Sentinel、双机热备Java 应用 Full GC、Redis 阻塞解决方案仲裁机制、租约、Fencing优化 GC、健康检查、多维心跳。

对比点取模哈希一致性哈希实现复杂度简单相对复杂（需环/虚拟节点）节点变更时数据迁移大规模迁移仅局部迁移负载均衡均匀（N 固定时）需配合虚拟节点，效果更好适用场景节点数固定的集群节点数经常变动的分布式系统。

Jenkins 是一个开源的持续集成和持续交付(CI/CD)工具，用于自动化软件开发过程中的构建、测试和部署阶段。

业务指标采集@Service// 创建计数器// 创建计时器.publishPercentiles(0.5, 0.95) // 50%和95%分位// 方法1: 手动计时try {// 业务逻辑...// 方法2: 使用Lambda自动计时// 业务逻辑...});@Override// 添加自定义指标)));// 注册Collector。

分布式链路追踪系统的实现涉及多个核心技术环节，下面我将从数据采集、上下文传播、存储分析等维度深入解析其工作原理。

/ 创建自定义Span.start();// 业务逻辑// 记录事件throw e;span.end();

Nacos作为阿里巴巴开源的配置中心，其实现原理涉及多个关键技术点，下面我将从核心架构、数据模型、通信机制等方面进行详细解析。

客户端发起请求后，服务端若配置无变更则保持连接，直到变更或超时。：建立全双工通信通道，服务端主动推送变更。

配置中心是一种用于集中管理和动态下发配置信息的系统服务，属于微服务治理和DevOps领域的重要组件。将应用程序配置从代码中剥离，实现配置的集中管理、动态更新、统一发布等能力。配置中心是一种集中式的配置管理系统，用于提高微服务架构下配置的可维护性、可动态性和安全性。Nacos：如果你在使用 Spring Cloud Alibaba；Apollo：适合更复杂的企业配置管理（权限、审计、灰度）；：适合中小型项目、轻量场景。

HAProxy 和 Nginx 都是优秀的负载均衡工具，但它们在设计目标、适用场景和功能特性上有显著区别。

总的来说，Leaf 基于 Snowflake 算法实现了一个高效、高性能的分布式 ID 生成系统，通过合理地利用时间戳、机器ID和序列号，确保生成的 ID 在分布式环境下唯一且趋势递增。Tinyid是滴滴开源的轻量级分布式ID生成系统，它是基于号段模式原理实现的与Leaf如出一辙，每个服务获取一个号段（1000,2000]、（2000,3000]、（3000,4000]我们日常开发中，经常需要使用到分布式ID。通过机器ID的划分，可以支持多台机器生成唯一的ID，适用于分布式系统中的 ID 生成需求。

apollo官网源码：https://github.com/apolloconfig/apolloapollo使用文档：https://www.apolloconfig.com/#/zh/README。

一旦发现本地缓存的配置内容和服务端的配置内容有差异，那么，就表示服务器端的配置有更新。于是，需要把更新的配置拉到本地，在这个过程中，有可能因为客户端的配置比较多，而导致对比的时间较长，使得配置的同步效率非常低。尽管Nacos提供了注册中心和配置中心的功能，但根据实践经验和推荐做法，更多的团队会选择将Nacos用作配置中心，而将服务发现和注册功能交给其他工具如Consul、Eureka等来实现。最后，再加上长轮询的方式，既减少了Pull的轮询次数，又利用了长轮询的优势，很好地实现了配置动态更新的。

Snowflake算法是Twitter开发的一种分布式唯一ID生成算法，用于解决在分布式系统中生成全局唯一ID的问题。该算法的核心思想是通过对64位的ID进行合理的位分配，保证在分布式环境下生成的ID具有全局唯一性和有序性。

锁我们都知道，在程序中的作用就是同步工具，保证共享资源在同一时刻只能被一个线程访问，Java中的锁我们都很熟悉了，像synchronized 、Lock都是我们经常使用的，但是Java的锁只能保证单机的时候有效，分布式集群环境就无能为力了，这个时候我们就需要用到分布式锁。3.使用带有唯一标识的锁：在设置锁时，可以为每个获取锁的客户端生成一个唯一的标识，释放锁时验证标识是否匹配，确保只有持有锁的客户端才能释放锁，避免其他客户端误操作导致的死锁。在这里，判断当前线程加的锁和释放锁是不是一个原子操作。

1.Redis是基于它的命令执行是单线程的这个特性，所以在获取数据的时候不会有并发问题来去做分布式锁的，其中Redisson客户端，对分布式锁进行了很好的包装，redisson分布式锁 基于lua+hash来实现加锁逻辑，同时利用Redis的发布与订阅以及seamphore来实现锁的等待。2.zk的分布式锁，主要是基于zk的临时有序节点+watch机制来实现的，每个线程去尝试加锁都会创建一个临时有序节点，然后拿锁的时候，判断是否是最小的那几个节点，如果不是，就线程安全的去监听上一个节点。

锁我们都知道，在程序中的作用就是同步工具，保证共享资源在同一时刻只能被一个线程访问，Java中的锁我们都很熟悉了，像synchronized 、Lock都是我们经常使用的，但是Java的锁只能保证单机的时候有效，分布式集群环境就无能为力了，这个时候我们就需要用到分布式锁。其实我们设想一下，是否可以给获得锁的线程，开启一个定时守护线程，每隔一段时间检查锁是否还存在，存在则对锁的过期时间延长，防止锁过期提前释放。秒杀下单、抢红包等等业务场景，都需要用到分布式锁，我们项目中经常使用Redis作为分布式锁。

基于zookeeper临时有序节点可以实现的分布式锁。1、zookeeper天生设计定位就是分布式协调，强一致性。锁的模型健壮、简单易用、适合做分布式锁。2、如果获取不到锁，只需要添加一个监听器就可以了，不用一直轮询，性能消耗较小。3、如果有较多的客户端频繁的申请加锁、释放锁，对于zk集群的压力会比较大。

分布式,通俗意义上来讲，分布式是将一个整体按照分布到不同地方，只要一个节点出现问题，则会导致系统出现问题，分布式就是将多台服务器集中在一起，每台服务器都实现总体中的不同业务。每台服务器都缺一不可，如果某台服务器发生宕机了，则部分功能缺失，将导致整体无法运行。

部署的越多，可靠性就越高，当然只能部署奇数个，偶数个是不可以的（zookeeper有这样一个特性：集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的。同理，要是有3个zookeeper，一个死了，还剩下2个正常的，过半了，所以3个zookeeper的容忍度为1；但是，会带来Leader选举的一个问题，也就是说，如果Leader节点宕机了，为了保证集群继续提供可靠的服务，Zookeeper需要从剩下的Follower节点里面去选举一个新的节点作为Leader，也就是所谓的Leader选举。

Dubbo 是一款开源的高性能分布式服务框架，由阿里巴巴集团开发和维护。它提供了一套完整的分布式服务治理解决方案，帮助用户轻松构建和管理大规模的分布式系统。服务注册与发现：Dubbo 提供了服务注册中心，用于集中管理服务的注册和发现。服务提供者在启动时将自己的服务注册到注册中心，服务消费者通过注册中心获取服务提供者的地址并进行调用。负载均衡：Dubbo 支持多种负载均衡策略，可以根据实际场景选择适合的负载均衡算法，以实现请求在服务提供者之间的均衡分发。

XXL-JOB是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。在平时的业务场景中，经常有一些场景需要使用定时任务，比如：时间驱动的场景：某个时间点发送优惠券，发送短信等等。批量处理数据：批量统计上个月的账单，统计上个月销售数据等等。固定频率的场景：每隔5分钟需要执行一次。所以定时任务在平时开发中并不少见，而且对于现在快速消费的时代，每天都需要发送各种推送，消息都需要依赖定时任务去完成，应用非常广泛。

TCC（Try-Confirm-Cancel）补偿机制是一种事务处理模式，用于确保分布式系统中的操作成功完成或在失败时进行补偿。TCC将一个事务拆分为三个阶段，即Try、Confirm和Cancel阶段。在Try阶段，业务系统尝试执行事务并锁定所需资源。如果Try阶段成功，业务系统将进入Confirm阶段并提交事务。如果Try阶段失败或出现其他异常情况，业务系统将回滚事务并释放所有锁定的资源。TCC 采用了补偿机制，其核心思想：针对每个操作，都要注册一个与其对应确认和补偿（撤销）操作。

3PC 利用超时机制解决了 2PC 同步阻塞问题，避免资源被永久锁定，进一步加强了整个事务过程可靠性。但 3PC 同样无法应对类似宕机问题，只不过出现多数据源中数据不一致问题概率更小。a. 概念：三阶段提交协议在协调者和参与者中都引入超时机制，并且把两阶段提交协议的第⼀个阶段拆分成了两步：询问，然后再锁资源，最后真正提交。这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

二阶段提交（2PC）是一种用于确保在分布式系统中的所有节点在进行事务提交时保持一致性的算法二阶段提交（Two-Phase Commit，2PC）是一种经典的分布式事务协议，用于保证分布式系统中多个节点之间的事务操作的一致性。它主要分为两个阶段：准备阶段和提交阶段。2PC，即两阶段提交，它将分布式事务提交拆分为 2 个阶段：prepare和commit/rollback，即准备阶段和提交执行阶段。

分布式事务是指涉及多个独立的系统或服务之间的事务操作，这些系统或服务可以位于不同的物理节点、网络或数据库中。在分布式系统中，由于每个节点或服务都有自己的本地事务，因此需要一种机制来保证所有涉及的系统或服务在一个事务中具有一致性和原子性。传统的关系型数据库事务（例如 ACID）通常只适用于单个数据库实例，无法满足分布式系统中跨多个数据库或服务的事务需求。因此，分布式事务需要使用特定的技术和协议来保证事务的一致性和可靠性。

RocketMQ事务消息RocketMQ在4.3.0版中支持分布式事务消息，这里RocketMQ的事务消息是采用2PC(两段式协议) +补偿机制（消息回查）的分布式事务功能。提供消息发送与业务落库的一致性。RocketMQ事务消息（Transactional Message）是指应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败。RocketMQ的事务消息提供类似 X/Open XA 的分布式事务功能，通过事务消息能达到分布式事务的最终一致。

Seata是一款开源的分布式事务解决方案，提供了全局事务管理和协调服务，支持多种主流的数据库和RPC框架，以及Spring Cloud和Dubbo等微服务框架。Seata的设计目标是解决分布式事务的一致性问题，实现高可用、高性能、易扩展的分布式事务管理。Seata是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata有四种模式，分别是AT、TCC、Saga和XA。AT模式：用户只需关心自己的“业务SQL”。

最大努力通知方案的目标，就发起通知方通过一定机制，最大努力将业务处理结果通知到收方。最大努力通知（Best Effort Notification，BEN）：它是一种不保证强一致性的方法，通过异步通知来达到尽量保证事务的一致性，即尽力保证事务成功，但不能完全保证。最大努力通知：这是一种通过消息中间件实现分布式事务的方案，主要应用在金融交易场景中。分布式事务最大努力通知（Best Effort Delivery）是一种分布式系统中处理事务的方法。

本地消息表：这是ebay研发出的一种分布式事务解决方案，通过将消息表存储在数据库中，实现了消息的一致性。它的核心思想就将分布式事务拆分成本地事务进行处理本地消息表是利用各系统本地事务来实现分布式事务。业务系统的执行和消息均放入本地消息表中,确保本地业务执行和消息表的操作在一个事务中。不尝机制重试读取本地消息表,调用远程应用操作。需要加入重试机制、最大执行次数、报警机制。本地消息表容忍数据暂时不一致，期望数据的最终一致性。

这时，我们就可以建⼀张去重表，并且把唯⼀标识作为唯⼀索引，在我们实现时，把创建⽀付单据和写⼊去去重表，放在⼀个事务中，如果重复创建，数据库会抛出唯⼀约束异常，操作就会回滚。5、状态机控制：这种⽅法适合在有状态机流转的情况下，⽐如就会订单的创建和付款，订单的付款肯定是在之前，这时我们可以通过在设计状态字段时，使⽤int类型，并且通过值类型的⼤⼩来做幂等，⽐如订单的创建为0，付款成功为100。然的实现幂等性，比如查询接口，对于查询来说，你查询⼀次和两次，对于系统来说，没有任何影响，查出的结果也是⼀样。

Raft协议是一种用于分布式一致性的共识算法，旨在解决分布式系统中的数据一致性问题。它通过选举领导者（leader）的方式来实现数据的复制和同步。Raft 算法分布式系统开发首选共识算法，它通过“一切以领导者为准”方式，实现一系列值共识和各节点日志一致。Raft 算法一共涉及三种角色（Follower、Candidate、Leader）和两个过程（Leader 选举和日志复制）。

Paxos算法的基本流程包括：提议者向多个接受者发起提议，接受者对提议进行投票，并将投票结果告知提议者，最终提议者根据接受者的投票结果确定一个值。Paxos算法更简单，但Raft算法提供了更强大的领导者选举和日志复制机制，从而提高了系统的稳定性和容错性。Paxos：在Paxos中，每个节点都有一个独立的日志系统，每个提议者都可以向多个接受者发送提案。Raft：在Raft中，日志复制是按照一定的规则进行的。Paxos和Raft都是分布式一致性算法，它们的主要目标是确保在分布式系统中数据的完整性和一致性。