چطور کانوا صدها میلیون نشست رو مدیریت میکنه
خلاصهٔ کاملتر
تو این مقالهٔ مهندسی کانوا اومده که مدیریت نشست برای صدها میلیون کاربر سخته، چون هر درخواست بکاند باید بدونه کدوم کاربرِ لاگینکرده فرستادتش. کانوا اطلاعات نشست رو تو کوکی رمزنگاریشده نگه میداره تا گیتویها بدون زدن به دیتابیس بهش اعتماد کنن، ولی وقتی کاربری خارج میشه یا دسترسیاش عوض میشه، باید بشه نشست رو تقریبا آنی باطل کرد.
برای همین هر گیتوی یه کپی از نشستهای باطلشده رو تو حافظه داره (۱۲ ساعت آخر). مشکل اینجا بود که موقع استقرار، صدها پاد هرکدوم بیش از یه میلیون رکورد رو همزمان از MySQL میکشیدن و یه هجوم هماهنگ به دیتابیس راه میافتاد. نویسنده میگه نمیخواستن استقرار رو کند کنن، پس دنبال راهی بودن که این بار رو برداره.
Redis رو بررسی کردن ولی چون معمولا کاملا بادوام مستقر نمیشه و مدیریت خودش هم دردسر داشت، رفتن سراغ S3. داده رو به قطعههای ۳۰ دقیقهای تقسیم کردن که هر قطعه یه آبجکت تو S3ه. هر رکورد ابطال رو هم با یهکم بازی با بیتها تو ۱۶ بایت جا دادن و آرایه رو مرتب کردن تا بشه با جستوجوی دودویی سریع توش گشت؛ همین باعث شد حجم کش تو حافظه ۸ برابر کم بشه.
برای بهروز نگه داشتن قطعهها یه ورکر ناهمگام مدام دیتابیس رو اسکن میکنه و رکوردهای جدید رو به قطعه اضافه میکنه؛ برای جلوگیری از مسابقه بین چند ورکر هم از PUT شرطی (کنترل همزمانی خوشبینانه) و انتخاب رهبر با ZooKeeper استفاده میکنن. نتیجه: سرعت استقرار بهتر شد، تعداد رپلیکاهای خوندنی به دو تا رسید و حجم کش تو حافظه ۸۷.۵٪ کم شد. نویسنده میگه درس بزرگ پروژه، فرق مقیاسپذیری تو تئوری و عمل بود.
نکات کلیدی:
- نشستها تو کوکی رمزنگاریشده، لیست ابطال ۱۲ ساعت آخر تو حافظهٔ گیتوی
- گلوگاه: هجوم صدها پاد به MySQL موقع استقرار
- راهحل: قطعههای باینری ۱۶ بایتی رو S3 با جستوجوی دودویی
- PUT شرطی و رهبرگزینی ZooKeeper برای جلوگیری از گم شدن داده
- حجم کش تو حافظه ۸۷.۵٪ کم شد
