第四周周报：03-19~03-25

工作：思考感悟，学以致用

上周主要工作中是：熟悉之前的分账系统，同时做相应的优化。

有个优化的场景可以记录一下，情景是：分账系统首先把资金收入，然后判断支付操作成功了，就执行分账请求操作，将刚才那笔资金分出到不同商户：保险商户和第三方商户。

问题：之前代码开发，使用Spring Quartz定时器：隔一段时间比如5秒钟，去检查数据库有没有待分账的交易。这种用定时器驱动业务缺点是：

1>定时器时间间隔必须设置很短，保证待分账记录能迅速被处理，可是时间间隔很短会有很大性能消耗；

2>使用定时器轮询，即便再快，仍然不是第一时间发起分账请求；

3>定时器任务，使用了静态变量boolean isRun来保证并发。无法监控有多少个阻塞进程等待进入定时器任务。

优化：

方案1：使用“观察者模式”，也叫发布订阅模式。Spring中有对应的支持。后来否定了这种方案：当高并发情况，短时间内很多单子支付成功了，发布很多支付成功事件，我不清楚spring框架监听器是否都能监听到，能否保证已发布的事件不丢失。这种情况感觉需要结合消息管道：ActiveMQ等来使用，构建一个消息缓存队列。最主要原因是：自己的业务场景不太适合此模式，这种模式在多个(超过3个)业务模块都耦合“支付成功”发布事件时，具有最大优势。

方案2：使用Spring AOP，在接受到支付成功响应(同步或异步)后，对方法进行@AfterReturing进行后增强。

后来也否定了此方案。我本地写了代码测试了一下，接受同步支付成功响应后，使用aop后增强处理执行分账请求（测试让线程休眠一分钟来模拟处理时间）。控制器会在后增强中的分账请求完成后，才将支付成功响应，这样就将资金收入和资金分出，两个业务耦合在了一起。

AOP增强：可以使用于耗时时间短的，非http请求增强中，比如：记录下日志，查看方法执行时间等。

方案3：使用spring线程池来完成即时异步分账请求。在接受到支付成功响应(同步或异步)后，直接启动对应的分账请求线程，这些所有的分账异步线程统一由spring线程池管理、配置、监控。

精进：好好研究一下spring线程池的细节部分，异常情况下回怎么样？

学习：

上周在完成学习目标时，发现自己学习方向有些错误。看太多形而上学的东西，脱离了代码实战，总觉得自己没有得到任何东西。

学习方向调整：更多地关注实战知识：Linux的shell、spring in action等，因为这些知识你的精力投入，回报立竿见影，会增强自己的学习信心和热情！

生活：

定慧初修，空悲双运，中道力行。

总结：

上周学习了linux*章，

下周目标：

linux学习2章、spring in action3章，仔细地看。