分布式系统常见问题

分布式系统CAP与BASE理论：

      CAP 与 BASE 理论为分布式系统技术选型指导理论，引导项目正确选择技术方案

       CAP 理论：CAP 分别指 一致性(consistency)、可用性(可用性)、分区容错性(Partition tolerance)

        分区容错性（P）：在分布式系统中各个服务节点之间都使用网络通讯，一定存在网络故障或因某些原因导致一些服务不能互通的可能性，从而出现分布式系统网络分区问题，可是对客户而言他并不关心这个问题，该怎么使用系统就怎么使用，所以在出现分区问题时整个系统还是要对外提供服务，那么在分布式系统中分区容错性是必须要考虑的

         一致性（C）：同一个功能用户在访问分布式系统中任意一个节点获取到数据是一致

         可用性（A）：用户在访问集群节点中任意一个节点，必须得到响应而不是超时或拒绝

         结论：一般在分布式系统要根据业务需求做架构选择，如果业务需要保证数据强一致性选择CP 架构，如果需要保证服务访问高可用选择 AP 架构

         BASE 理论主要是三个核心思想  服务基本可用、数据软状态、数据最终一致性，是对 CAP 理论实现方案

         服务基本可用：在服务出现网络分区问题时保证核心功能可用性，允许丢失部分服务可用性

        数据软状态：允许某一段时间内出现数据不一致的情况

        数据最终一致性：在软状态之后要保证数据最终一致性

分布式系统事务处理：

      经常使用 Seate 工具处理分布式事务问题，Seate 在管理分布式事务时提供三个角色：

       TC  分布式事务协调者：维护全局事务与每个分支事务状态， 协调事务提交与回滚

       TM 分布式事务管理者：管理全局事务的范围，开启全局事务、提交与回滚全局事务

       RM 分支事务资源管理者：管理分支事务与事务协调者交互，注册分支事务、提交分支事务状态、提交与回滚分支事务

   Seate 提供三种分布式事务处理方案： XA 方式、AT 方式、TCC 方式(该方式需要手动编写代码控制有代码侵入，后面不介绍了)

     XA 方案执行流程：

        事务管理者(TM)开启全局事务，然后调用分支事务(RM)向分布式事务协调者(TC)注册分支事务信息，分支事务执行完 SQL 语句后不提交事务，先向事务协调者报告当前事务的状态，事务协调者检查所有分支事务状态，如果都没有问题事务协调者通知所有分支事务提交数据结束全局事务，如果有一个分支事务状态异常，事务协调者通知所有分支事务回滚数据， XA 方案要求数据强一致性是 CP 架构

    AT 方案执行流程：

      事务管理者(TM)开启全局事务，然后调用分支事务(RM)向分布式事务协调者(TC)注册分支事务信息，分支事务执行完 SQL 语句后提交事务同时生成一个undo log 日志存到 undo log 表中， 然后在向事务协调中报告当前事务状态，事务协调者检查所有分支事务状态，如果没有分支事务异常通知每个分支删除 undo log 日志，如果有分支事务异常通知每个分支事务根据 undo log 日志回滚数据，AT 方案允许数据出现软状态，但最终数据一致性属于 AP 架构

分布式接口幂等性：

   幂等：多次执行与一次执行任务的结果一致

     当前项目接口基本都是用 RESTFul 风格设计接口，相同参数 Get 请求基本是获取数据，多次与一次执行获取数据都是一致的，不存在幂等性问题，相同参数 Post 请求一般为修改或添加数据，如果是添加数据多次调用接口，会多次添加相同的数据与一次调用接口结果不一致，存在幂等性问题，如果是绝对值修改数据多次修改与一次修改结果一致，不存在幂等性问题，增量修改数据会出现幂等性问题 ，相同参数 Delete 请求多次与一次执行删除，数据都会被删除调结果一致，不会出现幂等性问题，综上一般只需要考虑 Post 接口是否做幂等性校验

     接口幂等性问题，常用解决方案分布式锁，根据 请求参数 + 用户token或者唯一ID 做缓存key ，第一个请求尝试加锁肯定加锁成功，可以去修改或者添加数据，后续的请求尝试获取锁信息不成功，也不需要阻塞或多次尝试获取锁信息，可以直接返回一个提示信息给前端，等第一个求情结束任务之后释放锁 

分布式任务调度：          

       分布式任务调度框架有多种，目前主流有 xxl-Job 、Elastic-Job ，这里简单介绍一下 xxl-Job 分布式任务调度平台，xxl-Job 提供多种任务调度策略，这里介绍常用的四种策略 轮询、随机、故障转移、分片广播 

        轮询：多个实例节点被循环调度执行任务

        随机：随机选着一个节点执行任务

        故障转移：在调度任务开始前先检查被调度的节点是否故障，如果正常调用任务执行器执行任务，不正常跳到下一个节点并检查是否正常，找到一个正常的节点执行任务

        分片广播：大量数据要定时处理时一个节点很难完成处理，xxl-Job 会将任务拆分多个片段，广播发送给所有节点，每个节点完成整个任务的一小段逻辑