Penulis | Liang Junjie
Edit Xiaozhi
PhxQueue adalah antrean terdistribusi WeChat open source dengan ketersediaan tinggi, throughput tinggi, dan keandalan tinggi berdasarkan protokol Paxos. PhxQueue menjamin Pengiriman Paling Sedikit dan mendukung berbagai layanan penting seperti pembayaran WeChat dan platform publik.
Alamat sumber terbuka
https://github.com/Tencent/phxqueue
Ringkasan antrian pesan
Sebagai mode komunikasi asinkron yang matang, antrean pesan memiliki keunggulan berikut dibandingkan dengan mode komunikasi sinkron yang umum digunakan:
Decoupling: Mencegah masuknya API yang terlalu banyak dari membawa risiko pada stabilitas sistem; penggunaan yang tidak tepat oleh pemanggil akan menyebabkan tekanan pada sistem callee, dan penanganan yang tidak tepat oleh callee akan mengurangi responsivitas sistem pemanggil.
Peak shaving dan flow control: pembuat pesan tidak akan diblokir, pesan burst disimpan dalam antrian, dan konsumen dapat membaca pesan sesuai dengan kemampuan mereka yang sebenarnya.
Penggunaan kembali: Publikasikan beberapa langganan sekaligus.
Latar belakang lahir PhxQueue
Antrian lama
Antrean terdistribusi (disebut antrean lama) yang digunakan oleh WeChat pada tahap awal merupakan komponen penting dari latar belakang yang dikembangkan sendiri oleh WeChat, yang banyak digunakan dalam berbagai skenario bisnis untuk menyediakan layanan seperti decoupling, caching, dan asinkronisasi.
Antrian lama menggunakan Quorum NRW sebagai mekanisme sinkronisasi, di mana N = 3, W = R = 2, dan metode brushing menggunakan brushing asinkron, yang memperhitungkan performa dan ketersediaan.
permintaan baru
Dengan perkembangan layanan, jenis layanan akses meningkat, dan antrian lama secara bertahap tampaknya tidak mampu. Kekurangan utama adalah sebagai berikut:
Flash disk asinkron, keandalan data mengkhawatirkan
Untuk bisnis terkait pembayaran, memastikan data yang andal adalah persyaratan utama. Saat ini, sebagian besar skema antrian terdistribusi menggunakan replikasi sinkronis + pembilasan asinkron untuk memastikan keandalan data, tetapi kami yakin bahwa pembilasan sinkron diperlukan untuk lebih meningkatkan keandalan data.
Masalah rusak
Beberapa bisnis mengajukan persyaratan yang benar-benar tertib, tetapi NRW tidak menjamin ketertiban dan tidak dapat memenuhi persyaratan.
Selain itu, antrian lama masih memiliki masalah lain seperti dequeue deduplication, load balancing, dll yang perlu ditingkatkan. Semua hal di atas mendorong kami untuk mempertimbangkan opsi baru.
Kekurangan solusi industri
Kafka adalah antrian pesan yang umum digunakan di bidang big data, awalnya dikembangkan oleh LinkedIn menggunakan bahasa Scala dan digunakan sebagai dasar untuk pelacakan aliran aktivitas LinkedIn dan pipeline pemrosesan data sistem operasi.
Fitur-fiturnya seperti throughput yang tinggi, pemulihan bencana otomatis, dan masuk dan keluar yang teratur telah menarik banyak perusahaan untuk menggunakan dan memainkan peran penting dalam skenario pengumpulan dan transmisi data.Untuk detailnya, lihat Powerd By Kafka.
Namun, kami telah menyelidiki sepenuhnya Kafka dan percaya bahwa Kafka memiliki kekurangan berikut dalam konteks keandalan data:
Kontradiksi antara kinerja Kafka dan flashing sinkron
Ketika Kafka menyalakan log konfigurasi.flush.interval.messages = 1 dan mengaktifkan fitur flashing sinkron, throughput akan menurun tajam. Fenomena ini disebabkan oleh faktor-faktor berikut:
Amplifikasi tulis SSD
Ukuran rata-rata pesan bisnis adalah sekitar 1k. Unit terkecil dari flashing SSD adalah ukuran halaman, yaitu 4k. Saat Kafka menghapus pesan yang ukurannya kurang dari 4k, jumlah data fisik yang sebenarnya ditulis beberapa kali ukuran pesan. Akibatnya, sumber daya bandwidth tulis hard disk terbuang percuma.
Kumpulan produsen tidak berfungsi dengan baik dalam skenario bisnis
Kafka Producer batch, secara sederhana, adalah mengemas beberapa pesan bersama dan mengirimkannya ke Broker, yang banyak digunakan dalam skenario big data. Secara logis, efek batch cukup untuk mengimbangi efek amplifikasi tulis. Namun, produksi pesan dalam skenario bisnis berbeda dengan produksi log dalam skenario data besar. Setiap permintaan bisnis yang perlu diantrekan memiliki konteks independen dalam sistem bisnis, dan pengelompokan sulit dilakukan. Bahkan jika lapisan agen ditambahkan antara bisnis dan Pialang, dan Produser ditransfer ke lapisan agen untuk pengelompokan, karena banyaknya node di lapisan agen, efek batch sulit untuk ditingkatkan, dan amplifikasi tulis tidak dapat diimbangi.
Kurangnya desain sinkronisasi replika Kafka
Ringkasan desain sinkronisasi replika Kafka:
Pemimpin Kafka Broker akan melacak daftar pengikut yang tetap sinkron dengannya. Daftar ini disebut ISR (In-sync Replica). Jika pengikut turun atau terlalu jauh di belakang, pemimpin akan menghapusnya dari ISR.
Metode sinkronisasi ini menekankan pada efisiensi sinkronisasi, tetapi sedikit kurang dalam hal kegunaan:
Broker gagal karena tingkat keberhasilan proses turun drastis
Dalam skenario 3 replika, pemimpin didistribusikan secara merata di setiap Broker. Kegagalan broker berarti 1/3 dari pemimpin dan pengikut sedang offline, dan tingkat keberhasilan baca dan tulis turun:
-
Untuk partisi yang pemimpinnya sedang offline, untuk sementara tidak dapat membaca dan menulis, dan itu perlu menunggu Pengendali untuk memilih pemimpin baru sebelum dapat dipulihkan;
-
Partisi offline pengikut untuk sementara tidak dapat membaca dan menulis. Partisi harus menunggu selama jangka waktu tertentu (tergantung pada replica.lag.time.max.ms, default 10s) sebelum pemimpin menghapus pengikut yang gagal dari ISR untuk pulih.
Dengan kata lain, ketika ada Broker yang gagal, tingkat keberhasilan baca dan tulis akan turun menjadi 0 dalam jangka waktu tertentu.
Penundaan sinkronisasi tergantung pada node yang paling lambat
Dalam skenario replikasi sinkronis, Anda harus menunggu hingga semua node mengembalikan ack.
Dengan membandingkan performa replika Kafka dan Paxos, kami yakin Paxos adalah pilihan yang lebih baik dalam hal sinkronisasi:
Oleh karena itu, berdasarkan antrian lama, kami menggunakan protokol Paxos untuk mengubah logika sinkronisasi, dan melakukan sejumlah pengoptimalan termasuk sikat sinkronisasi, dan menyelesaikan PhxQueue.
Pengenalan PhxQueue
PhxQueue saat ini mendukung beberapa bisnis penting seperti pembayaran WeChat dan platform publik dalam WeChat, dengan pendaftaran harian rata-rata 100 miliar dan pendaftaran puncak 100 juta per menit.
Titik awal desainnya adalah keandalan data yang tinggi tanpa mengorbankan ketersediaan dan throughput yang tinggi, sekaligus mendukung berbagai fitur antrean umum.
Fitur-fitur yang didukung oleh PhxQueue adalah sebagai berikut:
-
Kedipan sinkron, tidak pernah kehilangan data yang terdaftar, dengan rekonsiliasi real-time internal
-
Masuk dan keluar yang ketat dan tertib
-
Berlangganan multi
-
Batas kecepatan keberangkatan
-
Dequeue replay
-
Semua modul dapat diperluas secara paralel
-
Batch flashing dan sinkronisasi lapisan penyimpanan untuk memastikan throughput yang tinggi
-
Lapisan penyimpanan mendukung penerapan multi-pusat di kota yang sama
-
Pemulihan bencana otomatis / keseimbangan akses di lapisan penyimpanan
-
Pemulihan bencana / load balancing otomatis konsumen
Desain PhxQueue
Struktur keseluruhan
PhxQueue terdiri dari 5 modul berikut.
Penyimpanan antrian toko
Simpan bertindak sebagai penyimpanan antrian dan memperkenalkan pustaka PhxPaxos, yang menggunakan protokol Paxos untuk sinkronisasi salinan. Selama sebagian besar node berfungsi dan saling berhubungan, layanan baca dan tulis yang konsisten dan linier dapat disediakan.
Untuk meningkatkan keandalan data, flashing sinkron adalah fitur default, dan kinerjanya tidak kalah dengan flashing asinkron.
Dalam hal ketersediaan, ada beberapa grup paxos independen di Store. Setiap grup paxos hanya menyediakan layanan baca dan tulis ke master. Biasanya master didistribusikan secara dinamis dan merata di antara node di Store untuk menyeimbangkan tekanan akses dan secara otomatis mengalihkan master ke node lain saat bencana terjadi. Node yang tersedia.
Produser-Produser
Sebagai pembuat pesan, Produser memutuskan rute penyimpanan pesan sesuai dengan kuncinya. Pesan dengan kunci yang sama dirutekan ke antrian yang sama secara default untuk memastikan bahwa urutan antrian konsisten dengan urutan entri antrian.
Konsumen-Konsumen
Sebagai konsumen, Konsumen menarik pesan dari Store dalam mode penarikan batch, dan mendukung pemrosesan batch pesan dengan cara multi-coroutine.
Konsumen menyediakan layanan dalam bentuk kerangka layanan, dan pengguna menentukan logika pemrosesan pesan tertentu sesuai dengan topik yang berbeda (Topik) dan jenis pemrosesan yang berbeda (Penangan) dengan mengimplementasikan callback.
Scheduler-Consumer Manager (penerapan opsional)
Peran Penjadwal adalah mengumpulkan informasi pemuatan global konsumen, dan melakukan pemulihan bencana dan penyeimbangan muatan untuk konsumen. Jika pengguna tidak memiliki persyaratan ini, mereka dapat mengabaikan penerapan Penjadwal. Pada saat ini, setiap Konsumen menentukan hubungan pemrosesan dengan antrian sesuai dengan bobot konfigurasi.
Setelah Penjadwal diterapkan, pemimpin Penjadwal menjaga detak jantung dengan semua Conuser. Saat mengumpulkan informasi muatan Konsumen, itu secara terbalik menyesuaikan hubungan pemrosesan antara Konsumen dan antrian.
Saat pemimpin Penjadwal turun, Penjadwal mengandalkan layanan kunci terdistribusi berikut untuk memilih pemimpin baru. Periode tidak tersedia hanya memengaruhi toleransi bencana dan penyeimbangan beban Konsumen, dan tidak memengaruhi konsumsi normal Konsumen.
Kunci Terdistribusi Kunci (penerapan opsional)
Kunci adalah kunci terdistribusi. Desain antarmukanya sangat umum. Pengguna dapat memilih untuk menerapkan Lock secara independen untuk menyediakan layanan kunci yang didistribusikan secara umum.
Peran Lock di PhxQueue adalah sebagai berikut:
Pilih seorang pemimpin untuk Penjadwal;
Mencegah banyak Konsumen memproses antrian pada saat yang bersamaan.
Lock juga merupakan modul penerapan opsional:
-
Jika Penjadwal diterapkan, Kunci harus digunakan untuk memilih pemimpin Penjadwal;
-
Jika tidak, jika bisnis tidak sensitif terhadap konsumsi berulang, Anda dapat memilih untuk tidak menerapkan Lock.
Skenario konsumsi berulang yang dirujuk di sini adalah: jika penerapan Penjadwal dihilangkan, Konsumen perlu mengetahui kumpulan antrian yang dapat diproses dengan membaca konfigurasi; ketika antrian diubah (seperti penyusutan dan perluasan antrian), konfigurasi pada setiap mesin Konsumen berubah terlebih dahulu Setelah beberapa waktu, status konfigurasi yang dilihat setiap Konsumen pada saat yang sama mungkin berbeda, menyebabkan dua Konsumen berpikir bahwa mereka harus menggunakan antrian yang sama untuk jangka waktu tertentu, sehingga mengakibatkan konsumsi berulang. Penerapan Lock dapat menghindari konsumsi berulang dalam skenario ini. (Perhatikan bahwa meskipun penerapan Lock dihilangkan, skenario ini hanya akan menyebabkan konsumsi berulang, dan tidak akan menyebabkan konsumsi tidak teratur)
Simpan proses penyalinan
PhxQueue Store mereplikasi salinan melalui protokol PhxPaxos.
Implementasi teknik PhxPaxos dibagi menjadi tiga lapisan: lapisan aplikasi bertanggung jawab untuk memproses permintaan bisnis, lapisan paxos melakukan proses sinkronisasi paxos, dan lapisan mesin status memperbarui status bisnis.
Diantaranya, lapisan aplikasi memulai proposal paxos, dan setiap node dari lapisan paxos bersama-sama menyelesaikan konfirmasi log paxos melalui protokol paxos. Setelah itu, mesin status menggunakan log paxos sebagai masukan untuk transfer status, memperbarui status bisnis, dan terakhir mengembalikan hasil transfer status ke lapisan aplikasi. Lapisan mesin status yang konsisten, ditambah masukan yang konsisten dari lapisan paxos, menghasilkan transisi status yang konsisten, sehingga memastikan konsistensi yang kuat di antara beberapa node.
Di sini kita ingin mengimplementasikan antrian pada lapisan mesin status berdasarkan PhxPaxos, dan kita perlu membuat pemetaan konseptual berikut:
-
Model antrian tidak melibatkan modifikasi data, ini adalah pengumpulan data yang terurut, yang sangat mirip dengan definisi log paxos, sehingga data antrian dapat langsung digunakan sebagai log paxos, dan mesin status hanya perlu menyimpan urutan log paxos.
-
Sifat id instance yang semakin meningkat membuatnya nyaman untuk digunakan sebagai offset antrean.
-
Data sebelum pembacaan offset dalam antrian dianggap data yang dapat dihapus, yang sesuai dengan definisi check point.
Secara keseluruhan, mesin status antrian dan paxos cocok.
Simpan sinkronisasi penyiraman dan salinan yang Efisien Komit Grup
Protokol Paxos yang tidak dioptimalkan tidak menyelesaikan masalah amplifikasi tulis dari flashing sinkron. Apalagi efisiensi sinkronisasi replikanya tidak sebaik Kafka.
Alasannya adalah sinkronisasi replika Kafka di-streaming dalam batch, sedangkan protokol Paxos menggunakan log paxos sebagai unit untuk sinkronisasi serial. Overhead sinkronisasi setiap log paxos adalah 1 RTT + 1 flush.
Dalam skenario penerapan multi-DC, penundaan ping dapat mencapai 4ms, yang akan menghasilkan TPS maksimum teoretis hanya 250 untuk satu grup paxos.
Kami menggunakan beberapa penyebaran grup paxos dan metode Komitmen Grup untuk secara bersamaan memecahkan masalah amplifikasi tulis dari flashing sinkron dan masalah throughput Paxos.
Seperti yang ditunjukkan pada gambar di atas, kami menerapkan beberapa grup paxos, dengan grup paxos sebagai unit Komitmen Grup, satu grup paxos sesuai dengan beberapa antrian, dan data bahwa beberapa antrian antrian dalam satu periode waktu digabungkan bersama, saat menunggu memakan waktu atau akumulasi Ketika jumlah data mencapai ambang batas, sinkronisasi Paxos dan sinkronisasi berkedip akan dipicu satu kali, dan ujung depan akan diblokir selama masa tunggu.
Dibandingkan dengan logika batch Producer Kafka, keuntungan dari penggabungan batch dengan Komitmen Grup pada lapisan penyimpanan adalah sebagai berikut:
Lapisan bisnis tidak perlu memperhatikan cara mengatur permintaan dalam kelompok;
Pada lapisan penyimpanan, efek agregasi kelompok paxos lebih baik daripada efek agregasi lapisan atas.
Perbandingan PhxQueue dan Kafka
Berikut ini membandingkan PhxQueue dan Kafka dari tiga aspek: desain, kinerja, dan proses failover lapisan penyimpanan.
Perbandingan desain
Meskipun arsitektur PhxQueue mirip dengan antrian terdistribusi umum seperti Kafka, masih banyak fitur unik dalam desainnya. Untuk memudahkan pembaca yang memiliki pengetahuan tentang Kafka untuk memahami PhxQueue, perbandingan antara keduanya tercantum di bawah ini.
Catatan: Perbandingan berikut ini didasarkan pada skenario keandalan data yang sama: node minoritas gagal, tidak akan menyebabkan kehilangan data, dan keseluruhan masih tersedia.
Perbandingan kinerja
lingkungan pengujian
Uji tolok ukur dan konfigurasi
Hasil tes
Mulai Batch Produser:
Tutup Kelompok Produser:
Dalam skenario di atas, hambatan PhxQueue ada di cpu, dan tingkat pemanfaatannya adalah 70% ~ 80%.
ringkasan
Kinerja PhxQueue sama dengan Kafka;
Di bawah QPS yang sama, karena tidak perlu menunggu node paling lambat kembali, konsumsi waktu rata-rata PhxQueue sedikit lebih baik daripada Kafka;
Setelah menutup Producer Batch, kinerja PhxQueue dapat menjadi dua kali lipat dari Kafka dalam skenario flash disk sinkron. Alasannya adalah bahwa lapisan penyimpanan PhxQueue melakukan batch sebelum menulis ke disk, tetapi Kafka tidak, sehingga yang terakhir akan memiliki amplifikasi tulis.
Perbandingan proses failover lapisan penyimpanan
Terutama membandingkan dampak pada throughput keseluruhan setelah mematikan node di lapisan penyimpanan.
Kafka
yang dilakukan:
-
Selama periode Failover, tingkatannya berbeda pada tahapan yang berbeda, dan tingkat keberhasilan bergabung dengan tim adalah 0% ~ 33%;
-
Durasi Failover ditentukan oleh sewa, dan durasi sewa default adalah 10 detik.
Proses pengujian:
Sesuaikan replica.lag.time.max.ms dari 10 detik menjadi 60 detik (perpanjang waktu untuk memfasilitasi observasi), lalu matikan Broker 0, pilih 3 partisi, dan amati perubahan ISR sebagai berikut:
Diantaranya, tingkat keberhasilan bergabung dengan tim di tahap kedua dan ketiga terganggu:
-
Selama fase kedua, Partisi 96/97/98 tidak dapat ditulis, dan tingkat keberhasilan bergabung dengan tim turun menjadi 0%.
-
Selama fase ketiga, Partisi 96 dapat terus menulis, tetapi Partisi 97/98 tidak dapat menulis, karena penulisan harus menunggu Broker 0 mengembalikan ack, tetapi Broker 0 telah terbunuh, dan tingkat keberhasilan bergabung dengan tim turun menjadi 33%.
Berdasarkan pengamatan aktual, tidak ada throughput selama fase kedua dan ketiga, alasannya adalah alat uji tekanan terus melaporkan kegagalan koneksi dan berhenti menulis.
Keluaran alat uji tekanan:
Log kegagalan alat uji stres yang terhubung ke Broker:
Analisis Penyebab:
Pemimpin Kafka Broker dipilih melalui Pengendali, dan daftar ISR dipegang oleh pemimpin.
Sewa yang pertama ditentukan oleh Kontroler, dan sewa yang terakhir ditentukan oleh replica.lag.time.max.ms konfigurasi broker.
Oleh karena itu, tahap kedua memiliki durasi yang lebih pendek dan ditentukan oleh waktu sewa pengontrol, dan tahap ketiga memiliki durasi yang lebih lama dan ditentukan oleh replica.lag.time.max.ms.
Saat Broker 0 terbunuh, yang pertama memengaruhi tingkat keberhasilan antrean 1/3 partisi di mana Broker 0 adalah pemimpinnya, dan yang terakhir memengaruhi tingkat keberhasilan antrean dari 2/3 partisi dari Broker 0 sebagai pengikut.
PhxQueue
yang dilakukan:
-
Selama periode Failover, tingkat keberhasilan bergabung dengan tim hanya turun menjadi 66%;
-
Durasi Failover ditentukan oleh sewa, dan durasi sewa default adalah 5 detik.
-
Setelah mengaktifkan fitur coba ulang pengubah antrean (cocok untuk bisnis yang tidak memiliki persyaratan urutan mutlak untuk meningkatkan ketersediaan), masih ada tingkat keberhasilan antrean 90 +% selama periode failover.
Proses pengujian:
Sesuaikan durasi sewa master toko dari 10 detik menjadi 60 detik (perpanjang waktu untuk memfasilitasi pengamatan), lalu tutup toko 0 untuk mengamati tingkat keberhasilan Produser tertentu dalam tim:
Matikan fitur coba lagi antrian:
Aktifkan fitur coba lagi antrean:
ringkasan
Pada proses failover pada lapisan penyimpanan, tingkat keberhasilan PhxQueue dan Kafka telah menurun dalam jangka waktu tertentu, tingkat keberhasilan PhxQueue adalah 66% ~ 100%, dan tingkat keberhasilan Kafka adalah 0% ~ 33%;
Setelah PhxQueue mengaktifkan fitur coba ulang pengubah antrean, tingkat keberhasilan bergabung dengan antrian selama proses failover tetap pada 90 +%;
Baik PhxQueue dan Kafka dapat secara otomatis beralih master, dan akhirnya tingkat keberhasilan bergabung ke antrean dipulihkan sepenuhnya.
Tulis di akhir
PhxQueue telah melakukan banyak upaya di lapisan penyimpanan: ia menyadari pengalihan master otomatis, dan masih menjamin konsistensi linier, dan masih sangat tersedia selama peralihan; ia menjamin throughput dari flashing sinkron, dan kinerjanya tidak kurang dari flashing asinkron.
Selain itu, ia menyadari sebagian besar fitur praktis dari antrean, seperti urutan masuk dan keluar yang konsisten, beberapa langganan, batas kecepatan, pemutaran ulang pesan, dll., Yang sesuai untuk berbagai skenario bisnis.
Saat ini, PhxQueue telah digunakan dalam skala besar dalam WeChat dan secara resmi merupakan open source.
Kami akan mempertahankan versi sumber terbuka PhxQueue konsisten dengan versi internal. Pembaca dipersilakan untuk mencobanya dan memberikan umpan balik.
Alamat sumber terbuka:
https://github.com/Tencent/phxqueue
tentang PenulisLiang Junjie, insinyur senior WeChat, saat ini bertanggung jawab atas pengembangan dan optimalisasi sistem perpesanan WeChat dan middleware perpesanan. Lulus dari South China Normal University pada tahun 2011, ia telah berpartisipasi dalam dan memimpin perpesanan pribadi Weibo, sistem anti-spam, dan beberapa proyek pengoptimalan arsitektur sistem WeChat. Sekitar setahun terakhir ini, sebagai salah satu anggota kreatif utama PhxQueue, dia telah melakukan transformasi arsitektural utama dari antrean terdistribusi WeChat, dan berkomitmen untuk menyediakan layanan middleware pesan dengan ketersediaan tinggi, throughput tinggi, dan sangat andal.
Rekomendasi Hari IniKlik gambar di bawah untuk membaca
Perbandingan besar dari solusi konsistensi transaksi sistem terdistribusi
- 190324 Kuda hidup! Tutorial dialek Sichuan memungkinkan Anda memahami Li Yifeng dalam beberapa menit
- Detail dari "Apakah Kamu Tahu" dipuji dengan sangat baik, dan nama orang-orang telah memberi bayangan akhir dari setiap karakter
- Netflix meluncurkan serial Italia "Rome Baby", menceritakan kisah gadis-gadis muda yang tidak diketahui!