java 分布式

一：分布式

        分布式是一种架构模式，是将公有模块进行提取，构建成单独的模块，部署在不同服务器上进行调用。分布式系统一定是由多个节点组成的系统(这些节点一般不是孤立的，而是互通的);节点之间相互的操作会有协同。

特点：

        1.增大系统容量

        2.加强系统可用

        3.系统模块重用度高

        4.模块被拆分，开发和发布速度可以并行而变得更快

        5.系统扩展性更高

类型：

        1.分布式处理，但只有一个总数据库，没有局部数据库

        2.分层式处理，每一层都有自己的数据库

        3.充分分散的分布式网络，没有中央控制部分，各节点之间的联系方式又可以有多种

二、分布式理论

CAP理论

        CAP理论：又称为布鲁尔定理；CAP是一致性、可用性、分区容错性的首字母组合；CAP定理指出对于一个分布式系统来说需满足以下三点中的两点（分区容错性一定要满足，一致性和可用性二选一）：

        一致性：所有节点访问同一份最新的数据副本

        可用性：非故障的节点在合理的时间内返回合理的响应

        分区容错性：分布式系统出现网络分区的时候，仍然能够对外提供服务

网络分区：分布式系统中，多个节点之前的网络本来是连通的，但是因为某些故障（比如部分节点网络出了问题）某些节点之间不连通了，整个网络就分成了几块区域。

总结：

        1.在系统发生“分区”的情况下，CAP 理论只能满足 CP 或者 AP。要注意的是，这里的前提是系统发生了“分区”

        2.如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以同时保证 C 和 A 了

        3.如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA

BASE理论

        BASE：基本可用、软状态、最终一致性的缩写；BASE理论是对CAP中的一致性C和可用性A权衡的结果是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。

        核心思想：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采取适当的方式来使系统达到强一致性（也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”）。

        基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。（响应时间上的损失、系统功能上的损失）

        软状态：软状态指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

        最终一致性：系统中所有的数据，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

分布式一致性：

        强一致性 ：系统写入了什么，读出来的就是什么

        弱一致性 ：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态

        最终一致性 ：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态

如何实现最终一致性：

        1.读时修复 : 在读取数据时，检测数据的不一致，进行修复

        2.写时修复 : 在写入数据，检测数据的不一致时，进行修复

        3.异步修复 （推荐）: 这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复

CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸

三、分布式ID

ID：ID就是数据的唯一标识。

分布式ID：分布式系统下的 ID；如何为不同的数据节点生成全局唯一主键，这个时候就需要生成分布式 ID了。

分布式ID满足条件：

        1.全局唯一：ID 的全局唯一性肯定是首先要满足的

        2.高性能：分布式 ID 的生成速度要快，对本地资源消耗要小

        3.高可用：生成分布式 ID 的服务要保证可用性无限接近于 100%

        4.方便易用：拿来即用，使用方便，快速接入

分布式ID常见解决方案：

数据库：

        数据库主键自增：数据库的自增主键产生来唯一的 ID，新建占位字段，创建了唯一索引，保证其唯一性；插入时，如果主键或唯一索引字段出现重复数据错误而插入失败时，先从表中删除含有重复关键字值的冲突行，然后再次尝试把数据插入到表中

                优点：实现起来比较简单、ID 有序递增、存储消耗空间小

                缺点：支持的并发量不大、每次获取 ID 都要访问一次数据库

        数据库号段模式:批量获取ID，然后存在内存里面，需要用到的时候，直接从内存里面拿；基于数据库的号段模式来生成分布式 ID（数据库的访问次数更少，数据库压力更小）；

                优点：ID 有序递增、存储消耗空间小

                缺点：存在数据库单点问题、ID 没有具体业务含义

        redis：利用命令即可实现对 id 原子顺序递增

算法：

        UUID:包含 32 个 16 进制数字，生成简单

                优点：生成速度比较快、简单易用

                缺点：存储消耗空间大、无序

        雪花算法：生成64 bit的二进制被分成了几部分，每一部分存储的数据都有特定的含义（第 1~41 位 ：一共 41 位，用来表示时间戳；第 42~52 位 ：一共 10 位，一般来说，前 5 位表示机房 ID，后 5 位表示机器 ID；第 53~64 位 ：一共 12 位，用来表示序列号）

                优点 ：生成速度比较快、生成的 ID 有序递增、比较灵活

                优点 ：生成速度比较快、生成的 ID 有序递增、比较灵活

