分布式

分布式

负载均衡算法

  • 轮询
  • 最小链接 请求数连接最少的服务器
  • 散列 需要处理状态要求用户链接到相同的服务器

熔断

  • 时间段内 失败率达到阈值 直接短路 请求打不到该服务

服务降级

  • 非核心业务降级运行

分布式消息队列之坑

  1. 消息重复消费

    • 数据库幂等校验
    • redis set校验
    • 生产者发送消息时增加一个全局id
  2. 生产者存放队列消息丢失

    • 事物机制 不推荐

    • confirm 机制

      写入mq队列则回传ack,如果没有写入队列则回调nack接口,重发消息 。 需要确保消费这消费消息幂等

  3. 消息队列丢失消息

  4. 消费者丢失消息

  5. 消息乱序

    • 将queue 拆分多个内存queue 消息1和消息2进入同一个queue
    • 每个消费这对应一个queue
  6. 消息积压

    • 快速解决消费者问题 将堆积消息转到临时queue 增加消费者消费这些消息
  7. 消息过期失效

    • 消息入库
    • 装备好批量重导程序
  8. 消息队列写满

    • 消息入库
    • 装备好批量重导程序

Redis丢失数据之坑

分布式事物

  1. 2PC 2阶段提交 DB层面支持

    prepate: 事物管理器发送指令 数据库操作记录redo undo,事物持续中

    commint: 上一次结束管理器未收到异常 发送commit指令 异常rollback; 结束

    缺点: 事物持续时间太长 数据库压力山大 性能影响

  2. TCC try confirm cancle 业务侵入太强 太复杂不考虑

    try: 测试 以及资源预留

    confirm: commit各个服务

    cancle: 补偿 回滚

  3. 可靠消息最终一致性 实时要求不高

    参与A 完成本地事物后发一条消息 参与B一定接受消息并处理成功 这样AB就能事物一致

    问题1: A本地事物与MQ 原子问题

    ​ begin transaction;

    ​ DB;

    ​ MQ;

    ​ Commit;

    ​ 发送mq失败 异常回滚 没问题

    ​ 发送mq超时 其实mq已经发送 则会不一致了

    问题2: B接收消息可靠性 mq ack机制保证

    问题3: 消息重复消费问题 消息幂等处理

    解决方法:

    解决问题1: 本地消息方案

    ​ begin transaction;

    ​ DB;

    ​ 本地mq日志;

    ​ Commit;

    定时任务扫描本地mq日志发送mq,收到成功后删除日志,失败则等待下一轮发送 解决A和MQ原子问题

    1. seata 分布式事物理解成 一个包含若干分支事物的全局事物

      TC: 事物协调器 独立部署

      TM: 事物管理器 嵌入应用 负责开启全局事物 向TC发送全局提交或回滚

      RM:控制分支事物 接收TC指令 本地事物提交或回滚

      执行流程:

      A的TM向TC申请全局事物 XID;

      A的RM向TC注册分支事物 纳入XID管控

      A执行分支事物

      B的RM向TC注册分支事物 纳入XID管控

      B执行分支事物 返回A

      A的TM向TC发起提交或回滚决议

      TC调度所有XID的分支事物提交或回滚

      seata与传统2pc差别?

      架构层面: 2pc: RM数据库自身支持才行 seata是以jar包支持

      性能方面: 2pc资源保持到phase2; seata资源保持到phase1,回滚反向命令

原文地址:https://www.cnblogs.com/albertXe/p/14842272.html