键盘不用可以过，房租不交就没地方住啦

感觉很多人没明白 op 说的意思，op 的意思其实就是一个典型的异步事务管控，主体就好比是 A 表，日志就好比是 B 表，而 A 表不在异步事务内，B 表在异步事务内，倘若 A 表出现异常了，这个时候的事务只能回滚 A ，无法回滚 B 。

而 op 需要的就是 A 回滚的时候，也把 B 回滚，以下说几种方法：

1：手动事务提交，主体完成后修改事务为待提交，B 完成后，整体提交事务，这种情况需要注意的是主体的执行时间和日志记录的执行时间不能相差太多，好比主体执行 1s ，日志执行 5s...

2：主体与日志进行某种程度的关联，主体失败后马上记录一条失败的消息到本地表，日志业务执行完成后，检测一下本地表的主体任务是否是完成状态，根据状态进行修正

3：异步消息回滚，类似于 MQ 之类的，这个说起来就比较复杂了，建议还是上面 2 种比较切合实际

@mxT52CRuqR6o5 没有下架啊，我刚看了还在的

先沉住气，干 1-2 个月看看领导的动向，也许是上面在考验你，希望你能干后端，也能干运维，也许后面招一个运维呢，那你岂不是就是管理了？ 干 1-2 个月也不会很累的吧。1-2 个月过后看看领导的意思是怎样的。

@xinxingi 你也要看看 op 会不会 spark ，搞这么个数据替换又重新学个新技能，而且这个新技能还不熟练

@DinnyXu 主要的瓶颈是这个单表有 2-3 亿的数据，查询更新个 100w 数据不是轻轻松松吗，而是如何在 2-3 亿的表中去更这 100w 条数据。

这里 op 还没有把表结构发出来，我们不知道这个表是否有对应的索引，如果没有索引，在单表 2-3 亿的数据量下去查询，效率极低，每次只能分页查询一定的数据量。

个人建议：op 第一步先针对改表的索引进行查询，使查询语句尽量走在索引上，然后分页查询一定的数据，并开启轮询进行更新，上传和更新不一定是一个步骤，可以分为多个步骤。

通过分页查询出这些数据，集体上传，并获取 url ，上传完毕后，再分页进行更新。

我感觉大多数人都没理解到 OP 的意思，查个数据，上传并更新 OP 不会写这些代码？

现在的市场要求更高了，何况你是应届，任何行业都是一样的，你不敲代码，你大学如果学的相关的专业多少有点吃亏吧，当然这也不是绝对的。你应该多了解当下的行情，尽可能的多提高自己，放低要求先去一些小公司积累一些经验。

@DinnyXu CR 是有的

有冒烟用例，等同于单元测试吧，但是等级比单元测试低一等。CR

@shuiixng 这个真的看运气的，我和我同事都被要求上传资料了，可能第一批申请的大部分都会核算吧

@Outshine 支付这一块，如果不想用户超时，第一个要规避的是唤起支付那用户输入密码可能会超时，还有一种是三方回调的时候可能会超时，因为根据你的说明是在回调后扣减库存，表示该笔订单已完成。回调这个地方你不能太依赖三方。特别是做这种限时的订单

@Outshine 你说的的订单过期用户操作很极限，我给你举例个场景，你看极限不。点击支付的时候，该笔订单需要在 5 秒内支付完成，5 秒内用户已经唤起支付了，但是输入密码最后一位的时候，已经超过 5 秒了，但是这个订单其实也属于超时了对不。

@Outshine 微信唤起支付那个页面，系统是不可控的，你可以去试试

@jaggle op 说了 2 种情况啊，我说的明显是解决第一种情况，回调超时的话处理更简单。

@jaggle 假设我订单有效时长设置 30 秒，回调回来的时候已经超过 30 秒了？ 那就计算总体库存数量呗。不可能所有人的回调都超时了吧，没超时的就把订单库存买完了啊。超时那个运气不好，自动退款就行了。

@crazychang 技术要求不高，学历到是卡的死死的

假如用户在超时前发起了支付但是在超时后才支付成功：
OP 的这个问题是：用户在下单前发起的支付，这个时候订单还未超时，常见的手机支付，微信或支付宝在唤起支付时，付钱的那一刻，也就是输入密码或者面容识别，OP 的系统是无法感知的。

举个例子：
- OP 的订单设置为 10 分钟内必须支付完成。
- 用户在 10 分钟内发起了支付，此时已经停留在输入密码的界面。
- 用户停留在输入密码的界面超过 10 分钟，并且成功付钱了，OP 需要控制的是这个过程

解决方案：在用户点击支付时(此次在输入密码的界面)，进行预下单，这个时候会生成一笔订单，我对接过的支付宝和微信中有一个订单过期参数，OP 需要将这个参数设置为你的订单超时时间，这样用户停留在输入密码页面超过 10 分钟后，付钱的时候三方系统会通过你的这个超时参数判断，是不是已经超时了，从而拒绝该笔订单。

楼上说随机的，我今天早上就接到了审核电话，然后就是我同事也接到了，这随机概率这么大吗？