最近某个系统的性能问题尤为突出，经常告警数据库表扫描、响应超时、CPU使用率过高等问题。
负责这个模块的兄弟来找我说了一下方案，一看就是技术思维导向。
简单来说，他把可能引发性能问题的各种技术手段做了一个罗列，然后逐类去梳理所有程序。
这种做法对吗？
技术上，对。
合适吗？
商业上，不合适。
因为现在不是按照技术维度，按部就班分析技术情况的时候。
有一句话还需要再强调一遍：技术只是我们的工具，我们交付的是商业能力。
对于一个系统来说，已经出现了问题，那么现在最重要的是要先给功能服务排优先级，按照重要性以及紧迫程度，应用多种技术手段进行提升。
尤其是要找到最能提升性能的关键措施，尽快提升性能，避免影响线上业务服务水平。
都不一定把所有的可提升点全部完善。
是以某个功能的维度，纵向梳理，而不是按照技术的维度横向梳理。
另外，异步一般情况下是提升OLTP类系统性能的不二法门。
这里简单记录一下，一个通用的异步处理的通用实现模式。
1
请求接收
这个接收比较简单，一般就是消费者发起请求，发过来单笔或者批量的处理指令，然后应用将这些指令入库，然后反馈给消费者指令接收成功或者失败状态信息。
注意，这里说的是：指令接收成功或者失败状态信息，而不是指令的业务执行结果。
业务处理结果应该是第二步获取。
2
后台处理
在指令落库之后，应该通过事件通知机制，或者后台线程扫描的机制，来去扫描指令库中的待执行任务。
这就涉及到任务竟抢、一致性保证、唯一执行保证等方面内容，在另外文章中可看到，本文不再赘述。
需要注意的是，如果后台系统也是异步任务，那么最终的结果就需要等待回调，或者有另外一个线程来进行查询结果丙更新。
如果是同步任务，一般需要注意业务执行的结果，一般有如下三种状态：成功、失败、异常。
成功最简单，失败这个状态我们一般指业务失败，具体的处理过程可见第四节。
异常，包含网络中断、响应超时等等方面内容，需要进行如下“异常重试”的步骤。
3
异常重试
一般情况下，异常业务都需要重试。
“重试”包含两种情况。
一种是对方已经成功处理完成业务，只不过链接中断，消费方没有及时获取响应，这种模式下只需要把结果查询回来重新更新业务结果，再继续后面流程即可。
另外一种是对方没有收到、处理异常，在保证业务幂等的情况下，可以由后台线程重新发起调用。
两种模式需要根据后台服务的机制进行相应处理。
4
失败补偿
这里的失败，指的是正常处理返回处理失败。
也需要根据业务模式，进行判断，是需要发起重试，或者这就是最终状态，需要通知上层调用方结果，并进行一系列的处理。
如果需要失败重试的，基本机制和上面一节一样。
5
业务告警
对于异步处理模式，有个经常忽略的问题，就是系统后台处理的不透明性。
由于是后台线程处理的，不直接给调用方反馈结果，我们很难知道其内部处理情况。
这个时候，就需要有完善的告警处理机制，防止业务异常后无人跟踪，一直等到客户投诉。
原文始发于微信公众号（架构突围）：异步处理功能的通用完备实现模式
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/170118.html
