Gesaan dan konteks
Perkhidmatan pesanan, keutamaan (preference), atau inventori mesti menawarkan bacaan dan penulisan tempatan di beberapa Region. Bandingkan DynamoDB Global Tables MREC (multi-Region eventual consistency) dengan MRSC (multi-Region strong consistency), dan terangkan penghalaan, konflik, failover, kapasiti, serta pemulihan. Temu duga ini menguji batas ketekalan dan operasi, bukan sekadar menyalin pangkalan data ke lokasi lain.
Global Tables ialah replikasi berbilang Region, berbilang aktif yang diuruskan: mana-mana replika boleh melayani bacaan dan penulisan. MREC ialah mod lalai dan mereplikasi secara tak segerak (asynchronous); apabila item yang sama diubah suai hampir serentak di Region yang berbeza, DynamoDB menyelesaikannya pada granulariti item dengan peraturan last-writer-wins berdasarkan cap masa dalaman. MRSC mereplikasi secara segerak (synchronous) ke sekurang-kurangnya satu Region lain sebelum mengesahkan penulisan, dan bacaan tekal kukuh pada mana-mana replika mengembalikan nilai terkini; ia memerlukan tepat tiga Region (tiga replika, atau dua replika ditambah satu saksi).
Perkara yang diuji oleh penemu duga
Jawapan yang kukuh memecahkan batas kekal perniagaan (business invariants) kepada item, partition key, dan transaksi rentas item sebelum memilih mod berdasarkan RPO, kependaman penulisan, dan jaminan bacaan. Jangkakan soalan tentang kehilangan data senyap di bawah last-writer-wins, kekangan tiga Region bagi MRSC, keterlihatan transaksi MREC merentasi Region, dan susunan semasa failback.
Sekadar menyebut "dayakan replikasi berbilang Region" adalah tidak mencukupi. Terangkan titik akhir (endpoint) Region tempatan, cara mengelakkan penulisan duaan (dual writes) pada satu item, cara memantau ReplicationLatency, dan cara mengendalikan pemadaman, percubaan semula, serta peristiwa pendua.
Soalan untuk dijelaskan terlebih dahulu
Batas kekal dan bentuk konflik
Tanya sama ada status pesanan boleh berundur ke belakang, sama ada inventori mesti boleh dilinearize (linearizable), dan sama ada satu item boleh diedit secara serentak di beberapa Region. Medan yang boleh digabungkan secara bebas boleh menjadi item berasingan atau subrekod berversi. Keatoman rentas medan memerlukan pemahaman bahawa transaksi MREC adalah atomik hanya di Region yang memanggilnya dan tidak direplikasi sebagai satu transaksi tunggal.
RPO, kependaman, dan bilangan Region
Jelaskan RPO, kependaman penulisan P99, masa failover, dan Region yang patuh. MREC boleh menggunakan sebarang bilangan Region yang tersedia dan biasanya merambat dalam masa satu saat; MRSC menukar sedikit kependaman penulisan untuk bacaan kukuh rentas Region dan sasaran sifar RPO, di samping memerlukan tiga Region.
Pemilikan penulisan dan pemulihan
Tentukan sama ada penulisan benar-benar berbilang aktif atau setiap penyewa (tenant) mempunyai Region asal (home Region) dengan replika bacaan di tempat lain. Jika perniagaan tidak boleh menerima LWW, gunakan IAM atau penghalaan untuk mengekang penulis dan menentukan autoriti bagi keputusan konflik semasa pemulihan dan bukannya menyerahkan semantik kepada replikasi.
Jawapan 30 saat
"Saya memilih mod berdasarkan batas kekal perniagaan: pengurangan inventori dan bacaan kukuh rentas Region menjurus kepada MRSC, manakala beban kerja yang bertoleransi terhadap data lapuk seketika dan mengutamakan kependaman penulisan tempatan menggunakan MREC lalai. MREC adalah tak segerak dan menggunakan LWW peringkat item, jadi saya menetapkan setiap pesanan atau penyewa ke satu Region dan menambah penulisan bersyarat, kunci keidempotanan, dan versi eksplisit; status yang tidak boleh digabungkan tidak bergantung pada LWW. Setiap permintaan menggunakan titik akhir tempatannya, dan trafik dialihkan di pinggir aplikasi semasa kegagalan serantau. Saya memantau ReplicationLatency, ralat replikasi, dan kegagalan penulisan bersyarat, kemudian memainkan semula serta mengaudit pemulihan menggunakan versi, peristiwa, dan peraturan perniagaan."
Penyelesaian langkah demi langkah
Langkah 1: Pilih mod ketekalan
MREC ialah mod lalai, menyokong sebarang bilangan Region, dan bersifat tekal akhirnya, sesuai untuk keutamaan, katalog, dan model bacaan yang bertoleransi terhadap kelapukan. MRSC mereplikasi penulisan secara segerak ke sekurang-kurangnya satu Region lain sebelum berjaya; bacaan kukuh pada mana-mana replika melihat nilai terkini. Ia memerlukan tepat tiga Region dan tidak menyokong operasi transaksi. Mod ini dipilih semasa penciptaan: replika tidak boleh mencampurkan mod dan jadual tidak boleh ditukar kemudian.
Langkah 2: Tentukan topologi penulisan
Aplikasi harus menggunakan titik akhir DynamoDB di Region tempatan mereka. Penulisan berbilang aktif hanya sesuai apabila perniagaan boleh menyelesaikan konflik serentak. Objek yang dikekang dengan ketat seperti pesanan dan inventori boleh menggunakan penulisan Region asal dengan bacaan di tempat lain, atau partisi penulis tunggal mengikut penyewa atau pesanan. Panggilan rentas Region menambah kependaman dan permukaan kegagalan; pertukaran trafik adalah milik titik masuk aplikasi atau lapisan penghalaan.
Langkah 3: Kekang konflik di bawah MREC
MREC menggunakan LWW cap masa dalaman untuk kemas kini yang hampir serentak pada satu item. Replika menumpu (converge), tetapi perubahan perniagaan yang dibuang tidak menjadi kerja pampasan secara automatik. Gunakan ungkapan syarat (condition expressions) untuk versi dan sertakan ID permintaan idempoten. Kekalkan peristiwa tambah sahaja (append-only events) atau rekod konflik untuk status yang tidak boleh ditimpa ganti. Wakili pemadaman dengan tombstone atau status eksplisit supaya kemas kini lapuk tidak dapat menghidupkan semula objek yang telah dipadam.
Langkah 4: Kendalikan transaksi dan percubaan semula
MREC TransactWriteItems adalah atomik hanya di Region yang memanggil; replika lain boleh memerhatikan kesan separa buat sementara waktu, jadi bacaan rentas Region bukanlah pengesahan transaksi. Percubaan semula mesti membezakan kegagalan bersyarat, pendikitan (throttling), dan kelewatan replikasi, dengan undur eksponen terbatas (bounded exponential backoff) dan kunci keidempotanan. MRSC tidak menyokong operasi transaksi, jadi batas kekal rentas item memerlukan model baharu atau penyelarasan perkhidmatan.
Langkah 5: Rancang failover dan pemulihan
Pantau kependaman replikasi, ralat replikasi, kegagalan penulisan bersyarat, Region permintaan, dan versi perniagaan. Semasa pemencilan, alihkan trafik masuk ke Region yang sihat. Dengan MREC, jedakan dahulu penulisan yang sensitif terhadap konflik atau tetapkan semula Region asal bagi penyewa, dengan merekodkan masa pertukaran dan versi keterlihatan terakhir. Selepas pemulihan, sahkan penumpuan dengan log peristiwa, versi, dan peraturan perniagaan; replika yang seiras sahaja tidak membuktikan inventori atau pesanan yang betul.
Langkah 6: Kapasiti, keselamatan, dan tadbir urus
Nilai kapasiti baca/tulis, penskalaan automatik, dan kuota untuk setiap replika. Replika baharu mewarisi tetapan kapasiti Region sumber semasa penciptaan dan boleh dilaraskan selepas itu. Dayakan perlindungan pemadaman bagi setiap replika, gunakan IAM untuk mengekang Region penulis dan operasi jadual, dan ingat bahawa kehilangan kebenaran KMS akan menghentikan replikasi yang sepadan. Global Tables berbilang akaun menyokong MREC, bukan MRSC, jadi pemilikan akaun, Region, dan audit mestilah eksplisit.
Langkah 7: Sahkan dan lakukan latihan simulasi
Lakukan latihan simulasi penulisan serentak pada satu item di dua Region, percubaan semula bersyarat, sekatan partisi (partition), pemadaman dengan kemas kini lewat, lonjakan replikasi, peralihan trafik, dan failback. Sahkan penumpuan akhir, peristiwa pampasan yang lengkap, dan main semula yang selamat daripada pendua, sambil mengaitkan ReplicationLatency dan kiraan konflik dengan ID permintaan. Ujian beban mesti mencerminkan jarak Region dan mod kapasiti sebenar; kependaman mesin tunggal bukanlah anggaran rentas Region.
Contoh jawapan berkualiti tinggi
Saya memilih mod berdasarkan batas kekal. Data kritikal yang memerlukan bacaan kukuh rentas Region dan sasaran sifar RPO boleh menggunakan MRSC, dengan menerima syarat tepat tiga Region, kependaman penulisan yang lebih tinggi, dan tiada operasi transaksi. Katalog dan keutamaan boleh menggunakan MREC. Oleh sebab LWW peringkat item yang tak segerak tidak dapat menggabungkan semantik perniagaan, pesanan dan inventori menggunakan penulisan tunggal di Region asal bagi penyewa atau pesanan, ungkapan syarat, versi, dan kunci keidempotanan. Medan yang boleh digabungkan dijadikan item berasingan; kemas kini yang tidak boleh digabungkan menjadi peristiwa konflik.
Aplikasi menggunakan titik akhir tempatan dan lapisan kemasukan melaksanakan failover serantau. Saya memantau ReplicationLatency, kegagalan replikasi dan penulisan bersyarat, serta perbezaan versi, dengan undur terbatas untuk pendikitan dan kelewatan. Semasa pemulihan, saya membekukan penulisan yang terjejas, mengesahkan penumpuan daripada log peristiwa dan peraturan perniagaan, kemudian membuka semula trafik secara beransur-ansur. Saya mengaudit kapasiti, perlindungan pemadaman, IAM, dan KMS bagi setiap replika serta melakukan latihan penulisan serentak, partisi, pemadaman lewat, dan main semula pendua.
Kesilapan lazim
- Kesilapan: Menganggap Global Tables bermaksud penulisan berbilang aktif tanpa sekatan. → Sebab ia gagal: MREC LWW boleh membuang perubahan perniagaan yang tidak boleh digabungkan. → Penyelesaian: Tetapkan pemilikan penulisan atau reka bentuk versi eksplisit, peristiwa, dan pampasan.
- Kesilapan: Menganggap transaksi MREC adalah atomik secara global. → Sebab ia gagal: Keatoman adalah bersifat tempatan pada Region yang memanggil dan replika lain mungkin melihat kesan separa. → Penyelesaian: Reka bentuk semula batas kekal rentas Region dan selaraskan dengan peristiwa serta keidempotanan.
- Kesilapan: Menukar Region secara membuta tuli selepas masa tamat (timeout). → Sebab ia gagal: Penulisan duaan menguatkan konflik dan risiko failback. → Penyelesaian: Jedakan atau kekang penulisan, rekodkan versi, kemudian beralih mengikut sempadan penyewa atau perniagaan.
- Kesilapan: Menyamakan penumpuan replika dengan ketepatan inventori. → Sebab ia gagal: LWW menyelesaikan replikasi, bukan makna perniagaan. → Penyelesaian: Sahkan dengan penulisan bersyarat, log peristiwa, pampasan, dan audit.
Soalan susulan dan respons
Susulan 1: Bilakah anda akan memilih MRSC?
Pilih MRSC apabila bacaan kukuh rentas Region dan sasaran sifar RPO mengatasi isu kependaman penulisan serta fleksibiliti Region. Ia memerlukan tepat tiga Region, secara pilihan satu saksi, dan tidak menyokong transaksi. Jika beban kerja memerlukan kiraan replika sewenang-wenangnya atau replikasi berbilang akaun, nilai semula MREC dan penyelarasan peringkat perkhidmatan.
Susulan 2: Bagaimana jika LWW menimpa ganti pengurangan inventori?
Jangan pulihkan kuantiti daripada LWW. Gunakan ungkapan syarat dan versi untuk pengurangan tersebut, tetapkan pemilik penulisan yang stabil mengikut produk atau shard inventori, dan rekodkan setiap pengurangan sebagai peristiwa idempoten. Pengesan konflik membandingkan urutan peristiwa dan mengeluarkan pampasan atau menghantarnya ke baris gilir manusia; bacaan menyemak kedua-dua versi dan masa keterlihatan.
Susulan 3: Apakah yang anda lakukan apabila kelengahan replikasi MREC meningkat?
Kumpulkan amaran mengikut Region sumber, Region destinasi, dan impak perniagaan. Hadkan penulisan rentas Region atau kembalikan penyewa ke Region asal mereka untuk berhenti mencipta konflik. Hadkan percubaan semula klien, kemudian selaraskan versi, peristiwa lewat, dan penanda padam sebelum memulihkan penulisan berbilang aktif. ReplicationLatency mengukur perambatan, bukan ketepatan perniagaan.
Susulan 4: Bagaimana anda menguji failback?
Laksanakan latihan peralihan trafik, pemulihan Region lama, permintaan yang tiba pada kedua-dua belah pihak, dan pemadaman lewat. Rekodkan Region, versi, dan ID keidempotanan bagi setiap permintaan. Sahkan bahawa Region lama tidak boleh menimpa ganti status yang lebih baharu, peristiwa konflik kekal boleh dikesan, dan pampasan boleh diulang. Laporkan RPO, RTO, kiraan konflik, dan campur tangan manusia.
Susulan 5: Mengapakah replika tidak boleh mencampurkan MREC dan MRSC?
Mod ketekalan ialah tetapan penciptaan peringkat jadual: replika tidak boleh menggunakan mod yang berbeza dan jadual tidak boleh ditukar selepas penciptaan. Keperluan yang berubah memerlukan jadual baharu, migrasi, dan tetingkap penulisan duaan atau main semula yang terkawal, dengan kapasiti, kebenaran, keserasian klien, dan rollback disahkan terlebih dahulu.