流量大的这么做的感觉也不少，比如 Google 也是这样

这个问题是需要妥协的，Designing data-intensive applications 里有专门描述这个问题的章节，你可以找来看看。

我们的备库都没读，只用来做高可用了。负载全靠 cluster 抗 😂

一般同步都是非常快的，所以一般就是
1. 如果是客户端插入的数据，客户端可以直接乐观更新，就显示本地的数据
2. 如果插入之后需要立即查，就等几秒钟，一般没啥问题
3. 其他客户端查到旧数据也无所谓，只要不是一会儿新一会儿旧就行，因为同步很快，一般也没问题
如果同步十几秒才完成，那就说明有问题了。

一楼说的刚插入就查主库实际做起来还是挺麻烦的。看你需求严格到哪种程度了。

话说用非国区的市场到底麻烦吗。我就是因为这个问题从来不考虑 iPhone 。

想想你读了一二十年，现在除了工作用的到的还记得多少。

2k 显示器用 Windows 我都不想开电脑。4k 感觉还可以

一般来说不至于这么脆，两年就挂。你这个 120g 容量小，同样体质换个 1t 的寿命就翻几倍了。

前端自己过滤掉重复的就好了，取的时候多取几条。像推荐之类的也是这样防止重复的

@PatrickChen https://www.rebilly.com/careers/ 据说准备招 5 个前端。可以试试，能不能过随缘了。

elance 这种地方属实不行，还是正经找个远程工作吧。我有个朋友公司正在招人，不过他们用 vue 的

m1 之前我用公司发的一台 256 的。用了快 4 年，除了系统升级剩余空间不够感觉也还勉强。所以部分人够用是正常的

不好办啊，即使你钻了空子也不一定用得了多久。不如试试 fastspring 之类的？就是费率比较高。

原因就是 5 楼说的了。这种其实是很符合直觉的，一般这个功能是应付意外停电，如果是你自己关机了，就不该再给你启动了

要想无缝升级你的服务就得兼容前后两个版本，然后按其他人说的一个一个替换。如果更新不兼容，那不兼容的这些就最好停机一次更完。

我还挺喜欢这个功能，就是喜欢抖笔的话就难受了。。。另外一头当橡皮如果擦的频繁的话感觉并不方便。

一般来说我倾向于不依赖别的服务能同步验证的，就放在 entity 里，比如 email 格式。其他的就搞个 factory ，在创建 entity 的时候验证，比如保证 email 唯一