سوالات مصاحبه کش توزیع‌شده و CDN سطح سینیور (50 سوال)

Question 1

«probabilistic early expiration» (الگوریتم XFetch) چگونه stampede را بدون lock کاهش می‌دهد؟

Accepted Answer

هر reader با احتمالی که با نزدیک شدن به انقضا و هزینه recompute بیشتر می‌شود، زودتر refresh می‌کند

Answer

هر reader به‌صورت تصادفی TTL کلید را کم یا زیاد می‌کند تا انقضاها پخش شوند

Answer

فقط readerی که hash شناسه‌اش کوچک‌ترین است اجازه recompute دارد

Answer

هر reader با احتمال ثابت 1٪ در هر درخواست cache را کاملاً bypass می‌کند

Question 2

در مقاله Facebook درباره memcache، «lease» دو مشکل را همزمان حل می‌کند. کدام دو؟

Accepted Answer

stale set (نوشتن مقدار قدیمی پس از delete) و thundering herd روی یک کلید

Answer

hot key روی یک shard و نابرابری توزیع در حلقه hash

Answer

از دست رفتن داده هنگام failover و split brain بین replicaها

Answer

big keyها و هزینه serialize کردن objectها

Question 3

سرویسی پس از write روی primary کلید cache را delete می‌کند، اما در miss از read replica با lag چند صد میلی‌ثانیه‌ای می‌خواند. نتیجه چیست و راه‌حل مناسب کدام است؟

Accepted Answer

miss بعدی مقدار قدیمی را از replica خوانده و تا TTL دوباره cache می‌کند؛ invalidation را پس از اعمال روی replica (مثلاً از CDC replica) انجام دهید یا miss را از primary بخوانید

Answer

هیچ مشکلی نیست چون delete کلید تضمین می‌کند read بعدی مقدار جدید را ببیند

Answer

replica به‌طور خودکار درخواست را به primary forward می‌کند چون کلید در cache نیست

Answer

cache مقدار جدید را از binlog primary می‌خواند و replica را نادیده می‌گیرد

Question 4

محدودیت اصلی الگوی «delayed double delete» (delete، write، sleep، delete مجدد) چیست؟

Accepted Answer

انتخاب delay حدسی است؛ اگر read کند یا lag replica از آن بیشتر شود، باز هم stale set رخ می‌دهد

Answer

delete دوم همیشه باعث از دست رفتن write اصلی در DB می‌شود

Answer

این الگو فقط در cacheهای in-process کار می‌کند و در Redis قابل استفاده نیست

Answer

delete دوم باعث می‌شود TTL همه کلیدهای دیگر reset شود

Question 5

برای جلوگیری از نوشته شدن مقدار قدیمی روی مقدار جدیدتر در cache، کدام رویکرد مستحکم‌تر است؟

Accepted Answer

ذخیره version (مثلاً شماره ردیف یا LSN) کنار مقدار و set اتمیک فقط در صورت بزرگ‌تر بودن version با یک اسکریپت Lua

Answer

استفاده از `SET` با `NX` تا کلید فقط وقتی وجود ندارد نوشته شود

Answer

کاهش TTL همه کلیدها به یک ثانیه تا stale ماندن کوتاه باشد

Answer

قرار دادن یک `sleep` تصادفی قبل از هر set تا raceها نادر شوند

Question 6

چرا invalidate کردن cache داخل تراکنش DB (قبل از commit) خطرناک است؟

Accepted Answer

readerها بین delete و commit مقدار قدیمی را از DB خوانده و دوباره cache می‌کنند، و rollback هم invalidation را برنمی‌گرداند

Answer

چون DB در حین تراکنش اجازه هیچ ارتباط شبکه‌ای با cache را نمی‌دهد

Answer

چون delete در cache باعث قفل شدن ردیف در DB و deadlock می‌شود

Answer

چون invalidation قبل از commit باعث می‌شود تراکنش DB همیشه abort شود

Question 7

در یک سیستم فروش بلیت با تقاضای انفجاری، موجودی صندلی‌ها در cache نگه داشته می‌شود. طراحی صحیح کدام است؟

Accepted Answer

cache فقط به‌عنوان hint برای نمایش استفاده شود و رزرو نهایی با conditional write یا تراکنش روی منبع حقیقت انجام شود

Answer

