[编织消息框架][消息处理模式]请求响应模式

消息处理常有以下几种方式 来源ZeroMq

1.请求响应模式 Request-reply

2.发布订阅模式 Publisher-Subscriber

3.推拉模式 Push-Pull

4.管道/异步模式 Pipeline

 

如果单单只用一种模式是无法满足业务上的千变万化,答案是采用混合方式

请求响应模式

发送端一请求 收接端一回答,一问一答的方式处理,一问一答的难点在于消息重发,消息丢失处理策略

而消息重发,消息丢失只能定制解决

发送消息失败几种常用处理策略

1.忽略消息

2.重发消息

3.持久化消息

消息去重策略 缓存队列记录处理结果

有个幂等的概念:一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同

去重变成维护管理队列,而队列控制策略又分为

1.LRU(最近最少使用) 先进先出(FIFO) 或后进后出(LILO)

2.Expires time 有效时间

3.永久有效

 

 

上图是没有任何容错处理

下图

1.每次请求时往监控队列注册

2.接收端首先去缓存队列查询结果

3.有结果就直接返回,否则正常处理逻辑再保存结果

4.当返回结果中途时可能出现发送端网络断开等因素导致响应失败

5.当请求超时,会发重试请求

6.正常返回结果,删除监控

可以看出发送端跟接收端都多了缓存队列,由于数据是无限增长的,至于采取控制策略跟业务有关

什么场景需要即时处理?又需要去重请求?

按数据操作划分

按数据类型划分,具体根据公司业务

可根据安全等级来决定是否加容错处理

如涉及金额交易或跨应用/跨平台处理的话就要加了

转载于:https://www.cnblogs.com/solq111/p/6560944.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值