两地三中心架构下的数据库搭建

什么/为什么/怎么样是两地三中心

~~这些问题不在我的分享范畴~~

因为我最近多次完成了两地三中心的搭建，所以想把这个过程中的一些体验记录下来

在设计一个架构时，我们可以考虑很多产生故障的可能性，但是顺着可能性，继续考虑下去，就容易把工程问题退化为概率问题。

如果反过来，先设定一个量化的目标，那么可能性就可以通过横向或者纵向的伸缩，剔除出系统。

所以我们先确定目标是几个九，再去找到会让它坍塌的点，最终搭建一个让人看起来达标的系统。

然而，如果你的架构足够重要，那么任何一个级别的中断都会让人痛苦。

没有感受到这种痛苦，说明你的系统不够重要，这是一个非常美丽的陷阱。

于是，我把可用性当成了核心，让故障不发生，或者至少让使用的人感受不到故障。

123是顺子，444是豹子，如果你的牌是未知、未知和未知，那么你都不知道是否该加注还是弃牌。

我们不需要知道花色的色号，但是需要知道花色。仔细的观察会消耗资源，观察到能够发现问题就可以。

如果出了问题，但却找不到现象，那么说明观察是不足的。加大观察的仔细程度会增加资源的消耗，更重要的是分散人的注意力，所以我们在观察之余，还需要增加哨兵，值守在每个观察的异常点位。

观察充足，每次动手都是非常满意地挥动指挥棒。

观察不足，每次动手都是给自己加大精神紧张。

曾经有一个数据服务，长期地高负载，我们的工程师，花费很多的时间精力，将服务的负载降低了5%。

实在找不出优化的点了，于是找老板，申请能否升级机器。老板当然会考虑成本，但是长期的高负载导致的体验下降，硬件故障概率的提升，运维压力的持续，每个点都让老板充分感受到。

老板最终买了更好的机器，负载降下去了90%。这就是沟通的价值，工程能力远远超过了很多工程师。

当然，有时候，老板并不愿意掏这个钱，那么就可以考虑找一个更挣钱且更愿意掏钱的老板。

没有路标的路人会迷路，如果只有你有地图，那么每个人都会找你问路。

搭建数据中心时，最先围拢的是网络，一定要把网络扎紧扎实。并且给包括自己在内的所有人发好门票，这样当门票出问题时，你会知道，而别人也会知道是门票出问题了，而不是你出问题了。

不要偷偷在网络内外加入捷径，这些会降低项目的生命值和你的脑容量。

当网络出现故障时，在城外排队只是让人觉得你能力有问题，如果大家都在城外，而你在城里面，那么下次不会有人排队了，他们都会找到你。

运行时的一切都是临时住所，持久化才是你永久的家。（赵本山老师）

今天先写到这里，去做饭了。