分布式

作者: 与搬砖有关的日子 | 来源:发表于2020-03-28 22:27 被阅读0次

    1、分布式事务

    1.1 两阶段提交方案/XA方案

    两阶段提交

    Spring+JTA

    public void transferAccount() {
      UserTransaction userTx = null;
      Connection connA = null; Statement stmtA = null;
      Connection connB = null; Statement stmtB = null;
      try{
        // 获得 Transaction 管理对象
        userTx = (UserTransaction)getContext().lookup("java:comp/UserTransaction");
        connA = getDataSourceA().getConnection();// 从数据库 A 中取得数据库连接
        connB = getDataSourceB().getConnection();// 从数据库 B 中取得数据库连接
        userTx.begin(); // 启动事务
        stmtA = connA.createStatement();// 将 A 账户中的金额减少 500
        stmtA.execute("update t_account set amount = amount - 500 where account_id = 'A'");
        // 将 B 账户中的金额增加 500
        stmtB = connB.createStatement();
        stmtB.execute("update t_account set amount = amount + 500 where account_id = 'B'");
        userTx.commit();// 提交事务
        // 事务提交:转账的两步操作同时成功(数据库 A 和数据库 B 中的数据被同时更新)
      } catch(SQLException sqle){
        // 发生异常,回滚在本事务中的操纵
        userTx.rollback();// 事务回滚:数据库 A 和数据库 B 中的数据更新被同时撤销 
      } catch(Exception ne){ }
    }
    

    这种分布式事务方案,比较适合单块应用里,跨多个库的分布式事务。

    1.2 TCC 方案

    TCC 的全称是:Try、Confirm、Cancel。

    • Try 阶段:这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留。
    • Confirm 阶段:这个阶段说的是在各个服务中执行实际的操作。
    • Cancel 阶段:如果任何一个服务的业务方法执行出错,那么这里就需要进行补偿,就是执行已经执行成功的业务逻辑的回滚操作。(把那些执行成功的回滚)

    1.3 可靠消息最终一致性方案

    a. A 系统先发送一个 prepared 消息到 mq,如果这个 prepared 消息发送失败那么就直接取消操作别执行了;

    b. 如果这个消息发送成功过了,那么接着执行本地事务,如果成功就告诉 mq 发送确认消息,如果失败就告诉 mq 回滚消息;

    c. 如果发送了确认消息,那么此时 B 系统会接收到确认消息,然后执行本地的事务;

    d. mq 会自动定时轮询所有 prepared 消息回调你的接口,问你,这个消息是不是本地事务处理失败了,所有没发送确认的消息,是继续重试还是回滚?一般来说这里你就可以查下数据库看之前本地事务是否执行,如果回滚了,那么这里也回滚吧。这个就是避免可能本地事务执行成功了,而确认消息却发送失败了。

    e. 这个方案里,要是系统 B 的事务失败了咋办?重试咯,自动不断重试直到成功,如果实在是不行,要么就是针对重要的资金类业务进行回滚,比如 B 系统本地回滚后,想办法通知系统 A 也回滚;或者是发送报警由人工来手工回滚和补偿。

    2、如何设计一个高并发系统?

    • 系统拆分
    • 缓存
    • MQ
    • 分库分表
    • 读写分离
    • ElasticSearch

    3、MySQL主从复制

    主库将变更写入 binlog 日志,然后从库连接到主库之后,从库有一个 IO 线程,将主库的 binlog 日志拷贝到自己本地,写入一个 relay 中继日志中。接着从库中有一个 SQL 线程会从中继日志读取 binlog,然后执行 binlog 日志中的内容,也就是在自己本地再次执行一遍 SQL,这样就可以保证自己跟主库的数据是一样的。


    image.png

    注:主库上并行的操作,在从库上是穿行,所以从库的数据要慢一些。要尽量避免插入后立即查询的操作,如果必须的话可以选择直接连主库查询。

    主库宕机从库数据还没同步解决办法:

    • 半同步复制,也叫 semi-sync 复制,指的就是主库写入 binlog 日志之后,就会将强制此时立即将数据同步到从库,从库将日志写入自己本地的 relay log 之后,接着会返回一个 ack 给主库,主库接收到至少一个从库的 ack 之后才会认为写操作完成了。

    • 并行复制,指的是从库开启多个线程,并行读取 relay log 中不同库的日志,然后并行重放不同库的日志,这是库级别的并行。

    相关文章

      网友评论

          本文标题:分布式

          本文链接:https://www.haomeiwen.com/subject/igesuhtx.html