Teras sistem teragih - log

Log ialah urutan rekod tersusun sepenuhnya yang dilampirkan dalam susunan kronologi Ia sebenarnya adalah format fail khas Fail ialah tatasusunan bait, dan log di sini ialah data rekod, tetapi berbanding dengan fail, setiap item di sini Rekod. disusun mengikut urutan masa Boleh dikatakan bahawa log adalah model storan yang paling mudah. ​​Sebagai contoh, baris gilir mesej secara linear .
Disebabkan oleh ciri-ciri yang wujud pada log itu sendiri, rekod dimasukkan secara berurutan dari kiri ke kanan, yang bermaksud bahawa rekod di sebelah kiri adalah "lebih tua" daripada rekod di sebelah kanan, dengan kata lain, kita tidak perlu bergantung pada jam sistem Ciri ini sangat berguna untuk diedarkan Sangat penting kepada sistem.

Adalah mustahil untuk mengetahui bila log itu muncul. Mungkin konsepnya terlalu mudah. Dalam bidang pangkalan data, log lebih digunakan untuk menyegerakkan data dan indeks apabila sistem ranap, seperti log semula dalam MySQL Redo log adalah struktur data berasaskan cakera yang digunakan untuk memastikan data apabila sistem ranap sistem juga dipanggil log tulis ke hadapan Sebagai contoh, semasa pelaksanaan sesuatu, log buat semula akan ditulis dahulu, dan kemudian perubahan sebenar akan digunakan Dengan cara ini, apabila sistem pulih selepas ranap, ia boleh dicipta semula berdasarkan log buat semula Letakkannya semula untuk memulihkan data (semasa proses permulaan, tiada sambungan klien pada masa ini). Log juga boleh digunakan untuk penyegerakan antara tuan pangkalan data dan hamba, kerana pada asasnya, semua rekod operasi pangkalan data telah ditulis ke log Kita hanya perlu menyegerakkan log kepada hamba dan memainkannya semula pada hamba untuk mencapai tuan -penyegerakan hamba Banyak komponen lain yang diperlukan juga boleh dilaksanakan di sini Kami boleh mendapatkan semua perubahan dalam pangkalan data dengan melanggan log buat semula, dengan itu melaksanakan logik perniagaan yang diperibadikan, seperti pengauditan, penyegerakan cache, dsb.

Perkhidmatan sistem yang diedarkan pada asasnya adalah mengenai perubahan keadaan, yang boleh difahami sebagai mesin keadaan Dua proses bebas (tidak bergantung pada persekitaran luaran, seperti jam sistem, antara muka luaran, dll.) akan menghasilkan output yang konsisten diberikan input yang konsisten keadaan yang konsisten, dan log tidak bergantung pada jam sistem kerana urutan yang wujud, yang boleh digunakan untuk menyelesaikan masalah susunan perubahan.
Kami menggunakan ciri ini untuk menyelesaikan banyak masalah yang dihadapi dalam sistem teragih. Sebagai contoh, dalam nod siap sedia dalam RocketMQ, broker utama menerima permintaan pelanggan dan merekodkan log, dan kemudian menyegerakkannya kepada hamba dalam masa nyata Hamba memainkan semula secara tempatan Apabila tuan menutup telefon, hamba boleh meneruskan memproses permintaan, seperti menolak permintaan tulis dan meneruskan permintaan baca. Log bukan sahaja boleh merekod data, tetapi juga secara langsung merekodkan operasi, seperti pernyataan SQL.

Log ialah struktur data utama untuk menyelesaikan masalah konsistensi Log adalah seperti urutan operasi.

Log boleh digunakan dengan mudah untuk mengendalikan aliran masuk dan keluar data Setiap sumber data boleh menjana log sendiri Sumber data di sini boleh datang dari pelbagai aspek, seperti strim acara (klik halaman, peringatan penyegaran cache, perubahan binlog pangkalan data. ), kami boleh menyimpan log secara berpusat dalam kelompok, dan pelanggan boleh membaca setiap rekod log berdasarkan offset, dan menggunakan perubahan mereka sendiri berdasarkan data dan operasi dalam setiap rekod.
Log di sini boleh difahami sebagai baris gilir mesej, dan baris gilir mesej boleh memainkan peranan penyahgandingan tak segerak dan pengehadan semasa. Kenapa kita kata decoupling? Kerana bagi pengguna dan pengeluar, tanggungjawab kedua-dua peranan itu sangat jelas, mereka bertanggungjawab untuk menghasilkan mesej dan menggunakan mesej, tanpa mempedulikan siapa di hiliran atau di hulu, sama ada log perubahan pangkalan data atau peristiwa tertentu tidak perlu mempedulikan pihak tertentu saya hanya perlu memberi perhatian kepada log yang menarik minat saya dan setiap rekod dalam log.