رزرو مستقیماً با کاهش موجودی در cache انجام شود و DB هر ساعت با cache همگام شود

Answer

TTL موجودی به صفر برسد تا cache همیشه دقیق باشد

Answer

از write-behind استفاده شود تا رزروها سریع‌تر به DB برسند

Question 8

چرا Facebook هنگام خرابی یک نود memcache به‌جای rehash کلیدهایش روی نودهای باقی‌مانده، از یک «gutter pool» کوچک استفاده می‌کرد؟

Accepted Answer

rehash می‌تواند یک کلید داغ را روی نود سالم بفرستد و خرابی آبشاری ایجاد کند؛ gutter با TTL کوتاه بار را ایزوله می‌کند

Answer

چون rehash در consistent hashing از نظر ریاضی ممکن نیست

Answer

چون gutter pool داده‌ها را روی دیسک نگه می‌دارد و هرگز از دست نمی‌دهد

Answer

چون gutter pool از strong consistency پشتیبانی می‌کند ولی نودهای عادی نه

Question 9

پس از restart کلاستر cache، DB زیر بار miss از کار می‌افتد و حتی پس از برگشتن هم timeoutها و retryها اجازه پر شدن cache را نمی‌دهند. این وضعیت چه نام دارد و راه خروج چیست؟

Accepted Answer

metastable failure؛ با load shedding، محدود کردن concurrency به DB و warm کردن تدریجی cache قبل از برگرداندن ترافیک کامل

Answer

split brain؛ با انتخاب مجدد leader در کلاستر cache و restart مجدد DB

Answer

cache pollution؛ با تغییر eviction policy به LFU و افزایش حافظه

Answer

hot key؛ با کپی کردن کلیدهای داغ روی چند shard

Question 10

DB شما فقط 10٪ ترافیک خواندن را بدون cache تحمل می‌کند. وقتی کل distributed cache از دسترس خارج شود، رفتار درست سرویس چیست؟

Accepted Answer

با circuit breaker و rate limit فقط بخشی از درخواست‌ها را به DB بفرستد و بقیه را degrade کند (پاسخ پیش‌فرض، stale یا خطای سریع)

Answer

همه درخواست‌ها را مستقیماً به DB بفرستد چون صحت داده از availability مهم‌تر است

Answer

همه درخواست‌ها را تا برگشتن cache در صف نگه دارد

Answer

به‌طور خودکار یک cache جدید راه‌اندازی کند و تا warm شدن کامل آن صبر کند

Question 11

در failover ترافیک از region A به region B، cache در B فقط برای ترافیک محلی گرم است. کدام استراتژی ریسک overload را بیشتر کاهش می‌دهد؟

Accepted Answer

انتقال تدریجی ترافیک با وزن‌دهی، به همراه گرم نگه داشتن B با replay یا shadow بخشی از ترافیک A در حالت عادی

Answer

انتقال آنی 100٪ ترافیک به B و افزایش TTL همه کلیدهای B

Answer

flush کردن cache در B قبل از failover تا داده‌های قدیمی حذف شوند

Answer

خاموش کردن cache در B و سرو مستقیم همه درخواست‌ها از DB

Question 12

در معماری با یک DB primary در یک region و replica و cache محلی در regionهای دیگر، invalidation cacheهای remote چگونه باید انجام شود؟

Accepted Answer

هر region از stream تغییرات replica محلی خودش invalidate کند تا delete پس از رسیدن داده جدید به آن region رخ دهد

Answer

سرویس writer بلافاصله پس از commit همه cacheهای جهان را مستقیماً invalidate کند

Answer

cacheهای remote هرگز invalidate نشوند و فقط به TTL تکیه شود

Answer

همه regionها از یک cache مرکزی مشترک در region primary بخوانند

Question 13

کاربری در region غیر primary داده‌ای را write می‌کند (که به primary می‌رود) و بلافاصله آن را می‌خواند. Facebook برای read-your-writes در این حالت از «remote marker» استفاده کرد. این مکانیزم چیست؟

Accepted Answer

یک marker در cache محلی که نشان می‌دهد replica محلی برای این کلید عقب است، پس miss باید از primary خوانده شود تا replication برسد

Answer

یک header در پاسخ HTTP که به مرورگر می‌گوید صفحه را refresh کند

Answer

یک lock توزیع‌شده که writeهای همزمان روی یک کلید را در همه regionها سریالی می‌کند

