本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
Amazon 中的復原能力 ElastiCache
AWS 全域基礎設施是以 AWS 區域和可用區域為基礎。 AWS 區域提供多個實體隔離和隔離的可用區域，這些區域與低延遲、高輸送量和高冗餘聯網連接。透過可用區域，您所設計與操作的應用程式和資料庫，就能夠在可用區域之間自動容錯移轉，而不會發生中斷。可用區域的可用性、容錯能力和擴充能力，均較單一或多個資料中心的傳統基礎設施還高。
如需 AWS 區域和可用區域的詳細資訊，請參閱AWS 全域基礎設施。
除了 AWS 全球基礎設施之外，Amazon ElastiCache 還提供多種功能，以協助支援您的資料彈性和備份需求。
主題
減少故障
規劃 Amazon ElastiCache 實作時，您應該規劃 ，讓失敗對您的應用程式和資料產生最小的影響。本節中的主題涵蓋您可以採取用來保護您的應用程式和資料不受故障的方法。
緩解執行 Memcached 時的故障
執行 Memcached 引擎時，您有下列選項可用於將故障的影響最小化。在您的故障緩解規劃中要解決兩個類型的故障：節點故障和可用區域故障。
緩解節點故障
無伺服器快取會利用複寫的 Multi-AZ 架構自動緩解節點故障，讓應用程式清楚了解節點故障的情況。若要緩解自行設計叢集中節點故障的影響，請將您的快取資料分散到多個節點。因為自行設計的叢集不支援複寫，因此節點故障將一律造成您的叢集遺失一些資料。
當您建立 Memcached 叢集時，您可以建立 1 到 60 個節點的叢集，或依特殊要求建立更多節點。將您的資料分割在更大量的節點間表示若節點故障，您遺失的資料較少。例如，如果將您的資料分割在 10 個節點間，任何單一節點大約會存放 10% 的快取資料。在此情況下，節點故障會遺失大約 10% 的快取，這個部分需要在建立和佈建替代節點時加以替代。如果在 3 個較大節點中快取相同的資料，節點的故障會遺失大約 33% 的快取資料。
如需指定 Memcached 叢集中節點數量的詳細資訊，請參閱建立 Memcached 叢集 (主控台)。
緩解可用區域故障
無伺服器快取會利用複寫的 Multi-AZ 架構自動緩解可用區域故障，讓應用程式清楚了解 AZ 故障的情況。
若要緩解自行設計叢集中可用區域故障的影響，請盡可能將您的節點分散放到多個可用區域中。萬一發生 AZ 故障，您將遺失在該 AZ 中快取的資料，而不是在其他 中快取的資料AZs。
為什麼要有這麼多節點？
如果我的區域只有 3 個可用區域，既然若一個 AZ 故障，我會遺失大約 1/3 的資料，為什麼我需要超過 3 個節點？
這是個好問題。請記得我們正嘗試緩解兩個獨特類型的故障，節點和可用區域。您是對的，如果您的資料分散在可用區域間，當其中一個區域故障時，您只會遺失在該 AZ 中快取的資料，而不論您擁有的節點數量為何。不過，如果某個節點故障，擁有的節點數量越多可減少資料遺失的比例。
沒有「神奇公式」可決定您叢集中的節點數量。您必須衡量資料遺失的影響、故障可能性與成本，並從中得出自己的結論。
如需指定 Memcached 叢集中節點數量的詳細資訊，請參閱建立 Memcached 叢集 (主控台)。
如需區域和可用區域的詳細資訊，請參閱區域和可用區域。
緩解執行 Valkey 或 Redis 時的失敗 OSS
執行 Valkey 或 Redis OSS引擎時，您有下列選項，可將節點或可用區域故障的影響降至最低。
緩解節點故障
無伺服器快取會利用 Multi-AZ 架構自動緩解節點故障，讓應用程式清楚了解節點故障的情況。自行設計的叢集必須經過適當設定，才能緩解個別節點的故障。
若要減輕 Valkey 或 Redis OSS節點故障對自行設計叢集的影響，您有下列選項：
緩解失敗：Valkey 或 Redis OSS 複寫群組
Valkey 或 Redis OSS複寫群組由單一主節點組成，您的應用程式可以讀取和寫入 1 到 5 個唯讀複本節點。每當資料寫入主要節點，它也會在僅供讀取複本節點上非同步更新。
當僅供讀取複本故障時
ElastiCache 會偵測失敗的僅供讀取複本。
ElastiCache 會取得失敗的節點離線。
ElastiCache 在相同的 AZ 中啟動和佈建取代節點。
新節點會與主要節點同步。
在這段時間，您的應用程式可以繼續使用其他節點來讀取和寫入。
Valkey 或 Redis OSS Multi-AZ
您可以在 Valkey 或 Redis OSS複寫群組上啟用多可用區。無論您是否啟用多個可用區，系統將偵測並自動取代故障的主要節點。它的發生方式可能因多可用區域是否已啟用而不同。
當多個可用區啟用時
ElastiCache 會偵測主要節點失敗。
ElastiCache 會將複寫延遲最低的僅供讀取複本節點提升為主要節點。
另一個複本與新主要節點同步。
ElastiCache 會在失敗的 主要 的 AZ 中啟動僅供讀取複本。
新節點會與新提升的主要節點同步。
容錯移轉至複本節點的速度一般會較建立和佈建新主要節點來得快。這表示您的應用程式可以較未啟用多個可用區時更早繼續寫入至您的主要節點。
如需詳細資訊，請參閱搭配 Valkey 和 Redis ElastiCache 使用多可用區域，將 中的停機時間降到最低 OSS。
當多個可用區停用時
ElastiCache 會偵測主要失敗。
ElastiCache 會離線使用主要 。
ElastiCache 會建立新的主要節點並佈建，以取代失敗的主要節點。
ElastiCache 會將新的主要 與其中一個現有複本同步。
同步完成時，新節點會如同叢集的主要節點般運作。
在此程序期間的步驟 1 到 4 期間，您的應用程式無法寫入主要節點。不過，應用程式可以繼續從複本節點讀取。
為了獲得更多保護，建議您在不同可用區域 （） 中啟動複寫群組中的節點AZs。如果您執行此動作，可用區域的故障只會影響該可用區域 (而非其他區域) 中的節點。
如需詳細資訊，請參閱使用複寫群組的高可用性。
緩解可用區域故障
無伺服器快取會利用複寫的 Multi-AZ 架構自動緩解可用區域故障，讓應用程式清楚了解 AZ 故障的情況。
若要緩解自行設計叢集中可用區域故障的影響，請盡可能將每個碎片的節點分散放到多個可用區域中。
不論碎片中有多少個節點，如果它們全都放在相同可用區域中，只要該可用區域發生災難性故障，就會造成您遺失所有碎片的資料。不過，如果您在多個 中尋找節點AZs，則任何 AZ 的失敗都會導致您僅失去該 AZ 中的節點。
無論您在何時遺失節點，都會遇到效能降級，因為讀取操作現在由較少的節點共用。此效能降級將繼續，直到節點遭到取代為止。
如需指定 Valkey 或 Redis OSS節點可用區域的資訊，請參閱 建立 Valkey （停用叢集模式） 叢集 （主控台）。
如需區域及可用區域的詳細資訊，請參閱選擇 的區域和可用區域 ElastiCache。
建議
我們建議您在自行設計的叢集上建立無伺服器快取，如此您無需額外的組態設定就能自動獲得更優異的容錯能力。不過，建立自行設計的叢集時，您需要針對兩個類型的故障進行規劃：個別節點故障和廣泛的可用區域故障。最佳的故障緩解規劃可解決這兩種類型的故障。
將節點故障的影響降至最低
若要在使用 Valkey 或 Redis 時將節點故障的影響降至最低OSS，建議您實作在每個碎片中使用多個節點，並將節點分佈到多個可用區域。無伺服器快取會自動進行此操作。
對於 Valkey 或 Redis 上的自行設計叢集OSS，我們建議您在複寫群組上啟用多可用區，以便在主要節點失敗時 ElastiCache 自動容錯移轉至複本。
執行 Memcached 並在節點間分割您的資料時，使用的節點愈多，任何節點故障時遺失的資料愈少。
將可用區域故障的影響降到最低
若要將可用區域故障的影響降到最低，建議您在盡可能多的不同可用區域中啟動節點。均勻分散節點AZs，將最大限度地減少 AZ 故障的不太可能事件的影響。無伺服器快取會自動進行此操作。
其他預防工作
如果您正在執行 Valkey 或 Redis OSS，除了上述項目之外，建議您排程叢集的定期備份。備份 (快照) 會建立一個 .rdb 檔案，供您在故障或損毀的情況下用來還原您的快取。如需詳細資訊，請參閱快照和還原。
