Please enable JavaScript.

Coggle requires JavaScript to display documents.

凤凰架构 - Coggle Diagram

- - - - 强一致性
        
        弱一致性
        
        最终一致性
    - - 每个服务之间通过消息队列流转消息
        
        定时任务从A中取状态为进行中的数据投到MQ
        
        B从MQ中获取消费消息，失败重试直到成功
        
        B成功后写消息入MQ，A收到消息修改状态
        最大努力交付一旦A执行成功就必须保证大家都成功
    - - 最大努力交付不适合流转环节中可以允许失败的情况。整个过程完全没有任何隔离性。
        
        TCC 适合强隔离的情况
      - 分为三个阶段
        
        Try 尝试执行，完成各个业务的可执行检查，并预留资源
        
        Commit 确认执行，不执行检查直接使用Try阶段预留资源提交，可能会重复执行需要保证幂等性
        
        Cancel 取消执行，释放try预留的资源
      - 具体流程 :star: :
      - TCC 的最主要限制是它的业务侵入性很强
        
        回退操作设计金额比如银行，作权限和数据结构就不可能再随心所欲的地自行定义，通常也就无法完成冻结款项、解冻、扣减这样的操作，
    - - 将整个分布式事务 T 分解为 n 个子事务。子事务是原子行为。分布式事务提交与连续提交子事务等价
      - 为每一个子事务设计对应的补偿动作，命名为 C1，C2，…，Ci，…，Cn。Ti与 Ci必须满足以下条件：
        
        Ti与 Ci都具备幂等性。
        
        Ti与 Ci满足交换律（Commutative），即先执行 Ti还是先执行 Ci，其效果都是一样的。
        
        Ci必须能成功提交，
      - 如果 T1到 Tn均成功提交，那事务顺利完成，否则，要采取以下两种恢复策略之一：
        
        正向恢复即最大努力交付
        
        反向恢复，通过Ci向前补偿每一个子事务
  - - - 保证原子性，和崩溃恢复，但是碰到大事务不能预写
    - - FORCE
        
        事务提交后强制写磁盘，还是写缓存，一般是NO FORCE 写缓存
      - STEAL
        
        是否允许事务未提交之前允许数据提交写入，mysql是允许通过redolog 和undolog 控制事务失败后回滚
  - - - 全局事务处理框架，有两个接口
        
        TransactionManager 事务管理接口
        
        XAResource 资源定义接口
    - - pre 参与者预写事务等待协调者发送commit
        
        commit 协调者发送commit 参与者提交日志
        
        如果失败了协调者发送abort 参与者回滚
      - 单点问题 如果协调者挂了，参与者会存在一直等待情况
        
        一致性问题如果协调者发送了一半commit挂了，会导致数据不一致
        
        性能问题，必须等待最慢的参与者提交成功
    - - can commit 询问是否准备好
        
        preCommit 如果准备好则预写事务
        
        doCommit 都写好了提交事务
      - 将准备阶段一分为二的理由是这个阶段是重负载的操作，事先询问是否准备好可以有效提高事务成功效率
        
        如果参与者没等到doCommit 默认会自动超时提交，避免一直等待的情况
        
        但是无法避免性能问题和一致性问题
- - - - 数据如何传输，如何通过网络传递数据
      - 方法如何确定，如何定位远程调用的方法
      - 数据怎么表示，即什么格式序列化
    - - CORBA
        
        SOAP/WebService
    - - 面向对象的
        
        RMI、.NET Remoting
      - 面向性能
        
        Thrift：序列化器，直接基于TCP传输避免应用层开销
        
        gRPC ：序列化器+http/2 支持多路复用和header压缩
      - 面向简化的
        
        JSON-RPC
  - - - 表征状态转移
        
        资源：即网页看的文章
        
        表征：以何种形式展现的文章，html/pdf...
        
        状态：需要看下一篇时，点击的超链接请求服务端数据，服务端根据当前是哪一篇返回下一篇
        
        转移：服务器把当前的文章变成下一篇
      - 其他
        
        统一接口： http协议中定义的统一接口如：PUT/GET...
        
        超文本驱动: 通过超文本向服务端请求数据
        
        自描述消息： 即Content-type: 表示用传输的数据使用哪一种数据格式
    - - 前后端分离
      - 无状态由客户端维护状态
      - 缓存：缓存请求，请求数据的过期时间等
      - 中间服务器可以通过负载均衡和共享缓存的机制提高系统的可扩展性例如CDN
      - 统一接口：接口重点是对资源操作，服务抽象成资源，比如：login/loginout 可使用put/delete 操作同一个SESSION资源
      - 按需代码
    - - REST 与 HTTP 完全绑定，不适合应用于要求高性能传输的场景中
      - REST 不利于事务支持
      - REST 没有传输可靠性支持
      - REST 缺乏对资源进行“部分”和“批量”的处理能力