Pengantar Scaleout di SignalR
oleh Patrick Fletcher
Peringatan
Dokumentasi ini bukan untuk versi terbaru SignalR. Lihatlah ASP.NET Core SignalR.
Versi perangkat lunak yang digunakan dalam topik ini
- Visual Studio 2013
- .NET 4.5
- SignalR versi 2
Versi sebelumnya dari topik ini
Untuk informasi tentang versi SignalR yang lebih lama, lihat Versi Lama SignalR.
Pertanyaan dan komentar
Silakan tinggalkan umpan balik tentang bagaimana Anda menyukai tutorial ini dan apa yang dapat kami tingkatkan di komentar di bagian bawah halaman. Jika Anda memiliki pertanyaan yang tidak terkait langsung dengan tutorial, Anda dapat mempostingnya ke forum ASP.NET SignalR atau StackOverflow.com.
Secara umum, ada dua cara untuk menskalakan aplikasi web: meningkatkan dan meluaskan skala.
- Meningkatkan skala berarti menggunakan server yang lebih besar (atau VM yang lebih besar) dengan lebih banyak RAM, CPU, dll.
- Peluasan skala berarti menambahkan lebih banyak server untuk menangani beban.
Masalah dengan peningkatan skala adalah Anda dengan cepat mencapai batas ukuran komputer. Di luar itu, Anda perlu menskalakan keluar. Namun, ketika Anda menskalakan keluar, klien bisa dirutekan ke server yang berbeda. Klien yang tersambung ke satu server tidak akan menerima pesan yang dikirim dari server lain.
Salah satu solusinya adalah meneruskan pesan antar server, menggunakan komponen yang disebut backplane. Dengan backplane diaktifkan, setiap instans aplikasi mengirim pesan ke backplane, dan backplane meneruskannya ke instans aplikasi lainnya. (Dalam elektronik, backplane adalah sekelompok konektor paralel. Secara analogi, backplane SignalR menghubungkan beberapa server.)
SignalR saat ini menyediakan tiga backplanes:
- Azure Service Bus. Service Bus adalah infrastruktur olahpesan yang memungkinkan komponen mengirim pesan dengan cara yang digabungkan secara longgar.
- Redis. Redis adalah penyimpanan kunci-nilai dalam memori. Redis mendukung pola terbitkan/berlangganan ("pub/sub") untuk mengirim pesan.
- SQL Server. Backplane SQL Server menulis pesan ke tabel SQL. Backplane menggunakan Service Broker untuk olahpesan yang efisien. Namun, ini juga berfungsi jika Service Broker tidak diaktifkan.
Jika Anda menyebarkan aplikasi di Azure, pertimbangkan untuk menggunakan backplane Redis menggunakan Azure Redis Cache. Jika Anda menyebarkan ke farm server Anda sendiri, pertimbangkan backplanes SQL Server atau Redis.
Topik berikut berisi tutorial langkah demi langkah untuk setiap backplane:
- SignalR Scaleout dengan Azure Service Bus
- Scaleout SignalR dengan Redis
- SignalR Scaleout dengan SQL Server
Implementasi
Di SignalR, setiap pesan dikirim melalui bus pesan. Bus pesan mengimplementasikan antarmuka IMessageBus , yang menyediakan abstraksi terbitkan/berlangganan. Backplanes bekerja dengan mengganti IMessageBus default dengan bus yang dirancang untuk backplane tersebut. Misalnya, bus pesan untuk Redis adalah RedisMessageBus, dan menggunakan mekanisme pub/sub Redis untuk mengirim dan menerima pesan.
Setiap instans server terhubung ke backplane melalui bus. Ketika pesan dikirim, pesan masuk ke backplane, dan backplane mengirimkannya ke setiap server. Ketika server mendapatkan pesan dari backplane, server menempatkan pesan di cache lokalnya. Server kemudian mengirimkan pesan kepada klien dari cache lokalnya.
Untuk setiap koneksi klien, kemajuan klien dalam membaca aliran pesan dilacak menggunakan kursor. (Kursor mewakili posisi di aliran pesan.) Jika klien terputus dan kemudian terhubung kembali, klien akan meminta pesan apa pun kepada bus yang tiba setelah nilai kursor klien. Hal yang sama terjadi ketika koneksi menggunakan polling panjang. Setelah permintaan polling yang panjang selesai, klien membuka koneksi baru dan meminta pesan yang tiba setelah kursor.
Mekanisme kursor berfungsi bahkan jika klien dirutekan ke server yang berbeda saat menyambungkan kembali. Backplane mengetahui semua server, dan tidak masalah server mana yang terhubung dengan klien.
Batasan
Menggunakan backplane, throughput pesan maksimum lebih rendah daripada ketika klien berbicara langsung ke satu simpul server. Itu karena backplane meneruskan setiap pesan ke setiap node, sehingga backplane dapat menjadi penyempitan. Apakah batasan ini adalah masalah tergantung pada aplikasi. Misalnya, berikut adalah beberapa skenario SignalR umum:
- Siaran server (misalnya, ticker stok): Backplanes bekerja dengan baik untuk skenario ini, karena server mengontrol laju pengiriman pesan.
- Klien ke klien (misalnya, obrolan): Dalam skenario ini, backplane mungkin menjadi hambatan jika jumlah pesan diskalakan dengan jumlah klien; artinya, jika tingkat pesan tumbuh secara proporsional saat lebih banyak klien bergabung.
- Realtime frekuensi tinggi (misalnya, game real-time): Backplane tidak disarankan untuk skenario ini.
Mengaktifkan pelacakan untuk penskalaan SignalR
Untuk mengaktifkan pelacakan untuk backplanes, tambahkan bagian berikut ke file web.config, di bawah elemen konfigurasi akar:
<configuration>
<system.diagnostics>
<sources>
<source name="SignalR.SqlMessageBus">
<listeners>
<add name="SignalR-Bus" />
</listeners>
</source>
<source name="SignalR.ServiceBusMessageBus">
<listeners>
<add name="SignalR-Bus" />
</listeners>
</source>
<source name="SignalR.ScaleoutMessageBus">
<listeners>
<add name="SignalR-Bus" />
</listeners>
</source>
</sources>
<switches>
<add name="SignalRSwitch" value="Verbose" />
<!-- Off, Critical, Error, Warning, Information, Verbose -->
</switches>
<sharedListeners>
<add name="SignalR-Bus"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="bus.log.txt" />
</sharedListeners>
<trace autoflush="true" />
</system.diagnostics>
. . .
</configuration>