WhatsApp 是一種社交消息程序,允許用戶相互交換消息。
您是否考慮過 WhatsApp 的工作原理?
支撐其創建和運營的概念是什麼?
本文將介紹 WhatsApp 的基礎知識 系統設計.
我們還將介紹 WhatsApp 的通用架構,該架構可用於構建任何類型的聊天軟件。
那麼,廢話不多說,讓我們來看看WhatsApp的系統設計吧!
一、關鍵要求
WhatsApp 是一種高度可擴展的技術,世界各地的許多人都在使用它。 因此,它應該經過精心設計,幾乎始終可靠且正常運行。
因此,確定係統的關鍵需求至關重要。
以下是 WhatsApp Messenger 的最低要求:
- 能夠促進一對一的互動。
- 消息確認和上次看到都是可能的(發送、傳遞和讀取)。
- 允許端到端加密和媒體支持(圖像/視頻)。
讓我們找出我們必要的服務需要多少容量。
2. 估計容量
我們的目標是創建一個能夠處理大量流量的平台。 假設每天發送 10 億條短信。 我們有:
- 每天有 10 億人發送 XNUMX 億條短信。
- 在高峰流量(每秒),有 700,000 人處於活躍狀態(平均 6 倍)
- 在高峰使用期間,每秒傳輸 40 萬條消息。
- 一條消息的平均長度為 160 個字符:每天產生 10B * 160 = 1.6TB 的數據。
- 以服務十年為例:10*1.6B*365PB
- 整個應用程序將由微服務組成,每個微服務都將執行一項專門的任務。 假設發送一條消息需要 20 毫秒,並且每台服務器有 100 個並發連接。 因此,預期所需的聊天服務器數量 =(每秒聊天消息延遲)/每台服務器的並發連接數 = 40M * 20ms / 100 = 8000 個服務器。
3. 高層架構
該系統建立在兩個核心服務之上。 例如聊天服務和臨時服務。 聊天服務處理用戶在線消息產生的所有流量。 同時,臨時服務在用戶離線時處理流量。
如果用戶在線,則聊天服務負責傳遞消息。
它將驗證消息的收件人是否在線; 如果收件人在線,該服務將立即傳遞消息; 如果收件人不在線,則臨時服務將在他們返回在線時將消息發送給他們。
臨時服務保留一個單獨的存儲區域,用於保存臨時可訪問的數據,直到離線用戶重新連接。
設計高級 API
該服務有兩個用於發送和讀取消息的高級功能 API。 該系統可以使用 REST 架構來實現。
發送消息的參數
此 API 將用於在兩個用戶之間傳輸消息。
對話參數
此 API 用於顯示線程聊天。 考慮一下這是您打開 WhatsApp 時看到的第一件事。 我們只想在單個 API 查詢中為一個用戶獲取幾條消息。 為了處理這個問題,需要偏移量和消息計數參數。
上次看到、單勾和雙勾等特徵的功能是什麼?
在部署這些服務中的重要作用是確認服務。 由於該服務繼續生成和驗證確認答案,因此開發了這些功能。
- 單tick:當來自用戶 A 的消息到達用戶 B 時,服務器會發送一個單次滴答,確認消息已發送。
- 雙勾:當服務器的消息通過正確的連接發送給用戶 B 後,用戶 B 將向服務器確認收到消息。 然後服務器將向用戶 A 提供另一個確認。 結果,將出現重複的勾號。
- 藍勾: 用戶 B 將在檢查消息後向服務器發送另一個確認。 然後,服務器將向用戶 A 發送一條額外的確認消息。 之後,用戶 A 的屏幕上會出現一個藍色勾號。
- 最後出現:心跳機製完全負責最後一次看到的功能。 每隔 5 秒,就會向服務器發送一個心跳,服務器會在一個表中跟踪每個用戶最後一次看到的狀態,任何其他用戶都可以輕鬆訪問該表。
4. 設計關鍵功能
個性化互動
這是聊天服務的必要組成部分。 用戶可以簡單地使用此服務向另一個用戶發送消息。 讓我們看看這是如何工作的:
假設 Jay 想與 Aayush 交流。 Jay 與他接收消息的聊天服務器相關聯。 Jay 從聊天服務器收到消息已發送的確認信息。 聊天服務器現在正在從數據存儲中請求有關 Aayush 連接到的聊天服務器的信息。 Jay 的聊天服務器現在將消息傳輸到 Aayush 的聊天服務器,Aayush 通過推送機制接收消息。 Aayush 現在向 Jay 的聊天服務器發送確認消息,通知 Jay 消息已送達。 如果 Aayush 再次閱讀該消息,則會向 Jay 發送一條新的確認消息,即該消息已被閱讀。
用戶活動狀態
一個人上一次活動的時間是即時通訊程序的常規功能。
該圖中描繪了用於維護客戶端和服務器之間的連接的系統。 Web 套接字用於在服務器和客戶端之間建立雙向連接。 這些連接發送心跳,用於監控用戶的活動狀態。
端到端隱私
端到端加密是一項關鍵功能,可確保只有會話用戶才能讀取通信。 公鑰在參與通信的所有用戶之間共享,對於維持端到端加密至關重要。 假設頻道上有兩個用戶,Jay 和 Aayush,他們相互通信。
Jay 擁有 Aayush 的公鑰,Aayush 擁有 Jay 的公鑰以及他們的非共享私鑰。 結果,Jay 在傳輸消息時,使用 Aayush 的公鑰對其進行加密,而該公鑰只能使用 Aayush 的私鑰進行解碼。
同樣,Jay 將只能解碼 Aayush 的通信。 這樣一來,只有 Jay 和 Aaysuh 可以看到彼此的通信,而服務器在整個過程中只是充當網關。
5. 瓶頸
每個系統都容易出現故障。 為了管理如此大量的流量,服務必須始終保持運行和容錯,以避免出現瓶頸。 因為我們的服務完全依賴於 Chat 和 Transient 服務器,所以我們必須解決它們運行中出現的所有問題。
聊天服務器故障: 這是我們系統的核心。 當用戶在線時,它負責管理和傳遞消息。 因此,該系統與其用戶保持聯繫。
結果,如果這個服務失敗,整個架構都會受到影響。 有兩種方法可以管理聊天服務器的故障。 一種方法是將 TCP 連接轉移到另一台服務器,而另一種方法是允許用戶在連接丟失的情況下自動開始連接。
瞬態存儲故障:另一個容易發生故障並最終可能損壞整個服務的組件是瞬態存儲。 如果此服務失敗,發送給離線用戶的消息會丟失。
我們可以通過複製每個用戶的臨時存儲來防止消息丟失。 因此,只要用戶在線返回,就可以使用副本來處理功能。 如果原始服務器變得可訪問,則用戶臨時存儲的原始實例和副本實例都將合併到一個存儲中。
6. 優化技術
潛伏:為了提供無縫和改進的客戶體驗,信使服務必須是實時的。 因此,必須通過緩存部分經常訪問的數據來減少延遲。 我們可以使用像 Redis 這樣的分佈式緩存在內存中緩存用戶活動狀態和最近的對話。
產品狀況:我們需要我們的服務在大部分時間都可用。 我們的系統必須是容錯的,因此我們可以保留多個臨時消息副本,以便任何丟失的消息都可以從其副本中快速恢復。 因此,系統的可用性不會受到損害。
結論
我們的系統現在只支持少數功能,但我們可以輕鬆擴展它以添加群聊以將消息分發給多個人。 您還可以提供視頻和電話通話功能。 還可以開發該系統,以便用戶可以發布狀態更新或敘述並相互閱讀。
我努力為您提供 WhatsApp 系統設計的高級概述。 我希望你喜歡它並且會好好利用它。
發表評論