java 知识点突击-(161-170)

Posted 2022-02-04 栗子~~

文章目录

• 前言
• • java 知识点扫盲目录
  • java 知识点突击-(161-170)
  • • 161 简述你对RPC的理解?
    • 162 分布式id生成方案?
    • 163 分布式锁解决方案?
    • • 163::01 db 乐观锁:
      • 163::02 Redis分布式锁:
      • 163::03 Redisson分布式锁
      • 163::04 ZooKeeper 分布式锁:
    • 164 为什么接口中所有的属性都是public static final修饰的?
    • 165 分布式的CAP理论与BASE理论?
    • • 165::01 分布式的CAP理论:
      • 165::02 分布式中的BASE理论:
    • 166 分布式事务是什么?
    • 167 分布式事务方案?
    • 168 分布式事务模型原理?
    • • 168::01 SAGA模型
      • 168::02 TCC模型
      • 168::03 消息模型
    • 169 分布式事务模型对比?
    • 170 分布式模型注意事项?
    • • 170::01 幂等性(重复提交)
      • 170::02 空回滚
      • 170::03 防悬挂
• 创作不易、点关注、不迷路
• 点击主页、更精彩 !!!

前言

  如果您觉得有用的话，记得给博主点个赞，评论，收藏一键三连啊，写作不易啊^ _ ^。
  而且听说点赞的人每天的运气都不会太差，实在白嫖的话，那欢迎常来啊!!!

---

java 知识点扫盲目录

https://blog.csdn.net/weixin_38316697/article/details/121991582

java 知识点突击-(161-170)

161 简述你对RPC的理解?

本地跨网络调用远程函数。
扩展:
RMI 远程方法调用，java用于实现RPC的一种机制。
根RPC区别，RPC无语言限制，而RMI只能是java，调用的前提是都在JVM部署，是java专属的RPC调用。

---

162 分布式id生成方案?

分布式id : 分布式场景下保证id的唯一性。

1)、uuid
java自带的UUID工具类
时间戳+时钟序列(计数器)+全局唯一机器识别码
缺点:
无序、长，对数据库不太友好，主键的聚族索引不太友好，占磁盘内存空间，
极端情况下，安全问题-机器识别码。
2)、数据库自增序列
前提是数据库是单点
多台数据时，id的起始值不一样，并设置相同的步长。
缺点:
系统扩容比较困难，步长初始时是死的，限制住了
数据主从同步的时候，同步延迟时导致查不到这个数据(分布式上数据一致性的问题)，数据要求严谨的话，查询主库

3、基于redis、mongodb、zk中间件
优势是比db的性能瓶颈要大.
4、雪花算法
生成64bit的整形数字。
第一位+41位时间戳+10位workid(可以理解为每个分布式节点服务给它的一编号)+12位序列号,同时位数可以根据实际情况做不同调整.
缺点:
极端情况下，依赖于机器时钟，当=时钟回拨，可能会导致重复id生成==，所以基于此算法，当发现时钟回拨时，会抛出异常，阻止ID生成。

---

163 分布式锁解决方案?

即通过第三方带有原子性的行为来保护高并发下的安全问题。

163::01 db 乐观锁:

概念: 乐观锁是一种很佛性的实现方式，在并发场景下，乐观锁的设计思路是每次从数据库中获取数据的时候都是最新的，并在这之前总认为没有其他线程对该数据进行修改，因此不会上锁，但是在更新时，会判断其他线程在这之前有没有对数据进行修改，通常用"版本号version"机制来实现。

整体流程:

核心sql伪代码:

update table set version = version +1 where id = #id and version=#version

核心伪代码:

if(0<update(vo))
   业务逻辑

核心步骤:
在于获取数据记录时，需要把version字段获取出来，在更新数据记录时需要将version作为匹对条件，并同时将version+1，最终实现version趋势递增的行为。

163::02 Redis分布式锁:

原理:
基于Redis的单线程机制，即不管外层应用系统并发多少个线程，当每个线程都需要使用Redis的某个原子性操作时，都需要排队等待，基于此原理，实现分布式锁效果。

实现操作:
SETNX操作外加EXPIRE操作
操作原理:
Set命令格式

SET Key Value [EX seconds] [PX miliseconds] [NX|XX]

其NX机制是用于实现分布式锁的核心，即SETNX
NX表示只有当Key不存在时才会设置其值

EXPIRE操作 即设置过期时间
EX表示Key的存活时间。

操作注意事项:

1. 使用SETNX命令操作时，返回0，表示Key及对应的锁已经存在，即被其他线程所获取，则获取失败，反之成功；
2. 为防止死锁，设置一个合理的过期时间；
3. 执行完相应的操作后，要释放锁；

