首页 > 其他 > 详细

阿里架构师介绍消息传递机制

时间:2014-05-22 02:27:21      阅读:454      评论:0      收藏:0      [点我收藏+]

消息传输

  • notify
  • metaQ

    Notify核心机制

  • 集群化

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

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

        MetaQ核心机制

  • 拉模式

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

阿里架构师介绍消息传递机制,布布扣,bubuko.com

阿里架构师介绍消息传递机制

原文:http://www.cnblogs.com/fallingriver/p/3731079.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!