<\/div>\n

\nMerhaba,<\/p>\n

Malumunuz, .NET ekosisteminde ger\u00e7ek zamanl\u0131 (realtime) uygulamalar geli\u015ftirirken ilk akla gelen ve en \u00e7ok tercih edilen \u00e7\u00f6z\u00fcm SignalR<\/a>‘d\u0131r. Uygulama k\u00fc\u00e7\u00fckten orta seviyeye do\u011fru seyrettik\u00e7e, SignalR tek bir sunucuda (single instance) olduk\u00e7a konforlu, sorunsuz ve ba\u015far\u0131l\u0131 bir \u015fekilde bizlere e\u015flik etmektedir. Ancak bu konfor, uygulaman\u0131n b\u00fcy\u00fcmesiyle ve horizontal scaling<\/a> ihtiya\u00e7lar\u0131n\u0131n ortaya \u00e7\u0131kmas\u0131yla h\u0131zla kaybolmakta ve yerini ciddi mimari karma\u015f\u0131kl\u0131klara ve zorluklara b\u0131rakmaktad\u0131r. D\u00fc\u015f\u00fcn\u00fcn ki; SignalR uygulamas\u0131n\u0131 birden fazla sunucuyla \u00f6l\u00e7eklendirdi\u011fimiz vakit, bu sunucular aras\u0131nda client’lar\u0131n ayn\u0131 Hub \u00fczerinden haberle\u015fmesi do\u011fal olarak engellenmi\u015f olacakt\u0131r. Ya da bir ba\u015fka deyi\u015fle bu client’lar, ayn\u0131 Hub \u00fczerinden ileti\u015fim kuramaz hale gelecektir. Neden mi?<\/em> \u015eundan ki; SignalR, varsay\u0131lan olarak in-memory bir mesajla\u015fma altyap\u0131s\u0131 kullanmaktad\u0131r… Ee haliyle \u00f6l\u00e7eklendirmenin yap\u0131ld\u0131\u011f\u0131 bu mimaride bir kullan\u0131c\u0131 X sunucusuna, di\u011feri ise Y sunucusuna ba\u011fland\u0131\u011f\u0131nda iki sunucunun birbirinden haberi olmayaca\u011f\u0131 i\u00e7in aralar\u0131nda ger\u00e7ek zamanl\u0131 bir ileti\u015fim modelinin kurulmas\u0131 \u015fu \u015fartlarda pekte m\u00fcmk\u00fcn olmayacakt\u0131r. \u0130\u015fte tam da bu noktada farkl\u0131 SignalR sunucular\u0131 aras\u0131nda mesaj trafi\u011fini koordine eden bir distributed mesajla\u015fma altyap\u0131s\u0131 sunan Backplane<\/strong> kavram\u0131 devreye girecektir. E\u011fer ki vaziyet SignalR uygulamas\u0131n\u0131 production’da \u00f6l\u00e7eklendirmeyi gerektiriyorsa, evet, bu kavram ile \u00e7\u00f6z\u00fcm rahatl\u0131kla sunulabilmektedir. Bizler bu i\u00e7eri\u011fimizde, SignalR’\u0131 \u00f6l\u00e7eklendirmenin en pop\u00fcler ve ba\u015far\u0131l\u0131 yollar\u0131ndan biri olan Redis Backplane’i detayl\u0131ca ele alacak ve bir yandan da Redis’in y\u00fcksek performansl\u0131 yap\u0131s\u0131n\u0131 nas\u0131l SignalR ile entegre edebilece\u011fimizi, kurulumundan konfig\u00fcrasyonuna, performans ipu\u00e7lar\u0131ndan olas\u0131 tuzaklara kadar t\u00fcm kritik noktalar\u0131 inceliyor olaca\u011f\u0131z… Haz\u0131rsan\u0131z ba\u015flayal\u0131m…<\/p>\n

