一个购物车引发的支付血案

  • 内容
  • 评论
  • 相关

 

温馨提示:看完本大约需要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的原理。当然了,这些都是在理论上的理论,只有实践出真实。

 

对于缓存一致性问题,在上面的途中也有说到过相关细节,如果有兴趣的可以参考我的另一篇文章《缓存穿透、缓存并发、缓存失效、缓存最终一致性的思路变迁》

 

对于进阶,其实就是在很多细节方面做了很多的处理,安全性方面,并发方面等。

在与用户的交互过程中,一定需要做表单重复提交,防重复提交。

在与三方的交互过程中,一定需要做幂等。

为了提高系统的整体并发量,同步该异步,牺牲多点系统资源利用多线程换取时间与并发。

 

 

你的关注,是我的荣幸

 

 

 

我不会,但是我可以学!

 

喜欢 4

评论

0条评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Title - Artist
0:00