Kami tahu bahawa QPS pangkalan data adalah pasti, dan aplikasi lapisan atas secara amnya boleh dikembangkan secara mendatar Pada masa ini, jika terdapat senario permintaan secara tiba-tiba seperti Double 11, pangkalan data akan terharu, maka kami boleh memperkenalkan baris gilir mesej. untuk menggabungkan operasi pangkalan data setiap pasukan Tulis ke log, dan aplikasi lain bertanggungjawab untuk menggunakan rekod log ini dan menggunakannya pada pangkalan data Walaupun pangkalan data hang, pemprosesan boleh diteruskan dari kedudukan mesej terakhir apabila pulih (kedua-duanya RocketMQ dan Kafka menyokong Exactly Once semantics ), di sini walaupun kelajuan pengeluar berbeza daripada kelajuan pengguna, Log memainkan peranan penimbal di sini. Ia boleh menyimpan semua rekod dalam log dan menyegerakkan ke nod hamba secara berkala, supaya mesej Kapasiti tunggakan boleh dipertingkatkan dengan ketara kerana log penulisan diproses oleh nod induk Terdapat dua jenis permintaan baca ekor, yang bermaksud kelajuan penggunaan boleh mengikuti dengan kelajuan menulis jenis ini Anda boleh pergi terus ke cache, dan yang lain adalah pengguna yang ketinggalan di belakang permintaan tulis Jenis ini boleh dibaca dari nod hamba, melalui pengasingan IO dan beberapa dasar fail yang datang dengan sistem pengendalian, seperti pagecache, cache baca ke hadapan, dsb. , prestasi boleh dipertingkatkan dengan ketara.

Skala mendatar adalah ciri yang sangat penting dalam sistem teragih Masalah yang boleh diselesaikan dengan menambah mesin bukan masalah. Jadi bagaimana untuk melaksanakan baris gilir mesej yang boleh mencapai pengembangan mendatar Jika kita mempunyai baris gilir mesej yang berdiri sendiri, apabila bilangan topik meningkat, IO, CPU, lebar jalur, dan lain-lain akan beransur-ansur menjadi kesesakan, dan prestasi akan berkurangan bagaimana untuk meneruskan di sini? Bagaimana dengan pengoptimuman prestasi?

1. perpecahan topik/log Pada asasnya, mesej yang ditulis oleh topik adalah rekod log Apabila bilangan penulisan bertambah, satu mesin perlahan-lahan akan menjadi halangan -topik. Dan peruntukkan setiap topik ke mesin yang berbeza Dengan cara ini, topik dengan jumlah mesej yang banyak boleh diselesaikan dengan menambah mesin, manakala beberapa topik dengan jumlah mesej yang kecil boleh ditetapkan ke mesin yang sama atau tidak diproses. Pembahagian
2. Komit kumpulan, seperti pelanggan pengeluar Kafka, apabila menulis mesej, mula-mula menulisnya ke baris gilir memori tempatan, kemudian meringkaskan mesej mengikut setiap partition dan nod, dan menyerahkannya dalam kelompok Untuk bahagian pelayan atau broker, ia boleh Juga menggunakan kaedah ini, cache halaman ditulis terlebih dahulu, dan kemudian cakera disiram dengan kerap Kaedah pembilasan boleh ditentukan mengikut perniagaan Sebagai contoh, perkhidmatan kewangan mungkin menggunakan kaedah pembilasan segerak.
3. Elak salinan data yang tidak berguna
4. IO Pengasingan
   

Log memainkan peranan yang sangat penting dalam sistem teragih dan merupakan kunci untuk memahami pelbagai komponen sistem teragih Apabila pemahaman kami semakin mendalam, kami mendapati bahawa banyak perisian tengah teragih dibina berdasarkan log, seperti Zookeeper, HDFS, Kafka, RocketMQ, Google. Spanner, dsb., dan juga pangkalan data seperti Redis, MySQL, dsb., master-slave mereka adalah berdasarkan penyegerakan log Bergantung pada sistem log yang dikongsi, kami boleh melaksanakan banyak sistem: penyegerakan data dan konkurensi antara nod Kemas kini isu pesanan data. (isu ketekalan), ketekunan (sistem boleh terus menyediakan perkhidmatan melalui nod lain apabila sistem ranap), perkhidmatan kunci yang diedarkan, dsb. Saya percaya bahawa melalui latihan dan membaca sejumlah besar kertas, akan ada tahap cerapan yang lebih mendalam persefahaman.

Atas ialah kandungan terperinci Teras sistem teragih - log. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!