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