Java架构师第十步——异步处理架构（读书笔记）

异步服务器框架设计思路

方法一：抽象状态。利用“状态 <=> 回调函数 映射表”实现各种状态和动作间的转换关系。这种方法并不好，原因在于全局状态过多，不利于抽象。

方法二：State模式。封装每一个网络调用成Context(维护每个调用自身的状态)，每个Context拥有如下统一动作(接口): 发包函数、回包处理函数、超时处理函数。通过组合Context实现对状态的管理。若N个调用不存在时序关系，则将每个调用Context组成一个更大的Context，该Context代表一个更大的状态。当所有的子Context调用完成后，则该Context完成，无状态转移。若N个调用存在时序关系，则按照调用时序，将各个Context组成一个状态转移链，依次处理各个Context并转移到下一个Context，当最后一个Context完成后，则整个请求完成。

 

异步处理的优缺点

优点：

1，前端进程（通常是Web页）响应更快，客户会认为这是一个运行速度较快的系统。

2，提供了用来提出负载平衡请求的简单方式。

3，提供了容错能力

4，异步处理无须额外的线程负担，并且使用回调的方式进行处理，在设计良好的情况下，处理函数可以不必使用共享变量（即使无法完全不用，最起码可以减少 共享变量的数量），减少了死锁的可能。

5，并发削峰。大型网站就免不了高并发的读写操作，很典型的一个例子就是电商中的秒杀，这种高并发的写操作，如果一下子都涌入到数据库里面去了，会导致数据库的压力非常大，从而导致客户端的访问延迟，就是不挂也容易造成数据库的死锁从而造成很多灵异事件，遇到这种一拥而入的情况，我们就必须进行线性化操作，在代码层面上我们可以用lock机制来串行化，在分布式中我们用“消息队列”来串行化，而且还可以通过逻辑操作来对消息队列进行动态的防洪，控洪。

缺点：

当然异步处理也并非完美无暇。编写异步处理的复杂程度较高，程序主要使用回调方式进行处理，与普通人的思维方式有些 初入，而且难以调试。

 

容错能力

异步体系结构可以让系统具有容错能力，这样，即使在进程中出现中断，整个系统也不会崩溃。对灵活的负载平衡提供支持的功能同时也就是对容错能力提供支持的功能。如果某个软件或硬件故障删除了某个进程步骤，请求执行该步骤的那些挂起请求就在队列中等候直至该服务被恢复。这对进程中先前的步骤并不产生什么实际的影响，尽管总体进程时间可能由于故障而延长。如果遵循了上一节关于负载平衡所讨论的技术，很可能仅仅减缓某一步骤的进程，但并不会停止。同样的功能也可以通过使用群集方式来提供；群集可以在不进行任何负载平衡工作的情况下提供故障转移能力。

尽管采用请求队列可以提供容错能力，但队列本身可能成为关键的故障点。用于确保这些队列可靠性的方法依赖于实施队列时所采用的特定技术，但一般都涉及故障转移群集以及将信息写入某个永久性的存储设备中，例如写入数据库中。

 

支持断续连接的系统

异步系统具有容错能力的行为也同样能够让异步系统在无需始终连接所有工作流组成部分的情况下正常运行。在异步系统中，工作流中的某个阶段可能由业务合作伙伴来进行处理。而系统与合作伙伴的系统之间的连接有可能是间断的，或者仅在需要时才连接。因此，异步功能可以将不可靠通信链接的影响降至最低程度，而且还可以实现更经济的系统操作，因为它将通信资源的占用减至最少。

在断续连接的系统中，某个合作伙伴可以连接工作流过程并将一个或多个请求置入工作流过程中排队，也可以接收某一具体步骤的处理结果并随后在自己的系统中进行处理。异步处理方式让系统之间相互独立；如果系统 A 与系统 B 能够在同一时刻相互连接，那很好；但如果不能在同一时刻连接，它们以后也能够进行通信而不会有任何麻烦，因为信息会被存储起来，直至与接收者接通。

 

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

一、消息并发处理

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

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

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

 

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

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

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

 

三、最好这个消息机制是全双工的

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

转载于:https://my.oschina.net/u/3448620/blog/1093759