阿里分布式开放消息服务(ONS)原理与实践——笔记整理
1、MQ场景
1)订单异步解耦
2)解决分布式事务问题
3)应用于聊天平台
4)大规模机器的Cache同步
5)MySQL BinLog订阅数据分发
2、ONS应用场景
异步、解耦、最终一致、并行
3、设计假定
1)每台PC机器都可能down机不可服务
2)任意集群都可能处理能力不足
3)最坏情况一定会发生
4)内网环境需要低延迟来提供你最佳用户体验
4、关键设计
1)分布式集群化
a、理论上无限处理能力
b、集群级别高可用
2)强数据安全
a、单机磁盘级别冗余
b、单组多队列级别冗余
c、多组消息队列冗余
3)海量数据堆积
a、推模式:订阅者逻辑简单
b、拉模式:关注吞吐量,快
c、推拉结合:队列通知消费者,消费者去拉取(两次交互)
d、阿里采用长连接和轮询:轮询去拉,有则拉取,无则保持长连接等待,直到有消息
4)毫秒级投递延迟
5、关键概念
1)Topic:第一级消息类型,主标题
2)Tug:第二级消息类型,分标题
3)发送组:生产者所在集群
4)订阅组:消费者所在集群
5)RocketMQ不是一对一,也不是一对多,是随机一对一
6)网络三种状态:成功、失败、没响应
6、消息乱序问题:Message服务器不处理,恰好不需要解决
1)发送时对消息进行编号
2)一组消息只有唯一一个订阅者处理(sharding)
3)一组消息的数量(即“锁的颗粒度”)越小越好
7、消息重复问题
1)重复原因:网络不可达
2)幂等:某个操作无论重复多少次,结果都一样(不需要解决,性能极高)
3)非幂等,去重
a、保证有个唯一ID标记每一条消息;
b、保证消息处理成功与去重表日志同时出现
4)去重代价:额外的tps和qps
8、事务的分布式优化
1)事务1-->MQ Server-->事务2
2)同时成功,同时失败:
a、发消息;
b、执行事务1;
c、确认消息发送;
d、投递消息到消费者
3)处理超时问题(重复):事务2增加消息确认表(去重表)
4)消息失败(事务2失败):记录后人工处理(小概率事件)
---------------------
作者:猴子哥哥1024
来源:CSDN
原文:https://blog.csdn.net/qq_21033663/article/details/73379103
版权声明:本文为博主原创文章,转载请附上博文链接!
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· 分享4款.NET开源、免费、实用的商城系统
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
· 上周热点回顾(2.24-3.2)