如何避免從給定的分佈式架構

Question

單點故障我通過這個video - Scalability Harvard Web Development David Malan

去這是我卡住了。說明問題 -

讓我們假設LB採用循環賽樣的辦法。

根據第一張圖片，所有服務器都將會話存儲在其本地空間中，而其他服務器無法訪問該會話。如果下次有相同的請求，並且LB將這個請求重定向到另一個服務器，那麼服務器會詢問認證。從用戶的角度來看，這非常令人不快。

根據第二張圖片，所有服務器都在共享會話。在這種情況下，當下一個請求來自同一個客戶端時，LB重定向到另一個服務器。現在，它不會要求認證，而是從會話主機獲取信息。

這是在上面的視頻鏈接中提到的。

問題 -

1. 現在會話主機成爲單點故障。如果主機停機，它會嚴重影響可用性。我們如何避免這種情況？

Answer 1

您有這些選項（假設會話的東西，可以不收任何費用丟失）

1）會話數據倉庫是一個高度可用的數據存儲。例如：您可以將MongoDB副本集用於此類會話存儲。它由MongoDB的三個節點組成，主節點和兩個從節點（最少），當主節點關閉時，其中一個節點被提升爲主節點。這次選舉可能需要幾秒鐘，但會議不會丟失。

2）使用內存數據共享庫，它可以進行數據分區以及複製。一個例子是Java的Hazelcast。它爲您提供跨Web層的對象級別共享，在這裏您可以存儲共享的會話。請注意AFAIK在這種情況下沒有數據持久性（在磁盤上）。

3）我到目前爲止使用的最具可擴展性的方法是擁有客戶端會話和無服務器端數據/會話存儲。在這種情況下你可以做的事情是在每個應用服務器上存儲一個非常長的密鑰，並且在用這個密鑰加密數據後將所有數據設置在cookie中。這種方法唯一的問題是，您需要對會話中存儲的內容進行選擇，因爲Cookie上的數據大小有限制。這種加密是雙向的。大多數基於SAAS的工具都使用這種方法。

Answer 2

將會話主機實施爲複製數據存儲有助於消除單點故障。例如，使用像Hazelcast這樣的複製高速緩存將保持高速緩存的複製和分發，從而消除單點故障。還有其他像Memcached和Mongo。自動故障轉移可以通過虛擬IP地址來實現。

Answer 3

出於這個確切原因，通常會話主機（例如memcache）面向VIP（虛擬IP）並且擁有多個主機。在分佈式架構中，您通常希望擁有1-N個主機。大多數大規模運營的公司都會生成使用數據存儲，如Couchbase（memcahce存儲桶）來存儲會話狀態，因爲它是快速，冗餘和高度可擴展的。