开源框架：

        百度：基于雪花算法进行了改进，生成ID的组成不一样；

        美团：基于雪花算法和号段模式

        滴滴：基于数据库号段模式的唯一 ID 生成器

四、分布式锁

分布式锁，分布式系统中的锁；为了解决分布式系统中控制资源共享访问的问题。

具备条件：

        1.互斥：任意一个时刻，锁只能被一个线程持有

        2.高可用：释放锁的代码逻辑出现问题，锁最终一定还是会被释放，不会影响其他线程对共享资源的访问

        3.可重入：一个节点获得锁之后，还可以再次获得锁

实现方式：

基于数据库的分布式锁

        1.基于数据库表的增删：先创建一张锁的表，当需要锁住某个方法时，往该表中插入一条相关的记录，如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功，那么我们就认为操作成功的那个线程获得了该方法的锁，可以执行方法体内容。执行完毕之后，需要delete该记录

        2.基于数据库的排它锁：数据库在查询过程中给数据库表增加排他锁。获得排它锁的线程即可获得分布式锁，当获得锁之后，可以执行方法的业务逻辑，执行完方法之后，释放锁。当某条记录被加上排他锁之后，其他线程无法获取排他锁并被阻塞。

redis实现分布式锁

        1.基于set命令的分布式锁：

        2.基于setnx、get、getset的分布式锁

        3.基于RedLock的分布式锁

        4.基于Redisson看门狗的分布式锁

zookeeper实现分布式锁

        基于zookeeper临时有序节点可以实现的分布式锁。每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。

五、分布式事务

分布式事务是指在分布式系统中实现事务，它其实是由多个本地事务组合而成；分布式事务而言几乎满足不了 ACID。

分布式事务方案：

1.2PC/3PC

2PC：二阶段提交。 二阶段提交是一种强一致性设计，2PC 引入一个事务协调者的角色来协调管理各参与者的提交和回滚，二阶段分别指的是准备和提交两个阶段：

        准备阶段：协调者会给各参与者发送准备命令，做完提交事务之外的所有事情

        提交阶段：提交或回滚事务

3PC： 是为了解决 2PC 的一些问题，相比于 2PC 它在参与者中也引入了超时机制，并且新增了一个阶段使得参与者可以利用这一个阶段统一各自的状态（预提交阶段）；

不管哪一个阶段有参与者返回失败都会宣布事务失败；

思想：先试探性的执行，如果都可以那就真正的执行，如果不行就回滚

2.本地消息表

本地消息表：利用了各系统本地的事务来实现分布式事务；

        会有一张存放本地消息的表，一般都是放在数据库中，然后在执行业务的时候 将业务的执行和将消息放入消息表中的操作放在同一个事务中，这样就能保证消息放入本地表中业务肯定是执行成功的。

本地消息表其实实现的是最终一致性，容忍了数据暂时不一致的情况

3.事务消息

事务消息是通过消息中间件来解耦本地消息表和业务数据表，适用于所有对数据最终一致性需求的场景。现在支持事务消息的消息中间件只有RocketMQ，这个概念最早也是RocketMQ提出的。

流程：发起方发送半事务消息会给RocketMQ，发起方进行本地事务操作，后确认提交消息，此时接受方可以消费到此消息了。

4.TCC

TCC 是业务层面的分布式事务；（预留-确认操作-撤销操作）；都是先试探性的执行，如果都可以那就真正的执行，如果不行就回滚；

        比如说一个事务要执行A、B、C三个操作，那么先对三个操作执行预留动作。如果都预留成功了那么就执行确认操作，如果有一个预留失败那就都执行撤销动作。

TCC可以跨数据库、跨不同的业务系统来实现事务

5.Saga

Saga事务模型又叫做长时间运行的事务；

        核心思想就是拆分分布式系统中的长事务为多个短事务，或者叫多个本地事务，然后由 Saga工作流引擎负责协调，如果整个流程正常结束，那么就算是业务成功完成，如果在这过程中实现失败，那么Saga工作流引擎就会以相反的顺序调用补偿操作，重新进行业务回滚。 

6.Seate

Seata是一个由阿里做背书的分布式事务框架，致力于提供高性能和简单易用的分布式事务服务。

        特点是对业务无入侵，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。

特点是对业务无入侵，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作