1、AWS全球數據庫解決方案“三劍客”技術創新，變革未來全球數據庫挑戰12Aurora global database3DynamoDB global tables4ElastiCache global datastore5客戶案例目錄CONTENTS全球數據庫的原因與挑戰為什么我們需要全球部署數據庫？為了災備，需要將數據庫跨region部署為了性能，需要將數據庫在多個region分布，貼近我們的用戶全球部署數據庫的挑戰？搭建多個region內數據庫之間復制環境帶來的技術挑戰維護多個數據庫環境帶來的運維壓力未來的擴展壓力盡量降低secondary region與primary region數據庫之

2、間的復制延遲24 區域77可用區222邊緣節點AWS全球基礎設施區域與可用區Availability Zone AAvailabilityZone BDatacenterDatacenterDatacenterZHY RegionAvailability ZoneAvailability Zone 可用區_ 每個region區域至少有兩個可用區_ 每個可用區都由多個數據中心組成_ 可用區之間地理與網絡都是獨立設計與運營_ 可用區專為實現物理冗余而設計，具有彈性，即使在出現斷電、互聯網停機、洪水和其他自然災害的情 況下也能實現不間斷的性能。Availability Zone CCommon da

3、ta categories and use casesRelationalKey-valueDocumentIn-memoryGraphTime-seriesLedgerQLDBTimestreamNeptuneElastiCacheDynamoDBRDSAuroraCommunity CommercialDocumentDBwith MongDB CompatibilityManaged Cassandra Servicewith Cassandra CompatibilityWide Column全球數據庫挑戰12Aurora global database3DynamoDB global

4、 tables4ElastiCache global datastore5客戶案例目錄CONTENTS媲美高端商業數據庫的速度與可用性媲美開源數據庫的簡單性與成本效益與MySQL及PostgreSQL全面 兼容按使用量計費的簡單定價模式以托管服務形式交付Amazon AuroraAmazon Aurora以開源級成本交付的企業級數據庫Amazon Aurora: 橫向擴展、分布式架構共享存儲卷主副副SQL事務緩存SQL事務緩存SQL事務緩存不再需要妥協！AZ1AZ2AZ3寫入性能讀取橫向擴展可用區+1容錯機制即時數據庫重做恢復將Log機制推送至存儲層4/6寫入仲裁與本地跟蹤“可用區+1”容錯機

5、制為什么？在大規模集群體系中，故障總會出現可用區故障是一種“命中注定”AZ 1AZ 2AZ 3可用區 故障時的 仲裁中斷2/3讀取2/3 寫入AZ 1AZ 2AZ 3可用區故障 時仲裁仍可 繼續起效3/6讀取4/6寫入如何實現？6份副本，每可用區2份2/3仲裁無法滿足需求寫入與讀取吞吐量Aurora MySQL的速度可達MySQL的5倍050,000100,000150,000200,000250,000MySQL 8.0MySQL 5.6Aurora 5.6800,000700,000600,000500,000400,000300,000200,000100,0000MySQL 8.0My

6、SQL 5.6Aurora 5.6MySQL 5.7Aurora 5.7MySQL 5.7Aurora 5.7寫入吞吐量讀取吞吐量在R4.16XL實例上運行Sysbench處理250份表，每份表包含20萬行負載條件下的性能變化SysBench OLTP（只寫）工作負載與250份表，每表20萬行，采用R4.16XL實例1210864200100200400500600300時間以秒為單位Amazon Aurora 一致性提升200倍寫入響應時間（秒）Amazon Aurora MySQL 5.6 on EBS頁面緩存更新Aurora 主節點30% 讀取70% 寫入Aurora副節點100% 新讀

