2015年11月14日凌晨，巴黎发生恐怖枪击案，接下来一系列的大规模恐怖袭击活动让世界震动，作为社交巨头的FACEBOOK迅速反应，在当天便推出了“Safety Check”的功能，该功能可以帮助在处在灾难发生区域的人们在FB上将自己标记为“安全”，当你处在再难区域时，FB会询问你“安全吗？”，确认了自己安全以后，你的FB页面就会出现一个“SAFE”标记，同样的，你的朋友确认你安全后也可以帮你标记。
该功能推出后，获得了业界一致“反应迅速”的好评，然而这个功能，早在以前就有了。
这次为大家翻译一篇在尼泊尔地震后highscalability报道Safety Check功能的文章，揭秘这个“Safety Check”功能是如何做出来的。
灵 感 来 源
当灾难发生时，人们迫切地需要知道自己所爱之人是否是安全的。当9.11发生时，当我住的区域燃起一场野火时，当1989的洛马普列塔地震发生时，我都深深地有这样的感觉。
地震的发生都是瞬间的，没人知道它什么时候来。当天花板上不再掉落尘渣，我们确认建筑不会崩塌后。第一反应都是想去确认亲人的安全，但在这时想要拨出电话基本是不可能的。电话在一瞬间从全国各地涌入湾区，信息拥堵后，我们只能紧张地看着电视里播报的灾难消息而无能为力。
经过了四分之一个世纪后，这种情况有所改变吗？
FACEBOOK做到了，他们推出了一个“Safety Check”的功能，当有灾难发生时，他们会给在灾难区域的人们发送一条确认安全的推送，当确认你的安全后，FB会立即告诉你的朋友：“别担心啦，你爱的人是安全的。”
这个功能是FACEBOOK的工程师Brian Sa主导开发的，说起来还是要回溯到2011年的日本海啸tsunami。
在灾难发生时，Brain于Facebook的首页放了一个banner指向各种帮助信息源，这件事促使他想开发一个新功能以便更好地帮助别人，于是“Safety Check”诞生了。
这个功能实在太棒了，为什么之前没人想到?这简直是个绝妙的idea！
关于这个功能更为清晰的想法也被FB的软件工程师Peter Cottle在一个访谈中提到。
在这个世界上，似乎也只有FACEBOOK能做到这件事了，这也与Brain在他的访谈里所提及到的主要观点相吻合：
在某种程度上，只有你们能解决现实世界的问题。打破常规，想想你和你的公司能发挥多独特的作用。
只有Facebook能创造出Safety Check，不仅仅是你所能想到的那些，Facebook是一家会让雇员去做像开发Safety Check这种疯狂举动的公司，他们拥有超过15亿用户，这意味着每个人之间只有极短的边界距离，并且Facebook的用户都是他们新闻源的狂热阅读者。
Peter提到了在Catch-22团队在初步开发Safety Check功能时资源是极度匮乏的，当时Safety Check这个项目还是个很小的功能，没多少资源去支撑，他们必须证明在没有资源的情况下他们也能开发出产品，这样才能得到足够的资源来发展产品。
我们经常在备受限制的情况下找到一个机智的解决方法，小团队无法建立一个大型的页面及渠道，所以他们写了一些PHP代码以保证工作得以进行。
Facebook究竟是怎样建立“Safety Check”的？这是我对Peter和Brian谈话的理解：
你可以把Facebook想象成一锅可以复制的“原始汤”，像病毒营销这样的案例很容易随着时间在数十亿的平台疯狂发展。
一个病毒传播案例是ReadWriteWeb，人们疯了一样把他们的头像换成红色的等号以示婚姻平等：
在支持同性婚姻平权时，facebook推出了一款彩虹覆盖的图片滤镜，使得用户可以很简单地去表明自己的立场，传递自己的时代精神。这使得他们的自定义头像应用使用量翻了1000倍。
这些案例促使他们有了“在灾难期间，帮助他人更好确保朋友知道自己安全”的想法：在灾难期间，人们可以更新自己的状态表示自己“安全”。
然而，这还不是一个让别人知道自己还“安全”的理想解决方法。
这个想法还不是很结构化，问题有两个方面：告诉朋友们你还安全以及你朋友得到信息确定你还安全。
首先，不是你所有的朋友都能看到这个更新；
其次，用户没有办法得到所有处在灾难中的朋友的名单；
在Safety Check中应该用更为结构化的思维来解决灾害通知问题。
它是如何运行的？
1.如果你处在受灾区域，Facebook会发给你一条推送，询问你是否安全；
2.如果你还OK，点击“我很安全”按钮，确定自己是安全的；
3.你所有的朋友都会被提醒你还安全；
4.你的朋友们也可以看见一个所有在受灾区域朋友的名单。
你是如何建立一个确定的灾难地域用户池的？
构建geoindex的确是一个好的解决方案，但它有很多弱点：
1.人们是在不断移动的，数据不能实时更新；
2.一个十五亿的geoindex太过庞大，他们并没有足够的资源去支撑它，记住，他们只是试图实现这个解决方案的小团队；
3.比起考虑如何支撑起一个庞大的数据管道，更需要去解决的问题是当有突发事件出现时，这个功能是能够被立即拿来使用的。
最后，解决方案利用了社交图谱的轮廓及属性：
比如说当尼泊尔地震发生时，Safety Check的信息截取“钩子”就会在每个独立信息源读取过程中被触发。
当用户检查他们的信息源时，“钩子”就会检查他们所在地是否在尼泊尔，如果用户确认自己不在，那“钩子”什么都不会做。
但当有人处在尼泊尔又去确认了他的信息源，奇迹发生了。
Safety Check会检查所有用户社交图谱上附近的人，如果他们在同一个区域，Safety Check就会立即发送一个推送通知，询问他们是否还安全。
这个过程会不断重复，对于每一个被确认在灾难地域的人，最主要的工作就是去检查他们的附近的人，然后发送通知。
在实践过程中，这个方案是非常有效的。算法是如此快地寻找到人，以至于让人觉得它是即时的。举个例子，一群人在同一个房间的人会在同一时间收到他们的提示信息，没有延迟。为什么？
系统在推送消息的时候随机挑选了一个更为活跃并且朋友数量比较多的用户，这样就过滤掉了很多无效的用户，不需要再进行数十亿的计算了。
图谱是密集且相互关联的，事实证明，六度分离定理是错的，至少在Facebook上，十五亿用户任意两名之间的分离度只有4.47。sorry凯文，我们似乎只要通过5步就能在脸书上认识十五亿里的任意一个了。社交图谱能帮我们更快更有效地找到另一个人。
Safety Check能够自由地使用并行服务器去处理不同的用户请求，包括用户的好友。
然而，这个时候竞争条件就成为分布式解决方案中最大的问题：
两台在不同的数据中心机器检测到同一个用户，这意味着遍历了分离度边缘后，有个用户会收到两条通知。
没想到，这会成为一个大麻烦。想象一下，处在灾难中的用户一下子会收到多个确认他平安的通知，这会让用户认为他们真的处在麻烦中而感到非常紧张。
解决方法是：
用一个数据库来储存状态，这样就只有一台机器被用来检查用户了。
这个功能在尼泊尔地震中得到了广泛的使用。
不到五分钟就有三百万人收到更新状态的请求，超过1亿在尼泊尔的人得到安全确认。
五分钟之内，三分之二的FACEBOOK用户被系统遍历了一回。
在经历了一些麻烦后，Safety Check发布了第一个版本。
但由于Facebook系统本身的复杂性，这个功能被暂时隐藏了，只有当发生紧急情况时，它才得以被启用。
文／产品100（简书作者）
原文链接：http://www.jianshu.com/p/f6ce7302adaf
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。
