Redis: replication, persistence ও cluster-এর পার্থক্য
Redis Replication, Persistence, and Cluster
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Persistence, replication ও clustering আলাদা করা
- Redis slots ও multi-key boundary
- Failover data loss ও cache recovery
সমস্যা দিয়ে শুরু
এক Redis node বন্ধ হওয়ায় session, cache এবং jobs একসঙ্গে সমস্যায় পড়ল। Team replica যোগ করল, কিন্তু এটি memory capacity তিনগুণ করবে ভাবল। Replica availability সাহায্য করতে পারে; sharding capacity ভাগ করে। Persistence restart-এর পরে data recovery-এর আরেক প্রশ্ন। এই তিনটি capability একে অন্যের বিকল্প নয়।
সহজ করে বুঝি
RDB snapshot নির্দিষ্ট সময়ের state সংরক্ষণ করে; AOF write operations record করে configurable sync policy-তে। Durability ও recovery cost configuration এবং storage failure model-এর ওপর নির্ভর করে। Replication সাধারণত asynchronous, ফলে primary acknowledged write replica-এ পৌঁছানোর আগে হারাতে পারে। Redis Cluster key space 16384 hash slot-এ ভাগ করে primary nodes-এ রাখে। Replica নির্দিষ্ট primary-এর copy; shard primary-গুলো capacity ভাগ করে। Cluster-aware client MOVED/ASK routing সামলায়।
পরিচিত একটি উপমা
গুদামের ছবি তুলে রাখা snapshot, প্রতিটি পরিবর্তনের খাতা AOF, পাশের গুদামে copy replication। আলাদা বিভাগে আলাদা পণ্য রাখা sharding। Copy update দেরিতে পৌঁছালে নতুন হিসাব হারাতে পারে; তিনটি copy মানেই সবশেষ sale-এর তিনটি guaranteed copy নয়।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD A[Cluster-aware Laravel Redis client] --> P1[Primary slots 0 to 8191] A --> P2[Primary slots 8192 to 16383] P1 --> R1[Replica of primary 1] P2 --> R2[Replica of primary 2] P1 --> F1[(Configured persistence)] P2 --> F2[(Configured persistence)]
Client key-এর slot অনুযায়ী primary বেছে নেয়। Replication arrow state copy দেখায়; synchronous commit বোঝায় না। প্রতিটি shard persistence configure করতে পারে। একটি shard-এর unavailability তার slot-এর key access-এ প্রভাব ফেলে। Cache rebuild source-এ surge আনতে পারে, তাই recovery time-এ rate/concurrency protection রাখুন।
PHP ও Laravel-এ প্রয়োগ
নিচের service fragment Redis connection named cluster configured আছে ধরে multi-key operation দেখায়। PhpRedis বা Predis cluster support deployment অনুযায়ী configure করুন। Same hash tag দুই key-কে একই slot-এ রাখে; tenant string trusted normalized identifier হতে হবে। এটি আর্থিক transaction নয়।
use Illuminate\Support\Facades\Redis;
$tenantId = 42;
$tag = "{tenant:{$tenantId}}";
$connection = Redis::connection('cluster');
$connection->mset([
"{$tag}:catalog:version" => '2',
"{$tag}:catalog:updated" => now()->toIso8601String(),
]);
$version = $connection->get("{$tag}:catalog:version");সুবিধা, সীমাবদ্ধতা ও trade-off
Persistence recovery সাহায্য করে কিন্তু disk I/O, rewrite এবং memory overhead যোগ করে। Replica failover downtime কমাতে পারে, data loss window শূন্য করে না। Cluster বড় key space distribute করে, কিন্তু cross-slot operations ও rebalancing জটিল। Hash tag multi-key locality দেয়; সব tenant data এক slot-এ জমালে বড় tenant hotspot হয়। Requirement ছোট হলে standalone managed node ও tested backup সহজ হতে পারে।
সাধারণ ভুল
- Replica count-কে independent shard count ভাবা।
- Cluster-এ যেকোনো দুই key atomic script-এ ব্যবহার করা।
- Snapshot আছে বলে restore পরীক্ষা বাদ দেওয়া।
আরও একটু গভীরে
RTO-তে failover detection, client reconnect ও warm-up ধরুন। RPO-তে persistence interval, fsync policy ও replication lag-এর সীমা লিখুন। Redis WAIT replication acknowledgement চাইতে পারে, কিন্তু সব failure model-এ strong consistency বা no-loss database transaction বানায় না। Queue ও lock workload-এর failover semantics cache-এর থেকে কঠোর হতে পারে; data loss সহ্য হবে কি না আলাদা বিচার করুন।
মনে রাখুন
Persistence restart recovery, replication copies, sharding distribution। Configuration না দেখে durability দাবি করবেন না। Cluster-aware routing ও slot boundary application design-এ ধরুন।
নিজে চেষ্টা করুন
Two-shard diagram-এ একটি primary crash হলে কোন keys affected হয় দেখান। Replica promote-এর আগে শেষ acknowledged write হারানোর timeline লিখুন। Snapshot restore ও cache warm-up-এ database protection-এর staging plan বানান।
নিজের বোঝা যাচাই করুন
1. Replica কি capacity shard?
এক primary-এর replica সাধারণত একই data copy রাখে। নতুন independent primary slot share নিলে key-space partition হয়।
2. AOF শূন্য loss?
না। Sync policy, hardware ও failure model বিচার করতে হয়। Acknowledgement-এর সঙ্গে durable fsync boundary এক কি না দেখুন।
3. Hash tag কেন?
Cluster multi-key operation-এর keys একই slot-এ রাখতে ব্যবহার হয়। তবে বড় tagged group এক shard-এ skew সৃষ্টি করতে পারে।
4. Failover-এ latest write থাকবে?
Async replication-এ guaranteed নয়। Replica lag-এর সময় primary হারালে acknowledged write হারাতে পারে।
5. Backup থাকলেই recovery শেষ?
না। Restore time, integrity, client reconnect ও source warm-up capacity পরীক্ষা জরুরি। Restore drill ছাড়া RTO শুধু অনুমান।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।