Semua orang mahukan kemas kini masa nyata sehinggalah mereka menyedari bahawa "pantas" dan "betul" bukanlah perkara yang sama. Dalam sistem teragih, acara boleh bergerak sepantas cahaya namun tetap tiba dalam urutan yang salah. WebSockets terputus dan menyambung semula. Broker mesej menghantar semula paket. Pekerja latar belakang berlumba dengan pembatalan tamat masa. Hasilnya? Klien mungkin melihat acara 42, kemudian acara 40, kemudian satu petikan (snapshot) yang mendakwa sistem sudah berada pada acara 45. Jika anda membina aliran kerja ejen yang berjalan lama, kekacauan itu bukanlah kes terpencil (edge case). Ia adalah tahap asas. Betulkan urutan acara anda sebelum anda bimbang tentang mengurangkan milisaat dalam penghantaran.
Realiti "Masa Nyata" yang Berserabut
Masa nyata adalah sifat pengangkutan. Ia menerangkan betapa cepatnya sesuatu paket bergerak merentasi kabel, bukan sama ada cerita yang disampaikan itu masuk akal. Tugasan yang berjalan lama membesarkan setiap ketidakkonsistenan kerana ia merentasi masa. Tugasan latihan model, aliran kelulusan berbilang langkah, atau saluran paip perenderaan video mungkin mengeluarkan berpuluh-puluh acara dalam tempoh minit atau jam. Dalam tempoh tersebut, apa sahaja boleh berlaku.
Broker mungkin mencuba semula mesej kerana pengakuan (acknowledgement) hilang. Pengimbang beban (load balancer) mungkin menghalakan dua acara melalui laluan rangkaian yang berbeza, menyebabkan yang lebih baharu tiba dahulu. Proses pekerja mungkin mati selepas menulis ke pangkalan data tetapi sebelum menerbitkan acara kejayaan, hanya untuk pekerja kedua mengambil tugasan tersebut dan menerbitkan kemajuannya sendiri. Jika bahagian hadapan (frontend) anda menganggap mesej terbaharu adalah mesej yang paling benar, ia akan memaparkan keadaan yang tidak pernah wujud. Pengguna akan melihat lencana "selesai" berkelip kembali ke "sedang diproses," atau lebih teruk lagi, tugasan yang dibatalkan tiba-tiba muncul semula. Kelajuan tanpa urutan hanyalah kekeliruan pada kadar bingkai (frame rate) yang lebih tinggi.
Nombor Urutan Adalah Jam yang Sebenar
Penyelesaiannya ialah nombor urutan monotonik yang ketat yang dijana oleh pengeluar. Setiap operasi yang mengubah keadaan mendapat nombor yang meningkat tepat sebanyak satu, tanpa jurang dan tanpa pengunduran (rollback). Nombor tersebut mesti disimpan dalam transaksi yang sama dengan acara itu sendiri. Jika baris pangkalan data dikemas kini tetapi komit urutan gagal, anda perlu melakukan pengunduran (rollback) untuk kedua-duanya. Ini memastikan garis masa logik adalah atomik dengan perubahan keadaan.
ID acara masih berguna, tetapi ia menyelesaikan masalah yang berbeza. ID acara mengenal pasti muatan (payload) tertentu supaya anda boleh menghapuskan duplikasi apabila broker menghantar mesej yang sama dua kali. Sebaliknya, nombor urutan memberitahu anda di mana muatan itu berada dalam rantaian kausal. Ia mendedahkan jurang. Ia mendedahkan urutan. Cap masa (timestamp) tidak melakukan kedua-duanya. Jam boleh lari (drift), NTP melangkah ke belakang, dan mesin maya terhenti seketika. Gunakan cap masa untuk tujuan paparan sahaja, seperti "Bermula 3 minit yang lalu," dan jangan sekali-kali menggunakannya sebagai kunci pengisihan untuk logik perniagaan.
Cara Klien Harus Mengendalikan Aliran
Sebaik sahaja pengeluar menjamin urutan monotonik, pengguna (consumer) akan mendapat peraturan yang mudah dan tegas. Jika nombor urutan masuk adalah kurang daripada atau sama dengan nombor terakhir yang digunakan, abaikannya. Ia sama ada pendua atau pendatang lewat yang sudah lapuk. Jika urutan adalah tepat satu lebih besar daripada nombor terakhir yang digunakan, laksanakannya dengan segera. Itulah laluan lancar (happy path). Jika urutan melompat ke hadapan, katakan anda menjangkakan 12 tetapi menerima 15, ada sesuatu yang hilang. Simpan acara baharu dalam penimbal (buffer) dan minta pelayan untuk memainkan semula bermula dari urutan seterusnya yang dijangkakan. Jangan meneka. Jangan melompat ke hadapan dengan harapan jurang tersebut tidak penting.
Keadaan terminal mesti dianggap sebagai tidak boleh diubah (irrevocable). Sebaik sahaja tugasan ditandakan sebagai selesai, gagal, atau dibatalkan, klien harus menolak sebarang perubahan keadaan seterusnya untuk operasi tersebut. Ini kedengaran jelas sehinggalah anda berhadapan dengan