Answer

کپی کردن داده نوشته‌شده در cache همه regionها قبل از commit در primary

Question 14

در یک سیستم active-active چند region، پیام‌های invalidation از طریق یک queue بین regionها پخش می‌شوند و ممکن است خارج از ترتیب برسند. چه طراحی‌ای cache را صحیح نگه می‌دارد؟

Accepted Answer

invalidation idempotent (delete نه set) یا set همراه version/timestamp منطقی تا پیام قدیمی‌تر مقدار جدیدتر را بازنویسی نکند

Answer

استفاده از یک queue با تحویل exactly-once که ترتیب جهانی را تضمین کند

Answer

همگام کردن ساعت همه سرورها با NTP و مقایسه wall-clock

Answer

ارسال هر invalidation سه بار تا حداقل یکی درست برسد

Question 15

چرا معمولاً یک کلاستر Redis مشترک بین چند region (مثلاً با سرورهای اپ در اروپا و آمریکا) طراحی بدی است؟

Accepted Answer

یک region روی هر hit حدود 80–100ms latency بین قاره‌ای می‌پردازد و قطعی لینک بین regionها cache را برای آن region از بین می‌برد

Answer

Redis اجازه اتصال کلاینت‌هایی با timezone متفاوت را نمی‌دهد

Answer

Redis در فواصل دور داده‌ها را خراب می‌کند

Answer

یک کلاستر مشترک hit ratio را همیشه پایین‌تر از cacheهای محلی می‌کند

Question 16

تیمی feature flagها و موجودی انبار را در Cloudflare Workers KV نگه می‌دارد. چه نکته‌ای را نادیده گرفته است؟

Accepted Answer

KV برای خواندن زیاد بهینه است و eventually consistent است (انتشار تا حدود یک دقیقه)، پس برای موجودی که نیاز به consistency دارد مناسب نیست

Answer

KV فقط مقادیر رشته‌ای کمتر از 100 بایت را پشتیبانی می‌کند

Answer

KV داده را فقط در یک PoP نگه می‌دارد و در بقیه جاها در دسترس نیست

Answer

KV هر خواندن را به origin forward می‌کند و latency را افزایش می‌دهد

Question 17

تیمی رندر SSR صفحه را به edge منتقل می‌کند، اما هر رندر 5 query ترتیبی به DB در یک region دارد. نتیجه محتمل چیست؟

Accepted Answer

latency بدتر می‌شود چون به‌جای یک round-trip دور، 5 round-trip دور از edge به DB انجام می‌شود

Answer

latency تقریباً صفر می‌شود چون کد نزدیک کاربر اجرا می‌شود

Answer

DB به‌طور خودکار به edge کپی می‌شود و queryها محلی می‌شوند

Answer

هیچ تفاوتی نمی‌کند چون شبکه CDN همه چیز را cache می‌کند

Question 18

origin از header `X-Forwarded-Host` برای ساخت URL اسکریپت‌ها در HTML استفاده می‌کند و CDN این header را در cache key ندارد. چه حمله‌ای ممکن است؟

Accepted Answer

web cache poisoning؛ مهاجم با header دست‌کاری‌شده پاسخی با اسکریپت مخرب در cache می‌نشاند که به همه کاربران سرو می‌شود

Answer

web cache deception؛ مهاجم صفحه شخصی قربانی را با پسوند static در cache ذخیره می‌کند

Answer

DNS rebinding؛ مهاجم آدرس IP origin را به سرور خودش تغییر می‌دهد

Answer

HTTP request smuggling؛ مهاجم دو درخواست را در یک اتصال ترکیب می‌کند

Question 19

CDN همه URLهای منتهی به `.css` را cache می‌کند و framework مسیر `/account/settings/x.css` را به صفحه `/account/settings` map می‌کند. ریسک چیست؟

Accepted Answer

web cache deception؛ مهاجم قربانی را به آن URL می‌کشاند و صفحه شخصی او به‌صورت عمومی در CDN cache می‌شود

Answer

CSS injection؛ مهاجم استایل‌های صفحه تنظیمات را تغییر می‌دهد

Answer

cache poisoning؛ مهاجم با header دست‌کاری‌شده یک CSS مخرب ذخیره می‌کند

Answer

هیچ ریسکی ندارد چون صفحه تنظیمات نیاز به لاگین دارد

