0
我對食物交付網絡/移動應用程序冗餘和故障轉移策略。關鍵是，我的服務器做更多的寫道：比讀取到數據庫。現在我運行的是PostgreSQL，問題在於很多服務器請求在短時間內（中午和晚上）發生，所以我需要各種實例（加上S3進行備份）才能夠實現寫道吞吐量，我認爲這不是什麼接近好的，因爲事情正在擴大，這些PG實例看起來像是兔子的複製。如何實現的Redis支持服務器
我的約束：
- 更寫道：比讀取
- 大約在25.000 REQ/s的寫入和成長
- 我需要的強一致性的數據，同時保證未在系統中註冊後處理（消費者訂單由餐廳檢查）（在數據庫中寫入）
- 優選的是，沒有一個服務運行，而不是有（有利於一致性的犧牲可用性）有故障的一個
做一些基準與我的生產服務器，Redis的能夠處理的1.5倍我的電流峯值只有一臺服務器，並有一個List結構，這對管理訂單隊列非常有用。
，我讀了Redis的，不與哨兵/羣集的箱子不能夠提供很強的一致性，因此，要實現這一點，我認爲這樣做的這2件事情之一：
- 集哨兵用3個實例（1個主2個從站）與
Wait和appendfsync always策略配置，並檢查客戶端的時候，不到2這樣Wait返回時，哨兵將採取與我的服務器的幫助下，將始終保持複製和故障轉移和護理一致性強。 - 第二個選項是有相同的3個實例與
appendfsync always，而是簡單地在這3個通過我的應用程序服務器應用軟件RAID 1，但這樣一來，我就不得不考慮在控制邏輯，以實現冗餘和故障轉移功能。當試圖在代理後面擴展我的應用程序（node.js）時，問題將會發生，因爲爲了提供完全冗餘，我將不得不管理在每個Redis實例中寫入的嘗試，並且如果此應用程序關閉，另一個可能不知道3是否同步以及要同步的最新數據是什麼。
從我的角度來看，第二個選擇似乎比第一個更健壯，因爲在此我只能鬆一臺服務器，而在第二個選項，我可以使用任何3，條件是我保證一致性。
我缺少什麼？建議？