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

@trzzzz thanks~

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

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

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

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

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

@Vendettar 考研专业代码哦

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

从今年五月中旬开始疼，期间去小门头搞了几次盲人按摩，缓解两天又开始不舒服。上周三去积水潭医院挂号看病，医生考虑说是肌肉疲劳，让平时多锻炼，开了四盒膏药，检查啥的都没有开。现在感觉好一些了，但是没有好利索。打算膏药贴完没好利索就去拍片，肌肉原因的话直接中医理疗搞起。

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

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

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

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

展示最新的上报数据需要聚合之类（ sum, count,group by ...）的操作吗？如果是，感觉 Doris 可以。

@lemonteacode 牛个毛啊，应该还有别的效率好的方法



- 感觉和我的需求有些类似。只不过在我这个需求中没有固定的顶级节点，每一个节点都有可能是顶级节点，而且层级是不确定的。此外，还有一种特性，顶级节点的下的某一层级的的节点很有可能又链接回了顶级节点（或者它的上层节点），例如：1_1->2_1->3_1->1_1 。
- 考察了两种解决方法。一种是把所有节点扁平化放在 mysql 中，实时查询组装成树形结构返回。另一种是使用图数据库存储。考虑到由于查询页面是在管理端，且未来数据量并不会多，并发量也不会大，最后决定使用第一种扁平化存储的方式。
- 查询方法。例如，某一个节点作为顶级节点，它的直接子节点有三个，那就开三个子线程，采用递归的方法让当前子节点作为中心节点查询，一直查询到最后一级。等到所有的线程查询完成，陆续通知主线程，最后返回，当某个线程超出时间限制没有返回时，直接丢弃。其中，要注意环的问题，判断出有环直接返回，不然递归无法跳出，直接内存溢出；还有之前通过节点查询出的数据在这个请求中要缓存一下，避免重复请求数据库。
- 递归问题。我的需求中使用缓存是不太合理的，原因是每个节点都是顶级节点，意味着每当和这个节点有关系的树形结构发生变更时都要进行缓存的更新，我感觉使用缓存不太合适。如果你的需求中顶级节点是固定的且更新不太频繁可以试一试，不过由于你说节点有上万个，是不是考虑一下是否有大 key 问题。使用 protobuff 结构所占的空间比使用 json 所占的空间要小的多。

test []( https://postimg.cc/HVpW7gLq)