Question 20

purge همزمان یک tag پرکاربرد (مثلاً `homepage`) در هزاران URL باعث جهش بار origin می‌شود. «soft purge» چگونه کمک می‌کند؟

Accepted Answer

محتوا را به‌جای حذف، stale علامت می‌زند تا با `stale-while-revalidate` سرو شود و revalidation تدریجی و با coalescing انجام شود

Answer

purge را تا ساعت کم‌ترافیک بعدی به تأخیر می‌اندازد

Answer

فقط محتوای PoPهای کم‌ترافیک را purge می‌کند

Answer

TTL محتوا را به نصف کاهش می‌دهد به‌جای حذف آن

Question 21

CMS پس از ذخیره مقاله فوراً CDN را purge می‌کند، اما origin مقاله را از read replica با lag می‌خواند. چه اتفاقی می‌افتد؟

Accepted Answer

درخواست بعد از purge نسخه قدیمی را از replica گرفته و با TTL کامل دوباره در CDN cache می‌کند

Answer

CDN درخواست را تا همگام شدن replica نگه می‌دارد

Answer

purge به‌طور خودکار replica را مجبور به همگام‌سازی فوری می‌کند

Answer

نسخه جدید نمایش داده می‌شود چون purge مستقیماً از primary می‌خواند

Question 22

یک پاسخ در Redis با TTL 5 دقیقه، سپس در CDN با `s-maxage=600` و در مرورگر با `max-age=300` cache می‌شود. بدترین staleness ممکن برای کاربر چقدر است و چرا؟

Accepted Answer

حدود 20 دقیقه، چون هر لایه ممکن است نسخه‌ای را درست قبل از انقضای لایه پایینی گرفته باشد و TTLها جمع می‌شوند

Answer

حداکثر 10 دقیقه، چون بزرگ‌ترین TTL در زنجیره تعیین‌کننده است

Answer

حداکثر 5 دقیقه، چون کوتاه‌ترین TTL روی همه لایه‌ها اعمال می‌شود

Answer

صفر، چون هر لایه قبل از سرو با لایه پایینی revalidate می‌کند

Question 23

در Varnish با request coalescing فعال، یک URL پرترافیک گاهی پاسخ غیرقابل cache (مثلاً با `Set-Cookie`) برمی‌گرداند و درخواست‌ها پشت سر هم صف می‌شوند. مفهوم «hit-for-pass/hit-for-miss» چه می‌کند؟

Accepted Answer

تصمیم «این را cache نکن» را برای مدتی cache می‌کند تا درخواست‌های بعدی بدون انتظار در صف موازی به backend بروند

Answer

پاسخ غیرقابل cache را به‌زور با TTL کوتاه برای همه کاربران cache می‌کند

Answer

header `Set-Cookie` را حذف کرده و پاسخ را قابل cache می‌کند

Answer

coalescing را برای کل سرور به‌طور دائمی غیرفعال می‌کند

Question 24

صفحه اصلی یک سایت خبری 20K درخواست در ثانیه دارد و محتوایش هر چند ثانیه تغییر می‌کند. «micro-caching» با TTL یک ثانیه چه اثری دارد؟

Accepted Answer

بار origin از 20K به حدود یک درخواست در ثانیه به‌ازای هر نود cache می‌رسد، با حداکثر یک ثانیه staleness

Answer

تقریباً هیچ اثری ندارد چون یک ثانیه برای cache کردن بسیار کوتاه است

Answer

بار origin نصف می‌شود چون نیمی از درخواست‌ها hit می‌شوند

Answer

staleness به چند دقیقه می‌رسد چون TTLها روی هم جمع می‌شوند

Question 25

آیا CDN باید پاسخ‌های `500` origin را cache کند؟ بهترین سیاست کدام است؟

Accepted Answer

معمولاً خیر، مگر با TTL بسیار کوتاه برای محافظت از origin تحت فشار، و ترجیحاً سرو نسخه stale سالم با `stale-if-error`

Answer

بله، با TTL طولانی تا origin هنگام خطا هرگز دوباره درگیر نشود

Answer

هرگز؛ cache کردن هر پاسخ غیر از `200` توسط مشخصات HTTP ممنوع است

Answer

بله، اما فقط در مرورگر و نه در CDN

Question 26

