@sadfQED2 无用的 goroutine 如果太多，大家都在抢，你怎么能保证你的 helloWorld 能抢到。当然具体的我也无法从上面的信息看出太多，如果这个第三方代码是开源的，可以贴一下 github 我可以去定位一下 相关的实现

@hopingtop 但是如果这些 goroutine 里面有大量的锁，那可很可能造成你当前这样现象。

但是按理来说 5W 的 goroutine 小 case ，

首先你的 go hello word 没有被打印，就相当于调度器就开始没有绑定你这个任务执行了，或者说调度器被其他的 goroutine 完全占用了。 占用的情况大一些
第二个，你重点看一下 代 loop 的函数， 比如 logger.writeLoop 和 metrics.asyncSendLoop 特别是后者，是否出现了，因为函数名是 异步 async 开头，这里是否是 开启了大量的 goroutine 然后没有正确的被释放，导致 goroutine 常驻 。

先看看 我说的上面这两个地方呢

给你举一个比较流行的东西， 混币器搜索关键词：Tornado.cash 也符合你现在的理解。
但是你可以看看他现在是什么状况，当产生了利益冲突，随时可以让你覆灭
能做一部分事，但是想颠覆，就不要幻想了，一定是在某种利益框架下执行的，特别是现在 ETH 转 POS

OP 这个应该不是一个一次性需求吧，说了冗余字段还会有。
其实在设计冗余字段的时候，就相当于大部分场景放弃了一致性。
那么其实可以 梳理一下业务，同步+异步一起处理， 或许梳理下来就只有 1-2 表 要求数据一致性呢，这不就好办，都兼顾到了嘛，如果 5-5 开，那也能减少大部分时间。真要是都要保证数据一致性，那冗余字段这个设计本来就是你们当前系统的大 BUG ！

@hopingtop 两边不定期把对方的 branch/commit 合并到自己的项目。怎么解决 merge 时的包名冲突问题？这个需求采用直接分支 merge 的方法好吗？正常流程是不是走 pull request 好点？

@#2

蹲一个好的解决方案

1.如果在都能满足功能的情况下，一定要选择团队熟悉的！！！
2.这里 2 亿数据确实不多，而且也不用依赖 mongodb 本身的分片，可依据时间自行管理分片，这样在扩容很有优势
3.mongodb 在查询方面性能还是很不错的，你的查询场景一般还带有时间限制。
4.楼上也说了参考 头部 ，Discord 当初在 2015 年就选择了 mongodb ，(2022 年的 mongodb 更强大了) 为什么不选择其他？当你数据量真的到达扛不住的量级了，我想肯定是很赚钱的了，这个时候人手和资源又不一样了！很多事情本就不可一步到位。
5.需要频繁查询聊天数据，这个需求一般只是 存在运营这个角色， 如果真到 DB 性能不够，那么你完全可以经过角色同步数据的概念到本地进行查询，然后，如果有必要再去服务器去获取上下文。

提醒一点：有时这种事是一个信任问题，两个人，这方面也应该考虑一下

可能当你打开页面那可以刻，就已经注定你能不能抢到了~ ~# 楼上说的对

Golang 里面 用 iota 枚举， 但是我喜欢用 X = iota + 1 来设置枚举值，经验之谈，可以避免很多问题。杠就是你对

看了你们的回答，本来我之前也打算换 ITX ， 现在决定脱坑，哈哈哈

@hopingtop 没看到 楼上已经有 推荐的了

推荐一个 DY 号，我也是 前两天关注的， 一直在找 躺平的地方，各种度假中心，海边的，山区的，价格很平民那种。 很有意思

账号： 轻徒鸟 不是广告！

更新这个操作，分摊到客户端， 去检测你下发 token 的过期 时间戳。他检测到 快 过期，在主动触发 服务端。 然后你 服务端，只需要一个 代价很小的 轮询 补偿机制就行了。 不知道这样能够解决你的问题？

复现

唉 脂肪肝， 尿酸 700 甘油三脂 5.64 都超正常的 3 倍了 血脂很糟糕，其他没有。准备清淡饮食+多走路，一个月后复查。
这结果真的被吓了一跳