با رسیدن به محصولی که بیش از یک دهه است در حال توسعه است، یافتن فناوری های قدیمی در آن اصلا تعجب آور نیست. اما اگر در شش ماه مجبور شوید بار را 10 برابر بیشتر نگه دارید و هزینه سقوط صدها برابر شود، چه؟ در این مورد، به یک مهندس Highload نیاز دارید. اما در نبود خدمتکار، حل مشکل را به من سپردند. در قسمت اول مقاله به شما می گویم که چگونه از Redis به Redis-cluster منتقل شدیم و در قسمت دوم توصیه هایی در مورد نحوه شروع استفاده از کلاستر و مواردی که هنگام استفاده از آن باید به آن توجه کنید را ارائه خواهم داد.

انتخاب تکنولوژی

اینقدر بد است؟ Redis را جدا کنید (ردیس مستقل) در پیکربندی 1 master و N برده؟ چرا من آن را فناوری منسوخ می نامم؟

نه، ردیس آنقدرها هم بد نیست... با این حال، کاستی هایی وجود دارد که نمی توان آنها را نادیده گرفت.

• اول، Redis از مکانیسم های بازیابی فاجعه پس از یک شکست اصلی پشتیبانی نمی کند. برای حل این مشکل، ما از یک پیکربندی با انتقال خودکار VIP ها به یک Master جدید، تغییر نقش یکی از Slave و تغییر بقیه استفاده کردیم. این مکانیسم کار کرد، اما نمی توان آن را یک راه حل قابل اعتماد نامید. اولاً آلارم های کاذب رخ می داد و ثانیاً یکبار مصرف بود و پس از بهره برداری اقدامات دستی برای شارژ فنر لازم بود.

• ثانیاً داشتن تنها یک استاد منجر به مشکل شاردینگ شد. ما مجبور شدیم چندین خوشه مستقل "1 master و N slaves" ایجاد کنیم، سپس به صورت دستی پایگاه های داده را بین این ماشین ها توزیع کنیم و امیدوار باشیم که فردا یکی از پایگاه های داده آنقدر متورم نشود که مجبور شود به یک نمونه جداگانه منتقل شود.

چه گزینه هایی وجود دارد؟

• گران ترین و غنی ترین راه حل Redis-Enterprise است. این یک راه حل جعبه ای با پشتیبانی فنی کامل است. علیرغم اینکه از نظر فنی ایده آل به نظر می رسد، به دلایل ایدئولوژیک مناسب ما نیست.
• Redis-cluster. خارج از جعبه، پشتیبانی از master failover و Sharding وجود دارد. رابط کاربری تقریباً هیچ تفاوتی با نسخه معمولی ندارد. امیدوار کننده به نظر می رسد، بعداً در مورد مشکلات صحبت خواهیم کرد.
• Tarantool، Memcache، Aerospike و دیگران. همه این ابزارها تقریباً یک کار را انجام می دهند. اما هر کدام کاستی های خاص خود را دارند. تصمیم گرفتیم همه تخم مرغ هایمان را در یک سبد قرار ندهیم. ما از Memcache و Tarantool برای کارهای دیگر استفاده می کنیم و با نگاهی به آینده، می گویم که در تمرین ما مشکلات بیشتری با آنها وجود داشت.

مشخصات استفاده

بیایید نگاهی بیندازیم که در طول تاریخ چه مشکلاتی را با Redis حل کرده ایم و از چه عملکردی استفاده کرده ایم:

• کش قبل از درخواست خدمات راه دور مانند 2GIS | گولنگ
  

  GET SET MGET MSET "SELECT DB"

• کش قبل از MYSQL | PHP
  

  GET SET MGET MSET SCAN "KEY BY PATTERN" "SELECT DB"

• ذخیره سازی اصلی برای سرویس کار با جلسات و مختصات درایور | گولنگ
  

  GET SET MGET MSET "SELECT DB" "ADD GEO KEY" "GET GEO KEY" SCAN

همانطور که می بینید، هیچ ریاضی بالاتری وجود ندارد. پس سختی چیست؟ بیایید هر روش را جداگانه بررسی کنیم.