缺点:
1、执行Redis的原子操作时、要设置EXPIRE，即Reds的key的TTL，不同的业务场景设置的过期时间是不同的，如果设置不当，很可能会影响系统与Redis服务的性能。
2、Redis 原子操作SETNX获取分布式锁的时候没有"可重入"特性，即当一个线程获得锁时，其他线程获取锁失败，永久的失败，本质上来说是没毛病的，但有些业务场景可能要求线程具有"可重入"特性，这时候，SETNX操作就不满足于当下的需求，就得需要一些配套的逻辑进行处理，即while(true)的代码，但这种方式即不优雅，也很有可能造成应用系统"卡顿"的风险。
3、当Redis原子性操作在【SETNX之后、EXPIPR之前】时，Reids服务发生宕机，同时应用服务出现问题导致该key未被删除，那么造成的影响最终会出现死锁线程，即永远没有线程可以获取到该key值的锁(未加TTL的同时锁也未被删除，导致其永久存在)。

163::03 Redisson分布式锁

概述:
Redisson是一款免费、开源的中间件，是一款基于Redis实现、拥有一系列分布式系统功能特性的工具包

使用:
可重入锁分为一次性和可重入，顾名词义，一次性代表着当前线程如果可以获取到分布式锁，如果成功，获取之，失败则永久失败，可重入代表着当当前线程没有获取到分布式锁的时候，它并不会立即失败，而是等待一段时间重新获取。
优点:
Redisson的底层基础架构采用基于NIO(非阻塞式的输出输入)的netty框架实现数据的传输，具有更为高效的数据传输性能，不仅仅可以作为Redis底层驱动客户端，还可以实现Redis命令以同步、异步】异步流甚至是管道的形式发送消息等功能。

想必比redis:
Redisson分布式锁解决了采用基于redis原子性操作实现分布式锁方式的缺陷。

163::04 ZooKeeper 分布式锁:

通过控制创建与共享资源相关的=="临时顺序节点"和动态Watcher监听机制==，从而控制多线程对共享资源的并发访问。
ZooKeeper 分布式锁整体设计流程:

ZooKeeper节点的数据结构与watcher监听器机制:

每个节点ZNode的动态新增与减少都可以通过Watcher监听器进行监听。

---

164 为什么接口中所有的属性都是public static final修饰的?

public :使接口的实现类可以使用这个常量；

static : static修饰就表示它属于类的，随着类的加载而存在的，如果是非static的话，就表示属于对象的，只有建立对象时才有它，而接口是不能建立对象的，所以 接口的常量必须是static；

final : final修饰就是保证接口中定义的常量不能被实现类所修改，如果没有final的话，由子类随意的进行修改的话， 那么接口建立这个常量就没有意义了；

---

165 分布式的CAP理论与BASE理论?

165::01 分布式的CAP理论:

C:一致性
所有节点上的数据要一致，比如:有三个节点，A节点上的数据有更新，那么B、C节点上的数据同一时间同步更新，达到所有节点上数据完全一致的目的(强一致性)。
A:可用性
服务一直可用，不能说某个节点宕机掉，导致整个服务不可用，即用户操作失败。
P:分区容错性
当某个节点网络分区故障时，仍然能对外提供一致性和可用性服务。
注:
当触发分区容错时:
即网络中断，对外提供访问时( 数据不一致，一致性是不能保证)，在恢复的这段时间内( 可用性就保证不了)。
即CP和AP:分区容错必须保证，当发生网络分区，那么强一致性和可用性只能二选一。

165::02 分布式中的BASE理论:

基于CAP的理论，出现了BASE理论，对CAP理论做的妥协。
BA:基本可用
a.响应时间上的损失可以接受；
由于系统处理故障，导致用户响应时间适当延长。
b.系统功能上的损失可以接受；
由于系统访问量突然剧增，可以让系统非核心功能无法使用。
S:软状态
数据同步允许一定延迟。
E:最终一致性
经历一段时间后，最终能达到一致的状态。

---

166 分布式事务是什么?

理念:
柔性事务的理念则是通过业务逻辑将互斥操作从资源层面移至业务层面，通过放宽对强一制性要求，来换取系统的吞吐量，另外提供自动的异常恢复机制，可以在发生异常后也能确保事务的最终一致性。

遵循分布式的CAP理论与BASE理论。
一个好的分布式事务应该尽可能满足以下特性:

1. 业务改造成本低；
2. 性能消耗低；
3. 隔离性保证完整；
   这三个特性是相互制衡的，往往只能满足两个，常见的实现中，TCC满足2，3，Seata(西塔) 满足1,3

总结:出于性能考虑，分布式架构下，分布式事务难以采用强一致性事务方案，只能最求柔性状态、最终一致性，因此分布式事务框架也称柔性事务框架。

---

167 分布式事务方案?

SAGA(西塔)模型、TCC模型、消息模型
SAGA模式: 正交易完成后业务立即落地，不保证隔离性，不锁数据库咨询，性能优。
TCC模式:通过业务设计保证隔离性，侵入性大，采用预留资源不锁数据库，性能优
消息模式:通过异步消息实现两个系统之间的解耦和并发缓存，下游服务处理结果不影响上游。

