分布式

分布式

负载均衡算法

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

熔断

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

服务降级

• 非核心业务降级运行

分布式消息队列之坑

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原子问题

   4. 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,回滚反向命令