روش
شرح
ویژگی های Redis-cluster
تصمیم

تنظیم کنید
کلید نوشتن/خواندن

MGET MSET
چندین کلید را بنویسید/بخوانید
کلیدها بر روی گره های مختلف خواهند بود. کتابخانه های آماده می توانند چند عملیات را فقط در یک گره انجام دهند
MGET را با خط لوله ای از عملیات N GET جایگزین کنید

DB را انتخاب کنید
پایه ای را که با آن کار خواهیم کرد انتخاب کنید
از چندین پایگاه داده پشتیبانی نمی کند
همه چیز را در یک پایگاه داده قرار دهید. اضافه کردن پیشوند به کلیدها

SCAN
تمام کلیدهای پایگاه داده را مرور کنید
از آنجایی که ما یک پایگاه داده داریم، بررسی همه کلیدهای خوشه بسیار گران است
یک متغیر را در یک کلید حفظ کنید و یک HSCAN روی این کلید انجام دهید. یا به طور کامل امتناع کنید

GEO
عملیات با geokey
ژئوکلید خرد نشده است

کلید بر اساس الگو
جستجوی کلید بر اساس الگو
از آنجایی که ما یک پایگاه داده داریم، همه کلیدهای خوشه را جستجو خواهیم کرد. بیش از حد گران
مانند مورد SCAN، ثابت را رد یا حفظ کنید

Redis vs Redis-cluster

وقتی به خوشه تغییر می کنیم چه چیزی را از دست می دهیم و چه چیزی را به دست می آوریم؟

• معایب: ما عملکرد چندین پایگاه داده را از دست می دهیم.
  • اگر بخواهیم داده های منطقی نامرتبط را در یک خوشه ذخیره کنیم، باید عصا را به صورت پیشوند بسازیم.
  • ما همه عملیات "پایه" را از دست می دهیم، مانند SCAN، DBSIZE، CLEAR DB و غیره.
  • اجرای چند عملیات بسیار دشوارتر شده است زیرا ممکن است نیاز به دسترسی به چندین گره داشته باشد.
• مزایا:
  • تحمل خطا به صورت Master Failover.
  • Sharding در سمت Redis.
  • انتقال داده ها بین گره ها به صورت اتمی و بدون خرابی.
  • اضافه کردن و توزیع مجدد ظرفیت و بارها بدون توقف.

من نتیجه می‌گیرم که اگر نیازی به ارائه سطح بالایی از تحمل خطا ندارید، انتقال به یک خوشه ارزش آن را ندارد، زیرا می‌تواند یک کار غیر ضروری باشد. اما اگر در ابتدا بین نسخه مجزا و خوشه ای یکی را انتخاب می کنید، پس باید خوشه ای را انتخاب کنید، زیرا بدتر نیست و علاوه بر این، شما را از سردردها رها می کند.

آماده شدن برای حرکت

بیایید با الزامات حرکت شروع کنیم:

• باید بدون درز باشد. توقف کامل خدمات به مدت 5 دقیقه برای ما مناسب نیست.
• باید تا حد امکان ایمن و تدریجی باشد. من می خواهم کمی روی اوضاع کنترل داشته باشم. ما نمی خواهیم همه چیز را به یکباره رها کنیم و روی دکمه برگشت دعا کنیم.
• حداقل از دست دادن اطلاعات هنگام جابجایی ما می‌دانیم که حرکت به صورت اتمی بسیار دشوار خواهد بود، بنابراین اجازه می‌دهیم تا مقداری همگام‌سازی بین داده‌ها در Redis معمولی و خوشه‌ای انجام شود.

نگهداری خوشه

درست قبل از حرکت، باید به این فکر کنیم که آیا می توانیم از خوشه حمایت کنیم:

• نمودار. ما از Prometheus و Grafana برای ترسیم بار CPU، میزان مصرف حافظه، تعداد کلاینت ها، تعداد عملیات GET، SET، AUTH و غیره استفاده می کنیم.
• تجربه و تخصص. تصور کنید که فردا یک خوشه بزرگ تحت مسئولیت خود خواهید داشت. اگر خراب شود، هیچکس جز شما نمی تواند آن را تعمیر کند. اگر او شروع به کند شدن کند، همه به سمت شما خواهند دوید. اگر نیاز به اضافه کردن منابع یا توزیع مجدد بار دارید، به سراغ شما بیایید. برای اینکه در 25 سالگی خاکستری نشوید، توصیه می شود این موارد را فراهم کنید و از قبل بررسی کنید که فناوری تحت برخی اقدامات چگونه رفتار می کند. بیایید در بخش "تخصص" در مورد این با جزئیات بیشتر صحبت کنیم.
• نظارت و هشدار. وقتی یک خوشه خراب می شود، شما می خواهید اولین کسی باشید که در مورد آن می دانید. در اینجا ما خودمان را به یک اعلان محدود کردیم مبنی بر اینکه همه گره ها اطلاعات یکسانی را در مورد وضعیت خوشه برمی گردانند (بله، متفاوت است). و سایر مشکلات را می توان با هشدارهای خدمات مشتری Redis سریعتر متوجه شد.

حرکت

چگونه حرکت خواهیم کرد:

• اول از همه، شما باید یک کتابخانه برای کار با کلاستر آماده کنید. ما go-redis را به عنوان پایه نسخه Go در نظر گرفتیم و آن را کمی تغییر دادیم تا مناسب خودمان باشد. ما چند روش را از طریق خطوط لوله پیاده‌سازی کردیم و همچنین قوانین تکرار درخواست‌ها را کمی اصلاح کردیم. نسخه PHP مشکلات بیشتری داشت، اما در نهایت روی php-redis قرار گرفتیم. آنها اخیراً پشتیبانی خوشه ای را معرفی کردند و از نظر ما خوب به نظر می رسد.
• در مرحله بعد باید خود خوشه را مستقر کنید. این به معنای واقعی کلمه در دو دستور بر اساس فایل پیکربندی انجام می شود. در ادامه با جزئیات بیشتری در مورد تنظیمات صحبت خواهیم کرد.
• برای حرکت تدریجی از حالت خشک استفاده می کنیم. از آنجایی که ما دو نسخه از کتابخانه با رابط یکسان داریم (یکی برای نسخه معمولی، دیگری برای کلاستر)، ایجاد یک پوشش که با نسخه جداگانه کار می کند و به طور موازی همه درخواست ها را به کلاستر کپی می کند، هزینه ای ندارد. پاسخ ها را مقایسه کنید و اختلافات را در گزارش ها بنویسید (در مورد ما در NewRelic). بنابراین، حتی اگر نسخه خوشه‌ای در حین عرضه خراب شود، تولید ما تحت تأثیر قرار نخواهد گرفت.
• پس از قرار دادن خوشه در حالت خشک، می‌توانیم با آرامش به نمودار تفاوت‌های پاسخ نگاه کنیم. اگر نرخ خطا به آرامی اما مطمئناً به سمت یک ثابت کوچک حرکت کند، همه چیز خوب است. چرا هنوز اختلاف نظر وجود دارد؟ زیرا ضبط در یک نسخه جداگانه کمی زودتر از خوشه اتفاق می افتد و به دلیل ریز لگ ممکن است داده ها از هم جدا شوند. تنها چیزی که باقی می‌ماند این است که به گزارش‌های اختلاف نگاه کنیم، و اگر همه آنها با اتمی نبودن رکورد توضیح داده شوند، می‌توانیم ادامه دهیم.
• اکنون می توانید حالت خشک را در جهت مخالف تغییر دهید. ما از خوشه می نویسیم و می خوانیم و آن را در یک نسخه جداگانه کپی می کنیم. برای چی؟ در طول هفته آینده من می خواهم کار خوشه را مشاهده کنم. اگر ناگهان مشخص شد که در اوج بار مشکلی وجود دارد، یا چیزی را در نظر نگرفتیم، به لطف حالت خشک، همیشه یک بازگشت اضطراری به کد قدیمی و داده‌های فعلی داریم.
• تنها چیزی که باقی می ماند این است که حالت خشک را غیرفعال کنید و نسخه جداگانه را جدا کنید.

