Session Tracked Services
خب یه سری وقت ها پیش میاد که سرویس های ما Stateful هستن مثل همون مثال sessionی که در مطلب قبلی گفتم

یه دلیل رایج دیگه هم وجود داره برای اینکه سرویس های ما stateful باشن: اونم چیزی نیست جز cache
خیلی از سرویس ها برای اینکه لود کمتری روی سرویس های پایین دست (downstream) مثل دیتابیس بندازن از cache برای پاسخگویی استفاده میکنن. به این صورت که اگه درخواستی برای بار اول به اون سرویس بیاد دیتارو از سرویس های پایین دست مثلا دیتابیس میگیرن و علاوه بر اینکه درخواست کاربر رو پاسخ میدن، یک نسخه از اون دیتا رو در حافظه خودشن یا دیتابیس وابسته به خودشون مثل Redis ذخیره میکنن تا اگه درخواست مشابهی اومد نیاز نباشه دوباره دیتارو از دیتابیس بخونن، اینطوری هم لود overall سیستم کمتر میشه هم response time خیلی پایین میاد.

خب مشکل اینجاست که وقتی ما از cache استفاده میکنیم، اگه بخوایم واقعا بصورت بهینه از کارایی cache بهره مند بشیم، باید سعی کنیم درخواست های مشابه رو همیشه به یه سری node مشخص بفرستیم نه اینکه بصورت تصادفی هر درخواست رو به یه node بفرستیم. در واقع تو این حالت سرویس ما stateful شده و دیگه به راحتی حالت stateless نیست که load balancer هر طور دلش بخواد درخواست هارو تقسیم بکنه بین node ها

عموما load balancer ها برای حل کردن قضیه stateful service ها از یه سری hash function استفاده میکنن. البته اگه بخوایم بهترین و بهینه ترین الگوریتم های hashing رو استفاده کنیم باید از consistent hashing استفاده کنیم. مثلا از ip مبدا و مقصد برای وروی تابع هش استفاده میکنن و خروجی hash که همیشه ثابته به عنوان کلیدی برای مشخص کردن nodeی که باید پاسخگو باشه استفاده میشه.

در مورد consistent hashing جلوتر با بررسی الگوی sharded صحبت میکنیم

#designing_distributed_systems_brendan_burns

@gocasts