初始设定

一开始我们就在 Azure 租一个 node ， 程序後端（以下称API)、Nginx、MongoDB 都在里面，完全是轻轻松松的会发生 single point of failure
後来发现这样，要 deploy 後端程序时候，就要把服务暂停才行。所以就把 API 跟 MongoDB 拆开，然後多加了几个 API 的 instance。

第一次遇到问题：太会聊天

本来因为 array 很方便，我们本来就开了一个储存对话的 collection，两个人间的对话就是一个 document。後来开始有人越用越多後，才发现一个 document 的大小有上限 (16M)，居然有人可以聊到达到这个上限。虽然算是 corner case，但也让我们发现目前的 schema 不可行，於是存对话的部分，改成了一个新的 collection，一个 document 就是一个讯息加上一个对话 ID。

第二次遇到问题：out of memory

後端跟资料库分开後，资料库这边维持现状好一阵子。
後来用户又持续增长，效能开始出问题後，就开始研究要怎麽不用花太多钱改善效能。这也是有钱大公司跟没钱小团队的最大差别。毕竟现在都是 host 在云端，只要有钱，按几个键提升主机的规格，效能马上改善。

虽然透过增加 index 可以改善，但我们遇到一个问题是，尖峰时段 MongoDB 会用超过 VM 的可用 memory (Out of memory) ，此时就会慢到不行，也就只好认明提升 instance 的规格。我们每次都是出事了才提升规格，目前已经改了好几次。难以想像以前要自己在办公室放主机的时代要多麻烦，哈哈。

第三次改善

後来看了 Mongo 官方建议。发现推荐的形式是要有至少三个 instance: primary、replica、arbiter。
我们才加到三个 insance。这也让我们大幅降低跟资料库有关的 downtime。

光是 mongo 就好多可以写，哈哈。下次写最终形态的改善。

最新文章会分享在脸书：https://www.facebook.com/gigi.wuwu/
欢迎留言讨论