یک ویدیو و صفحه آن در لحظه شروع یک رویداد زنده برای میلیون‌ها کاربر همزمان منتشر می‌شود. کدام ترکیب، origin را بهتر محافظت می‌کند؟

Accepted Answer

pre-warm کردن assetها در shield و PoPهای اصلی قبل از انتشار، origin shield، و request collapsing در همه tierها

Answer

افزایش TTL همه فایل‌ها به یک سال درست در لحظه انتشار

Answer

غیرفعال کردن CDN و سرو مستقیم از origin برای جلوگیری از stale شدن

Answer

افزودن `Vary: Cookie` تا هر کاربر نسخه جداگانه بگیرد

Question 27

برای پخش زنده HLS از طریق CDN، سیاست cache درست برای manifest (`.m3u8`) و segmentها (`.ts`) کدام است؟

Accepted Answer

segmentها immutable با TTL طولانی؛ manifest با TTL خیلی کوتاه (حدود نصف مدت segment) به همراه coalescing

Answer

هر دو با TTL طولانی چون محتوای ویدیو تغییر نمی‌کند

Answer

هر دو `no-store` چون پخش زنده نباید cache شود

Answer

manifest با TTL طولانی و segmentها با TTL خیلی کوتاه

Question 28

کاربران فایل‌های 4GB را با range request و seek دانلود می‌کنند. چرا CDNها از «slice/chunked caching» استفاده می‌کنند؟

Accepted Answer

فایل به بخش‌های مثلاً 1MB تقسیم و جدا cache می‌شود تا یک range کوچک نیازمند دریافت کل 4GB از origin نباشد

Answer

تا فایل‌های بزرگ به‌جای CDN مستقیماً از origin سرو شوند

Answer

تا هر range request با یک cache key کاملاً جدید و مستقل ذخیره شود

Answer

تا حجم فایل با فشرده‌سازی هر بخش به نصف برسد

Question 29

«consistent hashing with bounded loads» (به کار رفته در Vimeo و Google) چه مشکلی از consistent hashing کلاسیک را حل می‌کند؟

Accepted Answer

سقفی مثل `(1+ε)` برابر میانگین بار برای هر نود می‌گذارد و کلیدهای اضافه را به نود بعدی حلقه سرریز می‌کند

Answer

نیاز به virtual nodes را با استفاده از دو تابع hash مستقل حذف می‌کند

Answer

تضمین می‌کند هیچ کلیدی هنگام اضافه شدن نود جابه‌جا نشود

Answer

داده‌ها را روی همه نودها replicate می‌کند تا load یکنواخت شود

Question 30

rendezvous hashing (HRW) در مقایسه با حلقه consistent hashing چه ویژگی‌ای دارد؟

Accepted Answer

برای هر کلید، امتیاز `hash(key, node)` همه نودها محاسبه و بیشینه انتخاب می‌شود؛ بدون vnode توزیع یکنواخت دارد ولی lookup آن `O(n)` است

Answer

هر کلید را به نودی می‌فرستد که کمترین latency شبکه را دارد

Answer

برای اضافه کردن نود باید همه کلیدها دوباره توزیع شوند

Answer

فقط با تعداد نود توانی از 2 کار می‌کند

Question 31

Jump consistent hash گوگل حافظه صفر و توزیع عالی دارد. محدودیت اصلی آن برای یک کلاستر cache چیست؟

Accepted Answer

bucketها فقط از انتها اضافه یا حذف می‌شوند، پس خارج کردن یک نود دلخواه از وسط بدون remap گسترده ممکن نیست

Answer

فقط برای کلیدهای عددی کار می‌کند و رشته‌ها را پشتیبانی نمی‌کند

Answer

با اضافه شدن هر نود، همه کلیدها جابه‌جا می‌شوند

Answer

نیاز به یک coordinator مرکزی برای نگه‌داری نقشه کلیدها دارد

Question 32

در یک cache توزیع‌شده با consistent hashing و vnodes، replicaهای هر کلید روی N نود بعدی حلقه قرار می‌گیرند. چه نکته‌ای ضروری است؟

Accepted Answer

هنگام پیمایش حلقه، vnodeهای همان ماشین فیزیکی (و ترجیحاً همان rack/zone) رد شوند تا replicaها واقعاً مستقل باشند

Answer

همه replicaها باید روی یک ماشین باشند تا latency کم شود

Answer

