Veritabanlar\u0131n\u0131z\u0131n her zaman eri\u015filebilir olmas\u0131, modern uygulamalar\u0131n olmazsa olmaz\u0131d\u0131r. Peki, Redis gibi pop\u00fcler bir bellek i\u00e7i veri yap\u0131s\u0131 deposunu nas\u0131l y\u00fcksek eri\u015filebilir hale getirebilirsiniz? Bu makalede, Redis’in iki g\u00fc\u00e7l\u00fc y\u00fcksek eri\u015filebilirlik (high availability – HA) \u00e7\u00f6z\u00fcm\u00fc olan Sentinel ve Cluster’\u0131 derinlemesine inceleyecek, bu \u00e7\u00f6z\u00fcmleri WRedis gibi kullan\u0131c\u0131 dostu ara\u00e7larla nas\u0131l entegre edebilece\u011finizi ad\u0131m ad\u0131m anlataca\u011f\u0131z. Uygulamalar\u0131n\u0131z\u0131n kesintisiz \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamak ve veri kayb\u0131n\u0131 \u00f6nlemek i\u00e7in bilmeniz gereken her \u015fey burada!<\/p>\n
G\u00fcn\u00fcm\u00fcz\u00fcn dijital d\u00fcnyas\u0131nda, uygulamalar\u0131n s\u00fcrekli \u00e7evrimi\u00e7i olmas\u0131 ve kullan\u0131c\u0131 taleplerine an\u0131nda yan\u0131t vermesi kritik \u00f6neme sahiptir. Bir veritaban\u0131n\u0131n \u00e7\u00f6kmesi veya eri\u015filemez hale gelmesi, sadece bir teknik aksakl\u0131k de\u011fil, ayn\u0131 zamanda i\u015f s\u00fcreklili\u011fi i\u00e7in ciddi bir tehdit olu\u015fturur. \u00d6zellikle y\u00fcksek trafikli veya hassas verilerle \u00e7al\u0131\u015fan sistemlerde, Redis gibi performans odakl\u0131 veri depolar\u0131n\u0131n y\u00fcksek eri\u015filebilirli\u011fini sa\u011flamak, ba\u015far\u0131n\u0131n anahtarlar\u0131ndan biridir. Peki, bu y\u00fcksek eri\u015filebilirli\u011fi nas\u0131l garanti alt\u0131na alabiliriz? \u0130\u015fte bu noktada Redis’in sundu\u011fu g\u00fc\u00e7l\u00fc \u00e7\u00f6z\u00fcmler devreye giriyor: Redis Sentinel ve Redis Cluster.<\/p>\n
Bu makalede, Redis’in y\u00fcksek eri\u015filebilirlik konusundaki temel ta\u015flar\u0131 olan Sentinel ve Cluster’\u0131 detayl\u0131 bir \u015fekilde ele alaca\u011f\u0131z. Ayr\u0131ca, bu karma\u015f\u0131k g\u00f6r\u00fcnen yap\u0131lar\u0131 daha y\u00f6netilebilir hale getiren WRedis gibi ara\u00e7lar\u0131n rol\u00fcne de de\u011finece\u011fiz. Amac\u0131m\u0131z, hem Redis’e yeni ba\u015flayanlar\u0131n temel kavramlar\u0131 anlamas\u0131n\u0131 sa\u011flamak hem de deneyimli geli\u015ftiricilere ileri d\u00fczeyde bilgiler ve pratik ipu\u00e7lar\u0131 sunmakt\u0131r. Haz\u0131rsan\u0131z, Redis ile kesintisiz hizmetin kap\u0131lar\u0131n\u0131 aralayal\u0131m.<\/p>\n
Uygulamalar\u0131n\u0131z\u0131n performans\u0131n\u0131 ve kullan\u0131c\u0131 deneyimini do\u011frudan etkileyen veritaban\u0131 eri\u015filebilirli\u011fi, g\u00fcn\u00fcm\u00fcz i\u015f d\u00fcnyas\u0131n\u0131n vazge\u00e7ilmez bir par\u00e7as\u0131d\u0131r. Bir web sitesinin veya mobil uygulaman\u0131n yo\u011fun saatlerde yava\u015flamas\u0131 veya tamamen eri\u015filemez hale gelmesi, potansiyel m\u00fc\u015fteri kayb\u0131na, itibar zedelenmesine ve gelir d\u00fc\u015f\u00fc\u015f\u00fcne yol a\u00e7abilir. \u00d6zellikle e-ticaret platformlar\u0131, finansal uygulamalar, oyun sunucular\u0131 ve canl\u0131 yay\u0131n servisleri gibi s\u00fcrekli hizmet sunmas\u0131 gereken sistemlerde, tek bir Redis \u00f6rne\u011finin (instance) ar\u0131zalanmas\u0131 felaketle sonu\u00e7lanabilir. Bu nedenle, Redis gibi s\u0131k\u00e7a kullan\u0131lan ve y\u00fcksek performans gerektiren veri depolar\u0131 i\u00e7in “tek nokta hatas\u0131” (single point of failure – SPOF) riskini ortadan kald\u0131rmak hayati \u00f6nem ta\u015f\u0131r. Y\u00fcksek eri\u015filebilirlik (HA) \u00e7\u00f6z\u00fcmleri, birincil (primary) Redis sunucusunda bir sorun ya\u015fand\u0131\u011f\u0131nda, otomatik olarak yedek (standby) bir sunucuya ge\u00e7i\u015f yaparak hizmetin kesintisiz devam etmesini sa\u011flar. Bu, hem veri kayb\u0131n\u0131 \u00f6nler hem de kullan\u0131c\u0131lar\u0131n uygulaman\u0131za her zaman sorunsuz bir \u015fekilde eri\u015febilmesini garantiler. Bu ge\u00e7i\u015fin ne kadar h\u0131zl\u0131 ve sorunsuz ger\u00e7ekle\u015fti\u011fi, uygulaman\u0131z\u0131n g\u00fcvenilirli\u011fi a\u00e7\u0131s\u0131ndan do\u011frudan belirleyicidir.<\/p>\n
Ger\u00e7ek d\u00fcnya senaryolar\u0131nda, y\u00fcksek eri\u015filebilirli\u011fin \u00f6nemi daha da belirginle\u015fir. \u00d6rne\u011fin, bir e-ticaret sitesinin bayram indirimleri gibi en yo\u011fun oldu\u011fu d\u00f6nemde Redis sunucusunun \u00e7\u00f6kmesi, milyonlarca dolarl\u0131k sat\u0131\u015f kayb\u0131na neden olabilir. Benzer \u015fekilde, bir finansal i\u015flem platformunda meydana gelen bir kesinti, hem maddi kay\u0131plara hem de kullan\u0131c\u0131 g\u00fcveninin sars\u0131lmas\u0131na yol a\u00e7abilir. Bu t\u00fcr senaryolarda, otomatik hata devralma (automatic failover) yetene\u011fine sahip Redis HA \u00e7\u00f6z\u00fcmleri, sistemin h\u0131zla tekrar \u00e7evrimi\u00e7i olmas\u0131n\u0131 sa\u011flayarak bu riskleri minimize eder. Bu teknoloji, sadece b\u00fcy\u00fck \u00f6l\u00e7ekli kurumsal uygulamalar i\u00e7in de\u011fil, ayn\u0131 zamanda k\u00fc\u00e7\u00fck ve orta \u00f6l\u00e7ekli i\u015fletmelerin de rekabet\u00e7i kalabilmesi i\u00e7in kritik bir yat\u0131r\u0131m haline gelmi\u015ftir. M\u00fc\u015fterilerinize g\u00fcvenilir bir hizmet sunmak, uzun vadeli ba\u015far\u0131 i\u00e7in olmazsa olmazd\u0131r ve Redis’in HA yetenekleri bu g\u00fcveni in\u015fa etmenize yard\u0131mc\u0131 olur.<\/p>\n
Redis Sentinel, Redis’in y\u00fcksek eri\u015filebilirli\u011fini sa\u011flamak i\u00e7in tasarlanm\u0131\u015f bir hata izleme (failure detection) ve otomatik ge\u00e7i\u015f (automatic failover) sistemidir. Sentinel’in temel g\u00f6revi, Redis master (birincil) ve replica (yedek) sunucular\u0131n\u0131 s\u00fcrekli olarak izlemek, olas\u0131 sorunlar\u0131 tespit etmek ve bir master sunucusu \u00e7al\u0131\u015fmaz hale geldi\u011finde otomatik olarak bir replica’y\u0131 yeni master olarak atamakt\u0131r. Sentinel’i basit\u00e7e bir “g\u00f6zc\u00fc” olarak d\u00fc\u015f\u00fcnebilirsiniz. Bu g\u00f6zc\u00fcler, Redis master’\u0131n\u0131n ve replica’lar\u0131n\u0131n sa\u011fl\u0131k durumunu periyodik olarak kontrol ederler. E\u011fer bir Sentinel, master’\u0131n yan\u0131t vermedi\u011fini tespit ederse, di\u011fer Sentinel’lerle ileti\u015fim kurarak bir konsens\u00fcs (mutabakat) olu\u015fturmaya \u00e7al\u0131\u015f\u0131r. Yeterli say\u0131da Sentinel, master’\u0131n ger\u00e7ekten \u00e7\u00f6kt\u00fc\u011f\u00fcne karar verirse, bu durumda bir ge\u00e7i\u015f s\u00fcreci ba\u015flat\u0131l\u0131r. Bu s\u00fcre\u00e7te, en g\u00fcncel verilere sahip olan bir replica, yeni master olarak se\u00e7ilir ve di\u011fer replica’lar bu yeni master’\u0131 takip etmeye ba\u015flar. Bu otomatik ge\u00e7i\u015f, manuel m\u00fcdahaleye gerek kalmadan hizmetin kesintisiz devam etmesini sa\u011flar. Sentinel’in bir di\u011fer \u00f6nemli \u00f6zelli\u011fi ise client (istemci) y\u00f6nlendirmesidir. Uygulaman\u0131z, Redis’e ba\u011flan\u0131rken do\u011frudan master IP adresini bilmek yerine, Sentinel’e ba\u011flanabilir. Sentinel, o anki aktif master sunucusunun adresini istemciye bildirerek, ge\u00e7i\u015f durumlar\u0131nda istemcinin do\u011fru sunucuya ba\u011flanmas\u0131n\u0131 sa\u011flar. Bu, geli\u015ftiricilerin karma\u015f\u0131k HA altyap\u0131s\u0131n\u0131 soyutlamas\u0131na yard\u0131mc\u0131 olur.<\/p>\n
Sentinel mimarisi, tek bir Sentinel’in ar\u0131zalanmas\u0131 durumunda bile sistemin \u00e7al\u0131\u015fmaya devam etmesini sa\u011flamak i\u00e7in tasarlanm\u0131\u015ft\u0131r. Genellikle en az \u00fc\u00e7 Sentinel’den olu\u015fan bir k\u00fcme (cluster) kurulmas\u0131 \u00f6nerilir. Bu sayede, bir Sentinel ar\u0131zalansa bile di\u011ferleri g\u00f6revi devralabilir ve do\u011fru kararlar\u0131 verebilir. Sentinel’ler aras\u0131ndaki ileti\u015fim, Redis’in Pub\/Sub (yay\u0131nla\/abone ol) mekanizmas\u0131 \u00fczerinden ger\u00e7ekle\u015fir. Bu, Sentinel’lerin birbirlerine sa\u011fl\u0131k durumlar\u0131, ge\u00e7i\u015f olaylar\u0131 gibi bilgileri iletmelerini sa\u011flar. Sentinel yap\u0131land\u0131rmas\u0131, Redis sunucular\u0131n\u0131n IP adresleri, portlar\u0131, ge\u00e7i\u015f e\u015fikleri (failover thresholds) gibi parametreleri i\u00e7erir. Bu e\u015fikler, bir master’\u0131n ne kadar s\u00fcreyle yan\u0131t vermemesi durumunda ge\u00e7i\u015f yap\u0131laca\u011f\u0131n\u0131 belirler. Do\u011fru e\u015fik de\u011ferlerini ayarlamak, gereksiz ge\u00e7i\u015fleri \u00f6nlemek ve ger\u00e7ek ar\u0131zalara h\u0131zl\u0131 m\u00fcdahale etmek i\u00e7in \u00f6nemlidir. Ger\u00e7ek d\u00fcnya senaryolar\u0131nda, Sentinel’in ba\u015far\u0131l\u0131 bir \u015fekilde uygulanmas\u0131, Redis tabanl\u0131 uygulamalar\u0131n %99.99 veya daha y\u00fcksek bir eri\u015filebilirlik oran\u0131na ula\u015fmas\u0131n\u0131 sa\u011flayabilir. Bu, \u00f6zellikle finans, telekom\u00fcnikasyon ve oyun gibi sekt\u00f6rlerde faaliyet g\u00f6steren \u015firketler i\u00e7in kritik bir gerekliliktir. Sentinel’in sundu\u011fu bu otomatik hata devralma yetene\u011fi, manuel m\u00fcdahale s\u00fcresini ortadan kald\u0131rarak, kesinti s\u00fcresini minimuma indirir ve kullan\u0131c\u0131 memnuniyetini en \u00fcst d\u00fczeyde tutar.<\/p>\n
Sentinel’in \u00e7al\u0131\u015fma mant\u0131\u011f\u0131n\u0131 daha iyi anlamak i\u00e7in ad\u0131m ad\u0131m ilerleyelim. \u0130lk olarak, bir Redis Sentinel k\u00fcmesi kurulur. Bu k\u00fcme i\u00e7erisindeki her bir Sentinel, Redis master ve replica sunucular\u0131n\u0131 d\u00fczenli olarak sorgular. Bu sorgular genellikle Bir sonraki a\u015fama, “failover” (hata devralma) s\u00fcrecidir. Bu a\u015famada, Sentinel’ler aralar\u0131ndan birini “leader” (lider) olarak se\u00e7erler. Lider Sentinel, yeni master’\u0131 belirleme sorumlulu\u011funu \u00fcstlenir. Lider, mevcut replica’lar\u0131 inceler ve veri tutarl\u0131l\u0131\u011f\u0131, senkronizasyon durumu gibi kriterlere g\u00f6re en uygun replica’y\u0131 yeni master olarak se\u00e7er. Se\u00e7ilen replica, \u00d6rne\u011fin, bir \u015firketin ana Redis sunucusu (master) aniden \u00e7\u00f6kerse, Sentinel k\u00fcmesi bunu h\u0131zla fark eder. Di\u011fer Sentinel’lerle anla\u015farak, mevcut replica sunucular\u0131ndan birini yeni master olarak se\u00e7er. Bu yeni master, t\u00fcm istemcilere y\u00f6nlendirilir ve uygulama sanki hi\u00e7bir \u015fey olmam\u0131\u015f gibi \u00e7al\u0131\u015fmaya devam eder. Bu kesintisiz hizmet, \u00f6zellikle finansal i\u015flemlerin veya canl\u0131 oyun oturumlar\u0131n\u0131n s\u00f6z konusu oldu\u011fu durumlarda paha bi\u00e7ilmezdir. Sentinel’in bu yetene\u011fi, kurumsal d\u00fczeyde bir g\u00fcvenilirlik seviyesi sunar ve Redis’in b\u00fcy\u00fck \u00f6l\u00e7ekli uygulamalarda tercih edilmesindeki en \u00f6nemli nedenlerden biridir. Sentinel’in yap\u0131land\u0131rma dosyas\u0131 (\u00f6rne\u011fin, Redis Cluster, Redis’i yatay olarak \u00f6l\u00e7eklendirmek ve ayn\u0131 zamanda y\u00fcksek eri\u015filebilirlik sa\u011flamak i\u00e7in tasarlanm\u0131\u015f bir \u00e7\u00f6z\u00fcmd\u00fcr. Sentinel’in aksine, Cluster, verileri birden fazla Redis d\u00fc\u011f\u00fcm\u00fcne (node) da\u011f\u0131tarak (sharding) hem veri hacmini art\u0131rmay\u0131 hem de y\u00fck\u00fc b\u00f6lmeyi hedefler. Bir Redis Cluster’\u0131, birden fazla Redis master d\u00fc\u011f\u00fcm\u00fcnden ve her master d\u00fc\u011f\u00fcm\u00fc i\u00e7in iste\u011fe ba\u011fl\u0131 olarak bir veya daha fazla replica d\u00fc\u011f\u00fcm\u00fcnden olu\u015fur. Veriler, anahtar alanlar\u0131n\u0131n (keyspace) belirli bir aral\u0131\u011f\u0131na g\u00f6re otomatik olarak farkl\u0131 master d\u00fc\u011f\u00fcmlerine da\u011f\u0131t\u0131l\u0131r. Bu da\u011f\u0131t\u0131m, “hash slot” (karma yuvas\u0131) ad\u0131 verilen bir mekanizma ile ger\u00e7ekle\u015ftirilir. Toplam 16384 adet hash slot bulunur ve her bir anahtar, bu slotlardan birine atan\u0131r. Hangi anahtar\u0131n hangi slot’a atanaca\u011f\u0131, anahtar\u0131n kendisinin veya anahtar\u0131n bir par\u00e7as\u0131 olan bir “etiket”in (tag) hash’lenmesiyle belirlenir. \u00d6rne\u011fin, bir anahtar\u0131n ad\u0131 Cluster, ayn\u0131 zamanda Sentinel’in sundu\u011fu otomatik hata devralma yetene\u011fini de kendi i\u00e7inde bar\u0131nd\u0131r\u0131r. Her master d\u00fc\u011f\u00fcm\u00fcn\u00fcn bir veya daha fazla replica’s\u0131 olabilir. E\u011fer bir master d\u00fc\u011f\u00fcm\u00fc eri\u015filemez hale gelirse, Cluster i\u00e7indeki di\u011fer d\u00fc\u011f\u00fcmler bunu tespit eder ve replica’lardan biri otomatik olarak yeni master olarak atan\u0131r. Bu, hem \u00f6l\u00e7eklenebilirlik hem de y\u00fcksek eri\u015filebilirlik ihtiya\u00e7lar\u0131n\u0131 tek bir \u00e7\u00f6z\u00fcm alt\u0131nda birle\u015ftirir. Cluster’\u0131n bir di\u011fer \u00f6nemli \u00f6zelli\u011fi de “g\u00f6\u00e7” (migration) yetene\u011fidir. Cluster, d\u00fc\u011f\u00fcmler aras\u0131ndaki veri da\u011f\u0131l\u0131m\u0131n\u0131 dinamik olarak ayarlayabilir. E\u011fer bir d\u00fc\u011f\u00fcm a\u015f\u0131r\u0131 y\u00fcklenirse, Cluster otomatik olarak baz\u0131 veri setlerini (hash slot’lar\u0131) ba\u015fka bir d\u00fc\u011f\u00fcme ta\u015f\u0131yarak y\u00fck\u00fc dengeleyebilir. Bu, sistemin performans\u0131n\u0131 s\u00fcrekli olarak optimize etmeye yard\u0131mc\u0131 olur. Cluster, istemcilerin de Cluster’a \u00f6zel bir \u015fekilde ba\u011flanmas\u0131n\u0131 gerektirir. \u0130stemciler, veri okuma veya yazma taleplerini g\u00f6nderdiklerinde, Cluster, ilgili anahtar\u0131n hangi master d\u00fc\u011f\u00fcm\u00fcnde oldu\u011funu belirler ve istemciyi do\u011fru d\u00fc\u011f\u00fcme y\u00f6nlendirir. E\u011fer istemci yanl\u0131\u015f d\u00fc\u011f\u00fcme giderse, Cluster bir “MOVED” yan\u0131t\u0131 g\u00f6ndererek istemcinin do\u011fru d\u00fc\u011f\u00fcme tekrar denemesini sa\u011flar. Bu, istemci taraf\u0131nda belirli bir Cluster deste\u011fi gerektirse de, Redis’in b\u00fcy\u00fck veri setlerini ve y\u00fcksek trafikli uygulamalar\u0131 y\u00f6netme kabiliyetini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r.<\/p>\n Ger\u00e7ek d\u00fcnya senaryolar\u0131nda, b\u00fcy\u00fck \u00f6l\u00e7ekli sosyal medya platformlar\u0131, oyun sunucular\u0131 veya analitik sistemler gibi \u00e7ok y\u00fcksek veri hacmine ve trafik yo\u011funlu\u011funa sahip uygulamalar i\u00e7in Redis Cluster vazge\u00e7ilmezdir. \u00d6rne\u011fin, bir oyun \u015firketi, milyonlarca oyuncunun verisini depolamak ve anl\u0131k olarak eri\u015fmek i\u00e7in tek bir Redis sunucusuna g\u00fcvenemez. Redis Cluster ile bu veriler birden fazla sunucuya da\u011f\u0131t\u0131l\u0131r, b\u00f6ylece hem performans artar hem de herhangi bir sunucunun ar\u0131zalanmas\u0131 durumunda oyun hizmeti kesintiye u\u011framaz. Cluster’\u0131n bu \u00f6l\u00e7eklenebilirlik ve hata tolerans\u0131 yetene\u011fi, \u015firketlerin kullan\u0131c\u0131 tabanlar\u0131n\u0131 b\u00fcy\u00fctmelerine ve ayn\u0131 zamanda g\u00fcvenilir bir hizmet sunmalar\u0131na olanak tan\u0131r. Cluster’\u0131n kurulumu ve y\u00f6netimi, Sentinel’e g\u00f6re biraz daha karma\u015f\u0131k olsa da, sundu\u011fu avantajlar bu karma\u015f\u0131kl\u0131\u011f\u0131 fazlas\u0131yla telafi eder.<\/p>\n Redis Cluster’da veri da\u011f\u0131t\u0131m\u0131, yani sharding, “hash slot” mekanizmas\u0131 ile ger\u00e7ekle\u015ftirilir. Toplamda 16384 adet hash slot bulunur. Her bir Redis d\u00fc\u011f\u00fcm\u00fc (master), bu slotlar\u0131n bir alt k\u00fcmesinden sorumludur. Bir anahtar\u0131n hangi slot’a atanaca\u011f\u0131, anahtar\u0131n kendisi veya anahtar\u0131n belirli bir b\u00f6l\u00fcm\u00fc (genellikle Cluster, ba\u015flang\u0131\u00e7ta d\u00fc\u011f\u00fcmler aras\u0131nda bu slotlar\u0131 otomatik olarak da\u011f\u0131t\u0131r. Bir istemci bir anahtar \u00fczerinde i\u015flem yapmak istedi\u011finde, \u00f6ncelikle o anahtar\u0131n hangi slot’a ait oldu\u011funu hesaplar. Ard\u0131ndan, o slot’tan sorumlu olan master d\u00fc\u011f\u00fcm\u00fcn\u00fc \u00f6\u011frenir ve iste\u011fi o d\u00fc\u011f\u00fcme g\u00f6nderir. E\u011fer istemci yanl\u0131\u015f d\u00fc\u011f\u00fcme istek g\u00f6nderirse, Cluster, istemciye do\u011fru master d\u00fc\u011f\u00fcm\u00fcn\u00fcn adresini i\u00e7eren bir \u00d6rne\u011fin, bir e-ticaret sitesinin \u00fcr\u00fcn katalo\u011funu d\u00fc\u015f\u00fcnelim. \u00dcr\u00fcn ID’leri genellikle benzersizdir ve bu ID’ler \u00fczerinden hash slotlar\u0131 belirlenir. Bu sayede, ayn\u0131 \u00fcr\u00fcnle ilgili t\u00fcm veriler (fiyat, stok, a\u00e7\u0131klama vb.) tek bir master d\u00fc\u011f\u00fcm\u00fcnde saklan\u0131r. Bu, \u00fcr\u00fcn bilgilerini sorgularken gereksiz a\u011f trafi\u011fini \u00f6nler ve performans\u0131 art\u0131r\u0131r. E\u011fer \u00fcr\u00fcn veritaban\u0131 \u00e7ok b\u00fcy\u00fcrse, Cluster’a yeni d\u00fc\u011f\u00fcmler eklenerek veriler bu yeni d\u00fc\u011f\u00fcmlere da\u011f\u0131t\u0131l\u0131r ve sistemin kapasitesi art\u0131r\u0131l\u0131r. Bu otomatik veri da\u011f\u0131t\u0131m\u0131 ve y\u00fck dengeleme yetene\u011fi, Redis Cluster’\u0131 b\u00fcy\u00fck \u00f6l\u00e7ekli ve y\u00fcksek trafikli uygulamalar i\u00e7in ideal bir \u00e7\u00f6z\u00fcm haline getirir.<\/p>\n Redis Sentinel ve Cluster, Redis’in y\u00fcksek eri\u015filebilirli\u011fini ve \u00f6l\u00e7eklenebilirli\u011fini sa\u011flayan g\u00fc\u00e7l\u00fc ara\u00e7lard\u0131r. Ancak, bu yap\u0131lar\u0131 kurmak ve y\u00f6netmek ba\u015flang\u0131\u00e7ta biraz karma\u015f\u0131k g\u00f6r\u00fcnebilir. \u0130\u015fte tam bu noktada WRedis gibi kullan\u0131c\u0131 dostu ara\u00e7lar devreye girer. WRedis, Redis Sentinel ve Cluster k\u00fcmelerini daha kolay bir \u015fekilde kurman\u0131za, yap\u0131land\u0131rman\u0131za ve izlemenize olanak tan\u0131yan bir y\u00f6netim aray\u00fcz\u00fc sunar. WRedis, genellikle bir web tabanl\u0131 aray\u00fcz arac\u0131l\u0131\u011f\u0131yla \u00e7al\u0131\u015f\u0131r ve Redis k\u00fcmelerinin durumunu g\u00f6rsel olarak sunar. Bu sayede, hangi d\u00fc\u011f\u00fcmlerin aktif oldu\u011funu, hangi d\u00fc\u011f\u00fcmlerde sorunlar oldu\u011funu, veri da\u011f\u0131l\u0131m\u0131n\u0131 ve replica’lar\u0131n senkronizasyon durumunu kolayca g\u00f6rebilirsiniz. WRedis, yeni Redis d\u00fc\u011f\u00fcmleri ekleme, mevcut d\u00fc\u011f\u00fcmleri kald\u0131rma, yap\u0131land\u0131rma parametrelerini de\u011fi\u015ftirme gibi i\u015flemleri de basitle\u015ftirir. \u00d6rne\u011fin, bir Redis Cluster’a yeni bir master d\u00fc\u011f\u00fcm\u00fc eklemek istedi\u011finizde, WRedis aray\u00fcz\u00fc \u00fczerinden birka\u00e7 t\u0131klamayla bu i\u015flemi ger\u00e7ekle\u015ftirebilirsiniz. WRedis, arka planda gerekli komutlar\u0131 \u00e7al\u0131\u015ft\u0131rarak d\u00fc\u011f\u00fcm ekleme ve veri migrasyonu i\u015flemlerini otomatik olarak halleder.<\/p>\n WRedis’in sundu\u011fu bir di\u011fer \u00f6nemli \u00f6zellik ise izleme ve uyar\u0131 (alerting) yetenekleridir. WRedis, Redis k\u00fcmelerindeki olas\u0131 sorunlar\u0131 (\u00f6rne\u011fin, bir d\u00fc\u011f\u00fcm\u00fcn \u00e7\u00f6kmesi, replica’lar\u0131n senkronizasyonunun bozulmas\u0131, disk alan\u0131n\u0131n dolmas\u0131) tespit etti\u011finde sizi uyarabilir. Bu uyar\u0131lar e-posta, SMS veya di\u011fer bildirim kanallar\u0131 arac\u0131l\u0131\u011f\u0131yla g\u00f6nderilebilir. Bu sayede, sorunlar kullan\u0131c\u0131lar\u0131 etkilemeden \u00f6nce m\u00fcdahale etme \u015fans\u0131n\u0131z olur. WRedis, sadece kurulum ve izleme ile s\u0131n\u0131rl\u0131 kalmaz, ayn\u0131 zamanda performans optimizasyonu i\u00e7in de ipu\u00e7lar\u0131 sunabilir. \u00d6rne\u011fin, hangi anahtarlar\u0131n en \u00e7ok kullan\u0131ld\u0131\u011f\u0131n\u0131, hangi komutlar\u0131n en \u00e7ok zaman ald\u0131\u011f\u0131n\u0131 analiz ederek performans darbo\u011fazlar\u0131n\u0131 tespit etmenize yard\u0131mc\u0131 olabilir. Bu t\u00fcr ara\u00e7lar, \u00f6zellikle Redis’i ilk kez kuran veya karma\u015f\u0131k HA yap\u0131lar\u0131n\u0131 y\u00f6netmekte zorlanan ekipler i\u00e7in b\u00fcy\u00fck bir kolayl\u0131k sa\u011flar. WRedis, Redis’in g\u00fcc\u00fcn\u00fc daha eri\u015filebilir hale getirerek, geli\u015ftiricilerin ve sistem y\u00f6neticilerinin altyap\u0131 y\u00f6netimi yerine uygulama geli\u015ftirmeye odaklanmalar\u0131na olanak tan\u0131r. Bu, modern DevOps (Geli\u015ftirme ve Operasyonlar) pratikleriyle de uyumludur.<\/p>\n Ger\u00e7ek d\u00fcnya senaryolar\u0131nda, b\u00fcy\u00fck bir finansal kurumun binlerce Redis \u00f6rne\u011fini y\u00f6netti\u011fini d\u00fc\u015f\u00fcnelim. Bu \u00f6rneklerin her birinin Sentinel veya Cluster yap\u0131land\u0131rmas\u0131n\u0131 manuel olarak yapmak ve izlemek inan\u0131lmaz derecede zaman al\u0131c\u0131 ve hataya a\u00e7\u0131k olacakt\u0131r. WRedis gibi bir ara\u00e7, bu karma\u015f\u0131k altyap\u0131y\u0131 tek bir merkezi konsoldan y\u00f6netme imkan\u0131 sunar. Bu, hem operasyonel maliyetleri d\u00fc\u015f\u00fcr\u00fcr hem de sistemin genel g\u00fcvenilirli\u011fini art\u0131r\u0131r. \u00d6rne\u011fin, bir sistem y\u00f6neticisi, WRedis aray\u00fcz\u00fcn\u00fc kullanarak t\u00fcm Redis k\u00fcmelerinin sa\u011fl\u0131k durumunu an\u0131nda g\u00f6rebilir, olas\u0131 bir sorun tespit edildi\u011finde otomatik olarak uyar\u0131 al\u0131r ve sorunu gidermek i\u00e7in gerekli ad\u0131mlar\u0131 h\u0131zla atabilir. Bu verimlilik art\u0131\u015f\u0131, \u00f6zellikle s\u00fcrekli hizmet sunmas\u0131 gereken kritik sistemler i\u00e7in hayati \u00f6nem ta\u015f\u0131r. WRedis, Redis’in sundu\u011fu geli\u015fmi\u015f HA ve \u00f6l\u00e7eklenebilirlik \u00f6zelliklerini, daha anla\u015f\u0131l\u0131r ve y\u00f6netilebilir bir paket halinde sunarak, Redis’i daha geni\u015f bir kullan\u0131c\u0131 kitlesi i\u00e7in cazip hale getirir.<\/p>\n T\u00fcrkiye’de faaliyet g\u00f6steren b\u00fcy\u00fck bir e-ticaret \u015firketi, Black Friday ve Cyber Monday gibi \u00f6zel indirim g\u00fcnlerinde sunucular\u0131na gelen trafi\u011fin katlanarak artt\u0131\u011f\u0131n\u0131 g\u00f6zlemlemi\u015ftir. Uygulaman\u0131n ana veritaban\u0131 (SQL tabanl\u0131) bu yo\u011funlu\u011fa dayanabilirken, \u00f6nbellekleme (caching) ve oturum y\u00f6netimi (session management) i\u00e7in kullan\u0131lan Redis k\u00fcmesi, bu d\u00f6nemlerde performans sorunlar\u0131 ya\u015famaya ba\u015flam\u0131\u015ft\u0131r. Tek bir Redis master d\u00fc\u011f\u00fcm\u00fc, gelen yo\u011fun okuma ve yazma isteklerini kar\u015f\u0131lamakta zorlanmakta, bu da sayfa y\u00fckleme s\u00fcrelerinin uzamas\u0131na ve hatta baz\u0131 durumlarda Redis’in tamamen yan\u0131t vermemesine yol a\u00e7maktayd\u0131. Bu durum, kullan\u0131c\u0131 deneyimini olumsuz etkiliyor ve potansiyel sat\u0131\u015f kayb\u0131na neden oluyordu.<\/p>\n \u015eirket, bu sorunu \u00e7\u00f6zmek i\u00e7in Redis’i y\u00fcksek eri\u015filebilirlik ve \u00f6l\u00e7eklenebilirlik \u00f6zellikleriyle donatmaya karar verdi. \u0130lk olarak, tek master d\u00fc\u011f\u00fcml\u00fc yap\u0131lar\u0131n\u0131 Redis Cluster’a d\u00f6n\u00fc\u015ft\u00fcrd\u00fcler. Toplam 10 adet Redis master d\u00fc\u011f\u00fcm\u00fc ve her master i\u00e7in 2 adet replica d\u00fc\u011f\u00fcm\u00fcnden olu\u015fan bir Cluster kurdular. Veriler, \u00fcr\u00fcn ID’leri ve kullan\u0131c\u0131 oturum ID’leri \u00fczerinden hash slot’lar\u0131na da\u011f\u0131t\u0131ld\u0131. Bu sayede, veri y\u00fck\u00fc birden fazla sunucuya yay\u0131lm\u0131\u015f oldu. Ayr\u0131ca, her master d\u00fc\u011f\u00fcm\u00fc i\u00e7in ayr\u0131 bir Sentinel k\u00fcmesi kurarak, Cluster i\u00e7indeki d\u00fc\u011f\u00fcmlerin de otomatik hata devralma yetene\u011fini g\u00fc\u00e7lendirdiler. Bu karma\u015f\u0131k yap\u0131y\u0131 y\u00f6netmek i\u00e7in ise WRedis’i kullanmaya ba\u015flad\u0131lar. WRedis aray\u00fcz\u00fc sayesinde, t\u00fcm Redis d\u00fc\u011f\u00fcmlerinin sa\u011fl\u0131k durumunu, hash slot da\u011f\u0131l\u0131m\u0131n\u0131 ve replica senkronizasyonunu tek bir ekrandan izleyebildiler. \u0130ndirim g\u00fcnlerinde, WRedis \u00fczerindeki uyar\u0131lar sayesinde, bir master d\u00fc\u011f\u00fcm\u00fcnde hafif bir performans d\u00fc\u015f\u00fc\u015f\u00fc ya\u015fand\u0131\u011f\u0131nda bile, kullan\u0131c\u0131lar etkilenmeden replica’ya otomatik ge\u00e7i\u015f sa\u011fland\u0131.<\/p>\n Bu ge\u00e7i\u015f, birka\u00e7 saniye i\u00e7inde tamamland\u0131\u011f\u0131 i\u00e7in kullan\u0131c\u0131lar taraf\u0131ndan fark edilmedi. Sonu\u00e7 olarak, \u015firket, indirim g\u00fcnlerinde Redis kaynakl\u0131 herhangi bir performans sorunu ya\u015famad\u0131. Sayfa y\u00fckleme s\u00fcreleri optimum seviyede kald\u0131, kullan\u0131c\u0131 deneyimi kesintisiz s\u00fcrd\u00fc ve sat\u0131\u015f hedeflerine ula\u015f\u0131ld\u0131. Bu vaka analizi, Redis Sentinel ve Cluster’\u0131n, do\u011fru ara\u00e7larla (WRedis gibi) birle\u015ftirildi\u011finde, y\u00fcksek trafikli ortamlarda nas\u0131l kritik bir rol oynayabilece\u011fini a\u00e7\u0131k\u00e7a g\u00f6stermektedir. Kurumsal d\u00fczeyde y\u00fcksek eri\u015filebilirlik ve \u00f6l\u00e7eklenebilirlik, sadece teknik bir gereklilik de\u011fil, ayn\u0131 zamanda i\u015f s\u00fcreklili\u011fi ve m\u00fc\u015fteri memnuniyeti i\u00e7in stratejik bir yat\u0131r\u0131m olarak \u00f6ne \u00e7\u0131kmaktad\u0131r.<\/p>\n Redis Sentinel ve Cluster yap\u0131lar\u0131n\u0131 kurarken ve y\u00f6netirken dikkat edilmesi gereken baz\u0131 ileri d\u00fczey noktalar bulunmaktad\u0131r. Sentinel yap\u0131land\u0131rmas\u0131nda, ge\u00e7i\u015f e\u015fiklerini (failover thresholds) do\u011fru ayarlamak \u00e7ok \u00f6nemlidir. \u00c7ok d\u00fc\u015f\u00fck e\u015fikler, a\u011fdaki anl\u0131k dalgalanmalarda gereksiz ge\u00e7i\u015flere neden olabilirken, \u00e7ok y\u00fcksek e\u015fikler ise ger\u00e7ek bir ar\u0131za durumunda m\u00fcdahale s\u00fcresini uzatabilir. Genellikle, Redis Cluster taraf\u0131nda ise, anahtar etiketleme (key tagging) stratejisi b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. Ayn\u0131 i\u015flemle ilgili verilerin ayn\u0131 master d\u00fc\u011f\u00fcm\u00fcnde bulunmas\u0131n\u0131 sa\u011flamak i\u00e7in, anahtarlar\u0131n WRedis gibi y\u00f6netim ara\u00e7lar\u0131n\u0131 kullan\u0131rken de dikkatli olmak gerekir. Bu ara\u00e7lar i\u015flemleri basitle\u015ftirse de, arka planda \u00e7al\u0131\u015fan komutlar\u0131 anlamak ve olas\u0131 etkilerini bilmek \u00f6nemlidir. \u00d6rne\u011fin, bir d\u00fc\u011f\u00fcm\u00fcn “evicted” (\u00e7\u0131kar\u0131lan) anahtar say\u0131s\u0131n\u0131 izlemek, bellek kullan\u0131m\u0131n\u0131n artt\u0131\u011f\u0131n\u0131 ve bir optimizasyon gerekti\u011fini g\u00f6sterebilir. Benzer \u015fekilde, replica’lar\u0131n gecikme s\u00fcrelerini (replication lag) izlemek, veri senkronizasyonunda bir sorun olup olmad\u0131\u011f\u0131n\u0131 anlaman\u0131za yard\u0131mc\u0131 olur. Bu t\u00fcr metrikleri d\u00fczenli olarak takip etmek ve gerekti\u011finde m\u00fcdahale etmek, Redis HA yap\u0131n\u0131z\u0131n sa\u011fl\u0131\u011f\u0131n\u0131 koruman\u0131z\u0131 sa\u011flar. Unutmay\u0131n ki, y\u00fcksek eri\u015filebilirlik sadece donan\u0131m ve yaz\u0131l\u0131m yap\u0131land\u0131rmas\u0131yla de\u011fil, ayn\u0131 zamanda s\u00fcrekli izleme ve proaktif bak\u0131m ile de sa\u011flan\u0131r.<\/p>\n Redis Sentinel, \u00f6ncelikle y\u00fcksek eri\u015filebilirlik ve otomatik hata devralma (failover) sa\u011flamak i\u00e7in kullan\u0131l\u0131r. Tek bir Redis master ve replica k\u00fcmesini izler. Redis Cluster ise, verileri birden fazla d\u00fc\u011f\u00fcme da\u011f\u0131tarak (sharding) hem yatay \u00f6l\u00e7eklenebilirlik hem de y\u00fcksek eri\u015filebilirlik sunar. Yani Cluster, hem veri hacmini art\u0131r\u0131r hem de hata tolerans\u0131 sa\u011flar.<\/p>\n<\/li>\n E\u011fer uygulaman\u0131z\u0131n veri hacmi tek bir Redis sunucusunun kapasitesini a\u015fm\u0131yorsa ve \u00f6nceli\u011finiz sadece kesintisiz hizmet sunmaksa, Redis Sentinel yeterli olabilir. Ancak, uygulaman\u0131z\u0131n veri hacmi b\u00fcy\u00fcyorsa, \u00e7ok y\u00fcksek trafik al\u0131yorsa veya gelecekte b\u00fcy\u00fcme potansiyeli varsa, Redis Cluster daha uygun bir \u00e7\u00f6z\u00fcmd\u00fcr. Bir\u00e7ok b\u00fcy\u00fck \u00f6l\u00e7ekli uygulama, hem \u00f6l\u00e7eklenebilirlik hem de HA i\u00e7in Redis Cluster’\u0131 tercih eder.<\/p>\n<\/li>\n Redis Cluster, varsay\u0131lan olarak “at-least-once” (en az bir kere) veri i\u015fleme garantisi sunar. Yani, bir yazma i\u015flemi master’a ula\u015ft\u0131ktan sonra, e\u011fer replica’ya hen\u00fcz replike edilmeden master \u00e7\u00f6kerse, bu veri kayb\u0131na yol a\u00e7abilir. Ancak, Hay\u0131r, WRedis gibi ara\u00e7lar zorunlu de\u011fildir. Redis Cluster’\u0131 komut sat\u0131r\u0131 ara\u00e7lar\u0131 ( Evet, Redis Cluster’\u0131n kendi i\u00e7inde bir hata devralma mekanizmas\u0131 olsa da, baz\u0131 durumlarda Cluster d\u00fc\u011f\u00fcmleri i\u00e7in ayr\u0131ca Sentinel kullanmak da m\u00fcmk\u00fcnd\u00fcr. Bu, daha katmanl\u0131 bir HA \u00e7\u00f6z\u00fcm\u00fc sunabilir. Ancak, \u00e7o\u011fu durumda, Redis Cluster’\u0131n kendi HA yetenekleri yeterli olmaktad\u0131r.<\/p>\n<\/li>\n<\/ul>\n Sonu\u00e7 olarak, Redis’in y\u00fcksek eri\u015filebilirli\u011fini sa\u011flamak, modern uygulamalar\u0131n\u0131z\u0131n g\u00fcvenilirli\u011fi ve performans\u0131n\u0131 garanti alt\u0131na almak i\u00e7in kritik bir ad\u0131md\u0131r. Redis Sentinel ve Cluster, bu amaca ula\u015fmak i\u00e7in g\u00fc\u00e7l\u00fc ara\u00e7lar sunar. WRedis gibi y\u00f6netim ara\u00e7lar\u0131 ise bu karma\u015f\u0131k yap\u0131lar\u0131 daha eri\u015filebilir hale getirerek, geli\u015ftiricilerin ve sistem y\u00f6neticilerinin i\u015f y\u00fck\u00fcn\u00fc hafifletir. Uygulaman\u0131z\u0131n ihtiya\u00e7lar\u0131na en uygun \u00e7\u00f6z\u00fcm\u00fc se\u00e7erek ve en iyi pratikleri uygulayarak, Redis veritabanlar\u0131n\u0131z\u0131 kurumsal d\u00fczeyde g\u00fcvenilir ve \u00f6l\u00e7eklenebilir hale getirebilirsiniz.<\/p>\n #Redis #Y\u00fcksekEri\u015filebilirlik #Sentinel #Cluster #WRedis #Veritaban\u0131 #Teknoloji #Performans #\u00d6l\u00e7eklenebilirlik<\/p>\nPING<\/code> komutu ile yap\u0131l\u0131r ve belirli bir zaman a\u015f\u0131m\u0131 (timeout) s\u00fcresi i\u00e7erisinde yan\u0131t al\u0131namazsa, o sunucu “nedown” (eri\u015filemez) olarak i\u015faretlenir. Sentinel’ler, bir master sunucusunun “nedown” oldu\u011funu tespit ettiklerinde, bu bilgiyi di\u011fer Sentinel’lerle payla\u015f\u0131rlar. E\u011fer bir master sunucusunun “nedown” oldu\u011funa dair yeterli say\u0131da Sentinel hemfikir olursa, bu durum “\u00e7\u00f6km\u00fc\u015f” (fail) olarak kabul edilir.<\/p>\nREPLICAOF NO ONE<\/code> komutu ile master haline getirilir. Ard\u0131ndan, lider Sentinel, di\u011fer t\u00fcm replica’lara yeni master’\u0131 bildiren bir komut g\u00f6nderir. Bu komut, replica’lar\u0131n yeni master’a ba\u011flanmas\u0131n\u0131 ve veri senkronizasyonunu ba\u015flatmas\u0131n\u0131 sa\u011flar. Son olarak, lider Sentinel, istemcilere yeni master’\u0131n adresini bildirir. Bu, istemcilerin art\u0131k yeni master’a ba\u011flanarak veri okuma ve yazma i\u015flemlerini ger\u00e7ekle\u015ftirmesini sa\u011flar. Bu t\u00fcm s\u00fcre\u00e7, genellikle birka\u00e7 saniye i\u00e7erisinde tamamlan\u0131r, bu da hizmet kesintisinin minimumda kalmas\u0131n\u0131 sa\u011flar. Bu otomatikle\u015ftirilmi\u015f s\u00fcre\u00e7, manuel m\u00fcdahalenin getirece\u011fi insan hatas\u0131 riskini ortadan kald\u0131r\u0131r ve sistemin g\u00fcvenilirli\u011fini art\u0131r\u0131r.<\/p>\nsentinel.conf<\/code>), y\u00f6netilen Redis master’lar\u0131n\u0131n IP adreslerini, portlar\u0131n\u0131 ve Sentinel k\u00fcmesinin kendi kimlik bilgilerini i\u00e7erir. Bu dosyadaki do\u011fru ayarlar, Sentinel’in etkin bir \u015fekilde \u00e7al\u0131\u015fmas\u0131 i\u00e7in temeldir.<\/p>\nRedis Cluster: Yatay \u00d6l\u00e7eklenebilirlik ve Y\u00fcksek Eri\u015filebilirlik<\/h2>\n
user:{id}:profile<\/code> ise, hash i\u015flemi genellikle {id}<\/code> k\u0131sm\u0131 \u00fczerinden yap\u0131l\u0131r. Bu, ayn\u0131 kullan\u0131c\u0131ya ait t\u00fcm verilerin ayn\u0131 master d\u00fc\u011f\u00fcm\u00fcnde toplanmas\u0131n\u0131 sa\u011flar, bu da karma\u015f\u0131k sorgular\u0131 kolayla\u015ft\u0131r\u0131r.<\/p>\nRedis Cluster’da Veri Da\u011f\u0131t\u0131m\u0131 (Sharding) Nas\u0131l Yap\u0131l\u0131r?<\/h3>\n
{}<\/code> parantezleri i\u00e7indeki etiket) \u00fczerinden yap\u0131lan bir hash fonksiyonu ile belirlenir. \u00d6rne\u011fin, bir anahtar user:123:name<\/code> ise, hash fonksiyonu genellikle 123<\/code> k\u0131sm\u0131n\u0131 al\u0131r ve bu de\u011feri 16384’e g\u00f6re modunu alarak ilgili slot numaras\u0131n\u0131 bulur. Bu slot numaras\u0131, o anahtar\u0131n hangi master d\u00fc\u011f\u00fcm\u00fc taraf\u0131ndan y\u00f6netilece\u011fini belirler.<\/p>\nMOVED<\/code> hatas\u0131 d\u00f6nd\u00fcr\u00fcr. \u0130stemci bu hatay\u0131 al\u0131p do\u011fru d\u00fc\u011f\u00fcme tekrar ba\u011flan\u0131r. Bu mekanizma, veri da\u011f\u0131l\u0131m\u0131n\u0131 dinamik olarak y\u00f6netmeyi ve y\u00fck\u00fc dengeli tutmay\u0131 sa\u011flar. Cluster’\u0131n bir di\u011fer \u00f6nemli \u00f6zelli\u011fi, d\u00fc\u011f\u00fcm ekleme veya \u00e7\u0131karma i\u015flemlerini de desteklemesidir. Yeni bir d\u00fc\u011f\u00fcm eklendi\u011finde, Cluster otomatik olarak mevcut slot’lar\u0131 bu yeni d\u00fc\u011f\u00fcme migre ederek (g\u00f6\u00e7 ettirerek) veri da\u011f\u0131l\u0131m\u0131n\u0131 yeniden ayarlar. Bu, sistemin \u00f6l\u00e7eklenmesini veya k\u00fc\u00e7\u00fclmesini kolayla\u015ft\u0131r\u0131r.<\/p>\nWRedis ile Redis Sentinel ve Cluster Y\u00f6netimi<\/h2>\n
Ger\u00e7ek D\u00fcnya Vaka Analizi: Y\u00fcksek Trafikli E-Ticaret Sitesinde Redis HA<\/h2>\n
\u0130leri D\u00fczey \u0130pu\u00e7lar\u0131 ve Dikkat Edilmesi Gerekenler<\/h2>\n
down-after-milliseconds<\/code> de\u011feri 5000-10000ms, failover-timeout<\/code> de\u011feri ise 10000-30000ms aras\u0131nda ayarlan\u0131r. Ancak bu de\u011ferler, a\u011f altyap\u0131n\u0131z\u0131n ve uygulaman\u0131z\u0131n gereksinimlerine g\u00f6re optimize edilmelidir. Ayr\u0131ca, Sentinel’lerin yeterli say\u0131da olmas\u0131 (en az 3) ve birbirlerinden farkl\u0131 a\u011f segmentlerinde konumland\u0131r\u0131lmas\u0131, tek bir ar\u0131za noktas\u0131n\u0131n t\u00fcm sistemi etkilemesini \u00f6nler.<\/p>\n{}<\/code> parantezleri i\u00e7inde ortak bir etiket i\u00e7ermesi \u00f6nerilir. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n sepetindeki t\u00fcm \u00fcr\u00fcnleri sorgulamak istedi\u011finizde, sepet anahtarlar\u0131n\u0131z cart:{userId}<\/code> \u015feklinde olmal\u0131d\u0131r. Bu, userId<\/code> \u00fczerinden hash slot’unun belirlenmesini ve t\u00fcm sepet verilerinin tek bir master d\u00fc\u011f\u00fcm\u00fcnde saklanmas\u0131n\u0131 sa\u011flar. Bu, “scatter-gather” (da\u011f\u0131t ve topla) i\u015flemlerini azaltarak performans\u0131 art\u0131r\u0131r. Cluster’da d\u00fc\u011f\u00fcm ekleme veya \u00e7\u0131karma i\u015flemleri s\u0131ras\u0131nda veri migrasyonunun ne kadar s\u00fcrece\u011fini ve bu s\u00fcrenin performans\u0131 nas\u0131l etkileyece\u011fini \u00f6nceden planlamak da \u00f6nemlidir. B\u00fcy\u00fck veri k\u00fcmelerinin migrasyonu zaman alabilir ve bu s\u00fcre\u00e7te baz\u0131 d\u00fc\u011f\u00fcmlerin y\u00fck\u00fc artabilir. Bu nedenle, planl\u0131 bak\u0131m pencereleri veya daha az yo\u011fun zamanlar tercih edilmelidir. Ayr\u0131ca, Cluster’da redis-cli --cluster<\/code> komutunu kullanarak k\u00fcme durumunu d\u00fczenli olarak kontrol etmek ve olas\u0131 sorunlar\u0131 proaktif olarak tespit etmek \u00f6nemlidir.<\/p>\nS\u0131k\u00e7a Sorulan Sorular (SSS)<\/h2>\n
\n
Redis Sentinel ve Redis Cluster aras\u0131ndaki temel fark nedir?<\/h3>\n
Hangi senaryoda Redis Sentinel, hangi senaryoda Redis Cluster kullanmal\u0131y\u0131m?<\/h3>\n
Redis Cluster’da veri kayb\u0131 riski var m\u0131?<\/h3>\n
WAIT<\/code> komutu gibi mekanizmalar veya do\u011fru replica say\u0131s\u0131n\u0131 yap\u0131land\u0131rmak bu riski \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r. Genellikle, 2 veya daha fazla replica kullanmak ve WAIT<\/code> komutu ile senkronizasyonu beklemek veri kayb\u0131 riskini minimize eder.<\/p>\n<\/li>\nWRedis gibi ara\u00e7lar Redis Cluster’\u0131 y\u00f6netmek i\u00e7in zorunlu mu?<\/h3>\n
redis-cli --cluster<\/code>) ile de y\u00f6netebilirsiniz. Ancak, WRedis gibi aray\u00fczler, \u00f6zellikle karma\u015f\u0131k Cluster yap\u0131lar\u0131n\u0131 kurarken, yap\u0131land\u0131r\u0131rken ve izlerken s\u00fcreci \u00f6nemli \u00f6l\u00e7\u00fcde kolayla\u015ft\u0131r\u0131r ve hatalar\u0131 azalt\u0131r. B\u00fcy\u00fck \u00f6l\u00e7ekli da\u011f\u0131t\u0131mlar i\u00e7in kesinlikle \u00f6nerilir.<\/p>\n<\/li>\nRedis Sentinel ve Cluster ile birlikte kullan\u0131labilir mi?<\/h3>\n