| 10月4日、5日，由于数据碎片化和监控不力的原因，FourSquare经历两次宕机。FourSquare使用的后台数据库为MongoDB，在问题解决后不久，MongoDB的开发公司10gen的CTO和联合创始人Eliot Horowitz也在mongodb-user这个Google邮件组里分析了整个过程。 国内知名技术博主、医药生命科学网站丁香园CTO冯大辉翻译了Eliot的分析，本着不重复发明轮子的原则，本文将引用冯大辉先生博客的主要内容，全文请见冯大辉的博客——《FourSquare长达11小时的宕机》。 在冯大辉看来，Eliot的说明“有为MongoDB辟谣的意味在里面”，同时他也认为这个案例“是一个很好的研究样本，值得分享”。 为了提高响应速度，Foursquare 使用 MongoDB 存储 Check-in 的数据已经有一段时间了。这部分数据的数据库起初跑在一个 66GB 内存的 Amazon EC2 单实例上（全部在内存里），两个月前，出于对容量增长的考虑，迁移到两台 Shard 集群上。每个 Shard 机器都是 66GB 内存，为了冗余，每个 Shard 都有复制到 Slave 实例。迁移的目标是所有的 Check-in 数据都保存在内存中。数据根据 ID 分成 200 个 Shard 分片，两台机器各占一半，也就说联机数据在每台机器上各使用 33GB 的内存。两个月相安无事。 问题来了，因为 Shard 算法导致的数据分散不均衡，其中一台(Shard0)数据增长到 67GB(另外一台 50GB)，超过了 66GB 的限制，读写部分分散到磁盘上，性能急剧下降。从而，网站宕机。 首先尝试增加第三台 Shard 机器，上线后开始迁移，读取从三台进行，Shard0 的数据迁移到 5% 的时候，但是写操作还是让 Shard0 宕机了。这个时候发现Shard0 存在数据碎片(data fragmentation)，即使数据迁移走，还是会占用原来的内存。每个Check-in 文档大约占用 300 字节，而 MongoDB 是 4KB 的页(Page)，也就说十几个文档会填满一个页，而迁移 5% 反而造成了页更加稀疏，并不是将页全部删除。 这个时候已经到了第二天，随着网站全面宕机，技术团队开始用 MongoDB 的 repairDatabase() 功能来对数据库进行压缩，因为数据库太大和 EBS 慢，也因为 repairDatabase() 不能充分利用多核CPU 的能力，这个过程耗费了 4 个小时。之后这 5% 的内存空间终于释放出来，系统重新上线。 |
