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 倍了 血脂很糟糕，其他没有。准备清淡饮食+多走路，一个月后复查。
这结果真的被吓了一跳

楼主在哪个城市？
没得房贷，还能靠收租生活！那简直底气十足！！！

@daimubai 与你完全一致

@luistrong 你的第一个问题 “好像感受不到“，这种其实是一种预期规划，你的预期是钱越来越不值钱，你的收益越来越高，收入的浮盈赶上利息带来的成本。但是这只是一种预期。 实际上你减少这 5 年的利息是 实打实的 钱！而且如果你后面预期规划真是这样，那你照样可以第二年又多还一点，这样每年都叠加还，这样你的总 利息就可以降到更低。10 年换房这种更不影响你提前还贷，你归还了本金，你卖房子后还银行的本金也会变少。始终记住一点， 减少占用银行的资金时间，付出的利息成本就是会变低的。

第二个问题：借贷！不建议这样做，往往这种东西看似只有 4.3 的利率，但是其中有很多隐形成本，比如其中的手续费，过桥费，中介费，都可能是成本，可能最终算下来并不划算，而且这种借贷 如果是正规渠道，那么钱一般不可以直接用于房产，其他渠道可能有更多的风险。 而且借贷一般年限比较低，是否考虑有抽贷可能性？

@luistrong 要分情况，如果你现在手上钱比较富裕，然后能够预见未来 3 年内工作能够比较稳定，就建议缩短期限。这样你还款的速度就会变快，贷款使用成本最低。 如果未来 3 年内可能不太稳定，只是现在手上这笔钱找不到好的投资渠道，就选择减少月还款，这样可以把这笔钱收益最大化，同时能够减轻未来还款的压力

建议提前还，但是是分批次提前还， 别去看现在银行什么利率理财产品吹嘘的年化%5 ，但是记住那是投资不是银行的存单。现在 4 大行的银行大额存单 3 年 20W 起一般在 3.5 +-0.2 这个样子。从经济发展模型上来说，存单利率会波动向下走。但是你的贷款利率可不会这样。如果你房贷每个月按 5000 算，一年还 6W ，如果有闲钱，你可以选择再多还 6W 。
最终的目的就是，减少 **占用银行资金的时间**， 你的成本才会变低。 别去想什么通胀问题，那都是支出通胀，收入极低缓慢上涨。公积金不在考虑范围内
如果你有能力让你的钱超过当前房贷，大概率你也不会问这个问题了。