Dağıtık Durum Yönetimi
Birden çok WebSocket sunucusundaki durumu eşitlemek için harici ileti aracılarının (ör. Redis Pub/Sub, Kafka) kullanımını keşfedin.
Dağıtık Durum Yönetimi, CoddyKit'te ücretsiz bir WebSockets & Realtime Systems Programming dersidir. Bu, 4 dersinin 3. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, WebSockets & Realtime Systems Programming öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. WebSockets & Realtime Systems Programming kursu toplamda 4 dersten oluşur.
Bu dersin bazı bölümleri henüz çevrilmemiş olup İngilizce olarak gösterilmektedir.
Scaling Challenges: Shared State
You've learned about scaling WebSocket applications by running multiple server instances behind a load balancer. But what happens when a client connects to Server A, and another client connected to Server B needs to send a message to the first client?
This is the challenge of distributed state management: how do your servers share information and coordinate?
Why Centralize State?
Imagine a chat application. If Client 1 is on Server A and Client 2 is on Server B, and Client 1 sends a message, how does Server A tell Server B to deliver it to Client 2?
Without a way for servers to communicate, messages or updates might only reach clients connected to the same server, breaking the real-time experience.
Introducing Message Brokers
To solve this, we use a message broker. Think of it as a central post office for your servers.
- Servers send messages to the broker.
- Other servers can then receive messages from the broker.
This allows all your WebSocket servers to communicate indirectly, without needing to know about each other's existence.
The Pub/Sub Pattern
Many message brokers use a Publisher-Subscriber (Pub/Sub) pattern. It works like this:
- Publishers send messages to specific channels or topics.
- Subscribers express interest in one or more channels and receive all messages published to them.
This pattern is perfect for broadcasting data across multiple server instances.
Redis Pub/Sub Example
Redis is a popular, open-source, in-memory data store that's often used as a message broker. Its Pub/Sub feature is fast and simple to use.
You can have multiple Node.js WebSocket servers, all connected to a single Redis instance, using it to exchange messages.
Redis Pub/Sub Basics
Let's say you have two WebSocket servers, Server A and Server B, both connected to Redis.
- When
Server Areceives a message it needs to share, it publishes that message to a Redis channel (e.g.,'global_chat'). Server Bhas subscribed to'global_chat', so it instantly receives the message from Redis.
Then, Server B can forward that message to its own connected clients.
Server Publishes to Redis
Here's a simplified Node.js example for a WebSocket server publishing messages to a Redis channel. We'll use the ws library for WebSockets and ioredis for Redis.
Make sure you have Redis running and ws and ioredis installed (`npm i ws ioredis`).
const WebSocket = require('ws');
const Redis = require('ioredis');
const wss = new WebSocket.Server({ port: 8080 });
const publisher = new Redis(); // Connects to localhost:6379
wss.on('connection', ws => {
console.log('Client connected to Server 1');
ws.on('message', message => {
const msg = message.toString();
console.log(`Server 1 received: ${msg}`);
// Publish message to 'chat_messages' channel
publisher.publish('chat_messages', msg);
ws.send(`You said: ${msg}`); // Echo back to sender
});
});
console.log('Server 1 listening on ws://localhost:8080');Server Subscribes & Relays
Now, here's another Node.js WebSocket server (running on a different port) that subscribes to the same Redis channel. When it gets a message from Redis, it broadcasts it to its own connected clients.
You would run this in a separate terminal from server1.js.
const WebSocket = require('ws');
const Redis = require('ioredis');
const wss = new WebSocket.Server({ port: 8081 });
const subscriber = new Redis(); // Connects to localhost:6379
// Subscribe to the 'chat_messages' channel
subscriber.subscribe('chat_messages', (err, count) => {
if (err) console.error('Failed to subscribe:', err.message);
else console.log(`Subscribed to ${count} channel(s)`);
});
// Handle messages received from Redis
subscriber.on('message', (channel, message) => {
console.log(`Server 2 received from Redis [${channel}]: ${message}`);
// Broadcast to all connected clients on Server 2
wss.clients.forEach(client => {
if (client.readyState === WebSocket.OPEN) {
client.send(`Global Chat: ${message}`);
}
});
});
wss.on('connection', ws => {
console.log('Client connected to Server 2');
ws.send('Welcome to Server 2!');
});
console.log('Server 2 listening on ws://localhost:8081');Benefits for Scaling
Using a message broker like Redis Pub/Sub offers significant advantages for scaling WebSocket applications:
- Decoupling: Servers don't need direct knowledge of each other. They only interact with the broker.
- Horizontal Scalability: You can easily add more WebSocket servers as traffic grows, and they'll all connect to the same broker.
- Global Broadcasts: Messages can be efficiently broadcast to all clients, regardless of which server they are connected to.
Beyond Broadcasts: Presence
Message brokers aren't just for broadcasting chat messages. They are vital for synchronizing other types of distributed state, like user presence.
For example, when a user logs in, their connected server can publish an 'online' status to a Redis channel. Other servers subscribe to this to keep their lists of online users updated.
Message Broker Check
Consider a scenario where you have multiple WebSocket servers, and a message sent to one server needs to reach a client connected to another server. Which pattern best addresses this?
Recap: Distributed State
We learned that scaling WebSocket applications requires managing distributed state. Message brokers like Redis, using the Pub/Sub pattern, are crucial for allowing multiple WebSocket servers to communicate and synchronize data, ensuring all clients receive relevant updates regardless of which server they're connected to.
This makes your application more resilient and scalable as you add more server instances.
Sıkça Sorulan Sorular
“Dağıtık Durum Yönetimi” dersi ücretsiz mi?
Evet — “Dağıtık Durum Yönetimi” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve WebSockets & Realtime Systems Programming kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. WebSockets & Realtime Systems Programming kursu toplamda 4 dersten oluşur.
“Dağıtık Durum Yönetimi” dersinde ne öğreneceğim?
Birden çok WebSocket sunucusundaki durumu eşitlemek için harici ileti aracılarının (ör. Redis Pub/Sub, Kafka) kullanımını keşfedin. WebSockets & Realtime Systems Programming ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.
WebSockets & Realtime Systems Programming öğrenmeye başlamak için deneyim gerekli mi?
Önceden deneyim gerekmez. CoddyKit'te WebSockets & Realtime Systems Programming, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 3. dersidir.
“Dağıtık Durum Yönetimi” dersi ne kadar sürer?
Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.
Bu WebSockets & Realtime Systems Programming dersinde kod yazıp çalıştırabilir miyim?
Evet. Her WebSockets & Realtime Systems Programming dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.
Bu kursun tüm dersleri
- Yatay Ölçeklendirme Stratejileri
- WebSockets için Yük Dengeleme
- Dağıtık Durum Yönetimi
- Redis ile Yayınla/Abone Ol Arka Düzlemi