Sharded Caching

به عنوان یه sharded caching system رو در نظر بگیرید، وقتی میخوایم چنین سیستمی رو طراحی کنیم، سوالات مختلفی به ذهن میاد، از جمله:

- Why You Might Need a Sharded Cache
تصور کنید کل دیتای قابل کش شدن ۲۰۰ گیگ باشه، و شما ۱۰ سرویس replica داشته باشید که هر کدوم قابلیت ذخیره سازی ۱۰ گیگ دیتارو داشته باشه، ازونجایی که در مدل replica احتمال مشابه بودن دیتا در replica های مختلف خیلی زیاده، عملا شما در لحظه ۵ درصد (۱۰ گیگ از ۲۰۰ گیگ) رو دارید کش میکنید و خب این خیلی عملکرد بدیه

اما حالا تصور کنید که همون ۱۰ تا نود جای این که replicated باشن بصورت sharded باشن و هر کدوم ۱۰ گیگ دیتای متفاوت از دیگری رو کش کنن، اینطوری تقریبا ۵۰ درصد دیتای شما (۱۰۰ گیگ از ۲۰۰ گیگ) رو دارید کش میکنید که خیلی خوبه


- The Role of the Cache in Your Architecture (System Performance)
سیستم کش در سه معیار performance, reliability و stability برنامه شما بسیار تاثیرگذاره

یک معیار مهم برای ارزیابی عملکرد سیستم کش میزان hit rate هست که بالاتر بهش اشاره کردیم. تصور کنید سیستم شما قابلیت پاسخگویی به ۱۰۰۰ درخواست در ثانیه رو داشته باشه و بیشتر از اون خطای ۵۰۰ به کاربر نشون داده بشه، با اضافه کردن یه سیستم کش با hit rate نزدیک به ۵۰ درصد، شما میتونید ۲۰۰۰ درخواست رو در ثانیه پاسخ بدید، پس میتونید ببینید سیستم کش چه نقشی میتونه در performance سیستم شما داشته باشه

اما فقط بحث تعداد درخواست های موفق و ناموفق نیست، یه نکته دیگه ای که خیلی در تجربه کاربری تاثیر داره بحث latency هست، عموما سیستم های کش بسیار سریع تر از برنامه شما به درخواست های ورودی پاسخ میدن که همین امر باعث میشه میانگین latency سیستم شما خیلی کمتر بشه


#designing_distributed_systems_brendan_burns

@gocasts