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

之前从事过短信发送平台的项目，每天的发送量一个亿到两个亿之间，属于数据密集型应用。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


攒钱

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

@vcbal
@Nooooobycat
调研了一下，图数据库是可以实现且比较合理的方案。考虑到这块业务并不是很核心，在数据量并不多的情况下还是不增加项目复杂度，没有引用图数据库。目前还是在关系型数据库中存储的，一个 fromId ，一个 toId 。查询时开了多个线程，最后合并返回的。

无形装逼，最为致命。

@zhandouji2023 摸鸡老板在哪？

@suancaip 会被 ak 顶头吗？

由此可见得看什么公司什么领导

我纯是为了看片