（1）业务解耦
成功完结了一个异步解耦的进程。短信发送时只需确保放到音讯行列中就能够了，接着做后边的工作就行。一个业务只关怀实质的流程，需求依赖其他工作但是不那么重要的时分，有告诉即可，无需等候成果。每个成员不用受其他成员影响，能够更独立自主，只经过一个简略的容器来联系。
关于咱们的订单体系，订单终究付出成功之后或许需求给用户发送短信积分什么的，但其实这已经不是咱们体系的中心流程了。假如外部体系速度偏慢（比方短信网关速度不好），那么主流程的时刻会加长许多，用户必定不期望点击付出过好几分钟才看到成果。那么咱们只需求告诉短信体系“咱们付出成功了”，不必定非要等候它处理完结。
（2）终究一致性
主要是用记载和补偿的方法来处理；在做一切的不确定工作之前，先把工作记载下来，然后去做不确定的事，它的成果通常分为三种：成功，失利或许不确定；假如成功，咱们就能够把记载的东西清理掉，关于失利和不确定，咱们能够选用守时使命的方法把一切失利的工作从头做一遍直到成功停止。
确保了终究一致性，经过在行列中寄存使命确保它终究必定会履行。
终究一致性指的是两个体系的状况保持一致，要么都成功，要么都失利。当然有个时刻限制，理论上越快越好，但实际上在各种异常的情况下，或许会有必定推迟到达终究一致状况，但最后两个体系的状况是一样的。
业界有一些为“终究一致性”而生的音讯行列，如Notify（阿里）、QMQ（去哪儿）等，其设计初衷，便是为了交易体系中的高牢靠告诉。
以一个银行的转账进程来了解终究一致性，转账的需求很简略，假如A体系扣钱成功，则B体系加钱必定成功。反之则一起回滚，像什么都没发生一样。
然而，这个进程中存在许多或许的意外：
-
A扣钱成功，调用B加钱接口失利。
-
A扣钱成功，调用B加钱接口虽然成功，但获取终究成果时网络异常引起超时。
-
A扣钱成功，B加钱失利，A想回滚扣的钱，但A机器down机。
可见，想把这件看似简略的事真实做成，真的不那么容易。一切跨JVM的一致性问题，从技术的视点讲通用的解决方案是：
-
强一致性，分布式业务，但落地太难且本钱太高。
-
终究一致性，主要是用“记载”和“补偿”的方法。在做一切的不确定的工作之前，先把工作记载下来，然后去做不确定的工作，成果或许是：成功、失利或是不确定，“不确定”（例如超时等）能够等价为失利。成功就能够把记载的东西清理掉了，关于失利和不确定，能够依托守时使命等方法把一切失利的工作从头搞一遍，直到成功停止。
回到刚才的比方，体系在A扣钱成功的情况下，把要给B“告诉”这件事记载在库里（为了确保最高的牢靠性能够把告诉B体系加钱和扣钱成功这两件事保护在一个本地业务里），告诉成功则删除这条记载，告诉失利或不确定则依托守时使命补偿性地告诉咱们，直到咱们把状况更新成正确的停止。
音讯或许重复，留意音讯的重复和幂等。
（3）播送
假如没有音讯行列，每当一个新的业务接入时，咱们都需求连接一个新接口；有了音讯行列，咱们只需求关系音讯是否送到到音讯行列，新接入的接口订阅相关的音讯，自己去做处理就行了。
（4）错峰与流控
使用音讯行列，转储两个体系的通讯内容，并在下流体系有才能处理这些音讯的时分再处理这些音讯。试想上下流关于工作的处理才能是不同的。比方，Web前端每秒接受上千万的请求，并不是什么奇特的工作，只需求加多一点机器，再搭建一些LVS负载均衡设备和Nginx等即可。但数据库的处理才能却十分有限，即便运用SSD加分库分表，单机的处理才能仍然在万级。因为本钱的考虑，咱们不能奢求数据库的机器数量追上前端。
这种问题同样存在于体系和体系之间，如短信体系或许因为短板效应，速度卡在网关上（每秒几百次请求），跟前端的并发量不是一个数量级。但用户晚上个半分钟左右收到短信，一般是不会有太大问题的。假如没有音讯行列，两个体系之间经过洽谈、滑动窗口等杂乱的方案也不是说不能完结。但体系杂乱性指数级增加，势必在上游或许下流做存储，并且要处理守时、拥塞等一系列问题。并且每当有处理才能有距离的时分，都需求独自开发一套逻辑来保护这套逻辑。所以，使用中间体系转储两个体系的通讯内容，并在下流体系有才能处理这些音讯的时分，再处理这些音讯，是一套相对较通用的方法。
