我有一個電子商務網站，每天約有 30,000 名用戶，會話次數超過 50,000 次。我們正在使用 RDS m5.xlarge 實例。我們在日常讀取或寫入操作中沒有遇到任何問題。但有時我們會面臨以下挑戰：
- 有時，由於促銷或積極的行銷，我們的用戶數量會增加一倍以上，此時 CPU 會在白天多次達到 100%
- 非常偶爾，當正在進行一些大量寫入時，讀取速度會變慢
看到這裡，我無法判斷是否應該進一步垂直擴展 RDS 實例或旋轉唯讀副本。在做出這個決定時我想考慮兩點：
- 擁有唯讀副本是否可以幫助我消除在高流量日進一步垂直間隔資料庫的需要？
- 我可以降低只讀副本的成本或保持相同的成本，同時實現更高的可擴展性嗎？
平均而言，我在 m5.xlarge 實例上的使用情況如下：
- CPU使用率40%
- 資料庫連線 100
- 已使用 RAM 6 GB
- 125 寫入 IOPS
- 3 讀取IOPS
看起來除了CPU之外的使用率很低，只讀副本是一種在不增加成本的情況下實現更大可擴展性的方法嗎？
答案1
聽起來您需要的是一個自動縮放的 RDS，不幸的是，它不適合計算。
增加 RDS 大小
如果您增加實例大小，您將支付更多 24/7 費用。這是最簡單的解決方案，應該可以減少您的許多問題。如果成本不是問題，這可能是最好的問題。
讀取副本
另一個主要選項是只讀副本。您必須修改您的軟體才能使用唯讀副本，因為它將具有與主資料庫 URL 不同的端點。例如，您可以將所有寫入傳送到主資料庫，並將所有讀取傳送到唯讀副本。只讀副本可能會稍微落後於主伺服器的更新。您甚至可以減小主資料庫的大小 - 但您需要對您的方法進行基準測試或保守。
您可以考慮在任何預期的重大事件之前手動啟動唯讀副本。這將是手動的並且需要一些時間，並且您的應用程式必須處理有時但並非總是存在的資料庫。
快取
根據您的存取模式，在 Redis / Memcached 中快取資料可能會減少資料庫負載，以至於您無需更新資料庫。這當然依賴於必須多次讀取相同的數據，並且有足夠的快取存儲。
極光
你可以考慮適用於 MySQL 的 Amazon Aurora。我自己沒有使用過它，但它的擴展性非常好 - 儘管每個單獨的事務可能不如標準 RDS 更快。
資料庫最佳化
另一種選擇是查看是什麼佔用了資料庫容量並優化“昂貴”查詢或索引。如果您有簡單的查詢並且負載很高，則可能無濟於事。