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

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

@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)

test


攒钱

张一元的茉莉花茶，清香，我喝着挺不错。