本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Amazon Kinesis Data Streams 中的恢復能力
<a name="disaster-recovery-resiliency"></a>

 AWS 全球基礎設施是以 AWS 區域和可用區域為基礎建置的。 AWS 區域提供多個實體隔離和隔離的可用區域，這些區域以低延遲、高輸送量和高度備援的網路連接。透過可用區域，您所設計與操作的應用程式和資料庫，就能夠在可用區域之間自動容錯移轉，而不會發生中斷。可用區域的可用性、容錯能力和擴充能力，均較單一或多個資料中心的傳統基礎設施還高。

如需 AWS 區域和可用區域的詳細資訊，請參閱 [AWS 全球基礎設施](https://aws.amazon.com/about-aws/global-infrastructure/)。

除了 AWS 全球基礎設施之外，Kinesis Data Streams 還提供數種功能，以協助支援您的資料彈性和備份需求。

## Amazon Kinesis Data Streams 中的災難復原
<a name="disaster-recovery"></a>

當您使用 Amazon Kinesis Data Streams 應用程式處理來自串流的資料時，以下層面可能發生失敗：
+ 記錄處理器失敗
+ 工作者失敗，或是執行個體化工作者的應用程式執行個體失敗 
+ 託管應用程式一個或多個執行個體的 EC2 執行個體失敗

### 記錄處理器故障
<a name="kinesis-record-processor-failure-processor"></a>

工作者會使用 Java [ExecutorService](http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ExecutorService.html) 任務叫用記錄處理器方法。若有任務發生失敗，工作者將對記錄處理器原先處理的碎片保有控制權。工作者會啟動新的記錄處理器任務以處理該碎片。如需詳細資訊，請參閱[讀取限流](kinesis-record-processor-additional-considerations.md#kinesis-record-processor-read-throttling)。

### 工作者或應用程式故障
<a name="kinesis-record-processor-failure-worker"></a>

如果工作者 (或 Amazon Kinesis Data Streams 的執行個體) 發生失敗，您即應偵測並處理該情況。例如，若 `Worker.run` 方法擲回例外狀況，您應將其截獲並加以處理。

如果應用程式本身發生失敗，您應對其進行偵測並予重新啟動。應用程式啟動時會執行個體化新的工作者，再由後者執行個體化新的記錄處理器，系統將自動指派碎片供其處理。這些碎片可能是該等記錄處理器在發生失敗前處理過的同一批碎片，或是另行指派給該等記錄處理器的新碎片。

在工作者或應用程式失敗的情況下，如果未偵測到失敗，且在其他 EC 2 執行個體上執行的應用程式有其他執行個體，這些其他執行個體則會處理失敗。它們會建立其他記錄處理器，來處理失敗的工作者不再處理的碎片。上述其他 EC2 執行個體的負載也會相應地增加。

此處描述的情節假定即使工作者或應用程式已失敗，託管 EC2 執行個體仍將執行中，因而並不會由 Auto Scaling 群組重新啟動。

### Amazon EC2 執行個體失敗
<a name="kinesis-record-processor-failure-instance"></a>

建議您在 Auto Scaling 群組中執行 EC2 執行個體以用於您的應用程式。如此一來，若其中一個 EC2 執行個體發生失敗，Auto Scaling 群組會自動啟動新的執行個體予以取代。您應該將執行個體設定為在啟動時同時啟動 Amazon Kinesis Data Streams 應用程式。