تعداد replica باید برابر تعداد vnodeهای هر نود باشد

Answer

replicaها باید با یک تابع hash متفاوت از کلید اصلی جای‌گذاری شوند

Question 33

در حین resharding در Redis Cluster، تفاوت پاسخ `ASK` با `MOVED` چیست؟

Accepted Answer

`MOVED` یعنی slot به‌طور دائمی منتقل شده و client باید نقشه را آپدیت کند؛ `ASK` یعنی فقط همین درخواست را به نود مقصد (با `ASKING`) بفرست

Answer

`ASK` یعنی نود از کار افتاده و `MOVED` یعنی کلید حذف شده است

Answer

هر دو یکسان هستند و client باید در هر دو حالت نقشه slotها را آپدیت کند

Answer

`MOVED` فقط برای writeها و `ASK` فقط برای readها ارسال می‌شود

Question 34

در Redis Sentinel، primary قدیمی پس از partition شبکه همچنان از clientهای سمت خودش write می‌پذیرد در حالی که replica ارتقا یافته است. کدام تنظیم پنجره از دست رفتن write را محدود می‌کند؟

Accepted Answer

`min-replicas-to-write` به همراه `min-replicas-max-lag` تا primary بدون replica سالم writeها را رد کند

Answer

`maxmemory-policy noeviction` تا هیچ داده‌ای حذف نشود

Answer

`appendfsync always` تا هر write روی دیسک نوشته شود

Answer

افزایش تعداد Sentinelها به عدد زوج برای رأی‌گیری دقیق‌تر

Question 35

در یک کلاستر بزرگ، یک shard به‌طور نامنظم به 100٪ CPU می‌رسد. چگونه hot keyها را به‌صورت خودکار شناسایی و مهار می‌کنید؟

Accepted Answer

نمونه‌برداری از دسترسی‌ها در client یا proxy با sketchهایی مثل Count-Min/Top-K و ارتقای خودکار کلیدهای داغ به L1 محلی یا کپی‌های چندگانه

Answer

اجرای `KEYS *` هر دقیقه روی shard و شمارش کلیدها

Answer

افزودن shardهای بیشتر تا هر بار که CPU بالا می‌رود

Answer

کاهش TTL همه کلیدهای آن shard به یک ثانیه

Question 36

کلید داغ را با suffix به 10 کپی (`key#0..key#9`) روی shardهای مختلف پخش کرده‌اید. هزینه این کار در مسیر write چیست؟

Accepted Answer

هر invalidation یا update باید به 10 کلید برسد و در این فاصله readerها ممکن است نسخه‌های ناهمسان ببینند

Answer

هیچ هزینه‌ای ندارد چون Redis کپی‌ها را به‌طور خودکار همگام می‌کند

Answer

write فقط روی کپی اول انجام می‌شود و بقیه هرگز آپدیت نمی‌شوند

Answer

تعداد shardها باید دقیقاً برابر تعداد کپی‌ها باشد وگرنه خطا رخ می‌دهد

Question 37

W-TinyLFU (در Caffeine) چرا در workloadهای واقعی معمولاً hit ratio بهتری از LRU خالص دارد؟

Accepted Answer

یک admission policy با sketch فرکانس دارد که فقط وقتی کلید جدید از قربانی محبوب‌تر باشد آن را می‌پذیرد، به‌علاوه یک پنجره LRU کوچک برای burstها

Answer

همه کلیدها را بدون محدودیت می‌پذیرد و فقط بزرگ‌ترین‌ها را evict می‌کند

Answer

از TTL به‌جای eviction استفاده می‌کند و حافظه هرگز پر نمی‌شود

Answer

داده‌ها را به‌طور خودکار بین چند ماشین shard می‌کند

Question 38

چرا Redis به‌جای LRU دقیق از LRU تقریبی (نمونه‌برداری با `maxmemory-samples`) استفاده می‌کند؟

Accepted Answer

LRU دقیق به لیست پیوندی با اشاره‌گرهای اضافه برای هر کلید و به‌روزرسانی آن در هر دسترسی نیاز دارد؛ نمونه‌برداری با حافظه و CPU کمتر نتیجه نزدیکی می‌دهد

Answer

چون LRU دقیق از نظر ریاضی برای بیش از یک میلیون کلید تعریف نشده است

Answer

