Valkey Cluster برای زمانی طراحی شده است که داده یا بار کاری از ظرفیت یک گره فراتر می‌رود و لازم است مجموعه کلیدها میان چند گره تقسیم شود. اما اضافه‌کردن چند سرور، به‌تنهایی یک سامانه توزیع‌شده قابل اتکا نمی‌سازد. برنامه باید مسیر کلیدها را بشناسد، عملیات چندکلیدی با شیوه تقسیم داده سازگار باشد و تیم بهره‌برداری بداند هنگام خرابی چه چیزی حفظ می‌شود و چه چیزی ممکن است از دست برود. این مقاله مدل Cluster را از زاویه طراحی داده و عملیات توضیح می‌دهد. مثال‌ها آموزشی‌اند و نتیجه اجرای یک آزمایش واقعی گزارش نمی‌شوند.
پیش از انتخاب Cluster، مسئله را مشخص کنید
سه نیاز را از هم جدا کنید: ظرفیت بیشتر، ادامه خدمت هنگام خرابی و نگه‌داری نسخه قابل بازیابی از داده. تقسیم داده میان چند primary عمدتاً به ظرفیت و توزیع بار کمک می‌کند. replica برای همان بخش از داده نسخه دیگری فراهم می‌کند و می‌تواند در جایگزینی گره نقش داشته باشد. persistence و نسخه پشتیبان نیز درباره ماندگاری و بازیابی‌اند. این نیازها مرتبط‌اند، اما هیچ‌یک جای دیگری را کامل نمی‌گیرد. خوشه‌ای با چند replica هنوز ممکن است حذف اشتباه داده را در همه نسخه‌ها تکثیر کند.
نقطه شروع عملی، اندازه‌گیری بار موجود است. مصرف حافظه، نرخ درخواست و تأخیرهای انتهایی را جداگانه بررسی کنید. اگر مشکل فقط یک کلید بسیار داغ باشد، اضافه‌کردن shard لزوماً آن را حل نمی‌کند؛ زیرا یک کلید به یک slot و در نتیجه به یک مسیر اصلی تعلق دارد. اگر مشکل مجموعه بزرگی از کلیدهای مستقل باشد، تقسیم داده می‌تواند مناسب‌تر باشد. این تحلیل پیش از استقرار، مانع از افزودن پیچیدگی بدون حل گلوگاه واقعی می‌شود.
کلید، slot و shard چه رابطه‌ای دارند؟
در مدل Valkey Cluster، فضای کلید به ۱۶۳۸۴ hash slot تقسیم می‌شود. برای حالت معمول، CRC16 کلید و باقی‌مانده تقسیم آن بر ۱۶۳۸۴، شماره slot را تعیین می‌کند. سپس نقشه خوشه مشخص می‌کند هر slot در اختیار کدام primary است. بنابراین کلید مستقیماً به شماره سرور ثابت گره نمی‌خورد؛ میان آن‌ها یک لایه منطقی وجود دارد. همین لایه اجازه می‌دهد مالکیت slot جابه‌جا شود، بدون آنکه نام همه کلیدها تغییر کند. این مدل در راهنمای رسمی Cluster توضیح داده شده است.
برای تصور کاربردی، سه primary را در نظر بگیرید که هرکدام بخشی از slotها را نگه می‌دارند. افزودن گره چهارم به این معنا نیست که همه داده‌ها فوراً و خودکار به اندازه مساوی تقسیم شده‌اند. باید درباره انتقال سهمی از slotها تصمیم گرفت و نتیجه را سنجید. همچنین تعداد برابر slot الزاماً به معنای حافظه یا بار برابر نیست؛ بعضی کلیدها بزرگ‌تر یا پرتکرارترند. این تفاوت، دلیل نیاز به پایش واقعی پس از تغییر توپولوژی است.
دستور CLUSTER KEYSLOT ابزار مناسبی برای بررسی نام‌گذاری کلیدهاست. مستندات آن می‌گوید خروجی، شماره slot محاسبه‌شده برای همان کلید است. پیش از نوشتن منطق برنامه می‌توانید چند نام نماینده را بررسی کنید و مطمئن شوید فرض‌های طراحی درست‌اند. برای نمونه، در محیط آزمایشی دو نام زیر باید به slot مشترک برسند:
CLUSTER KEYSLOT user:{42}:profile
CLUSTER KEYSLOT user:{42}:settings
این دستور داده را جابه‌جا نمی‌کند؛ برای مشاهده و آزمودن نگاشت به کار می‌رود. در تست برنامه نیز می‌توان خروجی محاسبه کتابخانه مشتری را با آن مقایسه کرد تا ناسازگاری در محاسبه slot آشکار شود.
hash tag را بر اساس مرز عملیات انتخاب کنید
بخش مشترک داخل آکولاد در مثال بالا hash tag است. این سازوکار می‌تواند چند کلید مرتبط را در یک slot قرار دهد و به عملیات چندکلیدی کمک کند. اما تگ باید با مرز واقعی عملیات انتخاب شود. اگر هر حساب کاربری چند کلید دارد که لازم است با هم پردازش شوند، شناسه حساب می‌تواند نامزد مناسبی باشد. اگر همه حساب‌ها یک تگ ثابت بگیرند، توزیع بار عملاً به یک بخش محدود می‌شود.
تحلیل طراحی در اینجا مهم‌تر از حفظ‌کردن نحو است. ابتدا فهرست کنید کدام عملیات باید چند کلید را هم‌زمان ببیند. سپس مشخص کنید آیا این کلیدها از نظر مالکیت و چرخه عمر واقعاً یک گروه هستند. تگ‌زدن صرفاً برای خاموش‌کردن خطای CROSSSLOT می‌تواند مشکل معماری را پنهان کند. گاهی بهتر است داده تجمیع شود یا فرایند برنامه به چند مرحله مستقل و قابل جبران تغییر کند. تصمیم مناسب به نیاز اتمی‌بودن عملیات و الگوی بار بستگی دارد.
همچنین اندازه گروه را محدود در نظر بگیرید. یک مشتری بسیار بزرگ ممکن است بخش بزرگی از بار را در تگ خودش جمع کند. در چنین شرایطی باید میان عملیات مشترک و امکان تقسیم بیشتر داده مصالحه کرد. هیچ قاعده نام‌گذاری واحدی برای همه سامانه‌ها مناسب نیست. آزمون با داده نامتوازن، از آزمون صرف با چند کلید هم‌اندازه ارزشمندتر است، زیرا رفتار مشتریان واقعی معمولاً یکنواخت نیست.
مشتری خوشه‌آگاه لازم است
در Valkey Cluster، گره دریافت‌کننده قرار نیست همیشه درخواست را به‌جای مشتری به مقصد نهایی بفرستد. مستندات مشخصات خوشه، پیام‌های MOVED و ASK را برای هدایت مشتری توضیح می‌دهد. کتابخانه مناسب باید نقشه slotها را بشناسد و تغییرات آن را مدیریت کند. صرف برقرارشدن یک اتصال TCP یا موفقیت یک PING نشان نمی‌دهد کتابخانه برای عملیات خوشه‌ای آماده است.
دستور CLUSTER SHARDS اطلاعات shardها، بازه slot و گره‌های مرتبط را ارائه می‌کند. مستندات رسمی آن را برای شناخت توپولوژی توسط کتابخانه‌های مشتری مناسب می‌داند. در بررسی سازگاری، ببینید کتابخانه نسخه مورد استفاده شما چگونه نقشه را دریافت و تازه می‌کند. هنگام جابه‌جایی slot یا failover، برنامه باید بتواند مسیر جدید را پیدا کند. این رفتار را در محیط آزمایش بررسی کنید؛ وابستگی به نام کتابخانه بدون توجه به نسخه و تنظیمات کافی نیست.
از منظر عملیاتی، آدرس‌هایی که خوشه اعلام می‌کند باید از محیط اجرای برنامه قابل دسترس باشند. ممکن است ابزار مدیریتی داخل شبکه سرورها موفق باشد، ولی برنامه در شبکه دیگری مقصد اعلام‌شده را نبیند. در این حالت مشکل در رمز عبور یا خود داده نیست؛ نقشه قابل استفاده‌ای به مشتری نرسیده است. مسیر شبکه را از محل واقعی برنامه آزمایش کنید و دسترسی گره‌به‌گره را از دسترسی مشتری جدا ببینید.
replica احتمال توقف را کاهش می‌دهد، نه همه خطرها را
تکثیر در Cluster ناهمگام است. یعنی ممکن است primary پاسخ موفق بدهد، اما پیش از رسیدن نوشتن به replica از کار بیفتد. اگر نسخه‌ای عقب‌مانده جایگزین شود، بخشی از نوشتن‌های تأییدشده می‌تواند از دست برود. این محدودیت در مشخصات رسمی آمده و باید در انتخاب کاربرد دیده شود. داده موقتیِ قابل بازسازی با داده‌ای که تنها سند یک رویداد مهم است، نیاز یکسانی ندارد.
دستور WAIT امکان می‌دهد اتصال مشتری برای تأیید دریافت نوشتن‌های قبلی توسط تعداد مشخصی replica منتظر بماند. عدد خروجی باید بررسی شود؛ تمام‌شدن زمان انتظار به‌خودی‌خود به معنای رسیدن به تعداد درخواستی نیست. مستندات همچنین روشن می‌کند که WAIT، Valkey را به سامانه‌ای با سازگاری قوی تبدیل نمی‌کند. این ابزار احتمال برخی انواع از‌دست‌رفتن داده را کاهش می‌دهد، اما جای طراحی درست برای شکست و بازیابی را نمی‌گیرد.
در سطح برنامه، برای درخواست‌های قابل تکرار شناسه و رفتار مشخص داشته باشید. قطع اتصال پس از ارسال فرمان، وضعیتی مبهم ایجاد می‌کند: ممکن است فرمان اجرا شده باشد ولی پاسخ نرسیده باشد. ارسال مجدد یک افزایش شمارنده با خواندن دوباره یک مقدار تفاوت دارد. بنابراین سیاست retry باید با معنای عملیات هماهنگ باشد. این توصیه تحلیلی مختص Valkey نیست، اما در محیطی با failover و تغییر مسیر اهمیت بیشتری پیدا می‌کند.
سلامت خوشه را از چند زاویه ببینید
CLUSTER INFO خلاصه‌ای از وضعیت ارائه می‌کند. شماره slotهای تخصیص‌یافته، slotهای سالم و وضعیت‌های PFAIL یا FAIL برای تشخیص مسئله مفیدند. مستندات میان مشاهده موقتِ دسترس‌ناپذیری و تشخیص تأییدشده خرابی تفاوت می‌گذارد. از این رو، یک نمونه خروجی را با تاریخچه اشتباه نگیرید. روند خطا، زمان رخداد و دید گره‌های دیگر می‌تواند کمک کند قطعی واقعی را از اختلال گذرا جدا کنید.
وضعیت سالم خوشه نیز پایان پایش نیست. برنامه ممکن است به دلیل timeout نامناسب، ازدحام اتصال یا بار یک کلید دچار مشکل باشد. داشبورد عملی باید هم معیارهای گره و هم تجربه درخواست را ببیند. نرخ موفقیت، تأخیرهای بالا، تعداد تغییر مسیر و فاصله تکثیر مکمل هم‌اند. هدف این نیست که هر عدد ممکن جمع شود؛ باید بتوانید با مشاهده نشانه‌ها تصمیم بگیرید کدام فرض را بررسی کنید.
برای آزمایش تاب‌آوری، سناریوها را از هم جدا کنید: توقف یک فرایند، قطع مسیر شبکه، کندشدن دیسک و شکست هم‌زمان primary و replica اثر یکسانی ندارند. هر آزمایش باید معیار پایان و روش بازگرداندن محیط داشته باشد. همچنین ثبت کنید کدام درخواست‌ها پیش از اختلال تأیید شدند و کدام بعد از بازیابی دیده می‌شوند. بدون این ثبت، ادعای «داده‌ای از دست نرفت» ممکن است فقط ناشی از نداشتن ابزار مشاهده باشد.
resharding یک تغییر عملیاتی است
جابه‌جایی slot به معنی تغییر مالکیت همراه با انتقال داده است. برای برنامه‌ریزی آن، ظرفیت مقصد، بار شبکه و اندازه کلیدها را در نظر بگیرید. حتی اگر سازوکار برای ادامه خدمت طراحی شده باشد، نباید نتیجه گرفت تغییر در هر بار کاری بدون اثر محسوس خواهد بود. معیار پذیرش باید پیش از شروع تعریف شود: چه افزایش تأخیری قابل قبول است، چه خطایی باعث توقف می‌شود و چه زمانی تغییر را کامل می‌دانید؟
روش مناسب، شروع محدود و مشاهده نتیجه است. پس از انتقال بخشی کوچک، وضعیت slotها، رفتار مشتری و منابع دو طرف را بررسی کنید. به تعداد منتقل‌شده اکتفا نکنید؛ مطمئن شوید برنامه به مسیر جدید رسیده و عملیات نماینده درست پاسخ می‌گیرند. طرح بازگشت نیز باید معنای مشخص داشته باشد. بازگرداندن مالکیت داده با برگرداندن یک فایل تنظیمات ساده یکسان نیست و باید وضعیت فعلی انتقال در نظر گرفته شود.
نگه‌داری برنامه‌ریزی‌شده و بازیابی
CLUSTER FAILOVER در حالت معمول روی replica اجرا می‌شود و برای جابه‌جایی هماهنگ نقش‌ها به کار می‌رود. مستندات، انتظار برای رسیدن replica به offset لازم و هماهنگی با primary را توضیح می‌دهد. گزینه‌های FORCE و TAKEOVER رفتار متفاوتی دارند و نباید در راهنمای معمول نگه‌داری بدون شناخت شرایط جایگزین حالت عادی شوند. عملیات اضطراری با جابه‌جایی برنامه‌ریزی‌شده یکسان نیست.
برای ماندگاری داده، RDB و AOF را جدا از replica ارزیابی کنید. مستندات persistence، RDB را تصویر دوره‌ای و AOF را ثبت عملیات نوشتن معرفی می‌کند. انتخاب میان آن‌ها به میزان قابل قبول از‌دست‌رفتن داده، زمان بازیابی و هزینه منابع وابسته است. نسخه پشتیبان زمانی معنا دارد که از دامنه خرابی اصلی جدا باشد و بازگردانی آن آزمایش شده باشد. وجود فایل روی همان میزبان، در برابر از‌دست‌رفتن آن میزبان کافی نیست.
تصمیم نهایی درباره Cluster باید به مسئله اولیه برگردد. اگر داده قابل تقسیم است، مشتری مناسب دارید و تیم می‌تواند تغییر توپولوژی را پایش و آزمایش کند، این معماری ابزار مفیدی برای رشد فراهم می‌کند. اگر عملیات اصلی به تعداد زیادی کلید نامرتبط وابسته است یا نیاز ماندگاری با مدل تکثیر سازگار نیست، باید طراحی داده یا انتخاب سامانه بازبینی شود. ارزش Cluster در اضافه‌کردن سرور نیست؛ در توزیع کنترل‌شده مسئولیت داده با شناخت دقیق محدودیت‌هاست.