\n
\n
Ba\u015fl\u0131klar<\/p>\n Toggle<\/span>
Problem Nedir?<\/a>
Peki Bu Durum Neden Tehlikelidir?<\/a><\/li>
Peki \u00c7\u00f6z\u00fcm Ne Olabilir?<\/a><\/li><\/ul><\/li>
Redis Backplane Nedir?<\/a>
Art\u0131lar\u0131 & Eksileri Nelerdir?<\/a><\/li>
Nas\u0131l Kurulur & Kullan\u0131l\u0131r?<\/a><\/li><\/ul><\/li>
Sticky Sessions Hala Gerekli!<\/a><\/li>
Peki Redis \u00c7\u00f6kt\u00fc\u011f\u00fcnde Ne Olacak?<\/a><\/li><\/ul><\/nav><\/div>\n
<\/span>Problem Nedir?<\/span><\/h3>\n
Diyelim ki 3 adet uygulama sunucumuz olsun… $\"Redis$ <\/a>Ve s\u0131ras\u0131yla ‘A’, ‘B’ ve ‘C’ client’lar\u0131 bu sunuculara ba\u011flanm\u0131\u015f olsun. $\"Redis$ <\/a>\u015eimdi b\u00f6yle bir vaziyette sunucu 1’e ba\u011fl\u0131 olan ‘A’ client’\u0131 SignalR \u00fczerinden a\u015fa\u011f\u0131daki gibi bir mesaj g\u00f6nderirse e\u011fer; $\"Redis$ <\/a>sunucu 1 yaln\u0131zca kendi belle\u011findeki ba\u011flant\u0131lar\u0131 bilece\u011fi i\u00e7in bu mesaj di\u011fer sunuculara ba\u011fl\u0131 olan client’lara iletilmeyecek, yani sadece ‘A’ client’\u0131na iletilecektir.<\/p>\n
\u0130\u015fte b\u00f6yle, SignalR’\u0131n \u00f6l\u00e7eklendirilmesi gereken durumlarda bir handikap s\u00f6z konusu olmaktad\u0131r. Her ne kadar await Clients.All.SendAsync(...)<\/code> metoduna bak\u0131ld\u0131\u011f\u0131nda ilgili mesaj\u0131n her client’a g\u00f6nderilece\u011fi san\u0131l\u0131yor olsa da ger\u00e7ekte olan davran\u0131\u015f ise SignalR’\u0131n bildi\u011fi herkese g\u00f6nderece\u011fidir! Bunun nedeni yukar\u0131daki sat\u0131rlarda ifade etmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131m\u0131z gibi SignalR’\u0131n bulundu\u011fu sunucunun in-memory’si \u00fczerinden mesajla\u015fma altyap\u0131s\u0131 kullanmas\u0131d\u0131r. <\/p>\n
SignalR, sunucu belle\u011finde olu\u015fturdu\u011fu bir tablo \u00fczerinde client’lar\u0131 tutmakta ve await Clients.All.SendAsync(...)<\/code> gibi bir talimat geldi\u011fi taktirde bu ileti\u015fime bu tablodaki client’lar\u0131 muhattap k\u0131lmaktad\u0131r. Haliyle bu problem, SignalR’dan ziyade distributed sistemlerin realtime \u00e7al\u0131\u015fmalarda ya\u015fad\u0131\u011f\u0131 temel bir problemdir. Bizler, mimariye performans kayg\u0131lar\u0131yla ikinci bir sunucuyu ya da instance’\u0131 ekledi\u011fimiz anda mevzu bahis handikap durumu meydana gelmekte ve art\u0131k her bir SignalR bulundu\u011fu sunucu \u00fczerinde di\u011fer(ler)inden izole bir hale gelmektedir. Dolay\u0131s\u0131yla bu izolasyon sebebiyle, bir sunucuya ba\u011fl\u0131 olan istemciler di\u011fer sunuculardaki istemcilerle haberle\u015fememektedirler.<\/p>\n
<\/span>Peki Bu Durum Neden Tehlikelidir?<\/span><\/h4>\nBu durumun, farkl\u0131 sunuculardaki client’lar aras\u0131nda mesajla\u015fmay\u0131 imkans\u0131z hale getirdi\u011finin zaten fark\u0131nday\u0131z. Bunun d\u0131\u015f\u0131nda esas bahsedilmesi gereken daha kritik bir tehlike s\u00f6z konusu olabilir. O da sistemin bazen \u00e7al\u0131\u015f\u0131yor gibi g\u00f6r\u00fcnmesidir… Diyelim ki, ‘A’ ile ‘B’ client’lar\u0131 ayn\u0131 sunucuda olsun. Bu iki client aras\u0131ndaki haberle\u015fme s\u00fcrecinde herhangi bir problem meydana gelmeyece\u011fi i\u00e7in kimsenin ger\u00e7ek riske dair bir fark\u0131ndal\u0131\u011f\u0131 olmayacak ve durum anla\u015f\u0131lmayacakt\u0131r. Ancak bir zaman sonra bu iki client farkl\u0131 sunuculara gitti\u011fi taktirde client’lar realtime’da haberle\u015femeyecek ve kullan\u0131c\u0131lar g\u00f6z\u00fcnde mesajlar kaybolacakt\u0131r. Hatta kimi kullan\u0131c\u0131lar, durumu gir \u00e7\u0131k vs. gibi k\u00fc\u00e7\u00fck testlerde tekrar edecek ve bazen di\u011fer client ile ayn\u0131 sunucuya denk gelecekleri i\u00e7in mesajlar\u0131n ara ara iletildi\u011fini d\u00fc\u015f\u00fcnecektirler. Vee b\u00f6ylece g\u00fcn\u00fcn sonunda son kullan\u0131c\u0131 a\u00e7\u0131s\u0131ndan en bahts\u0131z kanaate var\u0131lacak ve “bazen \u00e7al\u0131\u015f\u0131yor, bazen \u00e7al\u0131\u015fm\u0131yor<\/em>” \u015feklinde uygulaman\u0131n ad\u0131 bir daha 8’e inmemek \u00fczere 9’a \u00e7\u0131kacakt\u0131r.<\/p>\n D\u00fc\u015f\u00fcnsenize, 2 sunucuyla \u00f6l\u00e7eklendirmenin yap\u0131ld\u0131\u011f\u0131 senaryolarda 50%, 4 sunucuyla 75%, 10 ve fazlas\u0131 sunucuyla yap\u0131lanlarda ise 90% client’lar\u0131n farkl\u0131 sunucularda olma ihtimali s\u00f6z konusudur. Yani SignalR’\u0131n kullan\u0131ld\u0131\u011f\u0131 projelerde, scaling ile performans kazanmak isterken do\u011frulu\u011fu kaybetmek olduk\u00e7a y\u00fcksek ihtimaldir.<\/p>\n<\/span>Peki \u00c7\u00f6z\u00fcm Ne Olabilir?<\/span><\/h4>\nBelki ilk etapta sticky sessions<\/a> akla geliyor olabilir ve evet, belki bir nebze i\u015fe yarayabilir. Ama sunuculardan biri \u00e7\u00f6kt\u00fc\u011f\u00fc taktirde client farkl\u0131 bir sunucuya ba\u011flanacak ve bu seferde ileti\u015fimde oldu\u011fu di\u011fer client’larla yine haberle\u015fmesi kesilecek ve ayn\u0131 problem meydana gelecektir.<\/p>\n Ayr\u0131ca, sticky session’da sunucular aras\u0131nda X sunucusunda 5000 kullan\u0131c\u0131, Y sunucusunda 200 kullan\u0131c\u0131 gibi tutars\u0131z y\u0131\u011f\u0131nla\u015fmalar s\u00f6z konusu olabilir. Haliyle \u00f6l\u00e7eklendirme gibi performans niyetiyle tercih edilen bir yakla\u015f\u0131mdan kaynakl\u0131, ortaya \u00e7\u0131kan problemlere daha farkl\u0131 ve tuhaf problemlerle \u00e7\u00f6z\u00fcm getirmek k\u00fclliyen yanl\u0131\u015f bir yakla\u015f\u0131m olacakt\u0131r.<\/p>\n Ee peki \u00e7\u00f6z\u00fcm\u00fc nas\u0131l getirece\u011fiz hoca la?<\/strong><\/em> diye sorarsan\u0131z \u00f6ncelikle \u015fudur budur demekten ziyade nas\u0131l bir yakla\u015f\u0131m sergilememiz gerekti\u011fini konu\u015fmal\u0131y\u0131z. Yani bir teknolojiden yahut teknikten ziyade, fark\u0131nda olunmas\u0131 gereken as\u0131l \u015fey distributed mant\u0131kta d\u00fc\u015f\u00fcnme bi\u00e7imimizi geli\u015ftirmektir. Bu d\u00fc\u015f\u00fcnme bi\u00e7iminde ideal safhaya gelirsek zaten akl\u0131n yolu bir olan y\u00f6ntem ya da yakla\u015f\u0131m her neyse o anki probleme \u00e7\u00f6z\u00fcm olarak kendili\u011finden tezah\u00fcr etmi\u015f olacakt\u0131r. \u00c7\u00fcnk\u00fc, bu g\u00fcn SignalR’\u0131 konu\u015fuyor olabiliriz ancak yar\u0131n; cache, session, authentication, AI Agent vs. gibi durumlarda da benzer problemler mevzu bahis olacak ve yine kar\u015f\u0131m\u0131za \u00e7\u0131kacakt\u0131r.<\/p>\n \u015eimdi d\u00fc\u015f\u00fcnmemiz gereken mant\u0131\u011fa gelirsek; distributed sistemlerde ne kadar sunucu ya da container s\u00f6z konusuysa olay\u0131 o kadar ger\u00e7eklik<\/u> olarak yorumlayabiliriz. Tek sunucuda, tek bir ger\u00e7eklik vard\u0131r. Dolay\u0131s\u0131yla t\u00fcm sistemin akl\u0131 tek bir bellekten i\u015flenmektedir. Ancak, distributed sisteme ge\u00e7ildi\u011finde art\u0131k birden fazla ger\u00e7eklik s\u00f6z konusu olacakt\u0131r. Dolay\u0131s\u0131yla burada hi\u00e7bir sunucunun t\u00fcm ger\u00e7e\u011fi bilemeyece\u011finin fark\u0131nda olmam\u0131z gerekmektedir. Haliyle bu fark\u0131ndal\u0131k \u00fczerinden \u015f\u00f6yle bir mant\u0131\u011fa do\u011fru evrilmemiz gerekmektedir. Bilgiyi \u00fcretildi\u011fi yerde de\u011fil, payla\u015f\u0131lmas\u0131 gereken yerde tutmal\u0131y\u0131z. Yani ortak bir evrende… Bir ba\u015fka deyi\u015fle mutlak bir ger\u00e7eklikte…<\/p>\n Bir di\u011fer fark\u0131ndal\u0131\u011f\u0131m\u0131z ise bir sunucunun \u00f6lmesi sonucunda sistemin ger\u00e7e\u011fini yok etmeyecek \u015fekilde bir yakla\u015f\u0131m sergilenmesi gereklili\u011fidir. E\u011fer ki, sunucunun \u00f6lmesi neticesinde t\u00fcm bilgiler kayboluyorsa bilgi yanl\u0131\u015f yere koyulmu\u015f demektir.<\/p>\n Dolay\u0131s\u0131yla bu mant\u0131ktan \u00e7\u0131karaca\u011f\u0131m\u0131z \u00e7\u00f6z\u00fcm yolu, ger\u00e7eklik boyutunu ge\u00e7ici olan sunucu seviyesinden kal\u0131c\u0131 hale getirebilmekten ge\u00e7mektedir. Evet, ger\u00e7eklik boyutu sunucudan ba\u011f\u0131ms\u0131z bir \u015fekilde daha evrensel hale getirilirse t\u00fcm sunucular ve instance’lar aralar\u0131nda durumlar\u0131 de\u011fil, art\u0131k olaylar\u0131 payla\u015f\u0131r hale gelecektir. \u0130\u015fte bu durum da distributed sistemler i\u00e7in olduk\u00e7a ideal bir zemindir. Zaten yaz\u0131l\u0131m mimarilerinde ad\u0131 konulmam\u0131\u015f bir ilke vard\u0131r \ud83d\ude42 Muhtemelen ilk benden duymu\u015f olacaks\u0131n\u0131z: Sunuculara G\u00fcvenmeme \u0130lkesi<\/em>\ud83e\udd23Belki de ad\u0131n\u0131 art\u0131k koymu\u015f oldu\u011fumuz bu ilke, ba\u015fta garip gelse de \u00f6zellikle b\u00fcy\u00fck ve ticari hassasiyete sahip yaz\u0131l\u0131mlarda olduk\u00e7a kritik arz etmektedir. Bundan kaynakl\u0131 modern yaz\u0131l\u0131m mimarilerinde sunucular\u0131n \u00f6lmesi beklenen bir durum oldu\u011fu i\u00e7in t\u00fcm tasar\u0131mlar (genellikle) ba\u015ftan Kubernetes gibi altyap\u0131lara g\u00f6re \u015fekillenmektedir. Ki bu, SignalR gibi realtime durumlar\u0131 ilgilendiren hassasiyet olan yaz\u0131l\u0131mlar i\u00e7in daha da ba\u015ftan d\u00fc\u015f\u00fcn\u00fclmesi gereken bir mimaridir.<\/p>\n Bir uygulama tek bir sunucudan distributed sisteme d\u00f6n\u00fc\u015f\u00fcyorsa e\u011fer, art\u0131k sunucu(lar\u0131n) belle\u011fine g\u00fcvenilemez…<\/em><\/p><\/blockquote>\n Velhas\u0131l, anlayaca\u011f\u0131n\u0131z veri ak\u0131\u015f s\u00fcrecinde ger\u00e7ekli\u011fi tek bir makinenin belle\u011finden ziyade, merkezi bir hale getirerek y\u00fcr\u00fctebilirsek i\u015fte o taktirde i\u00e7erik boyunca konu\u015ftu\u011fumuz probleme ideal bir \u00e7\u00f6z\u00fcm sa\u011flanm\u0131\u015f olacakt\u0131r.<\/p>\n Peki bunu neyle yapaca\u011f\u0131z?<\/strong> \nMerkezi bir ger\u00e7eklik deyince tabi ki de akla direkt message broker yap\u0131lanmalar\u0131n\u0131n bizlere sundu\u011fu imkanlar gelebilmektedir. Evet… Do\u011frudur, hakl\u0131 olabilirsiniz. Anlatt\u0131\u011f\u0131m mant\u0131\u011f\u0131 ince i\u015f\u00e7ili\u011fiyle uygulamam\u0131z\u0131 sa\u011flayacak teknik altyap\u0131y\u0131 bu yap\u0131lanmalar bizlere sunmaktad\u0131r. RabbitMQ, Kafka, SQL Server Backplane, Service Bus mimarisi, NATS vs. gibi teknolojiler ve yakla\u015f\u0131mlarla bu probleme \u00e7\u00f6z\u00fcm getirebiliriz. Yani anlayaca\u011f\u0131n\u0131z, yaz\u0131m\u0131z\u0131n ba\u015fl\u0131\u011f\u0131nda \u00f6zellikle vurgulad\u0131\u011f\u0131m\u0131z Redis Backplane asl\u0131nda bu problemin tek \u00e7\u00f6z\u00fcm\u00fc de\u011fildir. Ama, en yayg\u0131n ve en pratik \u00e7\u00f6z\u00fcmlerden biridir diyebiliriz. \u0130\u015fte bu y\u00fczden bu i\u00e7eri\u011fimizde Redis Backplane ile bu probleme ideal \u00e7\u00f6z\u00fcm\u00fcn nas\u0131l getirilebilece\u011fini pratik olarak hep birlikte tecr\u00fcbe edece\u011fiz.<\/p>\n Microsoft, \u00f6zellikle cloud ortamlar\u0131 i\u00e7in Redis yerine Azure SignalR Service<\/a>‘in kullan\u0131lmas\u0131n\u0131 \u00f6nermektedir.<\/em><\/p><\/blockquote>\n <\/span>Redis Backplane Nedir?<\/span><\/h3>\nRedis Backplane, birden fazla uygulama sunucusunun birbirine haber g\u00f6nderebilmesi i\u00e7in kullan\u0131lan bir mesajla\u015fma k\u00f6pr\u00fcs\u00fcd\u00fcr. Yukar\u0131daki sat\u0131rlarda message broker olarak tan\u0131tt\u0131m belki ama backplane bir message broker’dan ziyade bir mimarisel pattern’d\u0131r ve bir sunucuda olu\u015fan olaylar\u0131 di\u011fer sunuculara ileten katman g\u00f6revi g\u00f6rmektedir. Message broker ise bu i\u015flemi yapan teknolojilerin ta kendisidir… Haliyle burada Redis, backplane g\u00f6revi g\u00f6ren message broker’\u0131m\u0131zd\u0131r… Umar\u0131m anla\u015f\u0131lm\u0131\u015ft\u0131r \ud83d\ude09<\/p>\n<\/a>Velhas\u0131l, davran\u0131\u015f\u0131 olduk\u00e7a basittir. Normalde, SignalR ba\u011flam\u0131nda d\u00fc\u015f\u00fcn\u00fcrsek e\u011fer bir client’tan g\u00f6nderilen mesaj sunucu \u00fczerindeki t\u00fcm client’lara eri\u015ftirilecektir. Ancak di\u011fer sunuculara eri\u015ftirilemeyecektir. Redis Backplane’de ise sunucular \u00f6nce Redis’e mesajlar\u0131n\u0131 iletecek, Redis ise kendisine ba\u011fl\u0131 olan t\u00fcm sunuculara bu mesajlar\u0131 iletmi\u015f olacakt\u0131r. B\u00f6ylece esas\u0131nda olay \u00f6nce Redis’e yay\u0131nlanm\u0131\u015f olacak, Redis’te bu mesaj\u0131 t\u00fcm uygulama sunucular\u0131na iletecek ve sunucularda kendilerine ba\u011fl\u0131 client’lara mesajlar\u0131 g\u00f6nderecektir…<\/p>\n Bu mimaride, ne client Redis’i bilecektir, ne de sunucular Redis’in detaylar\u0131yla ilgilenecektir. Sunucular aras\u0131ndaki koordinasyon s\u00fcre\u00e7 aksamaks\u0131z\u0131n olduk\u00e7a h\u0131zl\u0131 bir \u015fekilde ger\u00e7eklecektir.<\/p>\n Redis bu davran\u0131\u015f\u0131 Pub\/Sub \u00f6zelli\u011fini kullanarak ger\u00e7ekle\u015ftirmektedir.<\/em><\/p><\/blockquote>\n <\/span>Art\u0131lar\u0131 & Eksileri Nelerdir?<\/span><\/h4>\n\n <\/p>\n\n\n \u2713 Avantajlar\n <\/div>\n\n\nH\u0131zl\u0131 de\u011fil, \u00e7ok h\u0131zl\u0131d\u0131r… \u00c7\u00fcnk\u00fc Redis verileri RAM \u00fczerinde tuttu\u011fu i\u00e7in olduk\u00e7a y\u00fcksek performans sunmaktad\u0131r.<\/li>\n Kod taraf\u0131nda neredeyse hi\u00e7bir de\u011fi\u015fiklik yap\u0131lmaya gerek kalmaks\u0131z\u0131n kurulumu olduk\u00e7a kolayd\u0131r. \u00c7\u00fcnk\u00fc, sunucular\u0131n birbirlerini bulma kayg\u0131s\u0131, yeni bir sunucu geldi\u011finde sisteme nas\u0131l i\u015flenece\u011fi, mesajlar\u0131n hangi s\u0131ras\u0131yla gidece\u011fi ve hata durumlar\u0131nda ne olaca\u011f\u0131 gibi m\u00fchendislik problemleri Redis taraf\u0131ndan \u00fcstlenilmi\u015f ve \u00e7oktan halledilmi\u015ftir.<\/li>\nAyn\u0131 durum SignalR i\u00e7in de ge\u00e7erlidir… Malum, iyi mimarilerde i\u015f kurallar\u0131 altyap\u0131dan ba\u011f\u0131ms\u0131z olmal\u0131d\u0131r. Yani kod yaln\u0131zca mesaj g\u00f6nder<\/code> talimat\u0131n\u0131 vermeli, \u015fu sunucuya g\u00f6nder<\/s>, \u015funa bildir tarz\u0131<\/s> gibi altyap\u0131 sorunlar\u0131yla ilgilenmemeli. Redis, bu tarz ayr\u0131nt\u0131lar\u0131 da s\u00fcre\u00e7ten soyutlayarak bizlere kolayl\u0131k sa\u011flamaktad\u0131r.<\/li>\n<\/ul><\/div>\n<\/p><\/div>\n <\/p>\n\n\n \u26a0 Dikkat Edilmesi Gerekenler\n <\/div>\n\n\nB\u00fcy\u00fck \u00f6l\u00e7eklerde darbo\u011faz s\u00f6z konusu olabilir. \u00d6zellikle 100bin 500bin gibi connection’\u0131n s\u00f6z konusu oldu\u011fu durumlarda Redis tek ba\u015f\u0131na bask\u0131 alt\u0131nda kalabilir. \u00c7\u00fcnk\u00fc t\u00fcm mesajla\u015fmalar Redis \u00fczerinden ge\u00e7ecektir. Bu taktirde art\u0131k sorun, SignalR + realtime yap\u0131lanmas\u0131n\u0131n distributed ko\u015fullarda ortaya \u00e7\u0131kan problemi de\u011fil, Redis’in kald\u0131rabilece\u011fi y\u00fck olacakt\u0131r. Haliyle bu seviyede art\u0131k Redis Cluster yap\u0131s\u0131 planlanarak daha ileri \u00e7\u00f6z\u00fcmlerle s\u00fcre\u00e7 desteklenmelidir.<\/li>\n Redis Pub\/Sub mesaj\u0131 iletir ve siler. Haliyle bir mesaj kal\u0131c\u0131l\u0131\u011f\u0131 durumu s\u00f6z konusu de\u011fildir. Bu durum \u00e7\u00f6zmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131m\u0131z problemin davran\u0131\u015fsal yap\u0131s\u0131 a\u00e7\u0131s\u0131ndan da normaldir de! \u00c7\u00fcnk\u00fc, SignalR ger\u00e7ek zamanl\u0131 ileti\u015fim i\u00e7in tasarlanm\u0131\u015ft\u0131r. Haliyle bir mesaj g\u00f6nderilirken sunucu kapal\u0131ysa ister istemez o sunucudan connection olan t\u00fcm client’lar o mesaj\u0131 ka\u00e7\u0131racakt\u0131r. E\u011fer ki, mesajlar\u0131n kaybolmamas\u0131 isteniyorsa burada en do\u011fru \u00e7\u00f6z\u00fcm olarak RabbitMQ yahut Kafka gibi daha geli\u015fmi\u015f ve ince ayarlanabilir message broker’lara y\u00f6nelinmelidir.<\/li>\n<\/ul><\/div>\n<\/p><\/div>\n<\/div>\nPeki client’lar aras\u0131 haberle\u015fmede user odakl\u0131 bir mesajla\u015fma durumu varsa nas\u0131l davran\u0131\u015f sergilemektedir?<\/strong><\/em> \n <\/a>SignalR Backplane’de kullan\u0131c\u0131 odakl\u0131 mesajla\u015fma durumunun zihinsel modeli…<\/p><\/div>await Clients.User(\"userId\").SendAsync(...)<\/code> \u015feklindeki kullan\u0131c\u0131 odakl\u0131 mesaj g\u00f6nderim s\u00fcre\u00e7lerinde ise i\u015fler biraz daha ilgin\u00e7 hale gelmektedir. Distributed mimaride hedef kullan\u0131c\u0131n\u0131n hangi sunucuya ba\u011fl\u0131 oldu\u011fu bilinmedi\u011finden, ilk akla gelen \u00e7\u00f6z\u00fcm bu bilginin merkezi bir yerde yani Redis’te sorgulanmas\u0131 olabilir. Ancak SignalR Redis Backplane mimarisinde temel yakla\u015f\u0131m bu de\u011fildir! Bunun yerine SignalR, ilgili kullan\u0131c\u0131ya g\u00f6nderilmek istenen mesajlar\u0131 Redis \u00fczerinden t\u00fcm SignalR sunucular\u0131na duyuracak, mesaj\u0131 alan her sunucu, hedef kullan\u0131c\u0131n\u0131n kendine ba\u011fl\u0131 client’lar\u0131 aras\u0131nda bulunup bulunmad\u0131\u011f\u0131n\u0131 yerel olarak kontrol edecektir. Hedef kullan\u0131c\u0131ya sahip olan sunucu mesaj\u0131 iletirken, di\u011fer sunucular mesaj\u0131 g\u00f6rmezden gelecektir. B\u00f6ylece merkezi bir ba\u011flant\u0131 sorgulama mekanizmas\u0131 yerine, olay\u0131n t\u00fcm sunuculara yay\u0131nlanmas\u0131 ve yerel do\u011frulama yakla\u015f\u0131m\u0131 tercih edilmi\u015f olacakt\u0131r.<\/p>\n Esas\u0131nda bu modelin alt\u0131nda yatan distributed sistem prensibi fark ettiyseniz \u015fudur;<\/p>\nVerinin nerede oldu\u011funu merkezi olarak sorgulamak yerine, olay\u0131 herkese duyur ve ilgili taraf\u0131n kendini tan\u0131mas\u0131n\u0131 sa\u011fla…<\/em><\/p><\/blockquote>\n<\/span>Nas\u0131l Kurulur & Kullan\u0131l\u0131r?<\/span><\/h4>\nRedis ile SignalR’\u0131 \u00f6l\u00e7eklendirebilmek i\u00e7in tek yap\u0131lmas\u0131 gereken ilgili projeye Microsoft.AspNetCore.SignalR.StackExchangeRedis<\/a> k\u00fct\u00fcphanesinin y\u00fcklenmesi ve ard\u0131ndan a\u015fa\u011f\u0131daki gibi SignalR servisi \u00fczerinden AddStackExchangeRedis<\/code> servisinin \u00e7a\u011fr\u0131lmas\u0131d\u0131r:<\/p>\n \n\r\nbuilder.Services.AddSignalR()\r\n .AddStackExchangeRedis(builder.Configuration.GetConnectionString("redisCache")!);\r\n<\/pre>\n<\/div>\nEvet, uygulama kodu a\u00e7\u0131s\u0131ndan yap\u0131lmas\u0131 gereken \u00e7al\u0131\u015fma b\u00fcy\u00fck \u00f6l\u00e7\u00fcde bundan ibarettir \ud83d\ude42 Hele hele Hub taraf\u0131nda hi\u00e7bir \u015feyin de\u011fi\u015ftirilmesine gerek duyulmamas\u0131 da cabas\u0131d\u0131r… Tabi kod taraf\u0131nda olay bu yap\u0131land\u0131rmayla bitiyor olsa da mimari seviyesinde sorumluluklar\u0131m\u0131z devam etmektedir. Redis Backplane’in \u00e7al\u0131\u015fabilmesi i\u00e7in Redis sunucusunun ayakta olmas\u0131 gerekmekte ve t\u00fcm uygulama instance’lar\u0131n\u0131n ayn\u0131 Redis sunucusuna ba\u011flanmas\u0131 gerekmektedir. A\u011f eri\u015fimleri, firewall izinleri vs. gibi u\u011fra\u015flar\u0131n yan\u0131nda Redis ba\u011flant\u0131s\u0131n\u0131n kopmas\u0131 s\u00fcre\u00e7lerinde nas\u0131l davran\u0131\u015flar\u0131n benimsenece\u011fi ekstradan d\u00fc\u015f\u00fcn\u00fcl\u00fcp, hesap edilmelidir.<\/p>\n Ayr\u0131ca, Redis Backplane ekleyince uygulaman\u0131n tamam\u0131 otomatik olarak distributed sisteme d\u00f6n\u00fc\u015fmeyecektir. Yani, Redis Backplane sadece SignalR’\u0131n distributed \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flayacak, uygulaman\u0131n geri kalan\u0131nda distributed sistem problemlerini \u00e7\u00f6zmeyecektir. \u015e\u00f6yle ki; \u00f6rnek vermemiz gerekirse e\u011fer uygulama belle\u011finde public static List OnlineUsers = [];<\/code> ile t\u00fcm kullan\u0131c\u0131lar\u0131 tutuyorsan\u0131z sadece ilgili sunucuda bu ge\u00e7erli olacak, t\u00fcm sunucular\u0131 k\u00fcm\u00fclatif olarak ilgilendirmeyecektir. Yani hala bu tarz durumalar da sunucular ayr\u0131 d\u00fcnyalar olaca\u011f\u0131 i\u00e7in meydana gelebilecek problemleri Redis \u00e7\u00f6zmeyecektir.<\/p>\n Buradan anla\u015f\u0131lmas\u0131 gereken \u015fudur ki; distributed bir sistemde bir state (durum\/veri) tutuluyorsa e\u011fer onun da ortak yerde olmas\u0131 elzemdir. Ancak bu tarz dokunu\u015flarla distributed sistem tam oturakl\u0131 olacakt\u0131r. “Redis Backplane ekledim, art\u0131k t\u00fcm uygulamam distributed sisteme uygun oldu…”<\/em> demek hi\u00e7te do\u011fru bir kabul olmayacakt\u0131r!<\/p>\n<\/p>\n \n Bir Redis sunucusunun birden fazla SignalR uygulamas\u0131 taraf\u0131ndan kullan\u0131lmas\u0131 durumu…\n <\/div>\n \nBurada k\u00fc\u00e7\u00fckte olsa bir yap\u0131land\u0131rma durumunu kritize etmek istiyorum. E\u011fer ki, ayn\u0131 Redis sunucusunu birden fazla SignalR uygulamas\u0131 kullan\u0131yorsa mesajlar\u0131n birbirine kar\u0131\u015fmamas\u0131 i\u00e7in bir kanal \u00f6neki (channel prefix) tan\u0131mlanmas\u0131 gerekmektedir.<\/p>\nBunu daha net anlayabilmeniz i\u00e7in hafiften problemi g\u00f6rselle\u015ftirmeye \u00e7al\u0131\u015fal\u0131m: Diyelim ki ayn\u0131 Redis sunucusunu kullanan iki uygulaman\u0131z var;<\/p>\n\n\nE-Ticaret Uygulamas\u0131 \n \u2514\u2500 SignalR<\/p>\nCRM Uygulamas\u0131 \n \u2514\u2500 SignalR<\/p>\n Redis\n<\/p><\/div>\n\nBurada her iki uygulamada .AddStackExchangeRedis(\"localhost:6379\")<\/code> ile ba\u011flanacakt\u0131r. Uygulaman\u0131n \u00e7al\u0131\u015fmas\u0131 s\u00fcrecinde SignalR, node’lar aras\u0131nda mesaj ta\u015f\u0131mak i\u00e7in Redis \u00fczerinde SignalR.SomeChannel<\/em>, SignalR.GroupUpdates<\/em>, SignalR.Broadcast<\/em> vs. gibi pub\/sub channel’lar\u0131 olu\u015fturacakt\u0131r. E\u011fer ki her iki uygulamada ayn\u0131 kanallar kullan\u0131l\u0131yorsa, birinde SignalR’da payla\u015f\u0131lan mesaj di\u011ferine de yans\u0131t\u0131lacakt\u0131r. Bu istenmeyen bir durumdur.\n <\/div>\n<\/div>\nBurada \u00e7\u00f6z\u00fcm olarak a\u015fa\u011f\u0131daki gibi ChannelPrefix<\/code> yap\u0131land\u0131rmas\u0131yla SignalR uygulamas\u0131n\u0131n kullanaca\u011f\u0131 t\u00fcm Redis channel’lar\u0131n\u0131n ba\u015f\u0131na bu prefix eklenecektir:<\/p>\n\n\r\nbuilder.Services.AddSignalR()\r\n .AddStackExchangeRedis(builder.Configuration.GetConnectionString("redisCache")!, configure =>\r\n {\r\n configure.Configuration.ChannelPrefix = RedisChannel.Literal("MyApp");\r\n });\r\n<\/pre>\n<\/div>\nB\u00f6ylece tek bir Redis sunucusunda olunsa dahi uygulama seviyesinde mesaj ak\u0131\u015flar\u0131 birbirlerinden ayr\u0131lm\u0131\u015f olacakt\u0131r.\n <\/p><\/div>\n<\/div>\n <\/span>Sticky Sessions Hala Gerekli!<\/span><\/h3>\nYukar\u0131daki sat\u0131rlarda sticky sessions’a dair ilk etapta gelen fikre kar\u015f\u0131 durmu\u015f olsak da, hala sticky sessions’a ihtiyac\u0131m\u0131z oldu\u011funu itiraf etmeliyiz! Evet, Redis Backplane distributed bir altyap\u0131da mesaj y\u00f6nlendirme sorununu \u00e7\u00f6z\u00fcyor \u00e7\u00f6zmesine ancak, sticky session’lara olan ihtiyac\u0131 ortadan kald\u0131rm\u0131yor. Neden mi?<\/strong><\/em> \u015eundan dolay\u0131… Bir client’\u0131n SignalR’a ba\u011flant\u0131s\u0131 temelde m\u00fczakere a\u015famas\u0131na dayanmaktad\u0131r. Bu a\u015famada;<\/p>\n \n1. Ad\u0131mda<\/em> \nClient, connection token’\u0131 alabilmek i\u00e7in \/hub\/negotiate<\/code> endpoint’ine bir POST iste\u011fi g\u00f6nderir.<\/li>\n 2. Ad\u0131mda<\/em> \nClient, elde etti\u011fi connection token arac\u0131l\u0131\u011f\u0131yla WebSocket ba\u011flant\u0131s\u0131n\u0131 sa\u011flar.<\/li>\n<\/ul>\nBu s\u00fcre\u00e7te her iki iste\u011fin de ayn\u0131 sunucuda oldu\u011funun garantisinin sa\u011flanmas\u0131 gerekmektedir. Load balancer<\/a>, m\u00fczakere iste\u011fini server 1’e y\u00f6nlendirirken, WebSocket ba\u011flant\u0131 iste\u011fi server 2’ye y\u00f6nlendirilirse beklenece\u011fi \u00fczere ba\u011flant\u0131 ba\u015far\u0131s\u0131z olacakt\u0131r.<\/p>\n Bundan kaynakl\u0131 load balancer’da sticky sessions yap\u0131land\u0131rmas\u0131n\u0131n etkinle\u015ftirilmesine \u00f6zen g\u00f6sterilmelidir.<\/p>\n <\/span>Peki Redis \u00c7\u00f6kt\u00fc\u011f\u00fcnde Ne Olacak?<\/span><\/h3>\nBu yakla\u015f\u0131mda Redis \u00e7\u00f6kerse e\u011fer, kesinti s\u0131ras\u0131nda g\u00f6nderilen t\u00fcm mesajlar kaybolacakt\u0131r. Belki Redis’ten kaynakl\u0131 SignalR uygulamas\u0131 exception f\u0131rlatabilir ancak WebSocket ba\u011flant\u0131lar\u0131 bundan etkilenmeyecek ve client’lar\u0131n ba\u011flant\u0131s\u0131 devam edecektir. Haliyle Redis es kaza bu s\u00fcre\u00e7te tekrar \u00e7al\u0131\u015fmaya ba\u015flarsa e\u011fer SignalR otomatik olarak yeniden ba\u011flanacak ve uygulamalar aras\u0131 haberle\u015fme ak\u0131\u015f\u0131 hi\u00e7 problem yokmu\u015fcas\u0131na devam ediyor olacakt\u0131r.<\/p>\n Sipari\u015f g\u00fcncellemeleri yahut canl\u0131 g\u00f6sterge panolar\u0131 gibi \u00e7o\u011fu kullan\u0131c\u0131 eylemleri a\u00e7\u0131s\u0131ndan pasif olan realtime senaryolar i\u00e7in bu durum pek sorun te\u015fkil etmeyecektir. Ancak finansal veriler gibi kritik de\u011ferlerin s\u00f6z konusu oldu\u011fu ak\u0131\u015flarda yahut kullan\u0131c\u0131 eylemlerinin mevzu bahis oldu\u011fu s\u00fcre\u00e7lerde Redis’in \u00e7\u00f6k\u00fcp yeniden aya\u011fa kalkmas\u0131 neticesinde client ile server aras\u0131nda tekrar bir mutabakat s\u00fcrecine ihtiya\u00e7 olacak ve senkron \u00e7al\u0131\u015fan kal\u0131c\u0131 (durable) bir kuyru\u011fa (queue) gereksinim duyulacakt\u0131r.<\/p>\n Nihai olarak;<\/p>\n Anl\u0131yoruz ki, distributed bir d\u00fcnyada ger\u00e7ek zamanl\u0131l\u0131\u011f\u0131 korumak, sunuculara g\u00fcvenmekten de\u011fil, onlar\u0131n aras\u0131ndaki koordinasyonu do\u011fru kurmaktan ge\u00e7mektedir. Redis Backplane de tam olarak bu noktada, SignalR’\u0131n \u00f6l\u00e7eklenebilirli\u011fi ile performans\u0131 aras\u0131ndaki k\u00f6pr\u00fcy\u00fc sa\u011flam bir \u015fekilde in\u015fa etmemize olanak tan\u0131maktad\u0131r.<\/p>\n \u0130lgilenenlerin faydalanmas\u0131 dile\u011fiyle… \nSonraki yaz\u0131lar\u0131mda g\u00f6r\u00fc\u015fmek \u00fczere… \n\u0130yi \u00e7al\u0131\u015fmalar…<\/p>\n\n\n \n\u00d6rnek \u00e7al\u0131\u015fmaya a\u015fa\u011f\u0131daki GitHub reposundan eri\u015febilirsiniz.<\/div>\nhttps:\/\/github.com\/gncyyldz\/SignalRScalingWithRedis<\/div>\n<\/p><\/div>\n<\/p><\/div>\n\n Bu repository, ilgili konuya dair \u00f6rnek \u00e7al\u0131\u015fman\u0131n kaynak kodlar\u0131n\u0131 ve mimari yap\u0131s\u0131n\u0131 i\u00e7ermektedir. Detaylar i\u00e7in GitHub \u00fczerinden incelemede bulunabilirsiniz.\n <\/div>\n \n GitHub\u2019da G\u00f6r\u00fcnt\u00fcle \u2192 \n <\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":" Merhaba, Malumunuz, .NET ekosisteminde ger\u00e7ek zamanl\u0131 (realtime) uygulamalar geli\u015ftirirken ilk akla gelen ve en \u00e7ok tercih edilen \u00e7\u00f6z\u00fcm SignalR‘d\u0131r. Uygulama k\u00fc\u00e7\u00fckten orta seviyeye do\u011fru seyrettik\u00e7e, SignalR tek bir sunucuda (single instance) olduk\u00e7a konforlu, sorunsuz...<\/p>\n","protected":false},"author":1,"featured_media":28738,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3383,3760],"tags":[5724,3384,5726,639,5725],"class_list":["post-28696","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-redis","category-signalr","tag-backplane","tag-redis","tag-redis-backplane","tag-signalr","tag-signalr-scaling"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28696","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/comments?post=28696"}],"version-history":[{"count":31,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28696\/revisions"}],"predecessor-version":[{"id":28739,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28696\/revisions\/28739"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media\/28738"}],"wp:attachment":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media?parent=28696"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/categories?post=28696"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/tags?post=28696"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}