分布式

         1..分布式幂如何设计

         在高并发得场景架构里，幂等性是必须保证的。比如支付功能，用户发起支付。如果后台没有做幂等校验，刚好手抖多点了几下，于是后台就可能多次受到同一个订单得请求，不做幂等就容易重复支付了，这样用户肯定是不能忍受的。

 解决方案：

1.查询和删除 不在幂等讨论范围，查询肯定没有幂等的说，删除：第一次删除成功后，后面来删除直接返回0，也是返回成功。

 2.建唯一索引：唯一索引或唯一组合索引来防止新增数据存在脏数据

 3.token机制：由于重复点击或网络重发，或者nginx重发等情况会导致数据被重复提交。前端在数据提交前要向后端申请token，token放到缓存，提交后后台校验token，同时删除token，生成新的token返回。redis要用删除操作来判断token，删除成功则校验通过，如果存在并发问题，不建议使用。

4.悲观锁         乐观锁   增加version字段

5.分布式锁      给key设置有效期   ，业务代码执行完释放

6.保底方案，先查询是否存在此单，不存在进行支付，存在就直接放回结果

          2. 简单一次完整的http请求的所经历步骤

1.DNS解析（通过访问的域名找出其TP地址，递归搜索）

2. HTTP请求，当输入一个请求时，建立一个Socket连接发起的TCP的3次握手

3.1  客户端向服务端发送请求命令  （一般  get或  post)

3.2   客户端发送请求头信息和数据

4.1服务器发送应答头信息

4.2服务器向客户端发送数据

5服务器关闭 TCP

6.客户端可以根据返回的html，CS，JS进行渲染   

        3.说说你对分布式事务的了解

分布式事务是企业集成中的一个技术难点，就是分布式架构都涉及的东西，特别是微服务架构中，几乎无法避免。  ACID   ，CAP，  BASE理论

       ACID  数据库事务得到四个基本要素

              原子性    一致性    隔离性       持久性

              CAP               一致性       高可用       分区容错性

              BASE理论       基本可用    最终一致性   软状态

        4.分布式事务解决方案

               1.两阶段提交  （2PC）

               2.三阶段提交（3pc）

                3 .补偿事务

                4.本地消息队列表（MQ）

               5.Sagas 事务模型（最终一致性）

        

5.什么是二阶段提交？

              二阶段提交（2PC）是分布式最强大的事务类型之一，两段提交就是分两个阶段提交：   第一阶段询问各个事务源是否准备好

              第二阶段才是真正将数据提交给事务数据源

              为了满足ACID，就要引入一个协调者。其他节点成为参与者。协调者负责调度者的行为，并决定这些参与者是否要把事务进行提交

              

阶段一：

          协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复

           各参与者执行事务操作，将undo和redo信息计入事务日志中

           如参与者执行成功，给协调者反馈yes，否则返回no

阶段二：

           如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚消息，否则发送提交消息。

  情况1：  当所有参与者均反馈yes，提交事务

  情况2:   当有一个参与者返回 no，回滚事务

问题     

         性能问题：  所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。

         可靠性问题：如果协调者存在单点故障，提供者将一直处于锁定状态

         数据一致性:  在阶段二中，如果出现协调者和参与者都挂了的情况，有可能数据不一致

         优点：尽量保证了数据的强一致，适合对数据强一致要求很高的领域

          缺点：实现复杂，牺牲了可用性，对性能影响较大，并不适合高并发高性能场景

 

三阶段提交  相对于二阶段提交，三阶段提交降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题

      缺点：  数据不一致问题依然存在   

 

    补偿事务：

                     TCC是服务化的二阶段编程模型，采用的补偿机制

                      TCC就是采用补偿机制，核心思想：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。

     它分为三个步骤：

                       Try阶段主要做业务系统做检测以及资源预留

                       Confirm阶段 主要是对业务系统确认提交，try阶段执行成功并开始执行Confirm阶段时， 默认Try成功，Confirm一定成功

                       Cancel阶段主要业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放

 

优点：   性能提升：  具体业务实现控制锁的粒度变小，不会锁定整个锁资源

              数据最终一致性：   基于Confirm和Cancel的幂等性，保证事务最终完成或取消保证数据一致性

               可靠性：  解决了协调者单点故障问题，又主业务方发起控制整个业务活动，业务管理器也编成多点，引入集群

缺点：  TCC的三个主要操作功能按照具体业务实现，业务耦合度较高   提高开发成本