感觉具体得看什么属性的数据。
1.如果是共享数据，如果不锁住读取的表内容，就会有并发导致的数据不正确的风险。可以在数据库中加一个乐观锁/悲观锁。
2.不是共享数据，串行化就 ok

感谢大家，我觉得我又行了。靠谱就是一个很难得的品质了了

生活没有起伏？上杠杆梭哈大 A

先去呆三天两天的看看情况，找个合适的机会问问同事。该提桶提桶~

国内计算机非全不好搞。同一所学校，参加研究生入学考试的门槛比全日制略低或持平。有的学校过线就要，有的学校会刷人，刷人的依据主要是看复试的表现、有无编程基础、能否毕业。。。入学之后基本放养，但同时还要完成毕业论文毕业，这就很难了，挺多在这个点上放弃的。最后一点，现在非全不太受待见，但比之前几年情况好一些了。

@trzzzz thanks~

@trzzzz hi ，我还是没 get 到弱网环境下的问题。实际在上传时后端会维护一个 uploadId 下的已上传分片数组，客户端（我这边是 windows 客户端）会根据这个数组尝试重试机制。所以无论网络环境如何、是否是并发上传，只要客户端能正确处理这个数组就可以。

我的做法是：
1.前端做好分片，为每一个分片生成序号，统计分片的个数。将这些数据传给后端，后端把这些数据记录下来，为这个文件生成一个全局 id ，返回给前端。
2.前端每次上传分片会连带文件 id+分片 id 一起传过来。分片文件会被上传到一个临时目录。每上传完成一个分片，后端会记录下来分片 id （分片序号）。如果是并发上传的话，要注意已上传分片 id 集合会有线程安全问题，不然会出现某个分片已上传但没记录的问题。
3.后端返回已上传分片集合。同时会有一个异步线程判断该文件 id 下的分片是否全都上传完毕。如果全都上传完成，调用文件系统 SDK 的合并文件方法（我用的是 minio ），合并完成之后，删除临时文件目录的分片。
4.与此同时，前端全部分片上传完成之后，循环调用获取文件合并状态接口。
完成~

就在昨晚，舍友还是拿着电池放在屋里充电。。。道理她都懂，另一个舍友和她说这件事的危险程度她反而说很少在屋里充。哎，三十多岁的人了还这么邋遢。

我深刻的体会到有些人不捡点东西就跟丢了东西一样

抱犊村旅店里厨师炒的包菜是吃过最好吃的

@Vendettar 考研专业代码哦

目前这种行情如果毕业以 非全本+一般的技术水平 这种条件大概率要寄很久，现在不少本科被毕业都难找。如果没有其他赚钱的路子、目前公司还算稳定只降薪不裁员的话，建议还是考个 0854 非全研究生。与那些本科就很棒的人相比已经处于劣势，只能是和过去的自己比。即使是现在非全不太受一些人的待见，那也是双证，比起非全本科或者大专好太多了。同时在职备考的过程也是磨练自己毅力的过程，而且一旦考上就相当于搞技术+搞学历，一举两得。

彩礼是什么？回 28w 彩礼也可以接受。要是回三床被子加头盔 年轻的话玩玩得了。

和尚太多，要求越来越变态了。。

每次都能候补成功，它总是在出发前一天的下午到晚上候补成功，这一点比较坑爹。

之前从事过短信发送平台的项目，每天的发送量一个亿到两个亿之间，属于数据密集型应用。qps 在某个时间段内也不算低，勉强算高并发了。在这个项目中除了大量使用多线程这点需要格外注意以外，其实感觉写起来和平时项目一样，剩下的就是堆配置。比如，分布式集群部署、分库分表、负载均衡使用硬件级别的、服务器加配置、使用缓存，其中 redis 集群单实例的内存就几百个 g 。 不过代码里还是理解了不少多线程的知识。

我也是这种情况，上班不开。搞个车就是为了周末出去玩或者回家用，不知道可操作性强不强。