7、取共享多可用區存儲MySQL 主節點30% 讀取70% 寫入MySQL副節點30% 讀取70% 寫入單線程二進制日志數據卷數據卷Aurora region內高可用與只讀副本的實現使用完整的變更邏輯相同的寫入工作負載獨立存儲以物理方式使用delta變更不向副節點寫入 共享存儲MYSQL 讀取擴展 AMAZON AURORA 讀取擴展 “在MySQL當中，我們看到復制延遲達到近12分鐘。從實際應用的角度來 看，這顯然是種近乎荒謬的情況。利用Aurora，4個副本的最大讀取延遲從 未超過20毫秒?！盉inlog Replica Lag (sec.)Aurora物理復制延遲（毫秒）Aurora邏輯復制

8、延遲（秒）Amazon Aurora MySQL region內邏輯與物理復制延遲將遠程的readers 提升為master快速的跨region災難恢復更方便的跨region遷移數據方法讓客戶的數據分布到不同region，更貼近用戶次秒級跨region數據復制更快的災難恢復和數據貼近用戶全局物理復制1ASYNC 4/6 quorumContinuousbackupAZ 1Primary instanceAmazonS3AZ 2Replica instancePrimary regionAZ 3Replica instanceReplicationserverReplication FleetS

9、torage fleet114Secondary regionAZ 1Replica instanceAZ 2AZ 3ASYNC 4/6 quorumContinuous backupAmazon S3Replica instanceReplica instanceReplication agentReplication FleetStorage fleet332 主實例將日志記錄并行發送到存儲節點, 只讀實例和復制服務器 復制服務器將日志流發送到secondary region的復制代理 復制代理將日志并行發送給存儲節點和只讀副本 復制服務器可以從存儲節點拉日志記錄以彌補故障造成的間隙高吞吐

10、: 即使高達150K writes/second的負載; 復制對性能的 影響也是微乎其微低復制延遲: 高負載下依然保持次秒級跨區域復制延遲 快速恢復: 區域故障后1分鐘以內即可承擔全面讀寫物理復制1000200300600500400050,000100,000150,000200,000250,000secondsQPSQPSLag邏輯復制0.001.002.003.004.005.00050,000100,000150,000200,000250,000secondsQPSQPSLag邏輯復制vs. 物理復制全局復制性能Active-active cross-Region setup wi

11、th Aurora Global DatabaseVersion of the application stack is set up in another Region torecover from disasters and serve fast local readsApplicationWRRead erWrit erRead erPrimary RegionDatabase storageApplicationRRead erRead erSecondary RegionDatabase storageRead erDNSFailover with Aurora Global Dat

12、abaseApplication stack can be spun up in the secondary region and traffic can begin to berouted there (via DNS) with the promoted writer serving write requests within 1 minuteApplication WRRead erWrit erRead erPrimary RegionDatabase storageApplicationWRRead erWrit erRead erPromoted RegionDatabase st

13、orageDNS全局數據庫Primary region (US West)Secondary region (US East)1ASYNC 4/6 quorumContinuousbackupPrimary instanceAmazonS3ReplicationserverReplication FleetStorage fleet14Replica instanceASYNC 4/6 quorumContinuous backupAmazon S3Replication agentReplication FleetStorage fleet332持續插入持續讀取U S West(Writer

14、)U S East(Reader)2019-11-2807:48:15.614.1242019-11-2807:48:15.725.479Replication Lag 110ms全球數據庫挑戰12Aurora global database3DynamoDB global tables4ElastiCache global datastore5客戶案例目錄CONTENTSAmazon DynamoDB鍵-值和文檔數據結構全托管NoSQL訪問控制事件驅動編程可擴展支持任意負載快速與一致性TableItemsAttributesPartitionSort KeyKeyLocal Secondar

15、y IndexGlobal Secondary Index利用DynamoDB進行全球擴展客戶可以采用業務層判斷行數據的主寫區域來避免沖突客戶可以使用DynamoDB觸發Lambda做緩存更新DynamoDB流DynamoDB流是針對表里的數據變化的順序記錄在流里，針對表的變化的記錄只會出現一次在流里的記錄的順序與表上發生修改操作的順序是一致的流里的數據保存24小時，24小時以后自動刪除可以把表的數據被更新前的值以及更新后的值都寫到流里流里的數據通過API進行消費DynamoDB流里記錄的數據內容DynamoDB流可以配置為四種寫入的數據內容：KEYS_ONLY 只有分區鍵和排序鍵的數據被寫入

