消息队列的问题

[li24361]

比如说下订单，扣款，确认 都是用消息队列，顾客点击就会返回信息 扣除 5 块成功
如果后台处理扣款失败，顾客查询钱的时候，会是多少？
谢谢。

[ChanneW]

“确认” 具体是干了个什么

[li24361]

@ChanneW 额，就是付完款之后，消息队列返回一个消息接受成功，然后前台就显示付款完成了

[domty]

支付，扣款，回复结果放一条事务里执行，失败回滚
扣款失败等于支付失败，查钱的时候等于没被扣过款

[watzds]

@domty 执行完才回复？那不是有可能很慢？

[watzds]

上次去阿里，吃饭时同学有问阿里中间件负责人，怎么回答的忘记了。。。

[watzds]

看双 11 瓶颈就是支付，是不是支付并没有用消息队列？

[li24361]

@domty 这并没有异步解耦

[domty]

@li24361
什么意思？
下订单和支付不是两个流程吗 支付和扣款在服务器端看来应该是一个过程里的吧

用户点击发出支付请求 服务器端获得请求后 先效验 之后扣除用户款项 修改订单支付状态 返回请求结果

假使你把扣款 修改支付状态等分拆成单独的服务接口 也应该存在 rollback 或者 commit 的执行步骤吧，否则一旦在支付过程中出现错误已修改的数据就无法恢复了。
假使以上这些数据库操作都是异步的，粗糙点想，当一个请求新进入消息队列后，先检测消息队列的长度，一旦队列过长（比如大于某个设定的阈值），直接返回创建请求失败。给每个请求的执行时间设定一个超时时间，一旦超过超时时间直接中止执行就地回滚。

我只做过小型的订单支付模块，以上只是我的理解。

[watzds]

可见关键交易操作不是异步的。

"以双 11 为例，完成一次交易动作需要调用 200 多个应用系统同时完成，假设每个系统需要 10 毫秒才能返回，那么整条链路就需要 2 秒钟才能完成调用过程，再结合前端延迟，总时长或超 3 秒。数据显示，每增加 1 秒延迟，就会有流失 6%的用户。而异步化系统能有效改善该现象，只要保证三个应用的同步调用保证，其他非重要的系统可并行在后端异步完成，最后用户体感的延迟将从原有的 2 秒直接下降到 30ms ，用户流失率将大幅降低。"

http://www.csdn.net/article/a/2015-11-18/15831083

[watzds]

还有一条关于阿里每秒支付达到 8 万笔 /秒的文章

[li24361]

@watzds 恩，其实这三个还是同步的，所以说只要优化到这三个应用足够快就好了