核心概念:
事务管理器:事务管理器是一个独立的服务，用于协调分布式事务，包括创建主事务记录，分支事务记录，并根据分布式事务的状态，调用参与者提交和回滚方法。
事务发起方:负责启动分布式事务，通过调用参与者的服务，将参与者纳入到分布式事务中，并决定整个分布式事务是提交和回滚。
事务参与者:当一个参与者被发起方调用后，该参与者会被纳入到该发起方启动的分布式事务中，成为该分布式事务的一个分支事务。

---

168 分布式事务模型原理?

168::01 SAGA模型

模型原理:冲正补偿。

• 一个事务有多个参与者；每个参与者都实现其正向交易和反向补偿交易。
• 业务流程中执行各参与者正交易
• 当出现失败时则补偿前面已完成交易的反交易

特点:

• 业务流程不锁数据库资源，按交易流程顺序执行，高性能。
• 正交易完成后业务立即落地，数据客户可见。
• 补偿模式易于实现。

适用场景:
适用于工作流、业务流等自身隔离性强的业务，或对同一业务数据修改无并发的业务。

168::02 TCC模型

模型原理:两阶段提交。

• 一阶段执行Try(预执行):业务检查、预留资源
• 根据Try交易反馈，二阶段执行
  Confirm(确认执行) : 业务事务执行提交
  Cancel(回滚) : 业务取消，释放预留资源

特点:

• 使用业务锁，实现不同交易之间的隔离
• 交易过程中，不释放数据库中资源，高性能
• 需要对业务进行TCC适配的改造，业务场景的侵入性的改造比较大

适用场景：
适用于账单核算，热点账户这类涉及一借多贷，多借多贷等可能造成银行账户风险的业务场景，或对同一业务修改有并发的业务。

TCC事务补偿是基于2PC实现的业务层事务控制方案， 它是Try、Confirm和Cancel三个单词的首字母， 含义如下：
1、Try 检查及预留业务资源完成提交事务前的检查，并预留好资源。每一个try是一个子事务，所有try方法成功才是成功，try对应第一阶段。
2、Confirm 确定执行业务操作对try阶段预留的资源正式执行。try成功后执行conform，每一个conform为一个独立子事务，conform为第二阶段事务。try和conform是相互独立的。
3、Cancel 取消执行业务操作对try阶段预留的资源释放。只要有一个try执行失败，第二阶段执行cancel方法。
流程：
1、业务服务向分布式事务管理器请求启动事务，并执行第一阶段的 Try 调用其他服务。
2、其他服务返回 Try 结果。
3、全部成功或有失败，向分布式事务管理器发起请求，提交或回滚事务。
4、分布式事务管理器执行第二阶段Conform或Cancel方法调用其他服务。
5、如果第二阶段cancel、conform执行失败，分布式事务管理器会不断重试。

168::03 消息模型

模型原理: 异步提交。

• 针对异步调用或者分布式消息场景下，需要保障主事务和消息事务一致性的场景。
• 主业务成功，由业务产生的消息事务一定要成功调用，否则丢失该消息事务。

特点:

• 通过异步实现两个系统之间的解耦和并发的缓存
• 下游服务处理结果不影响上游调用方的事务。

适用场景:
适用于下游分支事务处理依赖于上游调用方事务结果的业务。下游分支事务无法回滚的业务场景

---

169 分布式事务模型对比?

序号	模型	优点	缺点
1	SAGA	业务实现简单	正交易完成后。业务马上落地，数据客户可见，不保证隔离性
2	TCC	由业务设计来保证隔离性，业务风险小	业务改造较大，接入成本高
3	消息事务	通过异步实现两个系统之间的解耦和并发的缓冲	支撑场景有限，只提供异步场景下的事务一致性能力，一般需要配合其他模型混合使用

---

170 分布式模型注意事项?

170::01 幂等性(重复提交)

概述:
一个分支事务重复调用多次只会提交一次，且重复调用产生的业务结构，应与第一次的结果相同。
出现原因:
1、第一段Try成功后，触发第二阶段Confirm操作。
2、分支事务服务完成Confirm请求后，返回的结果因为网络
原因造成丢包超时。
3、分布式事务识别识别，触发Confirm恢复，则产生重复
调用。

170::02 空回滚

概述:
一个分支事务服务，当第二阶段事务的Cancel操作，早于第一阶段Try操作时，应允许事务正常闭环。
出现原因:
1、调用第一阶段Try操作时，网络丢包超时。
2、分布式事务回滚，触发第二阶段事务的Cancel操作。
3、分布式事务未收到Try请求，而收到Cancel请求则出现空
回滚。

170::03 防悬挂

概述:
分布式事务服务回滚后，当第一阶段Try操作在网络卡顿后恢复调用时业务应用拒绝处理并抛弃异常。
出现原因:
1、调用第一阶段Try操作时，网络拥堵(未丢包)，服务超时。
2、分布式事务回滚，触发第二阶段的Cancel操作。
3、分布式事务执行了空回滚，整个分布式事务结束。
4、被拥堵的第一阶段Try请求到达分布式事务服务，则出现事务挂悬。

---

创作不易、点关注、不迷路

点击主页、更精彩 !!!