想用就用何必纠结，日常公司一台 Mac 家里一台 Windows

@lopssh MQ 就是一个中转层，数据没法第一时间入库，只能通过 MQ 中转

@burymme11 我觉得你说的对，如果不实时读，干嘛要实时写，实时写一般是为了应付统计之类的，50-80w 的数据要进行实时写，对 MySQL 来说有很大的压力。

如果要实时读，可以根据读的业务来缓存数据。

3-5 年 只给 8k ，还有这么多人抢着去....服了。我觉得正儿八经干三年的，如果一直没跳槽薪资都不止 8k ，而且随便一跳怎么也是 13 起步吧，所以 8k 能招到的人 我认为不具备 3-5 年的工作能力。哈哈哈哈

@PainAndLove 这么吊，直接 16g 拉满了，我的 idea 是 4096

@PainAndLove 哥们儿你这个内存占用有点不正常了，可能跟你软件优化有关系，我用的 Jet 系列，idea + datagrip 最多也不超过 7 个 G ，你这个可以去官网贴一下内存分析，之前我贴了一个 idea 的，说是下个版本优化了。你问问 webstorm 有没有优化

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

感觉很多人没明白 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 秒了，但是这个订单其实也属于超时了对不。