一个好的异步消息架构需要考虑哪些操作

            最近的消息异步架构用得蛮多的，开始这个架构的不成熟，功能不够强大可能导致后期架构不够用或出现一些问题。我小小总结一下现在的IM项目的异步消息架构。

            这几次没有注意到的架构是：

             一、消息并发处理，

                          1、比如基本上同时发出去多个不同类型的消息，（而不是单工的），然后服务端返回后，怎么去区分不同类型的消息的返回，然后回调。

                          2、如果同时发出去多个同一个类型的消息，然后服务器端返回后，如何区分这些消息的返回。

                   这两种的处理，我都是是用addListener维护回调队列，然后用hashcode去鉴别不同的listener，同时listener中有相应的功能序列号作为功能区分（相同的功能不同的实例是不同的Listener回调的），这样基本上这个处理就可以了。

           二、消息的重发，撤销的处理

                   比如：

                          1、在第一个此类型消息发出去还没返回时（时间很短），我又点了一下此类型消息发送（比如这次的重复登录点击，明显是为了同一功能的，但是像CX这种用户， 他就会多点击几下，哦然后挂掉了..)，这类在语义上实际上是一个功能的一个实例的情况，但是代码上产生了一个功能的两个实例，当然这一般都是在比较短的时间内出现的，这个怎么处理...

                         基本上，我觉得如果能有一直阻塞的机制，或者锁，比较好，实现的功能是这个消息没有返回时，不可以发送同样的功能的消息，再次发送也不响应。我觉得这种要求随便用一些代码逻辑都可以实现吧，但是如何弄得比较正统，可能是需要再多试一试想一想..

                         2、如果发出去了一个消息（命令），然后在回调还没出现之前，我有取消的需求了，这个怎么处理...

          三、最好这个消息机制是全双工的，比如这次，我开始只是涉及ACTIVITY给service发送消息，然后顶多是service返回给activty消息，但是我并未作service主动给activity,activity的响应。到后期显然是有这种需求的了，虽然这个功能最终通过广播得以弥补，但是显然这不是全面的功能机制了。

---------------

                 目前为止，就总结出了这么多要求，第一个注意系列即并发系列我基本上已经有机制来弄了，第二个系列，因为IM这个项目没有注意到，所在现在只在UI点击逻辑上控制了一下，不属于异步消息架构的范畴，这个还要想一想的好。

                 IM的架构采用的是和微信差不多，前台Activity,后台service的双进程架构，从而两个进程的异步通信成了架构的重点，我采用了Messager的方法，是跨进程比较简单的实现方法了，但是包装这个消息架构就是我的工作了。