FourSquare经历两次宕机

作者 郑柯 发布于 2010年10月8日

领域

运维 & 基础架构,

架构 & 设计,

语言 & 开发

主题

扩展性 ,

面向对象编程 ,

案例研究 ,

运维 ,

方法论 ,

故事和案例分析 ,

互联网 ,

架构 ,

编程 ,

性能和可伸缩性 ,

社交网络 ,

敏捷

分享到

美国东部标准时间10月4日和5日，互联网业界最有名也是最具价值的地理位置服务网站FourSquare经历了两次宕机事件，第一次长达11个小时，第二次也有6个小时。第一次宕机问题解决之后，FourSquare技术团队在官方博客上发布帖子“这一次可真是郁闷了”，详细描述了该次发生问题的全过程。

FourSquare使用MongoDB作为后台数据存储，他们保存了海量的用户签到（check-in）记录，并且使用用户ID对数据进行了分片（sharding），希望数据可以平均分布到不同的数据库片（shard）之中。4日上午11时开始，FourSquare发现某一个数据库片的写入操作出现异常，在接下来的一个半小时，他们采取各种负载均衡措施，均不起效。他们希望引入一个新的数据库片，并在不关闭网站的情况下，将过载的数据库片中的部分数据转移到新的数据库片中。然而，该操作没有成功，同时直接导致整个网站关闭。不仅如此，将数据向新的数据库片迁移也没有腾出原先预期的存储空间数量。（他们认为“数据碎片化”和“使用用户ID切分”是两个主要原因。）接下来五个小时的各种努力也没有起效，网站仍然没有起来。

4日下午6时30分，他们决定重新建立数据库分片索引，这可以解决内存碎片化和可用性的问题。这个过程耗时5个小时。到晚上11时30分，网站恢复。而且由于他们之前做了足够的安全保障和备份工作，没有任何数据丢失。

FourSquare团队在该帖子中提到，将会采取三种措施避免类似状况：

1. 进一步与MongoDB的开发者们密切合作。
2. 改变运维流程，防止过载发生。
3. 寻找服务降级的方法，关闭某些服务，以避免整个网站全部受影响宕机。

然而，刚刚过了几个小时，FourSquare再次经历了第二次宕机⋯⋯

最新的博客帖子这样说明第二次发生问题的过程：

简单来说，还是发生了同样的事情：数据库过载，解决方案还是手动重新分配用户签到数据，以确保没有数据库过载，然后重启网站；在将近6个小时之后，我们终于恢复了服务。

除了FourSquare自己的讲述之外，MongoDB的开发公司10gen的CTO和联合创始人Eliot Horowitz也分析了整个过程，请关注InfoQ对于该事件的后续报道。

郑柯 InfoQ中文站总编。做过开发，当过PM，干过销售，搞过市场，最终还是回到媒体。实用的理想主义者，相信：每天改变一点点，这个世界会更好。

相关厂商内容

保持某些系统的高可用性，是一些企业的重中之重，如何设计？

海量数据处理，海量视频分发，架构热点难点，尽在架构师峰会！

相关赞助商

ArchSummit全球架构师峰会报名启动！7折优惠，5月31日截止！

1. 返回顶部

   关注！

   发表人 崔 康

   这种实战案例很值得学习！

   回复

2. 返回顶部

   继续关注,

   发表人 zenk zenk

   记得以前在项目里面使用mogodb的时候,觉得这东东暂时还不够成熟,硬盘IO以及内存使用上都还不够好

   回复