تخصص

ابتدا به طور خلاصه در مورد طراحی خوشه.

اول از همه، Redis یک فروشگاه با ارزش کلیدی است. از رشته های دلخواه به عنوان کلید استفاده می شود. اعداد، رشته ها و کل ساختارها می توانند به عنوان مقادیر استفاده شوند. تعداد زیادی از دومی ها وجود دارد، اما برای درک ساختار کلی این برای ما مهم نیست.
سطح بعدی انتزاع بعد از کلیدها اسلات (SLOTS) است. هر کلید متعلق به یکی از 16 اسلات است. در داخل هر شکاف می توان هر تعداد کلید وجود داشته باشد. بنابراین، تمام کلیدها به 383 مجموعه جدا تقسیم می شوند.

بعد، باید N گره اصلی در خوشه وجود داشته باشد. هر گره را می توان به عنوان یک نمونه Redis جداگانه در نظر گرفت که همه چیز را در مورد سایر گره های درون خوشه می داند. هر گره اصلی شامل تعدادی اسلات است. هر شکاف فقط به یک گره اصلی تعلق دارد. همه اسلات ها باید بین گره ها توزیع شوند. اگر برخی از اسلات ها تخصیص داده نشوند، کلیدهای ذخیره شده در آنها غیرقابل دسترسی خواهند بود. منطقی است که هر گره اصلی را روی یک ماشین منطقی یا فیزیکی جداگانه اجرا کنیم. همچنین لازم به یادآوری است که هر گره فقط بر روی یک هسته اجرا می شود، و اگر می خواهید چندین نمونه Redis را در یک ماشین منطقی اجرا کنید، مطمئن شوید که آنها بر روی هسته های مختلف اجرا می شوند (ما این را امتحان نکرده ایم، اما در تئوری باید کار کند) . اساساً، گره‌های اصلی، اشتراک‌گذاری منظم را ارائه می‌کنند، و گره‌های اصلی بیشتر اجازه می‌دهند درخواست‌های نوشتن و خواندن مقیاس شوند.

پس از اینکه همه کلیدها بین شکاف ها توزیع شدند و شکاف ها در بین گره های اصلی پراکنده شدند، می توان تعداد دلخواه گره های برده را به هر گره اصلی اضافه کرد. در هر پیوند master-slave، تکرار معمولی کار خواهد کرد. Slave ها برای مقیاس درخواست های خواندن و برای failover در صورت خرابی اصلی مورد نیاز هستند.

حالا بیایید در مورد عملیاتی صحبت کنیم که بهتر است بتوانیم انجام دهیم.

ما از طریق Redis-CLI به سیستم دسترسی خواهیم داشت. از آنجایی که Redis یک نقطه ورودی واحد ندارد، می توانید عملیات زیر را روی هر یک از گره ها انجام دهید. در هر نقطه به طور جداگانه توجه را به امکان انجام عملیات تحت بار جلب می کنم.

