一个购物车引发的支付血案
温馨提示:看完本大约需要3.2min~
前言:以下都是个人对于购物车与支付实现的一些看法,如果有不对的地方欢迎指点,可在文末留言区进行评论留言,或在博客最上方留言板留言,或直接与博主进行交流沟通。
一、序
对于购物车与支付的实现,一般分为两种:
一种是前端实现,比如apple.com就是利用前端实现购物车,当我们将商品加入到购物车,我们可直接进行加入到购物车,即使我们没有登陆,前端会在会话保存一份临时的购物车数据,在进行付款的时候,提交到后台。
一种是后端实现,这也是我们一般购物网站的实现方式,比如京东淘宝等,接下来将会细说这部分的具体实现,以及进阶。
二、前端实现
(点击查看大图)
说明:
我们的购物车是由于前端实现的,此时,我们在后端的设计可以有购物车模块,也可无购物车模块,当然设计购物车是比较合理的一种选择。
前端将商品添加到购物车,前端会将商品放到会话中,将其成为临时购物车,当你关闭网页或者退出app就会丢失。
当你提交订单到后台(1),后端生成订单提交到第三方,返回支付页面url到前端,让用户与三方进行直接交互付款,当用户未进行付款,三方会主动回调服务端(2),告知订单超时失效,当用户进行付款,支付成功后用户的页面依然停留在第三方支付页面上,几秒钟后跳转到服务端的支付成功页面。当用户支付成功的同时,第三方服务商会将该订单的支付结果告知于服务端(3),服务端更新订单状态,当用户访问到服务端的订单状态时,即为查询服务端的订单状态,此时为支付成功。
以上,便是一个简单的前端实现购物车与订单支付的全流程,当然,在以上的说明过程中,暂时只考虑完全成功的结果,并未考虑过多异常的情况,比如,在(1)处,我们可能需要做一些表单重复提交,或者做一个订单队列等;在(2)(3)处,我们与第三方服务商之间的交互,需要做幂等,需要做重试,我们需要考虑到网络异常,返回结果失败,但真实结果成功的情况等等。
三、后端实现
(点击查看大图)
说明:
可能在后端的实现过程中,与前端实现并无太大的区别,只是将购物车的模块提交到了后端实现,而在某些操作过程中添加事务的控制等。
具体细节可以参考《前端实现》
四、后端实现-进阶
(点击查看大图)
说明:
该图为后端实现的进阶,与后端实现,主要增加了许多的异常处理,缓存处理,提高系统的安全性,健壮性,稳定性等。
我们在对购物车的CRUD,我们在这里配上了Cache,利用缓存,提高这方面的并发,比如用Mybatis 的二级缓存,或者利用Redis自主实现FIFO、LRU等缓存策略,对其提高并发性。
对于缓存我为什么选择Redis,而不选择Memcache,这里可以参考我对于Redis学习的一篇文章《深入浅出Redis笔记》,再说了我们在这里我们可以做Redis集群,做主从链,对于稳定性,我们可以做做哨兵,有可能你还会问,再怎么搞,依然是一主多从,从根本无法解决写,或者也因为延迟原因缓存一致性问题,无法满足某些特定场景的强一致性要求,但是我们可以做路由,我们对key做路由,对于不同的key,打到不同的Reids集群,从而降低Redis服务的压力,这也是使用水瓶扩展的方式进行扩容吧,这也是codis的原理。当然了,这些都是在理论上的理论,只有实践出真实。
对于缓存一致性问题,在上面的途中也有说到过相关细节,如果有兴趣的可以参考我的另一篇文章《缓存穿透、缓存并发、缓存失效、缓存最终一致性的思路变迁》。
对于进阶,其实就是在很多细节方面做了很多的处理,安全性方面,并发方面等。
在与用户的交互过程中,一定需要做表单重复提交,防重复提交。
在与三方的交互过程中,一定需要做幂等。
为了提高系统的整体并发量,同步该异步,牺牲多点系统资源利用多线程换取时间与并发。
你的关注,是我的荣幸
我不会,但是我可以学!
发表评论