并发设计之A系统调用B系统

A-->B

    A在发送请求之前,用乐观锁,减少对B的重复调用,这样一定程度上是幂等性。

    比如A系统支付功能,要调用B系统进行支付操作,但是前端对"支付"按钮不进行控制,即用户会不断多次点击支付按钮,这时A系统会不断的发送请求给B系统(每点击一次就发送一次),如果B系统没有做幂等性设计,那就出问题了,如下图1所示:

                                                 图1  用户的多次请求在A系统中触发了很多个线程,A也对应的多次调用B

    我们是否可以在A系统就把相同的线程过滤掉,如下图2所示:

                             图2 用户的多次请求在A系统中触发了很多个线程,但是都被A过滤了,最后发到B的只有一个请求

    图2中的是怎么实现的呢,可以在A系统的数据库中创建一张表,由于A系统中支付,所以一定存在一个订单Id,我们就使用这个订单Id,加上版本号,来生成一条记录,这样多次支付同一个订单的请求,就只有一个线程会发送到B。用了数据库的乐观锁。

+----------+------------+------+-----+---------+----------------+
| Field    | Type       | Null | Key | Default | Extra          |
+----------+------------+------+-----+---------+----------------+
| id       | bigint(20) | NO   | PRI | NULL    | auto_increment |
| order_id | bigint(20) | YES  |     | NULL    |                |
| version  | int(11)    | YES  |     | 0       |                |
+----------+------------+------+-----+---------+----------------+
3 rows in set (0.00 sec)

    每个线程都执行update table set version=version+1 where order_id=#{orderId};这个就通过乐观锁,只有一个线程会成功修改这条记录,我们只让修改version成功的那个线程发送请求到B。

转载于:https://my.oschina.net/u/2518341/blog/1861720

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值