• اولین و مهمترین چیزی که به آن نیاز داریم عملیات گره های خوشه ای است. وضعیت خوشه را برمی گرداند، فهرستی از گره ها، نقش آنها، توزیع اسلات و غیره را نشان می دهد. اطلاعات بیشتر را می توان با استفاده از اطلاعات خوشه و شکاف های خوشه ای به دست آورد.
• خوب است که بتوانیم گره ها را اضافه و حذف کنیم. برای این منظور عملیات Cluster Meet و Cluster Forgot وجود دارد. لطفاً توجه داشته باشید که فراموشی خوشه‌ای باید برای هر گره اعمال شود، چه Master و چه Replica. و cluster meet فقط باید در یک گره فراخوانی شود. این تفاوت می تواند نگران کننده باشد، بنابراین بهتر است قبل از شروع زندگی مشترک با خوشه خود در مورد آن اطلاعات کسب کنید. افزودن گره در نبرد با خیال راحت انجام می شود و به هیچ وجه بر عملکرد خوشه تأثیری نمی گذارد (که منطقی است). اگر می‌خواهید یک گره را از خوشه حذف کنید، باید مطمئن شوید که هیچ شکافی روی آن باقی نمانده است (در غیر این صورت خطر از دست دادن دسترسی به تمام کلیدهای این گره را دارید). همچنین استادی را که برده دارد حذف نکنید در غیر این صورت رای غیرضروری برای استاد جدید انجام می شود. اگر گره‌ها دیگر اسلات ندارند، پس این یک مشکل کوچک است، اما اگر بتوانیم ابتدا بردها را حذف کنیم، چرا به انتخاب‌های اضافی نیاز داریم.
• اگر نیاز به تعویض اجباری موقعیت های master و slave دارید، دستور failover خوشه انجام می شود. هنگام فراخوانی آن در نبرد، باید بدانید که استاد در طول عملیات در دسترس نخواهد بود. به طور معمول سوئیچ در کمتر از یک ثانیه اتفاق می افتد، اما اتمی نیست. می توانید انتظار داشته باشید که برخی از درخواست ها به استاد در این مدت با شکست مواجه شوند.
• قبل از حذف یک گره از خوشه، نباید هیچ شکافی روی آن باقی بماند. بهتر است با استفاده از دستور cluster reshard آنها را دوباره توزیع کنید. اسلات ها از یک استاد به استاد دیگر منتقل می شوند. کل عملیات ممکن است چند دقیقه طول بکشد، این بستگی به حجم داده های در حال انتقال دارد، اما فرآیند انتقال امن است و به هیچ وجه بر عملکرد خوشه تأثیر نمی گذارد. بنابراین، تمام داده ها را می توان از یک گره به گره دیگر به طور مستقیم تحت بار، و بدون نگرانی در مورد در دسترس بودن آن منتقل کرد. با این حال، نکات ظریفی نیز وجود دارد. اولاً، انتقال داده با بار خاصی بر روی گره های گیرنده و فرستنده مرتبط است. اگر گره گیرنده قبلاً به شدت روی پردازنده بارگذاری شده است، نباید آن را با دریافت داده های جدید بارگیری کنید. ثانیاً، به محض اینکه حتی یک شکاف بر روی استاد فرستنده باقی نماند، همه Slave های آن بلافاصله به Master که این اسلات ها به آن منتقل شده است می روند. و مشکل این است که همه این بردها می خواهند داده ها را به یکباره همگام کنند. و اگر همگام سازی جزئی باشد نه کامل، خوش شانس خواهید بود. این را در نظر بگیرید و عملیات انتقال اسلات و غیرفعال کردن/انتقال بردها را ترکیب کنید. یا امیدوار باشید که از امنیت کافی برخوردار باشید.
• اگر در حین انتقال متوجه شدید که جایگاه خود را در جایی گم کرده اید، چه کاری باید انجام دهید؟ امیدوارم این مشکل شما را تحت تاثیر قرار ندهد، اما اگر تاثیری داشته باشد، عملیات رفع خوشه ای وجود دارد. حداقل، او شکاف ها را در سراسر گره ها به ترتیب تصادفی پراکنده می کند. توصیه می کنم ابتدا با حذف گره با شکاف های توزیع شده از خوشه، عملکرد آن را بررسی کنید. از آنجایی که داده‌های موجود در اسلات‌های تخصیص‌نخورده در حال حاضر در دسترس نیستند، برای نگرانی در مورد مشکلات در دسترس بودن این اسلات‌ها خیلی دیر است. به نوبه خود، این عملیات بر اسلات های توزیع شده تأثیری نخواهد گذاشت.
• یکی دیگر از عملیات مفید مانیتور است. این به شما امکان می دهد کل لیست درخواست هایی که به گره می روند را در زمان واقعی مشاهده کنید. علاوه بر این، می توانید آن را درک کنید و متوجه شوید که آیا ترافیک لازم وجود دارد یا خیر.

