《并发设计模式》第57章-半同步半异步模式-支付系统性能太差了

作者：冰河
星球：http://m6z.cn/6aeFbs
博客：https://binghe.site
文章汇总：https://binghe.site/md/all/all.html
源码获取地址：https://t.zsxq.com/0dhvFs5oR

沉淀，成长，突破，帮助他人，成就自我。

• 本章难度：★★☆☆☆
• 本章重点：了解半同步半异步模式的核心原理与使用场景，初步掌握半同步半异步模式的应用场景，能够初步结合自身项目实际场景思考如何将半同步半异步模式灵活应用到自身实际项目中。

大家好，我是冰河~~

头部电商平台中，往往都会有自己的支付系统，用户可以将自己的金额充值到支付系统中，在电商平台购物时，就可以直接使用支付系统中的余额进行支付。那支付系统的性能怎么会这么差呢？

一、故事背景

这天，小菜又接到一个新的需求，就是在用户下单并成功支付后，向用户的手机发送短信，告知用户支付系统余额的消费情况，以及当前的余额。小菜拿到需求后，心想：“怎么又给我分配这么简单的需求呢？”。小菜觉得这个需求很简单，从代码仓库将支付系统的代码拉取下来，二话没说，就在支付的逻辑里加了发短信的逻辑。随后，便自己测试好功能后，交付测试了。

没啥意外的话，还是出了意外，没一会儿，测试同事发来了测试报告——还是性能太差。小菜看到后，简直是有点无语了，“我就加了几行代码不至于性能这么差吧”。这几行代码怎么调优呢。没办法，以小菜当前的功力根本无法解决这个问题。于是，他决定还是求助于老王，在老王看过代码后，还是一如既往的为小菜耐心的分析问题，并且又告诉小菜这种场景非常适合使用半同步半异步模式。这下，小菜又知道了并发编程中的另一个设计模式，那就是半同步半异步模式。

二、案例分析

头部电商平台为了增强用户体验，往往都会开发一套单独的支付系统，用户向支付系统中充值后，后续在电商平台购物，就可以直接使用支付系统中，自己的账户余额进行付款，这样是非常方便的，如图57-1所示。

小菜所在的公司也是如此，为自主研发的社区电商系统单独开发了一套支付系统，并且小菜拿到的需求是用户下单并支付成功后，向用户的手机发送短信，告知用户支付系统余额的消费情况，以及当前的余额。按照找小菜的实现逻辑来看，流程如图57-2所示。

那性能差出在哪个环节呢？相信细心的小伙伴都能看出来，没错，就是出在了发短信的环节上，小菜使用的是同步的方法来调用短信服务发短信的接口，发送短信成功后，才返回结果给用户。短信最终是调用运营商接口进行发送，这种调用运营商远程发送短信的接口本身性能就不高，再加上网络的不稳定性，那性能就更差了。

三、案例重现

为了帮助大家更好的理解出现的性能问题，这里我们还是以模拟案例的形式为大家直观的呈现出代码逻辑。模拟案例的实现步骤如下所示。

（1）实现PayService接口

PayService接口是模拟案例中的支付接口，主要定义了一个pay()方法，传入支付的金额来模拟支付。

源码详见：io.binghe.concurrent.design.half.sync.async.wrong.PayService。

public interface PayService {
    void pay(BigDecimal money);
}

（2）实现PayServiceImpl类

PayServiceImpl类是PayService接口的实现类，主要实现了pay()方法，在pay()方法中，模拟实现了支付和发短信。

查看全文

加入冰河技术知识星球，解锁完整技术文章与完整代码