一.导言。

在通信系统或多系统协作软件系统中，网元或系统之间经常需要信息同步或信息查询系统之间的消息查询通常是一个很长的链接如果网络出现异常或者对方系统无法处理，就会在短时间内产生大量的查询消息重复查询失败，有大量以前失败的消息和新到达的查询消息积压重复查询和大量的消息处理使得系统性能急剧下降，甚至影响其他无关的服务因此，为了保证系统的稳定性和可靠性，处理异常情况是非常重要的特别适用于5 9对于所需的通信系统来说，一些异常情况往往会导致服务问题，需要足够的逻辑来保证系统在出现异常情况时仍然能够稳定可靠地处理业务

让我们沿着什么，怎么做，为什么做的思路，一步一步来讨论分析。

二，是什么导致网络信息波动。

如上图所示，我们可以看到大部分的业务开发都是三方系统之间服务应用的交互，所以很大程度上会有很多因素导致消息传输的波动上述业务的逻辑可以概括为两点一线

两点指的是起始端和目的端，一行指的是传输介质:

1)两点之间的服务中断或异常会导致无法到达的信息传输，直接导致信息丢失和业务失败。

2)传输介质的网络质量不好，比如丢包率太高，也会导致信息传输异常，业务失败。

基于以上两点，让我们对业务中网络信息波动的原因有一个大致的了解，然后我们会说明如何应对。

第三，如何降低信息传递失败的概率。

1)设计方案。

针对系统间信息同步的异常情况，基于消息队列Redis缓存，采用退避算法实现延迟消息消耗当网络波动或对方网元响应慢时，应根据退避算法对失败报文进行合理的退避这样既减少了消息的无效尝试，又减少了无效系统开销，保证了其他正常业务的顺利运行，保证了即使在网络波动或者对方系统回复延迟的异常情况下，也不会因为大量累积的查询消息而消耗过多的系统资源，保证了系统性能的稳定可靠

2)技术架构。

消息通过Kafka或其他消息中间件进入正常消费队列进行生产和消费，如果全部成功，则完成信息处理。

如果消息通过Kafka等消息中间件时出现异常，根据消息的失效情况和规避算法，计算消息的延迟时间在写入消息的延迟时间内，消息以某种格式(sortedSet)存储在Redis中

该消息是通过每秒一次的常规轮询通过reverseRangeByScore获得的根据消息的延迟时间判断消息是否到达消费时间，如果到达消费时间，将再次进入kafka中间件，进入重试消费队列进行生产消费如果未达到消耗时间，则继续排队，并优先考虑延迟时间已过期的其他消息这种机制减少了无效消息的重试次数，并确保队列中的其他消息能够得到及时处理

此外，在高并发的情况下，系统会持续生成大量的查询消息为了避免消息在队列中的累积，消息的重复消耗有次数限制根据测试，3次重试是有效的保证值如果3次重试后没有响应，消息将落入数据库，不再占用队列资源最后，调度任务将每小时轮询DB中累积的消息，轮询的消息将再次进入Kafka的重试队列进行消费

4.你为什么这样做，有什么好处。

从业务上讲:

从图1中，我们可以看到我们对接的业务都是相互分离的三方业务系统在网络信息波动的情况下，我们能从两点一线尽快解决的是属于自己业务服务端的，其他点和传输媒介需要花费大量的人力去沟通和解决我们需要尽可能将消费失败的信息传递给三方，但同时也要保证我们服务的信息不会积压，这样会导致我们系统的服务崩溃上述架构很好地解决了磁性问题

从高级角度来看，

该方案的消息中间件探索了一条在高并发场景下减少消息累积的有效途径在传统的设计模式中，系统之间的查询消息是等间隔查询的在网络稳定，低并发的情况下，该技术方案能够稳定但是，一旦网络发生波动或者并发量增加，等间隔的消息查询会导致大量的消息累积，从而影响系统的稳定性和可靠性在解决消息堆积的问题上，互联网上有很多解决方案，比如队列消息预警，相当于事后补救可是，该方案的消息中间件从消息的源头进行有效的算法设计，保证了从源头减少无效的重复消息该解决方案弥补了主流技术设计的不足，是一种先进的设计思路，填补了公司在处理高并发，高稳定性需求业务方面的技术空白

在兼容性方面，

该架构采用了多种技术的组合设计，并不局限于某一种特定的技术体系结构中可以使用流行的消息中间件，如:ActiveMQ，RabbitMQ，Kafka，RocketMQ和ZeroMQ该方案中消息中间件的架构设计具有很强的兼容性

在灵活性方面，

在这个框架下，消息延迟消费的级别可以根据自己项目的需要自由设置，消息延迟消费的次数也可以根据自己项目的需要自由设置，因此系统具有很强的灵活性。

在可重用性方面，

消息中间件采用了常用的消息队列Redis缓存，是一种可重用性很高的消息中间件，可以广泛应用于各种高并发，高可靠性要求的业务系统中。

性能方面，

Redis可以作为高性能的存储db，性能比MySQL好很多，而且支持持久性，稳定性好redis SortedSet队列自然支持以时间为条件进行排序，完美满足了我们选择推送的需求

记录的需要为保障消息均能得到及时处理，一次从队列中取出执行的数量可以设置得大一点或启动多个推送的服务假设一次从队列中取出执行的数量设置为:2000，推送的服务节点为:3个，定时任务执行间隔为:1秒，一分钟内可以实际推送的数量为:2000 * 60 * 3 = 360000这个数量已经可以满足绝大部分的需求

五，总结