领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
MongoDB创始人Eliot Horowitz分析FourSquare宕机原因
作者 郑柯 发布于 2010年10月9日
上回书我们提到：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% 的内存空间终于释放出来，系统重新上线。
随着 Shard0 修复，第三台成功上线，进而添加了更多的 Shard 服务器，现在数据已经更加的均衡，通过在Slave上运行 repairDatabase()，然后将其切换到 Master ，每台 Shard 内存占用缩减到 20GB左右。整个故障时间已经延续了 11 小时之多。
产生问题的主要原因就是系统过载，前面介绍每台 Shard 承载原来 50% 的压力，到了问题发生的时候，单台 Shard 的负载已经超过 Shard 之前的系统负载，这时候已经积重难返了，在容量的临界点增加新系统资源，必然导致更多的停机时间。暴露了 Foursquare 团队在容量规划方 面的不足之处，或许也因为业务增长太快了吧。另外，内存碎片化的问题在没有宕机之前，技术团队应该没考虑过这个问题，如果文档的大小超过 4K，碎片化问题就不严重了，这是特定应用场景造成的特定问题。10Gen 现在已经着手研究如何进在线压缩(online compaction)。再次，Shard 键值的顺序和插入顺序是不同的，这造成了迁移数据的时候 Chunk 的迁移不是连续的。
冯大辉认为这个案例能够带给我们很大启示：
最近 NoSQL 已经成为一个热词，类似 MongoDB 这样的新事物当然值得尝试，但是不能冒进，因为驾驭起来并非易事。仅仅能够使用是不够的，系统没出问题一切都好，一旦出了异常，有足够的技术力量(设想一 下 Foursquare 得不到 10gen 团队的支持会如何?) 支持么？在极端情况下如何控制？ 如果回答不了这个问题，那么还应该暂缓。最好的办法就是..."等待"。
作为InfoQ的读者，您是这么看么？这个案例对您有何启示？欢迎在下面留下您的想法。
郑柯 InfoQ中文站总编。做过开发，当过PM，干过销售，搞过市场，最终还是回到媒体。实用的理想主义者，相信：每天改变一点点，这个世界会更好。
发现一个错字
发表人
典 刘
发表于
Re: 发现一个错字
发表人
熊 小
发表于
Re: 发现一个错字
发表人
典 刘
发表于
Re: 发现一个错字
发表人
David Fenng
发表于
Re: 发现一个错字
发表人
典 刘
发表于
Re: 发现一个错字
发表人
霍 泰稳
发表于
反思开源与新技术
发表人
王 磊
发表于
其实
发表人
黄 超
发表于
Re: 其实
发表人
ma lionbule
发表于
Re: 其实
发表人
Han Meng
发表于
Re: 其实
发表人
howard howard
发表于
看来需要预警措施
发表人
曹 云飞
发表于
整理碎片应该是个常规事务
发表人
Shichao Liu
发表于
最好的办法就是..."等待" ???
发表人
haoxiang zhang
发表于
Re: 最好的办法就是...
发表人
wang xuan
发表于
Re: 最好的办法就是...
发表人
yu yu
发表于
与技术关系不大
发表人
Shi Yanjun
发表于
使用新技术需要更多的监控
发表人
qd he
发表于
過於熱衷！
发表人
David Fu
发表于
-
“两台机器各占一般”
-
NoSQL是一门新技术，而MongoDB又是一个开源的产品，新技术和开源确实是不容易驾驭的，没有足够的经验可以借鉴，没有足够的强大的技术团队给予支持，都是他们固有的问题。但是新技术和开源也有先天的优势，开发人员众多，低成本等等。建议还是要勇于实践，从小应用开始积累经验，慢慢向大规模使用前进。
-
已经修改，多谢提醒！！！
-
冯大辉的这个“启示”其实没有什么意义
-
冯大辉的这个“启示”其实没有什么意义
你的结论太武断了。
这次事件能导致服务停滞，也可见严重性。还是稳步试用比较好。 -
不客气，发现infoq上很少有人发言啊。infoq是很高端的网站了， 难道中国的精英都不喜欢交流？
-
允许匿名评论就好了。
除却4SQ 之外，Digg 运用 Cassandra 的经验也不是很成功。 -
比如在内存使用了50G的时候能够向系统管理员发报警短信
-
做不到魔兽那样每周一次, 也该做到每月1次, 或者定期监测硬件使用率, 这次宕机完全可以避免.
MongoDB对于高负荷和超负荷的响应也有值得改进的地方, 接近临界的时候应该向管理员报警, 到悬崖边的时候应该拒绝新的事物, 并且把原因记在日志里.
期待新的在线压缩功能. 蚂蚁搬家似地勤奋压缩(很像垃圾回收呢)应该会取得很好的效果. -
最好的办法就是..."等待" ??? 等待吗? 如果没有这样的技术先锋,没有这样的案例, 怎么能得到经验, 怎么能成熟呢? 这种想法比较消极. 看到别人宕机就怕了吗, 不敢用了? 不敢去发现别的问题了,不敢去总结经验了吗?
-
难道咱们要等到别人玩腻才跟上么？
-
技术在实际应用过程中并不占据主导地位，倒是凸显出计划性、适应性在业务过程中的决定性作用。试想，即使再好的技术方案，首先如果它不适合我的应用场景，如果再没有一个好的规划（至少在切换之初就该做好，对切换后任何意外的妥善处理方案），结果可想而知。
-
re~
-
您是twitter上的那位Fenng? 杨贵福的同学？
-
毕竟会出什么问题是未知的
-
很多時候，我們追求新技術，而且瘋狂的擁護在無任何深切理解下。
比如最近幾個比較熱門的技術，很多人瘋狂認為nosql可以取代普通數據庫。實際上這兩種東西並不是競爭關係，而是互補關係。“右翼”份子總是發布文章告訴他人如何用nosql來取代mysql或者其他產品。
mongodb所用到mapreduce也經常誤解，特別是幾個入門文章（wiki上）。小弟認為，用mapreduce排序和組合的例子絕對是一種誤導 -
InfoQ比较追求实名制，希望能给大家建立一个客观、真实的技术社区环境 :)
-
严重同意
最好的办法俨然不是等待 -
同意你这个，shard算法没弄好的话，在那个数据库都有问题，只不过
因为 Shard 算法导致的数据分散不均衡，其中一台(Shard0)数据增长到 67GB(另外一台 50GB)，超过了 66GB 的限制
19 条回复
关注此讨论 回复