چون LRU تقریبی همیشه hit ratio بالاتری از LRU دقیق دارد

Answer

چون Redis زمان دسترسی کلیدها را اصلاً ذخیره نمی‌کند

Question 39

مصرف حافظه Redis بالاست در حالی که بیشتر کلیدها منقضی شده‌اند و خوانده نمی‌شوند. چرا؟

Accepted Answer

حذف کلیدهای منقضی lazy (هنگام دسترسی) و با نمونه‌برداری فعال دوره‌ای است، پس کلیدهای منقضی دست‌نخورده می‌توانند مدتی حافظه بگیرند

Answer

Redis کلیدهای منقضی را هرگز حذف نمی‌کند مگر با `FLUSHALL`

Answer

TTL فقط روی replicaها اعمال می‌شود نه روی primary

Answer

کلیدهای منقضی به دیسک منتقل می‌شوند و در آمار حافظه شمرده می‌شوند

Question 40

مدیر از شما می‌پرسد آیا دو برابر کردن حافظه cache ارزشش را دارد. بهترین روش داده‌محور برای پاسخ چیست؟

Accepted Answer

ساخت miss ratio curve از trace واقعی دسترسی‌ها (مثلاً با شبیه‌سازی یا SHARDS) و مقایسه کاهش miss با هزینه حافظه و بار DB

Answer

دو برابر کردن حافظه همیشه miss ratio را نصف می‌کند، پس همیشه ارزش دارد

Answer

بررسی میانگین مصرف CPU سرورهای cache در هفته گذشته

Answer

شمارش تعداد کلیدهای فعلی و ضرب آن در دو

Question 41

چند سرویس از یک کلاستر Redis مشترک استفاده می‌کنند و یک batch job شبانه با میلیون‌ها کلید یک‌بارمصرف hit ratio بقیه را نابود می‌کند. بهترین اصلاح ساختاری چیست؟

Accepted Answer

جداسازی workloadها در کلاسترها یا pool‌های جدا با سهمیه حافظه، یا عدم cache کردن داده‌های یک‌بارمصرف batch

Answer

افزایش TTL کلیدهای سرویس‌های دیگر تا کمتر evict شوند

Answer

اجرای `FLUSHALL` بعد از اتمام batch job هر شب

Answer

تغییر eviction به `volatile-ttl` تا کلیدهای batch زودتر حذف شوند

Question 42

یک درخواست برای رندر feed به 100 shard cache به‌صورت موازی fan-out می‌کند. p99 هر shard 2ms است ولی p99 کل درخواست 30ms است. علت و راهکار چیست؟

Accepted Answer

با fan-out بالا تقریباً همیشه یک shard کند وجود دارد و p99 کل به tail shardها گره می‌خورد؛ کاهش fan-out با هم‌مکان‌سازی داده یا hedged request کمک می‌کند

Answer

latency شبکه بین shardها جمع می‌شود چون درخواست‌ها ترتیبی هستند

Answer

Redis درخواست‌های موازی از یک client را سریالی می‌کند

Answer

hit ratio پایین است و باید TTLها را افزایش داد

Question 43

تیمی برای ثبت لایک‌ها با 50K write در ثانیه از write-behind روی Redis استفاده می‌کند. کدام طراحی durability و صحت را بهتر حفظ می‌کند؟

Accepted Answer

ثبت رویدادها در یک log پایدار مثل Kafka یا Redis Stream با replication و consumerهای idempotent که دسته‌ای و با کلید یکتا در DB upsert کنند

Answer

نگه‌داشتن شمارنده‌ها فقط در حافظه Redis و flush هر ساعت با `KEYS *`

Answer

نوشتن مستقیم هر لایک در DB و حذف کامل لایه cache

Answer

flush کردن شمارنده‌ها از Redis به DB با `INCR` بدون ثبت آفست یا شناسه

Question 44

طبق GDPR باید داده کاربر ظرف مهلت مشخص حذف شود. نقش لایه‌های cache در این طراحی چیست؟

Accepted Answer

همه لایه‌ها (L1، Redis، CDN، search index) باید purge شوند یا TTL آن‌ها کمتر از مهلت قانونی باشد، و داده شخصی نباید در cacheهای غیرقابل purge مثل مرورگر بماند

Answer

cacheها نیازی به حذف ندارند چون فقط کپی موقت هستند و منبع حقیقت محسوب نمی‌شوند

