【无中生有】---7---分布式消息队列

技术背景：

为何使用分布式消息队列：

参考：使用消息队列的 10 个理由

几种常见分布式消息队列各有所长，有的性能好，有的数据安全性好，有的社区支持好。

可是不管使用何种消息队列，将本身需求进行分析后抽象为业务接口对成品消息队列产品进行封装是一种较好的选择，既便于消息队列软件和本身的业务软件之间解耦合，也能进行多个不一样特色消息队列软件的同时集成，方便不一样业务场景调用所须要特色的队列软件。cap原则在此也会有必定的做用性，因此根据不一样业务场景选择对应特性的消息队列软件是一个很好的选择。而因为大部分的消息队列软件基于非windows平台，考虑非web形式的服务调用，java以及基于mono的c#是很好的封装语言载体。

软件对比：

4 款消息队列软件产品大比拼

业务场景应用分析：

从数据操做角度，若是消息对应的操做是数据读取，一般不存在数据序列化或者去重的问题。可是若是通知消息对应的操做是数据插入、修改或者删除三种操做，尤为是所操做的数据和通知消息同时到达。并且一般状况下，消息通知机制更可能是做用于数据更改操做的，尤为是数据插入的操做，在高并发状况下面临数据重复插入或数据排序的问题。所以在面临这两种数据操做时，即便分布式消息队列也存在一个瓶颈点-----就是对数据去重和排序的功能点。消息队列自己的对列排序因为前端用户业务服务器响应时长的问题，尤为是高并发状况下，消息队列排序不必定符合业务要求，因此按照业务需求封装数据去重和排序功能也有至关的必要性。因为这个功能不必定是必须的，更适用于适配器模式，并经过配置或者客户端选择是否调用业务层次的数据去重或者排序。

而这个功能单点特性变为必须的，而队列数据也必须可以持久化已支持在进行故障转移时不会发生丢失。

三重封装：业务客户端调用消息队列、后端服务调用消息队列、数据去重和排序功能

版权声明：本文为博主原创文章，未经博主容许不得转载。