Cabut palam. Tekan suis pemati. Naluri ini berfungsi apabila anda berdiri di sebelah satu mesin tunggal. Ia gagal apabila sistem AI anda merangkumi lima puluh nod merentasi tiga zon ketersediaan. Kebanyakan pasukan kejuruteraan mempelajari perkara ini dengan cara yang sukar. Mereka mengemas kini pangkalan data pusat, menukar nilai boolean daripada true kepada false, dan menganggap sistem akan berhenti. Ia tidak berhenti. Pangkalan data kelihatan bersih. Perkhidmatan masih berjalan.

Ilusi Suis Tunggal

Bayangkan seorang pengawal yang merekodkan pembatalan pada epoch 12. Ia menulis perubahan tersebut ke dalam stor persisten dan menarik nafas lega. Sementara itu, Pekerja B sedang berjalan menggunakan pemberian (grant) dalam cache daripada epoch 11. Pekerja tersebut tidak pernah menerima makluman itu. Tiga puluh saat kemudian, ia memulakan tugasan inferens model, menjalankan kluster GPU, atau memanggil API luaran. Log audit menyatakan akses telah dibatalkan. Tindakan tetap berlaku.

Ini adalah jurang antara persistensi dan penyebaran. Penulisan pangkalan data bukanlah keadaan sistem. Ia hanyalah satu baris dalam satu jadual, dan banyak pelakon dalam sistem anda tidak pernah menyemak (poll) jadual tersebut pada saat tepat mereka memerlukannya. Jika anda menganggap hentian kecemasan seperti suis lampu, anda akan mendapati bahawa kegelapan tidak pernah tiba di sesetengah sudut bilik.

Realiti Pahit Sistem Teragih

Anda perlu mereka bentuk untuk kegagalan. Bukan kegagalan sekali-sekala. Kegagalan yang berterusan, kucar-kacir, dan bebas. Pekerja mula semula di tengah-tengah tugasan. Pengguna barisan (queue consumers) ketinggalan beberapa minit. Perkhidmatan kebenaran (authorization services) mengembalikan data lapuk kerana satu replika tersangkut. Mesej bertindih. Mesej hilang. Mesej tiba tidak mengikut urutan. Daemon NTP anda menyimpang, dan tiba-tiba satu nod menyangka ia sepuluh saat di belakang nod yang lain. Jam mempunyai ralat, dan anda tidak boleh mempercayai masa dinding (wall time) untuk menyusun peristiwa merentasi sempadan.

Jika protokol kecemasan anda mengandaikan rangkaian yang boleh dipercayai, penghantaran mesej yang tersusun, atau jam yang disinkronkan, anda tidak mempunyai protokol. Anda hanya mempunyai harapan. Pekerja, pengguna barisan, dan perkhidmatan kebenaran gagal secara bebas. Peraturan keselamatan anda mesti tetap teguh walaupun infrastruktur terasa sangat bermusuhan.

Lima Peraturan Yang Benar-benar Berkesan

Keselamatan datang daripada invarian yang mampu bertahan dalam kekacauan. Berikut adalah peraturan yang menghalang pembatalan daripada menjadi sekadar fiksyen.

Tiada tindakan bermula dengan epoch pemberian yang lebih rendah daripada epoch pembatalan.
Ini adalah penghadang teras anda. Setiap pemberian kebenaran membawa nombor epoch. Setiap pembatalan membawa nombor yang lebih baharu. Sebelum mana-mana pekerja bertindak, ia membandingkan nombor tersebut. Jika pemberian pekerja itu lebih lama daripada pembatalan terbaru yang dilihatnya, pekerja tersebut berhenti. Epoch memberikan anda jam logik yang tidak bergantung pada jam sistem. Pekerja yang memegang epoch 11 mesti enggan memulakan kerja sebaik sahaja ia mengetahui bahawa epoch 12 telah membatalkan kuasa yang berkaitan.

Pemberian dalam cache tamat tempoh dalam had masa yang ditetapkan.
Sesuatu kebenaran tidak boleh kekal selamanya dalam memori. Pekerja perlu mengesahkan semula atau menggugurkan hak mereka selepas selang masa yang terhad. Tanpa ini, nod yang luar talian boleh aktif semula beberapa hari atau minggu kemudian dan melaksanakan tugasan menggunakan pemberian yang sudah lapuk. Tetapkan pajakan (lease). Kuat kuasakan dengan ketat. Masa menjadi pasukan pembersihan automatik anda.

Mula semula sistem tidak boleh merendahkan epoch yang disimpan.
Persistensi adalah penting. Jika pengawal terhenti dan mula semula, ia mesti memulihkan epoch tertinggi yang pernah dikeluarkan. Mengundur balik ke epoch yang lebih lama akan menghidupkan semula kebenaran yang telah dibatalkan seolah-olah hentian kecemasan tidak pernah berlaku. Simpan epoch secara tahan lama sebelum anda menyiarkannya. Gunakan log tulis-awal (write-ahead log), fsync yang disahkan, atau kumpulan konsensus yang direplikasi. Sejarah hanya bergerak ke hadapan.

Duplikasi pembatalan