DreamSun的博客

部署在不同结点上的系统通过网络交互来完成协同工作的系统。比如：充值加积分的业务，用户在充值系统向自己的账户充钱，在积分系统中自己积分相应的增加。充值系统和积分系统是两个不同的系统，一次充值加积分的业务就需要这两个系统协同工作来完成。事务是指由一组操作组成的一个工作单元，这个工作单元具有原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）。原子性：执行单元中的操作要么全部执行成功，要么全部失败。

xxl-job 是一个分布式任务调度平台，支持定时任务和分片任务。其中，分片任务可以将一个大任务拆分成多个小任务，分布式地执行，提高任务的执行效率和可靠性。分片任务中，有一种特殊的任务类型叫做分片广播任务，可以将一个任务广播到所有的执行器节点上执行，本质上是一种并行执行的方式。分片广播是 xxl-job 的一种任务类型，适用于一些需要并行执行的任务场景。数据处理任务：例如对大量数据进行清洗、分析、转换等操作，可以将任务拆分成多个小任务，分布式地执行，提高任务的执行效率和可靠性。

2PC,即两阶段提交协议的简写，是整个事务过程分为两个阶段，准备阶段（Prepare phase）和提交阶段（Commit phase）3PC是2PC的改进版，将2PC的"提交事务请求"过程一分为二，共形成了由CanCommit,PreCommit和doCommit三个阶段组成的事务处理协议。

XXL-JOB调度中心集群部署配置（一）XXL-JOB执行器配置及定时任务的创建（二）XXL-JOB调度中心对执行器的上下线感知实现原理（三）调度中心如何进行任务调度执行器执行任务需要注意哪些问题在开始研究XXL-JOB的调度流程之前，我们不妨先思考一下，如果让自己来实现一个任务调度，需要从哪些方面去入手呢？对调度流程的思考在前面的配置相关的文章中，我们已经实现了一个调度中心集群、以及一个执行器，并创建了一个定时任务配置，在这样的基础上，要实现一个简单的任务调度Demo是非常简单的。

XXL-JOB调度中心集群部署配置（一）XXL-JOB执行器配置及定时任务的创建（二）在前面两篇文章内容中，我们已经获取到了一个XXL-JOB的集群，以及一个可以执行任务的调度器，同时，在实际的项目中可以参照这个流程，引入定时任务。执行器注册流程执行器的注销流程调度中心探活流程在运行过程中，调度中心要对执行器进行调度，得先获取到执行器的信息，才能根据信息发起调度请求，同时，我们又不希望因调度中心调用到已宕机的执行器而导致程序异常。

在上一篇《XXL-JOB调度中心集群部署配置》中，我们已经得到了一个调度中心的集群，接下来需要了解如何配置调度器及创建定时任务。配置并启动调度器创建并执行定时任务本篇讲解了在有了调度中心的基础上，如何配置执行器从而达到在服务中使用定时任务的过程。在SpringBoot项目中引入xxl-core包。编辑properties文件，并解析到字段中，然后使用这个配置初始化执行器。编写定时任务方法，并使用@XxlJob注解，并配置任务名称。

XXL-JOB是一款轻量级的分布式任务调度中间件，默认支持6000个定时任务，如果生产环境的任务数量在这个范围内，可以选择使用 XXL-JOB。操作更简单，学习成本更低使用异步化调度，性能更好有配套的运维后台系统，提供了配置、监控、日志、统计报表等功能拥有更简单的集群部署方案，服务的注册与发现等功能本文的内容是在官方文档的基础上做了一点细节补充，有经验的同学可以直接查阅《官方文档》。综上，一个基本的调度中心集群就搭建好了，是不是非常简单呢？

Redisson的分布式可重入读写锁RReadWriteLock Java对象实现了java.util.concurrent.locks.ReadWriteLock接口。该对象允许同时有多个读取锁，但是最多只能有一个写入锁。Redisson分布式可重入公平锁也是实现了java.util.concurrent.locks.Lock接口的一种RLock对象。Redisson的分布式可重入锁RLock Java对象实现了java.util.concurrent.locks.Lock接口，同时还支持自动过期解锁。

最后把我们需要推送的MUser对象，使用RTopic对象的publish方法加入到消息队列中。我们在数据库中找到这个用户，然后把这个用户对象塞入Redisson的消息队列中。之前在用Redis的时候，可以利用List这种数据类型的左进右出的特性，能够做消息中间件。为了让我们有一个类似监听器的对象，我们可以实现一个叫做ApplicationRunner接口，然后这个实现类就会一直在内存中。实现Ordered接口为其制定顺序，因为可能有多个ApplicationRunner接口的实现类。

说到分布式存储，我们先来看一下传统的存储是怎么个样子。传统的存储也称为集中式存储， 从概念上可以看出来是具有集中性的，也就是整个存储是集中在一个系统中的，但集中式存储并不是一个单独的设备，是集中在一套系统当中的多个设备，比如下图中的 EMC 存储就需要几个机柜来存放。在这个存储系统中包含很多组件，除了核心的机头（控制器）、磁盘阵列（ JBOD ）和交换机等设备外，还有管理设备等辅助设备。结构中包含一个机头，这个是存储系统中最为核心的部件。通常在机头中有包含两个控制器，互为备用， 避免硬件故障导致整个存储系

AT模式：无侵入式的分布式事务解决方案，适合不希望对业务进行改造的场景，但由于需要添加全局事务锁，对影响高并发系统的性能。该模式主要关注多DB访问的数据一致性，也包括多服务下的多DB数据访问一致性问题TCC模式：高性能的分布式事务解决方案，适用于对性能要求比较高的场景。该模式主要关注业务拆分，在按照业务横向扩展资源时，解决服务间调用的一致性问题Saga模式：长事务的分布式事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统。

现在最流行的redis分布式锁就是Redisson了，来看看它的底层原理就了解redis是如何使用分布式锁的了。

Seata 依赖 Spring 的注解机制，实现声明式事务，即开发者给 Bean 使用@GlobalTransactional注解 ，Seata 通过GlobalTransactionScanner重写此类 Bean 生命周期的三个阶段以完成分布式事务能力，这 3 步为：Bean 初始化阶段(`afterPropertiesSet()``)初始化 TM RM 客户端，建立与 TC 的长连接Bean 初始化后阶段(`wrapIfNecessary()``)

Seata AT模式下，如果服务A(服务接口或方法)参与全局事务，即在全局事务中作为一个分支事务，那么会在 TC 侧添加行锁记录，用于保障全局事务的隔离性。但还有另外一种情况，如果某个服务B从调用上下文上看，并未与其他服务一起协作，而是一个独立的逻辑，但与其他参与全局事务的服务都操控表C中的记录；这种情况下如没有处理好隔离性，会导致服务A无法完成二阶段回滚；如服务A在参与全局事务在一阶段修改了表C中的D记录，服务B也修改了表C中的D记录。

在某些场景中，多个进程必须以互斥的方式独占共享资源，这时用分布式锁是最直接有效的。随着技术快速发展，数据规模增大，分布式系统越来越普及，一个应用往往会部署在多台机器上（多节点），在有些场景中，为了保证数据不重复，要求在同一时刻，同一任务只在一个节点上运行，即保证某一方法同一时刻只能被一个线程执行。

JUC提供的锁机制，可以保证在同一个JVM进程中同一时刻只有一个线程执行操作逻辑；多服务多节点的情况下，就意味着有多个JVM进程，要做到这样，就需要有一个中间人；分布式锁就是用来保证在同一时刻，仅有一个JVM进程中的一个线程在执行操作逻辑；换句话说，JUC的锁和分布式锁都是一种保护系统资源的措施。尽可能将并发带来的不确定性转换为同步的确定性；特性1：互斥性。在任意时刻，只有一个客户端能持有锁。特性2： 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。特性3： 解

刚开始我以为熔断和降级是一体的，以为他们必须配合使用；只不过名字不一样而已，但是当我经过思考过后，发现他们其实不是一个东西;熔断很好理解，就是一个断开的过程；熔断就像是家里的保险丝一样，当电流达到一定条件时，比如保险丝能承受的电流是5A，如果你的电流达到了6A，因为保险丝承受不了这么高的电流，保险丝就会融化，这时候电路就会断开，起到了保护电器的作用；在微服务里面也是一样，当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。

如果在这一过程中，发生了网络分区或者网络通信故障。在恢复网络时，旧的leader会成为拥有多数follwer的新Leader的follwer。故障期间的commit回滚。共识算法就是为了解决分布式一致性的算法，但不适合解决分布式事务一致性（可以解决只是不合适）２：Leader要求Followe遵从他的指令，都将这个新的日志内容追加到他们各自日志中。１：Leader领导人已经选出，客户端发出增加一个日志的要求，比如日志是"hello"协议的事务编号 Zxid 设计中， Zxid 是一个 64位的数字。

概览欢迎来到 Nacos 的世界！Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。什么是 Nacos？服务（Service）是 Nacos 世界的一等公民。Nacos 支持几乎所有主流类型的“服务”的发现、配置和管理：Kubernetes

