技术背景：
为什么使用分布式消息队列：
几种常见分布式消息队列各有所长，有的性能好，有的数据安全性好，有的社区支持好。
但是无论使用何种消息队列，将自己需求进行分析后抽象为业务接口对成品消息队列产品进行封装是一种较好的选择，既便于消息队列软件和自己的业务软件之间解耦合，也能进行多个不同特点消息队列软件的同时集成，方便不同业务场景调用所需要特点的队列软件。cap原则在此也会有一定的作用性，所以根据不同业务场景选择对应特性的消息队列软件是一个很好的选择。而由于大部分的消息队列软件基于非windows平台，考虑非web形式的服务调用，java以及基于mono的c#是很好的封装语言载体。
软件对比：
业务场景应用分析：
从数据操作角度，如果消息对应的操作是数据读取，通常不存在数据序列化或者去重的问题。但是如果通知消息对应的操作是数据插入、修改或者删除三种操作，尤其是所操作的数据和通知消息同时到达。而且通常情况下，消息通知机制更多是作用于数据更改操作的，尤其是数据插入的操作，在高并发情况下面临数据重复插入或数据排序的问题。因此在面临这两种数据操作时，即使分布式消息队列也存在一个瓶颈点-----就是对数据去重和排序的功能点。消息队列本身的对列排序由于前端用户业务服务器响应时长的问题，尤其是高并发情况下，消息队列排序不一定符合业务要求，所以按照业务需求封装数据去重和排序功能也有相当的必要性。由于这个功能不一定是必须的，更适用于适配器模式，并通过配置或者客户端选择是否调用业务层次的数据去重或者排序。
而这个功能单点特性变为必须的，而队列数据也必须能够持久化已支持在进行故障转移时不会发生丢失。
三重封装：业务客户端调用消息队列、后端服务调用消息队列、数据去重和排序功能
版权声明：本文为博主原创文章，未经博主允许不得转载。