ApsaraMQ for RocketMQ menggunakan kebijakan load balancing untuk mengontrol cara produsen merutekan pesan ke antrian dan cara broker menetapkan pesan atau antrian ke konsumen. Kebijakan sisi konsumen bergantung pada versi TCP client SDK yang digunakan.
Cara kerja
ApsaraMQ for RocketMQ mendukung dua model load balancing konsumen:
| Model | Perilaku konsumen | Kompatibel dengan | Karakteristik utama |
|---|---|---|---|
| Berdasarkan pesan | Broker mendistribusikan pesan individual ke konsumen. Beberapa konsumen dapat memproses pesan dari antrian yang sama. | TCP client SDK untuk Java V2.x.x.Final, TCP client SDK untuk C++ V3.x.x | Tidak ada konsumen menganggur meskipun jumlah konsumen melebihi jumlah antrian. |
| Berdasarkan antrian | Broker menetapkan seluruh antrian ke konsumen. Setiap antrian diproses oleh tepat satu konsumen. | TCP client SDK untuk Java V1.x.x.Final, TCP client SDK untuk C++ V1.x.x dan V2.x.x | Jumlah konsumen sebaiknya tidak melebihi jumlah antrian agar tidak ada konsumen yang menganggur. |
Load balancing produsen bekerja dengan cara yang sama pada kedua model:
Pesan tidak terurut (pesan normal, transaksi, terjadwal, dan tertunda): Produsen mengirim pesan ke antrian secara round-robin.
Pesan terurut: Produsen mengirim semua pesan dengan kunci sharding yang sama ke antrian yang sama.
Kebijakan load balancing yang kompatibel dengan SDK untuk Java V2.x.x.Final dan SDK untuk C++ V3.x.x
Kebijakan load balancing ini mendistribusikan pesan individual — bukan seluruh antrian — ke konsumen. Beberapa konsumen dapat memproses pesan dari antrian yang sama secara bersamaan, dan tidak ada konsumen yang menganggur meskipun jumlah konsumen melebihi jumlah antrian.
Prasyarat
Untuk menggunakan kebijakan load balancing ini, lakukan upgrade TCP client SDK Anda:
TCP client SDK untuk Java: Upgrade ke V2.x.x.Final. Instans harus dideploy di salah satu wilayah berikut: Tiongkok (Hangzhou), Tiongkok (Qingdao), Tiongkok (Beijing), Tiongkok (Zhangjiakou), Tiongkok (Hohhot), Tiongkok (Shenzhen), Tiongkok (Chengdu), Jerman (Frankfurt), atau Indonesia (Jakarta).
TCP client SDK untuk C++: Upgrade ke V3.x.x. Instans dapat dideploy di wilayah mana pun.
Rute produsen
Load balancing produsen tetap sama terlepas dari versi SDK:
Pesan tidak terurut (pesan normal, transaksi, terjadwal, dan tertunda): Produsen mengirim pesan ke antrian secara round-robin. Dalam contoh ini, tersedia tiga antrian. Produsen mengirim Msg1 ke Queue 1, Msg2 ke Queue 2, Msg3 ke Queue 3, Msg4 kembali ke Queue 1, dan seterusnya.
Pesan terurut: Produsen mengirim semua pesan dengan kunci sharding yang sama ke antrian yang sama. Dalam contoh ini, semua pesan dengan kunci sharding 1 masuk ke Queue 1, dan semua pesan dengan kunci sharding 2 masuk ke Queue 2.
Penetapan konsumen untuk pesan tidak terurut
Untuk pesan tidak terurut, broker mendistribusikan semua pesan dalam suatu topik secara merata ke konsumen dalam kelompok yang sama. Pesan dalam antrian yang sama dapat dikonsumsi oleh konsumen berbeda secara bersamaan.
Dalam contoh ini, empat pesan dalam Queue 2 didistribusikan masing-masing ke Consumer 1, Consumer 2, Consumer 3, dan Consumer 4. Setiap konsumen memproses pesan secara independen, terlepas dari antrian tempat pesan tersebut berasal.
Penetapan konsumen untuk pesan terurut
Untuk pesan terurut, broker mendistribusikan pesan berdasarkan kunci sharding. Semua pesan dengan kunci sharding yang sama masuk ke konsumen yang sama, sehingga menjaga urutan produksi. Pesan dengan kunci sharding berbeda dapat didistribusikan ke konsumen berbeda.
: Pesan dengan warna latar belakang ini termasuk dalam Queue 1. Misalnya, Msg2-1 adalah pesan kedua dalam Queue 1, dan kunci sharding-nya adalah 1.
: Pesan dengan warna latar belakang ini termasuk dalam Queue 2. Misalnya, Msg3-2 adalah pesan ketiga dalam Queue 2, dan kunci sharding-nya adalah 2.
Dalam contoh ini:
Msg1-1, Msg2-1, dan Msg3-1 semuanya masuk ke Consumer 1 karena memiliki kunci sharding 1.
Pesan dengan kunci sharding 2 semuanya masuk ke Consumer 2.
Msg4-3 dan Msg4-4 masuk ke konsumen berbeda karena memiliki kunci sharding berbeda.
Kebijakan load balancing yang kompatibel dengan SDK untuk Java V1.x.x.Final dan SDK untuk C++ V1.x.x serta V2.x.x
Kebijakan load balancing ini menetapkan seluruh antrian ke konsumen. Setiap antrian diproses oleh tepat satu konsumen dalam satu waktu. Kebijakan penetapan untuk pesan tidak terurut dan pesan terurut adalah sama.
Cara distribusi antrian
Arsitektur ApsaraMQ for RocketMQ mencakup broker dan name server. Broker melaporkan informasi rute topik ke name server. Secara default, pesan dalam suatu topik didistribusikan ke 8 antrian per broker. Antrian merupakan konsep logis. Broker kemudian menetapkan antrian-antrian ini secara merata ke semua konsumen dalam kelompok yang sama.
Rute produsen
Load balancing produsen sama seperti pada SDK untuk Java V2.x.x.Final dan SDK untuk C++ V3.x.x:
Pesan tidak terurut: Produsen mengirim pesan ke antrian secara round-robin.
Pesan terurut: Produsen mengirim semua pesan dengan kunci sharding yang sama ke antrian yang sama.
Untuk detail dan diagram, lihat Rute produsen di atas.
Penetapan konsumen
Karena setiap antrian hanya dapat ditetapkan ke satu konsumen dalam satu waktu, rasio konsumen terhadap antrian secara langsung memengaruhi pemanfaatan resource:
Jumlah konsumen lebih banyak daripada antrian: Konsumen tambahan tetap menganggur. Misalnya, dengan 8 antrian dan 10 konsumen, 2 konsumen tidak memproses pesan apa pun.
Jumlah konsumen sama dengan jumlah antrian: Setiap konsumen memproses pesan dari tepat satu antrian.
Jumlah konsumen lebih sedikit daripada antrian: Setiap konsumen memproses pesan dari beberapa antrian.
Akumulasi pesan
Dengan load balancing berbasis antrian, konsumen mungkin gagal memproses pesan dalam antrian yang ditetapkan secara tepat waktu karena kendala perangkat keras, batasan sistem, masalah Remote Procedure Call (RPC), atau jeda Java Garbage Collection (GC). Ketika hal ini terjadi, pesan menumpuk di antrian.