消息传输
- notify
metaQ
Notify核心机制
- 集群化
- 发送方是一个集群
- 处理方也是一个集群
- 发送方和处理方没有对应关系,不需要知道消息的先后顺序—-顺序不care场景,需要应用程序做到幂等
- 保证消息不丢
- mysql双写
- 确保都城功才成功
- 交易日志对账
- 多重级别
- File
- Oracle
- MySql
- Mysql+复制
- 分布式事务(half消息)
- 等着应用写成功和应用一起提交
- 这个是保障应用事务和消息的一致性
- 用的地方不多,与支付宝交易模式类似
- 消息和事务本身实际是两阶段提交
- 异常情况是写成功,但反馈的消息是失败,此时需要做补偿
- 有个观察者,遇到异常时,通过他来进行补偿,,需要仔细看下两阶段事务
- 观察者判断异常时间是该提交还是回滚
- 要求随时能回到原状态,应用要记录操作,时间戳,这里要自己做,实现redo和undo
- 推模式和堆消息
- 推模式focus
- 什么时候消息算发送成功
- 等待接受者回掉,才能从notify中删除
- 不发送成功应该如何处理
- 会重复投递
- 什么时候消息算发送成功
- 堆积
- 为什么产生
- 业务bug导致
- 消费者太少
- 堆积后怎么办
- 有电话催你,问是否可以删除
- 想办法恢复处理能力
- 为什么产生
- 典型应用场景
- 200个下游系统
- 保障主流程提交后立刻返回成功
- 后续的200个下游系统异步完成他们要完成的功能
- 200个下游系统
- 有topic机制
- 一个消息发出去,notify负责发给订阅者
- 同一个topic不保证顺序,消息产生者控制topic生成的顺序
MetaQ核心机制
- 推模式focus
- 拉模式
- 保证消息不丢:
- 异步复制文件方式,类似mysql
时间: 2024-10-24 16:19:39