Hai Baru-baru ini saya menemukan deskripsi yang agak menarik tentang arsitektur Saluran Pusher dan memutuskan untuk menerjemahkannya untuk Anda. Menurut pendapat saya, penulis sangat mudah menggambarkan pendekatan untuk membangun arsitektur yang sangat dimuat dan terukur. Kemungkinan besar, artikel ini akan bermanfaat bagi pemula, serta spesialis dari bidang terkait.
Di kantor Pusher, kami memiliki loket kecil dengan jumlah yang terus meningkat. Ini menunjukkan jumlah pesan yang dikirim untuk seluruh keberadaan Saluran Pusher. Pada hari Jumat pukul 22.20 UTC, jumlahnya meningkat satu kategori dan mencapai 10.000.000.000.000. Ini memiliki 13 nol - 10 triliun.
Anda mungkin berpikir bahwa jumlah total pesan adalah metrik bengkak yang tidak berguna. Tetapi angka itu adalah indikator kunci keberhasilan Pusher Channels, produk komunikasi waktu-nyata kami. Pertama, penghitung ini mencerminkan kepercayaan yang diberikan kepada kami oleh pengguna. Kedua, ini mengukur skalabilitas sistem kami. Untuk menambah jumlahnya, kami di Pusher harus memastikan bahwa pengguna memercayai pengiriman pesan ke layanan kami, dan kami harus yakin bahwa sistem kami mampu memproses pesan-pesan ini. Tapi apa yang harus kita sampaikan 10 triliun pesan? Ayo lihat.
Sekitar 200.000 pesan dikirim per detik melalui Saluran Pusher, dan jutaan di waktu puncak. Misalnya, ketika New York Times menggunakan layanan ini untuk memberi informasi kepada para pembacanya tentang kemajuan pemilihan presiden AS.
Mari pertama-tama kita melihat Pusher Channels sebagai kotak hitam besar tempat semua pesan ini dikirimkan:
Saluran Pusher adalah sistem tipe publish-subscribe. Klien berlangganan saluran (misalnya, "btc-usd" atau "private-user-jim"), sementara klien lain mengirim pesan kepada mereka. Jika satu juta orang berlangganan saluran "btc-usd" dan seseorang mengirim biaya bitcoin sebenarnya di sana, maka Saluran Pusher perlu mengirimkan sejuta pesan. Kami melakukan ini dalam beberapa milidetik.
Satu server tidak dapat mengirimkan begitu banyak pesan dalam waktu yang singkat. Oleh karena itu, kami menggunakan tiga teknik yang telah teruji waktu: fan-out, sharding, dan load balancing. Mari kita lihat apa yang ada di kotak hitam.
Jutaan pelanggan didistribusikan di sekitar 170 server canggih, yang masing-masing memiliki sekitar 20.000 koneksi. Setiap server seperti itu mengingat daftar saluran yang menarik bagi pelanggannya dan berlangganan mereka di layanan Redis pusat. Bahkan jika 2000 klien tertarik pada "btc-usd" di server tepi, ia hanya perlu berlangganan sekali. Dengan demikian, ketika pesan baru tiba di saluran, Redis mengirim 170 pesan ke server tepi, yang sudah mengirim 20.000 pesan ke pelanggan mereka. Pendekatan ini disebut fan-out.
Tetapi hanya fan-out saja tidak cukup bagi kami, karena masih ada satu komponen Redis sentral yang melaluinya semua yang mengirim pesan pergi. Sentralisasi ini membatasi jumlah pesan yang dikirim per detik. Untuk mengatasi keterbatasan ini, layanan Redis pusat terdiri dari banyak pecahan Redis. Setiap saluran, pada gilirannya, dilampirkan ke Redis-shard dengan mencantumkan namanya. Ketika klien ingin mengirim pesan, ia pergi ke layanan sisanya. Yang terakhir hash nama saluran dan, berdasarkan hasilnya, menentukan Redis shard yang diperlukan untuk mana pesan harus dikirim. Pendekatan ini disebut sharding.
Sepertinya kami baru saja memindahkan sentralisasi dari layanan Redis ke layanan lainnya. Tetapi tidak demikian, karena layanan sisanya itu sendiri terdiri dari sekitar 90 server yang melakukan pekerjaan yang sama: mereka menerima permintaan untuk publikasi, menghitung Redis-shard dan mengirim pesan kepada mereka. Ketika penerbit ingin mengirim pesan, ia pergi ke salah satu dari banyak server lainnya. Pendekatan ini disebut load balancing.
Bersama fan-out, sharding dan load balancing memungkinkan sistem memiliki satu komponen utama. Properti ini adalah kunci untuk mencapai skalabilitas horizontal, yang memungkinkan pengiriman jutaan pesan per detik.
Kami memeriksa komponen utama layanan Pusher Channels, tetapi ada bagian lain, seperti metrik (bagaimana kami mendapatkan jumlah 10 triliun ini), webhooks (bagaimana kami memberi tahu pelanggan tentang peristiwa menarik), otorisasi (membatasi akses ke saluran), data aktif pengguna, pembatasan tingkat (bagaimana kami memastikan bahwa pelanggan kami menggunakan sumber daya persis sebanyak yang mereka bayar, dan bahwa mereka tidak mengganggu pelanggan lain). Semua fungsi tambahan ini harus dilaksanakan tanpa mengorbankan bandwidth, waktu pengiriman pesan dan ketersediaan layanan kami secara keseluruhan.