# 在不到五分鐘的時間里，Facebook 如何告訴您的朋友您在災難中很安全 > 原文： [http://highscalability.com/blog/2015/9/28/how-facebook-tells-your-friends-youre-safe-in-a-disaster-in.html](http://highscalability.com/blog/2015/9/28/how-facebook-tells-your-friends-youre-safe-in-a-disaster-in.html)  *這是文章更新： [Facebook 的安全檢查如何進行](http://highscalability.com/blog/2015/11/14/how-facebooks-safety-check-works.html)。* 在災難中，迫切需要立即了解您所愛的人的安全。 在 9/11 期間，我有這種感覺。 我知道在我們地區的下一場野火中，我會有這種感覺。 我生動地記得在 [1989 年洛馬普里埃塔地震](https://en.wikipedia.org/wiki/1989_Loma_Prieta_earthquake) 期間的感覺。 大多數地震都沒有引起注意。 不是這個，每個人都知道。 在計算機實驗室中，天花板不再像雪花一樣飄落下來之后，我們確信建筑物不會倒塌，所有想法都轉向了親人的安全。 就像其他人必須擁有的一樣。 撥打電話幾乎是不可能的，因為電話從全國各地涌入灣區，所以所有電話線都很忙。 信息被卡住了。 由于電視顯示出持續不斷的死亡和破壞，許多無聊的時光被浪費了。 25 年后的今天，我們還能做得更好嗎？ Facebook 可以。 通過名為 [安全檢查](https://www.facebook.com/about/safetycheck/) 的產品，該產品在災難期間將親朋好友聯系在一起。 發生災難時，“安全檢查”會提示該地區的人員指示他們是否還可以。 然后，Facebook 通過告訴他們的朋友們如何做來結束擔憂循環。 [Facebook 工程師經理 Brian Sa](https://www.linkedin.com/pub/brian-sa/2/7a7/a3b) 根據 2011 年日本福島 [毀滅性地震的經歷創建了安全檢查](http://www.telegraph.co.uk/news/worldnews/asia/japan/8953574/Japan-earthquake-tsunami-and-Fukushima-nuclear-disaster-2011-review.html) 。 他在@Scale 發表的演講中講述了自己的故事，這是他感人至深的故事。 地震期間，布萊恩（Brian）在 Facebook 上張貼了一條標語，提供了有用的信息來源，但他被感動找到了一種更好的方式來幫助有需要的人。 那一刻成為安全檢查。 我對安全檢查的第一反應是該死，為什么以前沒有人想到這個？ 這是一個強大的主意。 當我聽 [相同視頻](https://www.youtube.com/watch?v=ptsCWGZW_P8) 和 [Peter Cottle ]](https://www.linkedin.com/pub/peter-cottle/a/961/387) ，Facebook 的軟件工程師，他還談到了建筑安全檢查。 可能只有 Facebook 可以創建安全檢查。 此觀察與 Brian 在演講中的主要課程很好地吻合： * **以只有您可以** 的方式解決實際問題。 與其走傳統路線，不如想想您和您的公司可以扮演的獨特角色。 只有 Facebook 可以創建安全檢查，不是因為您可能會想到資源，而是因為 Facebook 允許員工進行諸如安全檢查之類的瘋狂事情，并且因為只有 Facebook 擁有 15 億地理分布的用戶，而他們之間只有一定程度的分離 4.74 條優勢，只有 Facebook 擁有狂熱于閱讀新聞源的用戶。 稍后再詳細介紹。 實際上，Peter 在 Facebook 的產品開發 Catch-22 中談到了資源是如何成為問題的。 安全檢查小組很小，沒有很多資源。 他們必須先構建產品并在沒有資源的情況下證明其成功，然后才能獲得構建產品的資源。 必須在不花費大量金錢和資源的情況下大規模有效地解決該問題。 通常情況下，約束條件導致了一個明智的解決方案。 一個小的團隊無法建立龐大的管道和索引，因此他們編寫了一些駭人聽聞的 PHP 并有效地大規模完成了這項工作。 那么 Facebook 如何建立安全檢查？ 這是我對 Brian 和 Peter 的演講的掩飾： * 您可以將 Facebook 視為這種巨大的原始湯。 數十億人使用 Facebook，隨著時間的流逝，各種行為開始浮出水面，有些趨勢在不斷蔓延。 * 一個病毒性的例子是用戶如何開始將自己的個人資料圖片更新為紅色的平等標志，以表示婚姻平等。 * 在支持下，Facebook 建立了 Rainbow 覆蓋工具，使使用個人資料圖片進行交流變得更加容易。 這種做法最早起源于 Facebook。 在發明狀態消息之前，用戶將更改其個人資料圖片以傳達其當前的時代精神。 * 輕松自定義個人資料圖片**的采用率提高了 1000 倍**。 * 這使他們有了 **的概念，使人們在災難中更容易告訴朋友他們還可以** 。 * 在災難期間，人們會更新狀態，說他們還可以。 * 這不是讓人們知道您還可以的問題的理想解決方案。 * 它不是很結構化。 雙向都有問題，告訴人們您沒事的方向，而您的朋友得到您沒事的信息。 * 首先，不是所有的朋友都能看到此更新。 * 第二，用戶無法獲取受災難影響的所有朋友的名單。 * 在災難狀態通知問題上應用更加結構化的思想導致 [安全檢查](https://www.facebook.com/about/safetycheck/) 。 * 工作原理： * 如果您身處災區，Facebook 會給您發送推送通知，詢問您是否還可以。 （關于災難發生的時間由誰決定什么也沒說）。 * 輕按“我很安全”按鈕表示您很安全。 * 通知所有朋友您安全。 * 朋友還可以查看受災影響的所有人員及其生活狀況的列表。 * 您如何在特定區域中建立受災難影響的人員群體？ 建立地理索引是顯而易見的解決方案，但是它有缺點。 * 人們在不斷移動，因此索引會過時。 * 擁有 15 億人口的地理索引非常龐大，并且會占用很多他們沒有的資源。 請記住，這是一個很小的團隊，沒有大量資源來嘗試實施解決方案。 * 該解決方案應該始終在發生事件時才起作用，而不是一直保持活動狀態很少使用的數據管道。 這要求能夠進行動態 **動態即時** 查詢。 * 解決方案 **利用社交圖的形狀及其屬性** 。 * 如果發生災難，例如尼泊爾的地震，則在每個新聞提要負載 中都會打開 **安全檢查鉤。** * **人們檢查其新聞提要時，掛鉤將執行**。 如果檢查新聞源的人不在尼泊爾，那么什么也不會發生。 * 當尼泊爾某人查看其新聞時，就是發生魔術的時候。 * 安全檢查 **在社交網絡上向所有好友** 狂熱。 如果朋友在同一地區，則將發送推送通知，詢問他們是否可以。 * **該過程保持遞歸重復** 。 對于在災區找到的每個朋友，都會派出工作來檢查他們的朋友。 通知根據需要發送。 * 實際上，該**溶液是** **非常有效的**。 因為該算法能很快地找到人，所以產品體驗讓人感到實時和即時。 例如，同一房間中的每個人似乎都會同時收到他們的通知。 為什么？ * 使用新聞提要會給用戶提供**隨機抽樣，偏向于最活躍的用戶** **和最多的朋友**。 并且它過濾掉不活動的用戶，這是數十億行不需要執行的計算。 * **圖是密集且互連的** 。 [六度凱文·培根](https://en.wikipedia.org/wiki/Six_Degrees_of_Kevin_Bacon) 是錯誤的，至少在 Facebook 上是這樣。 Facebook 的 15 億用戶中，任意兩個用戶之間的 **平均距離為 4.74 邊緣** 。 抱歉，凱文。 擁有 15 億用戶，整個圖表可在 5 跳內進行瀏覽。 通過遵循社交圖譜可以有效地聯系到大多數人。 * 使用社交圖譜方法免費提供了 **許多并行性** 。 可以將好友分配給不同的計算機并進行并行處理。 他們的朋友一樣，依此類推。 * **競爭條件成為問題的解決方案** 對解決方案的分布式性質造成了影響。 * 兩個不同數據中心中的兩臺機器的用戶與同一個人成為朋友。 這意味著要遍歷兩個邊緣，最終會向同一個人發送兩個通知。 * 認為這沒什么大不了的，但實際上，用戶發現在災難情況下獲得多個通知確實壓力很大。 用戶認為如果他們同時收到兩個通知，他們一定會遇到麻煩。 而且，您也不希望與安全相關的項目在災難中感到車禍。 * 數據庫用于存儲狀態，因此只有一臺計算機可以檢查用戶。 問題是當您有多個數據中心時，例如在歐洲一個在美國，一個在美國，則傳播延遲使確定用戶是否正在處理的時間過長。 * 為兩層解決方案添加了內存中鎖定結構。 檢查內存中鎖定，如果為用戶設置了該位，則該用戶的作業將中止。 * 最大的產品推出是針對尼泊爾地震。 * 在不到 5 分鐘的時間內，邀請了 300 萬人發表他們的身份。 尼泊爾的人口太多，因此要檢查 10 億行。 * **在大約 5 分鐘內瀏覽了 Facebook 用戶群的 2 / 3rd** 。 * 在構建安全檢查的第一個版本時遇到一些問題。 * 臺式機，移動網絡和本機應用程序的碎片化在跨多個平臺管理內容，功能和操作方面造成了極大的復雜性。 * 想要個性化需要手動編碼的內容，該編碼緩慢，乏味且容易出錯。 * 當系統僅在緊急情況下處于開機狀態時，很難判斷它是否在緊急情況下可以正常工作。 * 那么，為了構建一個跨平臺但仍然可以本地響應的系統，應該采用哪種客戶端-服務器模型？ 如何包含動態內容？ 如何測試系統以確保其可靠性？ * 選擇讓服務器負責文本和圖像以及配置信息。 客戶端將預取數據，處理實時失效，并本地響應客戶端事件。 * 實時失效。 * 每當您處理預取的數據時，務必指定該數據應何時過期。 例如，如果用戶打開該應用程序并上傳了一些數據，則他們關閉該應用程序并僅在幾天后打開它。 如果上載的數據是選舉公告，則如果選舉通過，則用戶不應看到該公告。 * TTL（生存時間）參數告訴客戶端在需要刷新數據之前可以使用數據多長時間。 * 交互計數指示用戶可以與數據交互多少次。 * 更多可選的過濾器，例如：remaining_battery_percentage，如果設備電量不足，它將告訴客戶端不要向用戶顯示消息。 * 強制執行內容限制 * 指定文本中的最大行數不是一個好主意。 字符串翻譯成其他語言時，可能會急劇增長。 * 不同的平臺和設備具有不同的屏幕尺寸，因此一個固定的限制無效。 * 因此，請在服務器上定義內容長度限制，并內置一個緩沖區以應對較長的翻譯。 * 動態內容 * 這樣可以對安全檢查消息進行個性化設置，例如在文本中插入用戶名。 * 提出了一種語言，例如郵件合并，以指定諸如“危機名稱”和“危機 URL”之類的替代詞。 * 正緩存 * 您記得以前符合資格的單位 * 安全檢查是與用戶保持固定通信渠道的設備類型。 對于事件持續時間，沒有視圖限制。 如果在星期五將其打開，則將持續交付直到星期五將其關閉。 * 正向緩存有利于長期運行的單元，因為您無需評估任何單元的資格。 您確實需要檢查緩存單元的資格，因為您不想顯示它超出預期的時間。 * 負緩存 * 您記得沒有單位合格的地方。 * 琥珀色警報是一次性消息。 這種類型的設備的負載曲線確實不同。 例如，如果它是在上午 8:50 開啟的，那么在上午 9:00 之前它已經達到峰值投放，然后衰減很快。 一小時內達到了一半的人，三小時內幾乎達到了所有目標受眾。 * 負緩存有利于短期運行的單元，因為在大多數情況下，沒有可顯示的單元。 負緩存記住了這一事實。 * 黑暗發射 * 使用實時流量測試了系統，以發現意外問題。 使用了一個標志使它對用戶隱藏，因此不會對用戶造成影響。 * 運行測試 24 小時發現了一些意外問題。 產生社交句子的子系統之一的容量不足。 * 終止開關 * Facebook 由數百個聯鎖系統組成。 * 有時，在發生災難性故障的情況下，您需要快速減輕負載。 * Kill 開關使您可以完全關閉整個系統。 您還可以殺死特定的應用程序版本或設備。 ## 相關文章 * [上 reddit](https://www.reddit.com/r/tech/comments/3mq29e/how_facebook_tells_your_friends_youre_safe_in_a/)