MQ架构设计说明

15 篇文章 0 订阅
13 篇文章 0 订阅

MQ架构设计说明

中间件可以划分为以下几类

1、基于远程过程调用 (Remote Procedure Call, RPC) 的中间件,允许一个应用程序中的过程调用远程应用程序中的过程,就好像它们是本地调用一样。该中间件实现一个查找远程过程的链接机制并使调用方能够以透明方式使用这些过程。以前,这种类型的中间件处理基于过程的程序;现在,它还包括基于对象的组件。

2、基于对象请求代理 (Object Request Broker, ORB) 的中间件,使应用程序的对象能够在异类网络之间分布和共享。

3、面向消息的中间件或基于 MOM 的中间件,使分布式应用程序可以通过发送和接收消息来进行通信和交换数据。

所有这些模型都使一个软件组件可以通过网络影响另一个组件的行为。它们的区别在于基于 RPC 和 ORB 的中间件会创建紧密耦合组件系统,而基于 MOM 的系统允许组件进行更松散的耦合。在基于 RPC 或 ORB 的系统中,一个过程调用另一个过程时,必须等待调用的过程返回才能执行其他操作。正如前面所提到的,在这些模型中,中间件在一定程度上充当超级链接程序,在网络上查找被调用过程,并使用网络服务将函数或方法参数传递到被调用过程,然后返回查找结果。

一、基于分布式系统设计启示

对分布式系统设计的一些认识,借鉴 TCP/IP 设计思路。(数据包在网络传输上,不依赖中间路由等软硬件,线路选择等。超时重传、请求-应答、等等) 。那么,虽然不跨网络(机房),但在分布式系统设计上,有共同参照的地方。

面对MQ的一些设计,同样有一千个读者就有一千个哈姆雷特,但哈姆雷特不会变成李尔王。

一些较好的方式比如:(包括但不限于)

1、消息生命周期的设置

2、Fire and Forget (弱依赖、弱耦合)

3、幂等性、重试机制

关于幂等性与重试机制,在分布式系统设计中,非常通用与常见,特别是牵涉到数据一致性要求较高的场合。如果我们的业务是企业应用,那一些强依赖相关中间件,比如分布式事务等,但我们要经常性问一个问题,我们的系统是个什么样的系统?互联网应用。

二、ActiveMQ 设计

1+1+3 架构设计(2016-11-21 架构是演化,以此时间为据,不是起点,断然也不会是终点。)

一切设计决策,离不开两个东西,一个是目标,一个是场景。

Master/Slave 设计是任何有状态系统做HA时或是性能提升时,常用、常见的方案。比如:mysql,redis,kafka,mongodb、elasticsearch 等等等。(Oracle RAC共享存储。)

1+1+3 解释

1( 钱盒登录流) + 1 (开通宝登录流) + 3 (业务数据流)

1:单实例        3:HA集群

注意上述业务数据流,不含交易、支付流。


三、Kafka设计

目标:高吞吐

场景:丢失或是重复消费问题影响有限

四、RabbitMQ设计

目标:负载均衡集群第一、HA集群第二;消息路由第三。

场景:消息均衡分发

五、跨机房、网络调用说明

上述集群设置,均表示在同一个内部机房调用。如遇跨网络,机房调用。

需要另行设计,通过程序代理,(分发--MQ----代理)----->---传输---->( 代理----MQ----接收)

六、MQ重连机制

机制(failover:(tcp://IP地址:端口)?timeout=2000&maxReconnectDelay=5000)

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值