比如说下订单,扣款,确认 都是用消息队列,顾客点击就会返回信息 扣除 5 块成功
如果后台处理扣款失败,顾客查询钱的时候,会是多少?
谢谢。
1
ChanneW 2015-11-14 14:34:39 +08:00
“确认” 具体是干了个什么
|
3
domty 2015-11-14 14:55:05 +08:00
支付,扣款,回复结果放一条事务里执行,失败回滚
扣款失败等于支付失败,查钱的时候等于没被扣过款 |
5
watzds 2015-11-15 01:21:11 +08:00 via Android
上次去阿里,吃饭时同学有问阿里中间件负责人,怎么回答的忘记了。。。
|
6
watzds 2015-11-15 01:42:32 +08:00 via Android
看双 11 瓶颈就是支付,是不是支付并没有用消息队列?
|
8
domty 2015-11-15 15:15:02 +08:00
@li24361
什么意思? 下订单和支付不是两个流程吗 支付和扣款在服务器端看来应该是一个过程里的吧 用户点击发出支付请求 服务器端获得请求后 先效验 之后扣除用户款项 修改订单支付状态 返回请求结果 假使你把扣款 修改支付状态等分拆成单独的服务接口 也应该存在 rollback 或者 commit 的执行步骤吧,否则一旦在支付过程中出现错误已修改的数据就无法恢复了。 假使以上这些数据库操作都是异步的,粗糙点想,当一个请求新进入消息队列后,先检测消息队列的长度,一旦队列过长(比如大于某个设定的阈值),直接返回创建请求失败。给每个请求的执行时间设定一个超时时间,一旦超过超时时间直接中止执行就地回滚。 我只做过小型的订单支付模块,以上只是我的理解。 |
9
watzds 2015-11-18 21:12:23 +08:00
可见关键交易操作不是异步的。
"以双 11 为例,完成一次交易动作需要调用 200 多个应用系统同时完成,假设每个系统需要 10 毫秒才能返回,那么整条链路就需要 2 秒钟才能完成调用过程,再结合前端延迟,总时长或超 3 秒。数据显示,每增加 1 秒延迟,就会有流失 6%的用户。而异步化系统能有效改善该现象,只要保证三个应用的同步调用保证,其他非重要的系统可并行在后端异步完成,最后用户体感的延迟将从原有的 2 秒直接下降到 30ms ,用户流失率将大幅降低。" http://www.csdn.net/article/a/2015-11-18/15831083 |
10
watzds 2015-11-18 21:13:46 +08:00
还有一条关于阿里每秒支付达到 8 万笔 /秒的文章
|