@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 顶头吗？

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

我纯是为了看片

@googlefans 在丰台哪个地啊？

18.8w

@litguy 这个我感觉是相当于把所有的并发操作限制成了串行操作，是可以保证线程安全的，那效率怎么样呢？还有就是回调队列是干了什么事呢？

并发要求多少？这种共享变量的 读取-新增 操作不上锁都会有并发问题吧？可以试试把锁的粒度控制在最小，试试 select version from table where userid = ${} and business_type = ${} order by version limit 1 for update; where 条件字段要索引。