没法保证完全保证。需要做计算与存储分离。
把队列信息放到 zk 或 etcd 或者 redis mysql 上线。然后做一个分布式调度 就行了。

其实就是元信息抽象不够。最好的方式就是 产品懂技术。从技术的维度去构造需求。 可以把程序员理解为 实现，产品理解为 interface 。

这不就是 mongodb 的 api 封装么

@fxjson #40 rocket

我们在用 RMQ 商业版，感觉没啥大问题。
我读过 RMQ 的源码，感觉代码挺不错的。其实大吞吐就是硬盘的 mmap 玩法。其实都差不多。
我们是 java 团队，用了挺久的 RMQ.

我乱说的，
感觉楼主说的有些类似于 JMM 的规则。
java volatile 是保证属性可见性，线程栈改完就刷到主内存，读也是从主内存拿，其实靠的禁止 cpu 指令重排。
但是 volatile 并不是保证 cas 操作。
cas 是保证替换的时候是期望的条件， 当然会出现 aba 的问题。但也有方式解决，加标记呗。

@arthas2234 #11 大佬，有没有渠道呢？

如果 qps 要求不高可以使用 360 的 pika 等 基于 rocksdb 的 redis 变种实现。
这些中间件都是经过验证的。 甚至 pika 可以前面加一个 codis 作为 proxy

另外数据肯定要分冷热。 冷数据还有一个逐渐变冷的过程。

其实题主就是来平衡成本和性能的。 大家抓核心。 楼主你说对吧。

@Exdui #23 这类型的产品还挺多的。treelab seatable 还有 vika 黑帕云等。 市场足够大。小厂也有机会。

@matrix67 #15 多维表格其实就是 notion 的 database 。 和国外的 airtable 是一样的。

@EMINEM1000 #1 好啊好啊，欢迎试用 https://www.surongyun.cn/ 速融云

@gushu #9 👍 分析的好。笔记的本质不也就是文档么。

另外微信可以看飞书文档了。

腾讯文档和石墨和 wps office 是一类型。比较老套。

钉钉和飞书是一波，核心理念与 notion 类似。all in one 。

为啥文档和笔记分的那么细呢？ 其实这些都是非结构化知识承载体，本来就不该分的这么细致。 我认为就和马桶为啥不设置 一个站着 和 一个坐着的一样。

@EasonC #6 「我来」这渣技术就不要凑热闹了。完全不是一个量级。

大家兴趣的体验下 飞书文档，比 Notion 弱到哪了？
当然我也不是飞书吹。 优秀的产品会说话。

一般来说有这种需求场景，肯定是要通知到运维进行备案。让运维心中有数。
毕竟总不能因为 AB 版本导致全服停机吧。
一般在消息设计里面肯定要设计版本号， 否则这种问题必然发生。
如果真的发生这种情况，肯定要进行切流量，dubbo 控制台本身就有切流量的的操作。
如果是 http 服务，这个好办，ng 或者 k8s 的 ingress 或者 service 都可以搞。 不过话说回来，现在没上 k8s 的的确比较蛋疼，毕竟我们 devops +k8s 这一套已经从 18 年用到现在。即便是出问题，也能方便切流量。

所以
1.团队基建有问题
2.架构考虑扩展性有问题
3.测试&发布流程有问题
4.领导有问题。

@karloku #39 这位老哥说的好。

这种瞎 jb 嘲讽的的确是 v2 的一个特色。
哈哈哈

哥来一次手动置顶。

我们现在都是在容器内部直接挂载 NFS 或者 smb 。量小可以试试。