spring-cloud-Gateway是spring-cloud的一个子项目。而zuul则是netflix公司的项目，只是spring将zuul集成在spring-cloud中使用而已。因为zuul2.0连续跳票和zuul1的性能表现不是很理想，所以催生了spring团队开发了Gateway项目。总的来说，在微服务架构，如果使用了Spring Cloud生态的基础组件，则Spring Cloud Gateway相比而言更加具备优势，单从流式编程+支持异步上就足以让开发者选择它了。

限流、熔断和服务降级是系统容错的重要设计模式，从一定意义上讲限流和熔断也是一种服务降级的手段。熔断和服务降级主要是针对非核心业务功能，而核心业务如果流程超过预估的峰值，就需要进行限流。对于限流，选择合理的限流算法很重要，令牌桶算法优势很明显，也是使用最多的限流算法。在系统设计的时候，这些模式需要配合业务量的预估、性能测试的数据进行相应阈值的配置，而这些阈值最好保存在配置中心，方便实时修改。

资损是在指在业务活动中，业务规则和实际资金流动不一致，导致业务参与方中的任何一方或多方遭受了资金损失。简单理解就是系统的某个功能出现了BUG，导致用户或者公司出现了资金的损失，比如在营销过程中多给某个用户发了10元红包，或者是用户领取了10元红包无法使用，用户在支付时看到的订单金额是100元，结果支付了101元或99元，这些情况都属于资损，用户支付了101用户资损1元，用户实际支付了99元公司资损了1元。为什么要重视资损防控？

稳定性保障简单理解就是不让系统出现不可用的情况，或者不可用的情况每年只能发生几十分钟。为什么要稳定性保障？因为现在很多的电商和支付系统已经属于社会基础系统，持续一段时间不可用会影响比较大，同时也损失了用户的信任。稳定性保障的场景非常多，只要流量非常大的业务就需要系统性的进行稳定性保障，包括直播、电商秒杀、电商大促等场景。2022年9月3日晚刘德华“把我唱给你听”线上演唱会，最终这场线上演唱会的在线观看人次达到3.5亿，那么支持3.5亿人次观看就是一种稳定性保障场景。

在并发编程中，当多个线程同时访问同一个共享的可变变量时，会产生不确定的结果，所以要编写线程安全的代码，其本质上是对这些可变的共享变量的访问操作进行管理。导致这种不确定结果的原因就是可见性、有序性和原子性问题，Java 为解决可见性和有序性问题引入了 Java 内存模型，使用互斥方案（其核心实现技术是锁）来解决原子性问题。这篇先来看看解决可见性、有序性问题的 Java 内存模型（JMM）。

XXL-JOB是一个分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。它的有两个核心模块，一个模块叫做调度中心，另外一个模块叫做执行器，它把任务调度和任务执行分成两个部分。这样调度模块只需要负责任务的调度属性，触发调度信号。执行模块只需要接收调度信号，去执行具体的业务逻辑，两者可以各自的进行扩容和缩容。图1是一张来自官方的架构图。图1 xxl-job v2.1.0架构图。

当你的才华还撑不起你的野心的时候，你就应该静下心来学习，愿你在我这里能有所收获。

分布式系统一定是由多个节点组成的系统。其中，节点指的是计算机服务器，而且这些节点一般不是孤立的，而是互通的。这些连通的节点上部署了我们的节点，并且相互的操作会有协同。分布式系统对于用户而言，他们面对的就是一个服务器，提供用户需要的服务而已，而实际上这些服务是通过背后的众多服务器组成的一个分布式系统，因此分布式系统看起来像是一个超级计算机一样。

在互联网的业务系统中，涉及到各种各样的ID，如在支付系统中就会有支付ID、退款ID等。那一般生成ID都有哪些解决方案呢？特别是在复杂的分布式系统业务场景中，我们应该采用哪种适合自己的解决方案是十分重要的。下面我们一一来列举一下，不一定全部适合，这些解决方案仅供你参考，或许对你有用。image.png。

一、概述1、SnowFlake算法生成id的结果是一个64bit大小的整数，它的结构如下图：● 1位，不用。二进制中最高位为1的都是负数，但是我们生成的id一般都使用整数，所以这个最高位固定是0● 41位，用来记录时间戳（毫秒）。○ 41位可以表示241−12^{41}-1241−1个数字，○ 如果只用来表示正整数（计算机中正数包含0），可以表示的数值范围是：0 至 241−12^{41}-1241−1，减1是因为可表示的数值范围是从0开始算的，而不是1。○ 也就是说41位可以表示24