消息传输

• notify

• metaQ

  Notify核心机制

• 集群化

  • 发送方是一个集群
  • 处理方也是一个集群
  • 发送方和处理方没有对应关系，不需要知道消息的先后顺序—-顺序不care场景，需要应用程序做到幂等
• 保证消息不丢
  • mysql双写
  • 确保都城功才成功
  • 交易日志对账
  • 多重级别
    • File
    • Oracle
    • MySql
    • Mysql+复制
• 分布式事务（half消息）
  • 等着应用写成功和应用一起提交
  • 这个是保障应用事务和消息的一致性
  • 用的地方不多，与支付宝交易模式类似
  • 消息和事务本身实际是两阶段提交
    • 异常情况是写成功，但反馈的消息是失败，此时需要做补偿
    • 有个观察者，遇到异常时，通过他来进行补偿，，需要仔细看下两阶段事务
      • 观察者判断异常时间是该提交还是回滚
    • 要求随时能回到原状态，应用要记录操作，时间戳，这里要自己做，实现redo和undo

• 推模式和堆消息

  • 推模式focus
    • 什么时候消息算发送成功
      • 等待接受者回掉，才能从notify中删除
    • 不发送成功应该如何处理
      • 会重复投递
  • 堆积
    • 为什么产生
      • 业务bug导致
      • 消费者太少
    • 堆积后怎么办
      • 有电话催你，问是否可以删除
      • 想办法恢复处理能力
  • 典型应用场景
    • 200个下游系统
      • 保障主流程提交后立刻返回成功
      • 后续的200个下游系统异步完成他们要完成的功能
  • 有topic机制
    • 一个消息发出去，notify负责发给订阅者
    • 同一个topic不保证顺序，消息产生者控制topic生成的顺序

      MetaQ核心机制

• 拉模式

• 保证消息不丢：
  • 异步复制文件方式，类似mysql