Sistem terdistribusi modern penuh dengan kompromi. Performa, keandalan, skalabilitas, dan konsistensi tidak datang begitu saja — Anda selalu harus membayar harganya. Di sinilah teorema CAP berperan: ini adalah titik awal untuk memahami kompromi yang tak terelakkan dalam desain terdistribusi.  Mengapa teorema CAP benar? Apa yang sebenarnya dijelaskannya? Dan, yang terpenting, apakah itu cukup? Dalam artikel ini, kita akan membahas teorema CAP, keterbatasannya, kritik yang dihadapinya, dan bagaimana ide-ide baru seperti PACELC mendorong diskusi ini ke depan. Mari kita bahas lebih dalam.  Teorema CAP  Versi pertama teorema CAP dimulai sebagai perdebatan antara   . Namun seiring berjalannya waktu, teorema ini berkembang, memperoleh pembuktian formal, dan berkembang menjadi teorema CAP seperti yang kita kenal sekarang. ASAM vs. BASA  Teorema CAP menyatakan bahwa   : sistem terdistribusi dapat memenuhi paling banyak dua dari tiga properti secara bersamaan   Konsistensi   Tersedianya   Toleransi Partisi  Keterbatasan ini memaksa para insinyur untuk membuat keputusan yang sulit, tergantung pada tujuan sistem dan realitas lingkungan terdistribusi mereka.  Konsistensi   Konsistensi dalam CAP tidak sama dengan konsistensi dalam   . Dalam teorema CAP, hal ini mengacu pada   atau   . Artinya,   , terlepas dari node mana yang memproses permintaan. Ini berarti bahwa setiap operasi baca mencerminkan penulisan terbaru, tidak peduli node mana yang Anda kueri. transaksi ACID linearisasi konsistensi yang kuat semua node dalam sistem terdistribusi harus selalu menyajikan satu tampilan data terkini  💡 Konsistensi dalam ACID, di sisi lain, berfokus pada upaya memastikan bahwa transaksi membawa basis data dari satu status valid ke status valid lainnya, mengikuti aturan yang ditetapkan oleh skema basis data. Konsistensi lebih pada penerapan batasan integritas (seperti kunci asing, batasan unik, dsb.) dan memastikan basis data tidak dibiarkan dalam status tidak valid, bahkan saat terjadi crash.  Tersedianya   Ketersediaan dalam CAP berarti bahwa   . Dengan kata lain, jika node yang sehat mendapat permintaan, ia harus memproses dan menanggapinya. Namun, CAP   — ia hanya memastikan node tidak gagal secara diam-diam (misalnya, dalam   node mungkin menanggapi dengan data basi selama partisi untuk memastikan ketersediaan). setiap node yang tidak gagal harus mengembalikan respons untuk setiap permintaan yang diterimanya, terlepas dari partisi jaringan tidak menjamin respons akan selalu "benar" atau terkini sistem AP  💡 Eric Brewer (penulis asli CAP) awalnya menjelaskan properti ini sedikit lebih fleksibel sebagai: "hampir semua kueri harus mendapat respons". Namun, dalam pembuktian formal CAP, ketersediaan dibuat lebih ketat, yang mengharuskan "setiap kueri menerima respons selama node yang menanganinya dalam kondisi baik".  Namun, dalam praktiknya, ketersediaan bukanlah jaminan mutlak — ketersediaan sering kali bergantung pada batasan khusus sistem, seperti seberapa lama Anda bersedia menunggu respons. Untuk sistem di dunia nyata,   memainkan peran penting dalam membentuk SLA (perjanjian tingkat layanan) Anda, meskipun CAP sendiri tidak secara langsung memperhitungkan latensi. Selengkapnya tentang hal ini dalam   . waktu respons (atau batas waktu) posting blog ini  Toleransi partisi   Toleransi partisi adalah tentang bertahan dari kegagalan jaringan.   Partisi terjadi ketika node tidak dapat berkomunikasi karena paket terputus, batas waktu, atau pemisahan jaringan. Jika node tidak dapat berkomunikasi karena pemisahan jaringan (partisi), sistem harus tetap memenuhi jaminan konsistensi atau ketersediaannya, tergantung pada pilihan desainnya.  Sistem terdistribusi tidak hidup di dunia dongeng dengan jaringan yang sempurna. Paket-paket terputus, terjadi batas waktu, dan lonjakan latensi tidak dapat dihindari. Karena itu,   — partisi akan terjadi cepat atau lambat, jadi Anda tidak dapat "memilih" untuk mengabaikannya, tidak peduli seberapa menggoda kedengarannya. toleransi partisi tidak dapat dinegosiasikan dalam sistem terdistribusi apa pun  Dalam CAP, toleransi partisi tidak berarti sistem terus berjalan seolah tidak terjadi apa-apa. Artinya, sistem harus memutuskan apakah akan memprioritaskan ketersediaan (AP) atau konsistensi (CP) selama partisi. Jika Anda mengabaikan toleransi partisi, pada dasarnya Anda akan membangun sistem monolitik yang tidak terdistribusi.  CAP dijelaskan  Cara termudah untuk memahami CAP adalah dengan mempertimbangkan   — situasi di mana dua bagian dari sistem terdistribusi tidak dapat berkomunikasi satu sama lain. Dalam skenario seperti itu, sistem menghadapi tiga kemungkinan hasil: partisi jaringan    sementara yang lain terisolasi, kedua bagian tersebut akan memiliki status yang tidak konsisten. Hal ini mengakibatkan hilangnya   . Jika satu bagian sistem menerima pembaruan C (Konsistensi)    , sistem harus memblokir pembaruan di satu atau kedua bagian partisi untuk memastikan status terpadu di semua node. Hal ini menyebabkan hilangnya   karena beberapa permintaan akan ditolak atau ditunda tanpa batas waktu. Jika sistem memilih untuk tetap konsisten A (Ketersediaan)    dan konsisten (C) tanpa menoleransi partisi (P), sistem tersebut tidak benar-benar terdistribusi. Ini akan mengharuskan node untuk berinteraksi dan merekonsiliasi status, yang tidak mungkin dilakukan selama partisi. Jika sistem memilih untuk tetap tersedia (A)  Jadi,   , sistem hanya dapat memenuhi   . Setelah partisi teratasi (yaitu node berinteraksi lagi), sistem dapat memperoleh kembali ketiga properti tersebut, tetapi   , tradeoff tidak dapat dihindari. selama partisi dua dari tiga properti (C, A, atau P) selama partisi itu sendiri  Implikasi dari teorema tersebut  Konsekuensi dari teorema untuk sistem asinkron adalah bahwa hanya tiga kombinasi konsistensi, ketersediaan, dan toleransi partisi yang mungkin:  AP (Ketersediaan + Toleransi Partisi)  Sistem jenis ini menanggapi permintaan, tetapi data yang dikembalikan mungkin tidak selalu mutakhir, dengan pembaruan data yang lebih lambat tetapi "selalu" tersedia. Contoh sistem semacam itu adalah DNS, DynamoDB, dan Cassandra.  CP (Konsistensi + Toleransi Partisi)  Sistem jenis ini selalu mengembalikan data terkini, tetapi beberapa, atau bahkan semua, node dalam sistem mungkin tidak merespons jika dipartisi. Sistem ini memberikan pembaruan atomik tetapi dapat menyebabkan waktu habis. Basis data NoSQL seperti Google BigTable, MongoDB, HBase, dan Redis semuanya adalah sistem jenis ini.  CA (Konsistensi + Ketersediaan)  Sistem jenis ini selalu mengembalikan data terkini saat tidak ada partisi. Karena keterbatasan terakhir, biasanya sistem seperti itu hanya digunakan dalam satu mesin. Contohnya adalah basis data relasional klasik.  Pada kenyataannya, kita memilih antara CP dan AP karena CA pada dasarnya adalah monolit tanpa partisi. Untuk sistem berskala besar, perancang tidak dapat mengabaikan P dan karena itu memiliki pilihan yang sulit antara C dan A.  Dalam CA, kegagalan node berarti layanan tidak tersedia sama sekali. Namun, hal ini tidak menonaktifkan skalabilitas, karena kita dapat mengkloning monolit independen dan mendistribusikan beban ke atasnya.  Kritik terhadap Teorema CAP  Teorema CAP telah menjadi konsep dasar dalam sistem terdistribusi, tetapi bukan tanpa keterbatasan. Meskipun jelas dalam menyajikan gagasan tentang tradeoff, teorema CAP sering dikritik karena terlalu menyederhanakan realitas yang kompleks, yang menyebabkan kesalahpahaman dan penerapan yang salah.  1. Kompromi Hanya Berlaku Selama Partisi  Salah satu kritik yang paling umum adalah bahwa tradeoff teorema CAP — memilih antara   dan   — hanya berlaku ketika   benar-benar terjadi. Dalam operasi normal, ketika jaringan stabil dan tidak ada partisi, tidak ada tradeoff inheren antara konsistensi dan ketersediaan. konsistensi (C) ketersediaan (A) partisi jaringan (P)  Lebih jauh lagi, tradeoff ini tidak berlaku secara universal di seluruh sistem. Dalam sistem terdistribusi yang sama:  Berbagai bagian sistem mungkin mengalami pertentangan berbeda berdasarkan konteks (seperti lokasi pengguna, jenis data).  Operasi tertentu mungkin mengutamakan konsistensi sementara yang lain mengutamakan ketersediaan.  Keputusan dapat bervariasi pada saat runtime tergantung pada faktor-faktor seperti beban, latensi, atau persyaratan pengguna.  Nuansa ini sering kali hilang dalam diskusi tingkat tinggi mengenai CAP, yang mengarah kepada klasifikasi sistem yang terlalu disederhanakan sebagai "CP" atau "AP" secara menyeluruh.  2. CAP Mengabaikan Latensi  Kritik penting lainnya adalah bahwa teorema CAP tidak memperhitungkan   , meskipun latensi dan partisi saling terkait erat dalam praktik. Misalnya: latensi  Jaringan yang lambat (latensi tinggi) mungkin tampak tidak dapat dibedakan dari sebuah partisi.  Batas waktu—yang digunakan untuk mendeteksi kegagalan—bersifat subjektif dan sangat bergantung pada desain sistem dan kondisi jaringan. Apa yang didefinisikan oleh satu sistem sebagai "partisi" mungkin hanya merupakan penundaan sementara bagi sistem lain.  Dalam sistem terdistribusi di dunia nyata, ketika terjadi partisi atau latensi tinggi, sistem harus membuat keputusan dalam   : memprioritaskan ketersediaan dengan mengembalikan hasil yang mungkin basi, atau memprioritaskan konsistensi dengan menunggu lebih lama (dan berpotensi gagal merespons). Pandangan biner CAP tidak menangkap kompleksitas keputusan ini. periode waktu habis  3. Properti CAP Tidak Bersifat Biner  Teorema CAP menyajikan konsistensi, ketersediaan, dan toleransi partisi sebagai properti biner—Anda memilikinya atau tidak. Namun dalam praktiknya,   : ketiga properti tersebut ada dalam spektrum    bukanlah properti biner "aktif/nonaktif"—ia berkisar dari 0% hingga 100%. Misalnya, suatu sistem dapat menjamin ketersediaan 99,99%, tetapi hal itu masih memungkinkan untuk periode tidak tersedia yang singkat. Ketersediaan    memiliki tingkatan yang bervariasi, dari konsistensi akhir hingga konsistensi kausal hingga konsistensi yang kuat. Tidak semua aplikasi memerlukan linearisasi penuh. Konsistensi    itu sendiri bukanlah peristiwa yang jelas. Sistem mungkin tidak sepakat tentang keberadaan partisi (misalnya, satu node melihat batas waktu sebagai kegagalan, sementara node lain tetap beroperasi secara normal). Toleransi partisi  Sifat properti yang berkesinambungan ini membuat CAP terlalu sederhana untuk memodelkan kompleksitas sistem terdistribusi modern.  Teorema PACELC  Meskipun CAP merevolusi pemahaman kita tentang tradeoff dalam sistem terdistribusi, itu bukanlah kata terakhir tentang pokok bahasan tersebut.   dianggap sebagai pendekatan alternatif untuk desain sistem terdistribusi. Pendekatan ini didasarkan pada model CAP, tetapi selain konsistensi, ketersediaan, dan toleransi partisi, pendekatan ini juga mencakup latensi dan pengecualian logis antara kombinasi konsep-konsep ini. Teorema PACELC yang dijelaskan oleh Daniel J. Abadi  PACELC memperkenalkan dua mode operasi berbeda untuk sistem terdistribusi:    (   ): Apa tradeoff yang dibuat sistem saat partisi terjadi? Di sini, kami meninjau kembali tradeoff CAP klasik antara   dan   . Mode partisi PAC ketersediaan (A) konsistensi (C)    (   ): Apa tradeoff yang dibuat sistem saat tidak ada partisi, dan jaringan berfungsi normal? Dalam mode ini, sistem menghadapi tradeoff yang berbeda — antara   dan   .  Mode lain ELC latensi (L) konsistensi (C)  Pertukaran Latensi-Konsistensi  Meskipun partisi tidak dapat dihindari dalam sistem terdistribusi, partisi jarang terjadi jika dibandingkan dengan tantangan yang muncul selama operasi normal. Dalam sistem terdistribusi modern,   sering kali menjadi hambatan yang lebih besar daripada partisi jaringan, khususnya untuk aplikasi berskala global. Di sinilah   berfokus — dengan mengatasi tradeoff yang terjadi saat sistem beroperasi tanpa partisi. Tidak seperti CAP, yang hanya berfokus pada perilaku selama skenario kegagalan, PACELC menekankan keputusan yang harus diambil arsitek setiap hari untuk menyeimbangkan   dan   : latensi PACELC latensi (L) konsistensi (C)    memerlukan koordinasi dan sinkronisasi antar node untuk mempertahankan tampilan data yang terpadu. Overhead ini menimbulkan penundaan, yang memperlambat waktu respons. Konsistensi yang kuat    (seperti sistem yang mengadopsi eventual continuity) memprioritaskan kecepatan dengan melonggarkan jaminan konsistensi. Sistem ini merespons lebih cepat tetapi terkadang dapat mengembalikan data yang basi atau tidak konsisten. Sistem latensi rendah  Dengan memperluas percakapan di luar partisi untuk mencakup operasi normal, PACELC memastikan bahwa kinerja sehari-hari sistem terdistribusi diperlakukan dengan kepentingan yang layak.  Menyimpulkan  Perumusan teorema CAP telah menjadi peristiwa penting dalam komunitas, dan studi tentang dampaknya pada desain sistem terdistribusi telah menunjukkan bahwa perancang sistem terdistribusi tidak boleh membatasi sistem pada dua properti - mereka harus berusaha untuk memaksimalkan jaminan yang diperlukan dalam setiap kasus tertentu. Untuk tujuan ini, masuk akal untuk membagi sistem menjadi beberapa segmen, yang masing-masing memiliki persyaratannya sendiri, dan merancang sistem berdasarkan persyaratan masing-masing segmen.  Teorema CAP telah menjadi landasan pemikiran sistem terdistribusi selama beberapa dekade. Teorema ini memberi kita kerangka kerja untuk bernalar tentang tradeoff yang melekat pada konsistensi, ketersediaan, dan toleransi partisi. Namun dalam banyak hal, ini merupakan penyederhanaan realitas, dengan asumsi pilihan biner dan mengabaikan faktor-faktor penting seperti latensi.  PACELC dibangun berdasarkan CAP, dengan mengakui bahwa:   Kompromi tetap ada bahkan ketika partisi tidak ada.    dalam desain sistem terdistribusi. Latensi merupakan perhatian utama  Baik CAP maupun PACELC merupakan perangkat yang berharga, tetapi keduanya bukanlah resep langkah demi langkah untuk membangun sistem. Sebaliknya, keduanya menyediakan   untuk mengevaluasi tradeoff dan memahami batasan arsitektur terdistribusi. model mental  Bahan tambahan   CAP Dua Belas Tahun Kemudian: Bagaimana "Aturan" Telah Berubah   Cassandra: Panduan Definitif    dan  Tolong berhenti menyebut database CP atau AP Kritik terhadap Teorema CAP oleh Martin Kleppmann   Catatan tentang Sistem Terdistribusi untuk Young Bloods   Terima kasih telah membaca!   Penasaran tentang sesuatu atau punya pemikiran untuk dibagikan? Tinggalkan komentar Anda di bawah! Lihat   atau ikuti saya melalui   ,   , atau   . blog saya LinkedIn Substack Telegram

Subscribe

Buy My Book

Audio ini diproduksi dalam bahasa asli cerita!

Mengapa Sistem Terdistribusi Tidak Dapat Memiliki Semuanya

About Author

KOMENTAR

HANG TAG

ARTIKEL INI DISAJIKAN PADA

Related Stories

How to Fetch Large Data Files Through GitHub API

The Crypto Trading Writing Contest: Submission Deadline Extended!

The Priory Ruins

Stocks will be More Profitable than Crypto - Interview With Bryan Applegate

How to Fetch Large Data Files Through GitHub API

The Crypto Trading Writing Contest: Submission Deadline Extended!

The Priory Ruins

Stocks will be More Profitable than Crypto - Interview With Bryan Applegate

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps