1. 分布式介绍：
分布式分为分布式缓存（Redis）、分布式锁（Redis 或 Zookeeper）、分布式服务（Dubbo 或 SpringCloud）、分布式服务协调（Zookeeper）、分布式消息队列（Kafka 、RabbitMq）、分布式 Session 、分布式事务、分布式搜索（Elasticsearch）等。不可能所有分布式内容都熟悉，一定要在某个领域有所专长。
2.分布式理论
分布式理论分为CAP，Base理论。
一.CAP理论
- 任何分布式系统都无法同时满足一致性(consistency),可用性(availibity),分区容错性(partition tolerance)这三项,最多只可同时满足其中的两项.
- zookeeper和Eureka做注册中心对比：
2.1.zookeeper做注册中心是满足CP，
2.2.Eurka是满足AP，
2.3.nacos同时满足AP和CP
二.Base理论
Basically Available(基本可用)
假设系统，出现了不可预知的故障，但还是能用, 可能会有性能或者功能上的影响，比如RT是 10ms，变成50ms
Soft state（软状态）
允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时
Eventually consistent（最终一致性）
系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值
- 关于数据一致性
强一致：操作后的能立马一致且可以访问
弱一致：容忍部分或者全部访问不到
最终一致：弱一致性经过多一段时间后，都一致且正常
3.理解分布式事务？分布式事务的协议有哪些？
分布式事务是指会涉及到操作多个数据库的事务。目的是为了保证分布式系统中的数据一致性。分布式事务类型：二阶段提交 2PC ，三阶段提交 3PC。
2PC ：第一阶段：准备阶段（投票阶段）和第二阶段：提交阶段（执行阶段）。
3PC ：三个阶段：CanCommit 、PreCommit 、DoCommit。
4.分布式事务的解决方案有哪些？
分布式事务解决方案： TCC 、2PC和3PC 、事务消息。
5.TCC柔性事务的解决方案
什么是TCC柔性事务
- 刚性事务：遵循ACID
- 柔性事务：遵循BASE理论
- TCC:
- 将事务提交分为
- Try：完成所有业务检查( 一致性 ) ，预留必须业务资源( 准隔离性 )
- Confirm ：对业务系统做确认提交，默认 Confirm阶段不会出错的 即只要Try成功，Confirm一定成功
- Cancel : 业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放, 进行补偿性
- TCC 事务和 2PC 的类似，Try为第一阶段，Confirm - Cancel为第二阶段，它对事务的提交/回滚是通过执行一段 confirm/cancel 业务逻辑来实现，并且也并没有全局事务来把控整个事务逻辑
- TCC交互图
- 将事务提交分为
- 优点：
- 它把事务运行过程分成 Try、Confirm/Cancel 两个阶段
- 每个阶段由业务代码控制，这样事务的锁力度可以完全自由控制
- 不存在资源阻塞的问题，每个方法都直接进行事务的提交
- 缺点
- 在业务层编写代码实现的两阶段提交，原本一个方法，现在却需要三个方法来支持
- 对业务的侵入性很强，不能很好的复用
- 注意：使用TCC时要注意Try - Confirm - Cancel 3个操作的幂等控制，由于网络原因或者重试操作都有可能导致这几个操作的重复执行
6.事务管理器宕掉了，怎么办
做冗余，设置多个事务管理器，一个宕掉了，其他的还可以用。
7.怎么保证分布式系统的幂等性
状态机制。版本号机制。
1.对于每个请求必须有一个唯一的标志，比如订单支付请求，必须要包含订单的id，一个id只能支付一次。
2.每次处理完请求之后，必须要有一个记录标识这个请求已经处理过了，比如最常见的是在mysql中记录一个状态，比如支付前先插入一条这个订单的支付流水，而且支付流水采用唯一约束，只有插入成功才进行支付。
3.每次接受到请求之后需要先判断之前是否已经处理过，比如一条订单已经支付了，那么就一定会有支付流水，如果存在就表示已经支付过了。
8.消息中间件如何解决消息丢失问题
-
事务消息
- 消息队列提供类似Open XA的分布式事务功能，通过消息队列事务消息能达到分布式事务的最终一致
-
半事务消息
- 暂不能投递的消息，发送方已经成功地将消息发送到了消息队列服务端，但是服务端未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半事务消息。
-
消息回查
- 由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，消息队列服务端通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（Commit或是Rollback），该询问过程即消息回查
-
交互图（来源rocketmq官方文档）
-
目前较为主流的MQ，比如ActiveMQ、RabbitMQ、Kafka、RocketMQ等，只有RocketMQ支持事务消息
- 如果其他队列需要事务消息，可以开发个消息服务，自行实现半消息和回查功能
-
好处
- 事务消息不仅可以实现应用之间的解耦，又能保证数据的最终一致性
- 同时将传统的大事务可以被拆分为小事务，能提升效率
- 不会因为某一个关联应用的不可用导致整体回滚，从而最大限度保证核心系统的可用性
-
缺点
- 不能实时保证数据一致性
- 极端情况下需要人工补偿，比如 假如生产者成功处理本地业务，消费者始终消费不成功
9.常见分布式事务解决方案概览
-
常见分布式事务解决方案
2PC 和 3PC
两阶段提交, 基于XA协议- TCC
Try、Confirm、Cancel - 事务消息
- 最大努力通知型
- TCC
-
分布式事务分类
- 刚性事务：遵循ACID
- 柔性事务：遵循BASE理论
-
分布式事务框架
- TX-LCN：支持2PC、TCC等多种模式
- https://github.com/codingapi/tx-lcn
- 更新慢（个人感觉处于停滞状态）
- Seata：支持 AT、TCC、SAGA 和 XA 多种模式
- https://github.com/seata/seata
- 背靠阿里，专门团队推广
- 阿里云商业化产品GTS
- RocketMq：自带事务消息解决分布式事务
- TX-LCN：支持2PC、TCC等多种模式
10.分布式事务常见核心概念
-
前置知识
- X/OpenDTP 事务模型
是X/Open 这个组织定义的一套分布式事务的标准，也就是定义了规范和 API 接口，由各个厂商进行具体的实现 DTP 是分布式事物处理(Distributed Transaction Processing)的简称- XA协议
XA是由X/Open组织提出的分布式事务规范。 XA规范主要定义了(全局)事务管理器(TM)和(局 部)资源管理器(RM)之间的接口 主流的数据库产品都实现了XA接口，是一个双向的系统接口，在事务管理器以及多个资源管理器之间作为通信桥梁- JTA
Java Transaction API,java根据XA规范提供的事务处理标准- AP
application, 应用程序也就是业务层，微服务等- RM
Resource Manager，资源管理器。一般是数据库，也可以是其他资源管理器，比如消息队列，文件系统- TM
Transaction Manager ，事务管理器、事务协调者，负责接收来自用户程序（AP）发起的 XA 事务指令，并调度和协调参与事务的所有 RM（数据库），确保事务正确完成 -
事务模型
在分布式系统中，每一个机器节点能够明确知道自己在进行事务操作过程中的 结果是成功还是失败，但无法直接获取到其他分布式节点的操作结果
当一个事务操作跨越多个分布式节点的时候，为了保持事务处理的 ACID 特性，
需要引入一个“协调者”（TM）来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点被称为 AP。
TM 负责调度 AP 的行为，并最终决定这些 AP 是否要把事务真正进行提交到（RM）
11.如何保证消息队列的高可用
可用采用集群来保证高可用,以RabbitMQ为例,推荐采用镜像集群,普通集群如果磁盘节点挂了就GG了,还是无法保证高可用,镜像集群的配置要用到HAProxy,需要在后台管理页面中设置策略,将ha-mode设置为all,表明每个节点上都存放镜像…限于篇幅,具体的集群配置我后面会专门写一篇博客总结.
12.项目中为什么引入消息队列
解耦，异步，削峰
- 解耦：
- 异步
- 削峰
最低0.47元/天 解锁文章
215
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
