縮放多個區域的身份識別服務

Question

我們有用戶數據庫，用於創建/更新用戶以及識別（讀取）用戶。我們閱讀的次數比我們寫的更多。寫約100萬/天，閱讀大約1億多。我們可以分開讀寫，但是AFAIK需要很強的一致性。

如果我們從讀取副本開始讀取，它將最終保持一致。用戶創建時可能會出現一些情況，但尚未在只讀副本中提供。或者，用戶已經更新了一些信息（名稱），並且這種改變在其他地區尚未出現。僅從一個地區服務意味着其他地區的更高延遲。

我們目前正在使用RDBMS。 Netflix's Active-Active blog是一個很好的閱讀。但這將是一個巨大的變化。最重要的是，它需要團隊/組織的思維模式改變。另外，要正確做到這一點需要付出很多努力。我們需要立即採取一些措施，因爲緩慢的反應會影響業務。因此，我正試圖探索其他可能給我們留出空間和時間來考慮實際實施的方案。

作爲第一步，我計劃在不同地區使用低TTL的一級緩存。這會減少相當多的讀取。這又將是最終一致的。

第二步可能會導致緩存失效。這可以稍微減少不一致。這又將是最終一致的。

• 還有其他的選擇嗎？
• 公司如Google，Facebook等 規模？
• 我不想進入分片。或者，我應該嗎？我們確實有 自動增量。
• 最終的一致性真的是如此巨大的痛苦嗎？ I 在面向讀取的情況下具有它的經驗，但是這個是 可讀/寫。

[編輯] - 基於的意見/建議

我在這裏談論不同的AWS區域。由於我們有單寫系統（1 RDBMS），所有寫操作只會到達一個區域。但是爲了實現多區域讀取，即使通過數據庫或自定義（例如SNS + SQS或Dynamodb流）進行異步複製，也可能會因爲調用跨區域邊界而延遲。由於網絡問題可能會導致故障，這可能會再次導致延遲（重試等）。

是的，最終的一致性將有所幫助，但我們將不得不考慮上面列出的問題。我們可能不得不接受一些不一致和失敗。有時可能通過支持來處理客戶問題。我還認爲，與這些問題相比，這些問題相對較少，大多數時候這些問題都是暫時的。如果有的話，我試圖找出更好更簡單的解決方案。我認爲這是我們許多人試圖解決或許多人已經解決的問題。因此，更好地引導和學習。

在此先感謝！

Answer 1

我覺得你的解決方案（在不同地區擁有隻讀副本，並具有低ttl的第一級內存緩存）是合適的。從內存緩存中爲客戶提供服務。如果用戶對象不在此緩存中，請從讀取副本 - >緩存中存儲 - >提供服務。如果用戶更改了名稱;只需更新內存緩存並創建異步事件（可能通過發送JMS消息）來更新主數據庫。

因爲你在內存中的用戶將會看到更新的信息。

請注意，此解決方案非常完美，因爲這是針對IAM的，而不是用於產品信息之類的內容，因爲用戶一次只能從一個位置登錄。