همچنین لازم به ذکر است که رویه اصلی failover. به طور خلاصه وجود دارد و به نظر من عالی کار می کند. با این حال، فکر نکنید که اگر سیم برق دستگاهی را با یک گره اصلی جدا کنید، Redis فوراً تغییر خواهد کرد و مشتریان متوجه از دست رفتن نخواهند شد. در تمرین من، تغییر در چند ثانیه اتفاق می افتد. در طول این مدت، برخی از داده‌ها در دسترس نیستند: در دسترس نبودن Master شناسایی می‌شود، گره‌ها به یک مورد جدید رأی می‌دهند، برده‌ها تغییر می‌کنند، داده‌ها همگام‌سازی می‌شوند. بهترین راه برای اطمینان از کارآمد بودن این طرح، انجام تمرینات محلی است. کلاستر را در لپ تاپ خود بالا ببرید، حداقل بار را به آن بدهید، خرابی را شبیه سازی کنید (مثلاً با مسدود کردن پورت ها)، و سرعت سوئیچینگ را ارزیابی کنید. به نظر من، تنها پس از یک یا دو روز بازی در این روش می توانید از عملکرد فناوری اطمینان داشته باشید. خوب، یا امیدواریم که نرم افزاری که نیمی از اینترنت از آن استفاده می کند احتمالاً کار می کند.

پیکربندی

اغلب، پیکربندی اولین چیزی است که برای شروع کار با ابزار نیاز دارید. و وقتی همه چیز کار می کند، حتی نمی خواهید پیکربندی را لمس کنید. برای اینکه خود را مجبور کنید به تنظیمات برگردید و با دقت آنها را مرور کنید، کمی تلاش می‌طلبد. در حافظه من حداقل دو شکست جدی به دلیل عدم توجه به پیکربندی داشتیم. به نکات زیر توجه ویژه داشته باشید:

• زمان 0
  زمانی که پس از آن اتصالات غیرفعال بسته می شوند (بر حسب ثانیه). 0 - نبندید
  همه کتابخانه های ما نتوانستند اتصالات را به درستی ببندند. با غیرفعال کردن این تنظیم، در معرض خطر رسیدن به محدودیت تعداد مشتریان هستیم. از طرف دیگر، اگر چنین مشکلی وجود داشته باشد، قطع خودکار اتصالات از دست رفته آن را پنهان می کند و ممکن است متوجه نشویم. علاوه بر این، هنگام استفاده از اتصالات پایدار، نباید این تنظیم را فعال کنید.
• ذخیره xy & appendonly بله
  ذخیره یک عکس فوری RDB.
  در زیر به طور مفصل در مورد مسائل RDB/AOF بحث خواهیم کرد.
• stop-writes-on-bgsave-error no & slave-serve-stale-data بله
  اگر فعال باشد، اگر عکس فوری RDB شکسته شود، کارشناسی ارشد درخواست تغییر را نمی‌پذیرد. اگر ارتباط با master قطع شود، Slave می‌تواند به درخواست‌ها پاسخ دهد (بله). یا دیگر پاسخ نمی دهد (نه)
  ما از وضعیتی که در آن ردیس به کدو تنبل تبدیل می شود راضی نیستیم.
• repl-ping-slave-period 5
  پس از این مدت زمان، ما شروع به نگرانی از خراب شدن master خواهیم کرد و زمان انجام فرآیند failover فرا رسیده است.
  شما باید به صورت دستی تعادلی بین موارد مثبت کاذب و راه اندازی یک شکست پیدا کنید. در تمرین ما این 5 ثانیه است.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  ما می‌توانیم دقیقاً این مقدار داده را در یک بافر برای یک کپی ناموفق ذخیره کنیم. اگر بافر تمام شود، باید به طور کامل همگام سازی کنید.
  تمرین نشان می دهد که بهتر است مقدار بالاتری تعیین کنید. دلایل زیادی وجود دارد که چرا یک ماکت ممکن است شروع به تاخیر کند. اگر تاخیر داشته باشد، به احتمال زیاد استاد شما در حال حاضر برای مقابله با مشکل تلاش می کند، و همگام سازی کامل آخرین نی خواهد بود.