16、流NEW_IMAGE 修改后的整條記錄都被寫入流OLD_IAMGE 修改前的整條記錄都被寫入流NEW_AND_OLD_IMAGES 修改前和修改后的整條記錄都被寫入流Partition KeyPartition Key修改前的記錄修改后的記錄DynamoDB流和AWS Lambda結合構建觸發器AWS Lambda把數據變化通知出去Amazon Kinesis Data FirehoseAmazon Simple Notification ServiceAmazon Elasticsearch ServiceStream Reader多區域復制Region區域 1Region區域 3Regio

17、n區域 2Stream ReaderStream Reader創建Global Tables創建Global Tables創建Global Tables管理Global TablesAmazon CloudWatch metricsReplicationLatency: 預計傳播時間PendingReplicationCount: 寫入一個region但尚未傳播到其他region的items written 數全球數據庫挑戰12Aurora global database3DynamoDB global tables4ElastiCache global datastore5客戶案例目錄CON

18、TENTSAmazon ElastiCache for Redis 介紹-全托管, 兼容Redis, 內存數據存儲在云端極致性能內存數據存儲并提供小于1ms的響應時間全托管AWS管理所有的硬件以及軟 件的配置和監控易伸縮通過副本提供讀操作的伸縮 通過分片提供寫操作的伸縮 非中斷的伸縮兼容 Redis支持 Redis 5兼容不同 Redis clients可靠性多可用區 深度監控自動故障轉移安全與合規Amazon VPC HIPAA, PCI, FedRAMP存儲和傳輸中進行加密 身份認證 Cache node副本分片 Cache node主節點異步復制檢測到故障啟用集群模式下的故障轉移 Cac

19、he node副本 Cache node主節點異步復制自動故障轉移(無需DNS廣播)使用故障轉移 API 進行測試SNS 事件: ElastiCache:CacheNodeReplaceCompleteSNS 事件: ElastiCache:FailoverComplete分片啟用集群模式下的故障轉移Global Datastore in Amazon ElastiCache for Redis快速、可靠、安全的完全托管式跨區域數據復制主集群在一個區域，從集群在其它區域 跨區域數據復制延遲通常小于 1 秒為全球化應用提供低延遲的快速本地數據讀取更快的跨區域災難恢復把從集群提升為主集群的時間通常

20、小于1分鐘Global Datastore in Amazon ElastiCache for Redis支持1個主集群（寫/讀），最多2個從集群（只讀）目前支持11個AWS區域：美國東部（弗吉尼亞北部）、美國東部（俄亥俄）、美國西部（加利福尼亞北部）、美國西部（俄勒岡）、 亞太地區（首爾）、亞太地區（新加坡）、亞太地區（悉尼）、亞太 地區（東京）、歐洲（法蘭克福）、歐洲（愛爾蘭）和歐洲（倫敦）支持Amazon ElastiCache for Redis 5.0.6 或更高版本支持 M5 和 R5 節點從集群與主集群具有相同的節點類型、引擎版本、和分片數目修改一個集群的本地參數組將應用于整個G

21、lobal Datastore中的集群設置Global Datastore使用現有集群作為主集 群或者直接創建一個新集群作為主集群添加/刪除/修改集群將從集群提升為主集群在主集群（區域）降級的 情況下，手動啟動故障轉 移從集群的故障轉移和升級 通常會在一分鐘內完成當從集群升級為主集群時， ElastiCache 會將舊的主集 群（如果可訪問）重新配 置為從集群，并設置復制 以將所有次要區域與新的 主集群同步全球數據庫挑戰12Aurora global database3DynamoDB global tables4ElastiCache global datastore5客戶案例目錄CONTENTS應用場景:2018年初，虎牙直播上線海外產品 Nimo TV，年底