کانوا ابطال سشن رو روی S3 برد
خلاصهٔ کاملتر
تو یه پست مهندسی، کانوا توضیح داده که چطور زیرساخت ابطال سشن (session revocation) رو از نو ساخته. این شرکت اطلاعات سشن رو داخل کوکیهای رمزنگاریشدهٔ مرورگر نگه میداره، پس گیتویها میتونن بدون تماس با یه دیتاستور شبکهای درخواستها رو احراز هویت کنن. مشکل اینجا بود که سشنهای باطلشده و تغییر دسترسیها باید تقریباً بلافاصله اعمال بشن؛ قبلاً ۱۲ ساعت دادهٔ ابطال تو حافظه میموند و رفرش سشنها هم همچنان سراغ MySQL میرفت.
به گفتهٔ کانوا، با بزرگ شدن پلتفرم این مدل کم آورد: موقع دیپلوی صدها نمونهٔ گیتوی هرکدوم بیش از یک میلیون رکورد ابطال رو از MySQL میخواستن و یه بار هماهنگ و سنگین روی دیتابیس میساختن. کانوا بهجای Redis سراغ S3 رفت تا مجبور نشه یه دیتاستور دیگه رو هم نگه داره. پنجرهٔ ۱۲ ساعته به آبجکتهای نیمساعته تقسیم میشه و هر ابطال یه رکورد باینری ۱۶ بایتیه که principal و timestamp رو نگه میداره؛ آرایههای مرتب جستوجوی مستقیم تو حافظه رو ممکن میکنن و همین ۸۷.۵ درصد از حجم کش کم کرده.
گیتویها با conditional GET فقط چانکهای تغییرکرده رو دانلود میکنن و دادهٔ قدیمیتر از ۱۲ ساعت رو دور میندازن. ورکرهای ناهمگام ابطالهای جدید رو پیدا میکنن، تو آخرین چانک ادغام و آپلودش میکنن، و conditional PUT نقش کنترل همروندی خوشبینانه رو بازی میکنه؛ انتخاب لیدر با ZooKeeper فقط تضاد رو کم میکنه و برای درستی کار لازم نیست. ورکر بیش از ۲۰۰۰ ابطال در ثانیه رو پردازش میکنه و یه چانک با یک میلیون رکورد فقط حدود ۱۶ مگابایته.
بعد از مهاجرت، دیتابیس ابطال به دو read replica برای افزونگی کم شده و سرعت دیپلوی بالا رفته؛ بار دیتابیس هم بهجای تعداد نمونههای گیتوی، با نرخ نوشتن ابطالها و ترافیک کلی سایت مقیاس میخوره. یه گیتوی هم میتونه وضعیت محلیش رو فقط با دانلود چانکهای S3 بازسازی کنه، بدون اینکه به دیتابیس نیاز داشته باشه. تو بحث ردیت یکی پیشنهاد داده بود بهجای این کار از refresh token با عمر کوتاه استفاده کنن، ولی یکی از مهندسهای کانوا جواب داده نگهداشتن دادهٔ ابطال تو حافظه توازن بهتری داره، چون رفرش مکرر توکن بار دیتابیس رو بالا میبره و دسترسپذیری رو به دیتابیس گره میزنه.
نکات کلیدی:
- دادهٔ ابطال روی S3 ذخیره میشه، نه Redis — بدون اضافه شدن یه دیتاستور جدید
- رکوردهای باینری ۱۶ بایتی و آرایههای مرتب، ۸۷.۵ درصد از حجم کش کم کردن
- پنجرهٔ ۱۲ ساعته تو چانکهای ۳۰ دقیقهای، با conditional GET برای خوندن و conditional PUT برای نوشتن
- گیتوی وضعیتش رو مستقیم از S3 بازسازی میکنه و به دیتابیس وابسته نیست
- دیتابیس ابطال به دو read replica کاهش پیدا کرده و بار دیتابیس قابلپیشبینیتر شده