Answer

کافی است ردیف کاربر در DB حذف شود؛ cacheها خودبه‌خود به‌روز می‌شوند

Answer

باید کل cache را در هر درخواست حذف یک بار flush کرد

Question 45

داشبوردی aggregateهای سنگینی دارد که محاسبه هر کدام 8 ثانیه طول می‌کشد و الگوی دسترسی پراکنده است، پس cache-aside مدام miss می‌شود. کدام رویکرد مناسب‌تر است؟

Accepted Answer

پیش‌محاسبه (materialized view یا جدول aggregate به‌روزشونده با stream) و ذخیره نتیجه به‌عنوان داده اصلی، نه cache تنبل

Answer

افزایش TTL cache به یک هفته تا missها کمتر شوند

Answer

افزودن حافظه بیشتر به Redis تا همه ترکیب‌ها جا شوند

Answer

فعال کردن request coalescing تا missهای همزمان یکی شوند

Question 46

CDN یک پاسخ با `max-age=300` را 290 ثانیه پیش از origin گرفته و اکنون آن را با header `Age: 290` به مرورگر می‌دهد. مرورگر آن را چه مدت تازه در نظر می‌گیرد؟

Accepted Answer

حدود 10 ثانیه، چون عمر فعلی از `max-age` کم می‌شود

Answer

300 ثانیه کامل از لحظه دریافت توسط مرورگر

Answer

590 ثانیه، چون `Age` به `max-age` اضافه می‌شود

Answer

صفر؛ هر پاسخ دارای `Age` باید فوراً revalidate شود

Question 47

شمارنده بازدید یک پست وایرال با `INCR` روی یک کلید Redis گلوگاه شده است. کدام طراحی write را مقیاس‌پذیر می‌کند؟

Accepted Answer

شمارنده‌های sharded (`views:42:0..N`) روی slotهای مختلف یا تجمیع محلی در هر instance و flush دوره‌ای؛ read با جمع زدن shardها

Answer

تبدیل `INCR` به `GET` و `SET` جداگانه برای کاهش قفل

Answer

افزایش TTL کلید شمارنده تا کمتر منقضی شود

Answer

اضافه کردن replica تا writeها بین آن‌ها پخش شوند

Question 48

معماری شما CDN جلوی origin دارد و origin هم پاسخ‌ها را در Redis cache می‌کند. پس از تغییر داده، invalidation به چه ترتیبی باید انجام شود؟

Accepted Answer

از داخل به بیرون: ابتدا Redis، سپس CDN، تا CDN در refetch نسخه قدیمی را از Redis نگیرد

Answer

از بیرون به داخل: ابتدا CDN، سپس Redis، چون CDN به کاربران نزدیک‌تر است

Answer

ترتیب اهمیتی ندارد چون هر دو در نهایت منقضی می‌شوند

Answer

فقط CDN purge شود؛ Redis با هر purge CDN خودبه‌خود خالی می‌شود

Question 49

برای مقابله با cache penetration یک Bloom filter از IDهای موجود جلوی cache قرار داده‌اید. کدام مشکل عملیاتی را باید طراحی کنید؟

Accepted Answer

آیتم جدید باید قبل از قابل‌مشاهده شدن به filter اضافه شود، و چون حذف ممکن نیست filter با گذشت زمان پر از false positive شده و باید دوره‌ای rebuild شود

Answer

Bloom filter گاهی false negative می‌دهد و آیتم‌های موجود را رد می‌کند، پس باید همیشه DB را هم چک کرد

Answer

Bloom filter باید کل objectها را نگه دارد، پس حافظه‌اش با cache برابر است

Answer

Bloom filter فقط با کلیدهای عددی پیوسته کار می‌کند

Question 50

سایتی با `Vary: Cookie` برای A/B testing صفحه اصلی، hit ratio نزدیک صفر در CDN دارد. طراحی بهتر کدام است؟

Accepted Answer

edge کاربر را به bucket تخصیص دهد، یک header مشتق مثل `X-Variant: B` بسازد و cache key فقط بر اساس آن variant باشد

Answer

حذف `Vary` و سرو تصادفی یکی از variantها از cache به همه کاربران

Answer

قرار دادن کل cookie در query string تا CDN آن را در key بگذارد

Answer

غیرفعال کردن CDN برای صفحه اصلی در طول آزمایش