• حداکثر مشتری 10000
  حداکثر تعداد مشتریان یکبار مصرف.
  طبق تجربه ما، بهتر است مقدار بالاتری تعیین کنیم. Redis به خوبی 10 هزار اتصال را مدیریت می کند. فقط مطمئن شوید که سوکت های کافی روی سیستم وجود دارد.
• maxmemory-policy volatile-ttl
  قانونی که به موجب آن کلیدها با رسیدن به محدودیت حافظه موجود حذف می شوند.
  آنچه در اینجا مهم است خود قانون نیست، بلکه درک چگونگی این اتفاق است. Redis را می توان به دلیل توانایی آن در عملکرد عادی در هنگام رسیدن به محدودیت حافظه تحسین کرد.

مشکلات RDB و AOF

اگرچه خود Redis تمام اطلاعات را در RAM ذخیره می کند، مکانیسمی نیز برای ذخیره داده ها در دیسک وجود دارد. به طور دقیق تر، سه مکانیسم:

• RDB-snapshot - یک عکس فوری کامل از تمام داده ها. با استفاده از پیکربندی SAVE XY تنظیم کنید و «اگر حداقل کلیدهای Y تغییر کرده باشند، هر X ثانیه یک عکس فوری کامل از همه داده‌ها ذخیره کنید».
• فایل فقط پیوست - فهرستی از عملیات به ترتیبی که انجام می شود. هر X ثانیه یا هر عملیات Y عملیات ورودی جدید را به فایل اضافه می کند.
• RDB و AOF ترکیبی از دو مورد قبلی هستند.

همه روش ها مزایا و معایب خود را دارند، من همه آنها را لیست نمی کنم، فقط به نکاتی توجه می کنم که به نظر من واضح نیستند.

اول، ذخیره یک عکس فوری RDB نیاز به فراخوانی FORK دارد. اگر داده‌های زیادی وجود داشته باشد، این می‌تواند همه Redis را برای مدت چند میلی‌ثانیه تا یک ثانیه معلق کند. علاوه بر این، سیستم نیاز به تخصیص حافظه برای چنین عکس فوری دارد، که منجر به نیاز به نگهداری دو برابر رم در ماشین منطقی می شود: اگر 8 گیگابایت برای Redis اختصاص داده شود، باید 16 گیگابایت در ماشین مجازی موجود باشد. آی تی.

ثانیا، مشکلاتی با همگام سازی جزئی وجود دارد. در حالت AOF، زمانی که Slave دوباره وصل می شود، به جای همگام سازی جزئی، می توان همگام سازی کامل را انجام داد. چرا این اتفاق می افتد، من نتوانستم بفهمم. اما ارزش یادآوری این را دارد.

این دو نکته در حال حاضر ما را به این فکر می‌کند که آیا واقعاً به این داده‌ها روی دیسک نیاز داریم، اگر همه چیز قبلاً توسط بردگان تکرار شده است. داده‌ها تنها در صورتی از بین می‌روند که همه بردها از کار بیفتند، و این یک مشکل در سطح "آتش در DC" است. به عنوان یک مصالحه، می‌توانید پیشنهاد کنید که داده‌ها را فقط در برده‌ها ذخیره کنید، اما در این مورد باید مطمئن شوید که این بردها در طول بازیابی فاجعه هرگز استاد نخواهند شد (برای این کار یک تنظیمات اولویت برده در پیکربندی آنها وجود دارد). برای خودمان، در هر مورد خاص به این فکر می کنیم که آیا لازم است داده ها را روی دیسک ذخیره کنیم یا خیر، و اغلب پاسخ "نه" است.

نتیجه

در خاتمه، امیدوارم توانسته باشم یک ایده کلی از نحوه عملکرد redis-cluster برای کسانی که اصلاً در مورد آن نشنیده اند ارائه دهم، و همچنین توجه را به نکات غیر واضح برای کسانی که از آن استفاده کرده اند جلب کرده باشم. برای مدت طولانی
از وقتی که گذاشتید متشکریم و مثل همیشه نظرات در مورد موضوع مورد استقبال قرار می گیرد.

منبع: www.habr.com