سوالات مصاحبه Replication و Sharding سطح سینیور (50 سوال)

Question 1

leader با lease ده‌ثانیه‌ای کار می‌کند. یک GC pause پانزده‌ثانیه‌ای رخ می‌دهد و leader جدید انتخاب می‌شود، اما leader قدیمی بعد از pause نوشتنش را ادامه می‌دهد. محکم‌ترین دفاع چیست؟

Accepted Answer

fencing token صعودی (epoch) که storage با آن نوشتن‌های token قدیمی‌تر را رد کند

Answer

بررسی اعتبار lease توسط خود leader درست قبل از هر نوشتن

Answer

کوتاه‌تر کردن lease به یک ثانیه تا pause کمتر اثر داشته باشد

Answer

هم‌گام کردن دقیق ساعت همه nodeها با NTP

Question 2

با N=3، W=2، R=2، نوشتنی در حال اجراست و فقط به یک replica رسیده است. دو خواننده پشت سر هم می‌خوانند. چه اتفاقی ممکن است بیفتد؟

Accepted Answer

خواننده اول مقدار جدید و خواننده دوم مقدار قدیمی را ببیند

Answer

شرط W+R>N تضمین می‌کند هر دو مقدار جدید را ببینند

Answer

هر دو خواننده تا کامل شدن نوشتن block می‌شوند

Answer

هر دو خواننده خطای conflict دریافت می‌کنند

Question 3

در یک store سبک Dynamo با version vector، چرا کلاینت باید context نسخه‌ای را که خوانده همراه نوشتن بعدی بفرستد؟

Accepted Answer

تا سرور بداند این نوشتن کدام siblingها را جایگزین می‌کند و کدام هم‌زمان‌اند

Answer

تا سرور بتواند timestamp دقیق نوشتن را محاسبه کند

Answer

تا نوشتن به‌طور خودکار به leader آن key route شود

Answer

تا نیاز به tombstone برای حذف‌ها از بین برود

Question 4

برای شمارنده «لایک» در یک سیستم active-active چند region، چرا G-Counter (یک شمارنده برای هر replica) به LWW روی یک عدد ترجیح دارد؟

Accepted Answer

merge با max هر خانه و جمع کل، هیچ افزایشی را از دست نمی‌دهد

Answer

G-Counter با ساعت دقیق‌تر timestamp می‌زند و LWW را بهتر می‌کند

Answer

G-Counter نیاز به replication بین regionها را حذف می‌کند

Answer

G-Counter اجازه کم کردن مقدار را هم بدون هزینه می‌دهد

Question 5

در یک OR-Set (Observed-Remove Set)، اگر یک replica آیتمی را حذف کند و هم‌زمان replica دیگر همان آیتم را دوباره اضافه کند، نتیجه بعد از merge چیست؟

Accepted Answer

آیتم باقی می‌ماند، چون حذف فقط tagهایی را که دیده بود پاک می‌کند (add-wins)

Answer

آیتم حذف می‌شود، چون حذف همیشه بر افزودن اولویت دارد

Answer

نتیجه به timestamp بزرگ‌تر بین دو عملیات بستگی دارد

Answer

merge شکست می‌خورد و conflict به اپلیکیشن برمی‌گردد

Question 6

leader در us-east است و replicaها در EU. کاربری در EU نوشتن انجام می‌دهد و درخواست بعدی‌اش ممکن است به هر region برسد. کدام طراحی read-your-writes را با کمترین هزینه latency حفظ می‌کند؟

Accepted Answer

برگرداندن commit position به کلاینت و سرو کردن از replica محلی فقط اگر به آن رسیده باشد، وگرنه انتظار کوتاه یا رفتن به leader

Answer

خواندن همه درخواست‌های کاربر از leader در us-east برای همیشه

Answer

sticky کردن کاربر به یک replica EU بدون توجه به موقعیت log

Answer

استفاده از timestamp ساعت مرورگر برای انتخاب replica

Question 7

در resharding با dual-write و backfill، بعد از cutover متوجه می‌شوید برخی رکوردها در shard جدید مقدار قدیمی دارند. محتمل‌ترین علت و راه‌حل کدام است؟

Accepted Answer

backfill یک snapshot قدیمی را روی dual-write جدیدتر نوشته؛ باید نوشتن backfill شرطی بر اساس version باشد

Answer

replication lag روی shardهای قدیمی؛ باید replication factor را بالا برد

Answer

hash function در shard جدید متفاوت است؛ باید آن را به MD5 تغییر داد

Answer

cache اپلیکیشن invalidate نشده؛ کافی است cache را پاک کرد

Question 8

در resharding مبتنی بر CDC (مثل VReplication در Vitess)، چرا لحظه cutover معمولاً شامل یک توقف کوتاه نوشتن است؟

Accepted Answer

تا stream کاملاً تخلیه شود و مقصد دقیقاً به موقعیت مبدأ برسد، سپس routing عوض شود

Answer

تا indexهای shard جدید از نو ساخته شوند

Answer

چون CDC فقط وقتی نوشتنی وجود ندارد کار می‌کند

Answer

تا replicaهای shard قدیمی حذف شوند

Question 9

برای پیام‌های یک اپ چت (گفتگوهای دونفره و گروه‌های تا ۵۰۰۰ نفر)، کدام shard key برای جدول پیام‌ها مناسب‌تر است؟

Accepted Answer

`conversation_id`، تا خواندن تاریخچه یک گفتگو تک‌shardی و مرتب باشد

Answer

`sender_id`، تا همه پیام‌های هر فرستنده کنار هم باشند

Answer

`message_id` تصادفی، تا توزیع کاملاً یکنواخت باشد

Answer

`created_at`، تا پیام‌های جدید سریع پیدا شوند

Question 10

کاربر سفارشی ثبت می‌کند و بلافاصله صفحه «سفارش‌های من بر اساس status» را باز می‌کند که از یک global secondary index async خوانده می‌شود؛ سفارش دیده نمی‌شود. بهترین اصلاح چیست؟

Accepted Answer

ادغام نتیجه index با رکوردهای اخیر کاربر که از جدول اصلی (با partition key) خوانده می‌شوند

Answer

تبدیل همه indexها به local index تا خواندن‌ها scatter-gather شوند

Answer

افزودن تأخیر ثابت ۵ ثانیه‌ای قبل از نمایش صفحه

Answer

افزایش replication factor جدول index

Question 11

cluster با ۲۵۶ vnode برای هر node کار می‌کند، اما یک partition key که ۴۰٪ ترافیک نوشتن را دارد یک node را اشباع کرده است. چرا افزایش vnodeها کمکی نمی‌کند؟

Accepted Answer

vnodeها بازه‌های hash را پخش می‌کنند، ولی یک key همیشه به یک نقطه hash و یک replica set می‌رسد

Answer

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

Answer

تعداد vnode بیش از ۲۵۶ از نظر فنی ممکن نیست

Answer

vnodeها فقط وقتی کار می‌کنند که hash function تغییر کند

Question 12

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

Accepted Answer

با سقف ظرفیت هر node، درخواست اضافه به node بعدی حلقه می‌رود تا هیچ nodeی بیش از حد بار نگیرد

Answer

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

Answer

نیاز به vnodeها را با استفاده از دو تابع hash حذف می‌کند

Answer

تضمین می‌کند هر key روی همه nodeها replicate شود

Question 13

Jump Consistent Hash توزیع تقریباً کامل و حافظه صفر دارد. محدودیت اصلی آن برای یک cluster ذخیره‌سازی چیست؟

Accepted Answer

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

Answer

با افزودن هر bucket همه کلیدها باید جابه‌جا شوند

Answer

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

Answer

برای هر key نیاز به lookup در یک جدول مرکزی دارد

Question 14

rendezvous hashing (HRW) چگونه node هر key را انتخاب می‌کند و چه مزیتی دارد؟

Accepted Answer

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

Answer

key را روی حلقه قرار می‌دهد و اولین node ساعتگرد را انتخاب می‌کند

Answer

از یک directory مرکزی برای انتخاب node استفاده می‌کند

Answer

hash(key) mod N را محاسبه و node متناظر را انتخاب می‌کند

Question 15

CockroachDB رنج‌های داغ را بر اساس بار split می‌کند. چرا این کار برای جدولی با primary key صعودی (مثل `SERIAL`) بار نوشتن را پخش نمی‌کند؟

Accepted Answer

همه insertها همیشه به انتهای آخرین range می‌روند و range تازه split‌شده دوباره همان tail داغ است

Answer

load-based splitting فقط برای خواندن‌ها فعال است

Answer

کلید `SERIAL` در CockroachDB اصلاً قابل split نیست

Answer

split کردن range باعث از دست رفتن replicaها می‌شود

Question 16

MySQL شما با semi-sync و `rpl_semi_sync_master_timeout` ده ثانیه کار می‌کند. در یک قطعی شبکه، replica تأیید نمی‌دهد. خطر پنهان این تنظیم چیست؟

Accepted Answer

master بی‌صدا به async برمی‌گردد و failover در این بازه می‌تواند نوشتن‌های تأییدشده را از دست بدهد

Answer

master همه نوشتن‌ها را برای همیشه تا برگشت replica رد می‌کند

Answer

replica به‌طور خودکار leader می‌شود و split brain رخ می‌دهد

Answer

binlog پاک می‌شود و replica باید از صفر ساخته شود

Question 17

یک Raft group پنج replica دارد: دو تا در us-east (leader یکی از آن‌هاست)، دو تا در us-west و یکی در EU. latency commit تقریباً با چه چیزی تعیین می‌شود؟

Accepted Answer

RTT به نزدیک‌ترین replicaهایی که با leader اکثریت ۳ تایی می‌سازند (اینجا us-west)

Answer

RTT به دورترین replica یعنی EU

Answer

فقط latency دیسک خود leader

Answer

میانگین RTT به همه چهار follower

Question 18

یک cluster مبتنی بر consensus با ۳ node در DC1 و ۲ node در DC2 دارید. با از دست رفتن کامل DC1 چه می‌شود و راه‌حل استاندارد چیست؟

Accepted Answer

DC2 اکثریت ندارد و cluster نوشتن را متوقف می‌کند؛ یک site سوم (حتی فقط witness) لازم است

Answer

DC2 خودکار ادامه می‌دهد چون ۲ node برای quorum کافی است

Answer

با افزودن یک node به DC2 (یعنی ۳+۳) مشکل حل می‌شود

Answer

باید consensus را با async replication جایگزین کرد تا مشکل حل شود

Question 19

در MySQL با دو master فعال (multi-leader)، چطور از تولید ID تکراری با `AUTO_INCREMENT` جلوگیری می‌کنند و چه هزینه‌ای دارد؟

Accepted Answer

با `auto_increment_increment=2` و offset متفاوت؛ ولی افزودن master سوم نیاز به تغییر پیکربندی دارد

Answer

MySQL به‌طور خودکار conflict را تشخیص داده و ID را عوض می‌کند

Answer

با sync replication بین دو master که هیچ هزینه‌ای ندارد

Answer

با LWW روی ستون ID که رکورد قدیمی‌تر را حذف می‌کند

Question 20

سیستم active-active دو region دارد و دو کاربر هم‌زمان در دو region username یکسانی ثبت می‌کنند. درست‌ترین طراحی چیست؟

Accepted Answer

ثبت username را از یک مسیر strongly consistent (یک home leader یا consensus) عبور دهیم

Answer

هر region محلی بررسی کند و LWW بعداً یکی را نگه دارد

Answer

با CRDT set هر دو ثبت‌نام را ادغام کنیم

Answer

replication بین regionها را سریع‌تر کنیم تا پنجره conflict کوچک شود

Question 21

قانون «هر پزشک در هر شیفت حداقل یک نفر on-call باشد» داریم، ولی رکوردهای پزشکان با `doctor_id` در shardهای مختلف‌اند. دو پزشک هم‌زمان از on-call خارج می‌شوند. بهترین راه برای حفظ invariant کدام است؟

Accepted Answer

داده مرتبط با invariant را با `shift_id` هم‌مکان کنیم تا تراکنش serializable تک‌shardی شود

Answer

از read replica برای بررسی تعداد on-call قبل از نوشتن استفاده کنیم

Answer

هر shard به‌طور مستقل invariant را با snapshot isolation بررسی کند

Answer

بعد از هر تغییر یک job شبانه برای اصلاح نقض‌ها اجرا کنیم

Question 22

تیمی 2PC بین shardها را با saga جایگزین می‌کند. مهم‌ترین چیزی که از دست می‌دهند چیست؟

Accepted Answer

isolation: حالت‌های میانی برای بقیه قابل مشاهده‌اند و باید با compensation و semantic lock مدیریت شوند

Answer

durability: مراحل saga روی دیسک ذخیره نمی‌شوند

Answer

availability: saga در صورت خرابی هر shard کل سیستم را متوقف می‌کند

Answer

امکان retry: مراحل saga هرگز قابل تکرار نیستند

Question 23

هر shard در p99 ده میلی‌ثانیه پاسخ می‌دهد. یک query که به ۱۰۰ shard fan-out می‌شود چه p50 تقریبی خواهد داشت؟

Accepted Answer

حدود همان p99 هر shard، چون احتمال اینکه حداقل یک shard کند باشد حدود ۶۳٪ است

Answer

حدود p50 هر shard، چون shardها موازی اجرا می‌شوند

Answer

حدود صد برابر p50 هر shard

Answer

کمتر از p50 هر shard، چون بار بین shardها پخش شده

Question 24

API با `ORDER BY created_at LIMIT 20 OFFSET 10000` روی ۵۰ shard کند شده است. ریشه مشکل و راه‌حل کدام است؟

Accepted Answer

هر shard باید ۱۰۰۲۰ ردیف برگرداند تا merge درست باشد؛ باید از keyset (cursor) pagination استفاده کرد

Answer

indexها روی shardها خراب شده‌اند؛ باید آن‌ها را rebuild کرد

Answer

replication lag باعث کندی است؛ باید از leader خواند

Answer

LIMIT 20 خیلی کوچک است؛ باید آن را به ۱۰۰۰ رساند

Question 25

داده کاربران EU طبق قانون باید در EU بماند، ولی email باید در سطح جهانی یکتا باشد. کدام طراحی هر دو را رعایت می‌کند؟

Accepted Answer

یک index سراسری فقط با hash email و region، و نگه‌داشتن داده شخصی در region کاربر

Answer

کپی کامل جدول کاربران در همه regionها برای بررسی یکتایی

Answer

بررسی یکتایی فقط داخل هر region و پذیرش تکراری‌ها بین regionها

Answer

نگه‌داشتن همه داده‌ها در EU برای همه کاربران جهان

Question 26

follower reads در CockroachDB یا stale reads در Spanner (مثلاً `AS OF SYSTEM TIME` با چند ثانیه قبل) چطور اجازه خواندن محلی از follower را بدون نقض consistency می‌دهند؟

Accepted Answer

follower فقط در timestampی پاسخ می‌دهد که می‌داند هیچ نوشتن جدیدی زیر آن commit نمی‌شود (closed timestamp)

Answer

follower همیشه آخرین داده خودش را برمی‌گرداند و امیدوار است به‌روز باشد

Answer

هر خواندن follower ابتدا با leader یک round-trip برای تأیید انجام می‌دهد

Answer

followerها sync replication دارند پس هیچ‌وقت عقب نیستند

Question 27

leader با ۳۲ thread نوشتن هم‌زمان را می‌پذیرد، اما replica با یک thread تغییرات را اعمال می‌کند و lag مدام بیشتر می‌شود. ریشه‌ای‌ترین راه‌حل چیست؟

Accepted Answer

parallel replication بر اساس writeset یا گروه commit تا تراکنش‌های مستقل هم‌زمان اعمال شوند

Answer

افزودن read replicaهای بیشتر برای پخش بار اعمال تغییرات

Answer

تغییر replication از row-based به statement-based

Answer

افزایش timeout تشخیص خرابی روی replica

Question 28

الزام RPO=0 حتی در صورت از دست رفتن کامل یک availability zone دارید و leader در AZ-a است. کدام پیکربندی حداقلی این را برآورده می‌کند؟

Accepted Answer

تأیید sync از حداقل یک replica در AZ دیگر قبل از ack هر commit

Answer

دو replica async در AZ-b و AZ-c با lag کمتر از یک ثانیه

Answer

یک replica sync در همان AZ-a روی rack دیگر

Answer

snapshot هر پنج دقیقه در object storage چند-region

Question 29

در Cassandra یک ردیف را `DELETE` و بلافاصله از سرور اپلیکیشن دیگری `INSERT` می‌کنید، ولی ردیف دیده نمی‌شود. محتمل‌ترین علت چیست؟

Accepted Answer

ساعت سرور دوم عقب‌تر است و timestamp کوچک‌تر insert در LWW به tombstone می‌بازد

Answer

insert به‌خاطر replication lag هنوز به هیچ replicaی نرسیده است

Answer

Cassandra اجازه insert بعد از delete را روی همان key نمی‌دهد

Answer

tombstone به‌طور دائمی آن partition key را قفل کرده است

Question 30

یک node در Cassandra ۱۵ روز خاموش بوده و `gc_grace_seconds` ده روز است. بعد از برگرداندن و repair چه خطری وجود دارد؟

Accepted Answer

داده‌هایی که در این مدت حذف و tombstoneشان پاک شده، از این node به بقیه برمی‌گردند

Answer

همه داده‌های جدید ۱۵ روز گذشته از روی cluster پاک می‌شوند

Answer

node به‌طور خودکار leader همه partitionها می‌شود

Answer

repair به‌خاطر تفاوت schema شکست می‌خورد و هیچ اثری ندارد

Question 31

چرا anti-entropy در سیستم‌هایی مثل Cassandra و DynamoDB از Merkle tree استفاده می‌کند؟

Accepted Answer

با مقایسه hashهای سطوح بالا فقط بازه‌های متفاوت پیدا و منتقل می‌شوند، نه کل داده

Answer

Merkle tree داده را رمزنگاری می‌کند تا انتقال بین replicaها امن باشد

Answer

Merkle tree ترتیب علّی نوشتن‌ها را مشخص می‌کند

Answer

Merkle tree جایگزین tombstone برای حذف‌ها می‌شود

Question 32

در Cassandra با دو datacenter (RF=3 در هر کدام)، استفاده از `LOCAL_QUORUM` برای خواندن و نوشتن چه trade-offی دارد؟

Accepted Answer

latency پایین و تحمل قطعی DC دیگر، ولی کلاینت DC دیگر ممکن است داده قدیمی بخواند

Answer

consistency قوی بین دو DC ولی latency بین‌DCی روی هر عملیات

Answer

هیچ داده‌ای به DC دوم replicate نمی‌شود

Answer

خرابی یک node در DC محلی همه عملیات را متوقف می‌کند

Question 33

با `hash(key) % N`، چرا دو برابر کردن تعداد shard (N به 2N) نسبت به افزودن یک shard انتخاب بهتری است؟

Accepted Answer

هر shard دقیقاً به دو shard تقسیم می‌شود و هر key یا می‌ماند یا به shard «خواهر» مشخصی می‌رود

Answer

دو برابر کردن باعث می‌شود هیچ keyی جابه‌جا نشود

Answer

با دو برابر کردن، نیاز به تابع hash از بین می‌رود

Answer

دو برابر کردن فقط ۱۰٪ داده را جابه‌جا می‌کند

Question 34

یک ویدیوی وایرال ۵۰ هزار like در ثانیه روی یک ردیف counter دریافت می‌کند. کدام طراحی هم بار نوشتن را پخش و هم خواندن را ارزان نگه می‌دارد؟

Accepted Answer

تقسیم counter به N زیر-counter تصادفی و نگه‌داشتن مجموع cache‌شده که دوره‌ای به‌روز می‌شود

Answer

قفل بدبینانه روی ردیف counter برای جلوگیری از lost update

Answer

افزایش replication factor ردیف counter به ۱۰

Answer

انتقال ردیف counter به سریع‌ترین shard cluster

Question 35

سفارش‌ها با `region_id` shard شده‌اند و کاربر آدرس تحویل را به region دیگری تغییر می‌دهد. چه پیچیدگی‌ای ایجاد می‌شود؟

Accepted Answer

تغییر shard key یعنی انتقال ردیف بین shardها (delete + insert) که تراکنش اتمی تک‌shardی نیست

Answer

فقط یک `UPDATE` ساده کافی است و دیتابیس خودش ردیف را جابه‌جا می‌کند بدون هیچ هزینه‌ای

Answer

تغییر shard key باعث rebalancing کل cluster می‌شود

Answer

همه replicaهای shard قدیمی باید از نو ساخته شوند

Question 36

در یک cluster با ۵۰۰ shard، query «پیدا کردن کاربر با شماره تلفن» هزاران بار در ثانیه اجرا می‌شود. کدام index مناسب‌تر است و چرا؟

Accepted Answer

global index، چون هر lookup به یک partition می‌رود و هزینه async بودن نوشتن قابل قبول است

Answer

local index، چون scatter-gather روی ۵۰۰ shard برای هر lookup ارزان است

Answer

هیچ index، چون full scan موازی همیشه سریع‌تر است

Answer

local index روی leader و global index روی followerها

Question 37

می‌خواهید PostgreSQL را از نسخه ۱۲ به ۱۶ با downtime چند ثانیه‌ای ارتقا دهید. کدام روش مناسب است؟

Accepted Answer

logical replication به یک cluster نسخه ۱۶، صبر تا catch up و سپس switchover

Answer

physical streaming replication به replica نسخه ۱۶ و promote آن

Answer

`pg_dump` کامل و restore در حالی که سرویس روشن است

Answer

ارتقای درجا روی leader در ساعات اوج ترافیک

Question 38

automatic failover شما در یک ساعت چهار بار leader را عوض کرده چون شبکه بین AZها ناپایدار است. کدام اصلاح مناسب‌تر است؟

Accepted Answer

hysteresis و rate limit روی failover (مثلاً حداقل فاصله بین failoverها) و تشخیص خرابی از چند نقطه دید

Answer

کوتاه‌تر کردن timeout تا failover سریع‌تر تمام شود

Answer

غیرفعال کردن replication تا شبکه پایدار شود

Answer

افزودن replicaهای بیشتر در همان AZ leader

Question 39

برای مقابله با رشد ترافیک، در ساعات اوج سه node اضافه می‌کنید و ناگهان p99 کل cluster سه برابر می‌شود. محتمل‌ترین علت چیست؟

Accepted Answer

streaming داده برای rebalancing، دیسک و شبکه nodeهای فعلی را اشباع کرده است

Answer

nodeهای جدید نسخه متفاوتی از hash function دارند

Answer

replication factor به‌طور خودکار به ۱ کاهش یافته است

Answer

nodeهای جدید همه نوشتن‌ها را رد می‌کنند

Question 40

برای یک اپ جهانی، انتخاب بین «active-active با CRDT برای همه داده‌ها» و «هر رکورد یک home region دارد و نوشتن‌ها به آن route می‌شوند» به چه بستگی دارد؟

Accepted Answer

اینکه نوشتن‌های هم‌زمان روی یک رکورد از چند region رایج است و آیا داده با semantics قابل merge مدل می‌شود

Answer

اینکه دیتابیس از SQL یا NoSQL استفاده می‌کند

Answer

تعداد کل جدول‌های اپلیکیشن

Answer

اینکه سرورها از Linux یا Windows استفاده می‌کنند

Question 41

در یک سیستم partition‌شده با async replication، کامنت و پاسخ آن در partitionهای متفاوت‌اند. کدام راه‌حل consistent prefix را برای خوانندگان تضمین می‌کند؟

Accepted Answer

ردیابی وابستگی علّی (مثلاً پاسخ نسخه کامنت را حمل کند) و نمایش آن فقط پس از دیده شدن وابستگی

Answer

استفاده از LWW با timestamp ساعت سرور برای هر دو رکورد

Answer

افزایش replication factor هر دو partition

Answer

خواندن از تصادفی‌ترین replica برای پخش بار

Question 42

در Cassandra دو درخواست هم‌زمان موجودی انبار را می‌خوانند، یکی کم می‌کنند و می‌نویسند (QUORUM). نتیجه و راه‌حل درست کدام است؟

Accepted Answer

lost update رخ می‌دهد؛ باید از lightweight transaction (`IF stock = ?`) مبتنی بر Paxos استفاده کرد

Answer

QUORUM تضمین می‌کند هر دو کاهش به‌درستی اعمال شوند

Answer

Cassandra conflict را تشخیص داده و یکی را با خطا رد می‌کند

Answer

باید consistency را به `ALL` رساند تا مشکل حل شود

Question 43

بعد از update، اپلیکیشن key مربوطه را از cache حذف می‌کند. درخواست بعدی cache miss می‌خورد و از read replica پر می‌شود. چرا داده قدیمی ساعت‌ها در cache می‌ماند؟

Accepted Answer

replica هنوز update را نگرفته و مقدار قدیمی با TTL طولانی دوباره در cache نوشته می‌شود

Answer

حذف key از cache هیچ‌وقت واقعاً انجام نمی‌شود

Answer

leader update را rollback کرده است

Answer

cache به‌طور خودکار داده را از backup بازیابی می‌کند

Question 44

یک سرویس تاکسی اینترنتی رانندگان را با geohash cell با دقت ثابت shard می‌کند. مرکز شهر در ساعت اوج یک shard را اشباع می‌کند. بهترین بازطراحی کدام است؟

Accepted Answer

cellهای سلسله‌مراتبی (مثل S2) که در مناطق پرتراکم به cellهای ریزتر split و به shardهای مختلف نگاشت شوند

Answer

hash کردن `driver_id` و scatter-gather روی همه shardها برای هر جستجوی مکانی

Answer

افزایش دقت geohash برای کل جهان به‌طور یکسان

Answer

انتقال آن shard به سرور قوی‌تر و نگه‌داشتن همان طراحی

Question 45

داشبورد «تعداد کل سفارش‌های امروز» هر ثانیه روی ۲۰۰ shard اجرا می‌شود و بار زیادی ایجاد کرده است. بهترین رویکرد چیست؟

Accepted Answer

stream کردن رویدادهای سفارش (CDC) به یک aggregator که شمارنده از پیش محاسبه‌شده را نگه می‌دارد

Answer

اجرای `COUNT(*)` روی همه shardها ولی با timeout کوتاه‌تر

Answer

افزودن replicaهای بیشتر به همه ۲۰۰ shard

Answer

انتقال همه سفارش‌های امروز به یک shard جداگانه

Question 46

یک topic در Kafka با key=`order_id` ترتیب رویدادهای هر سفارش را تضمین می‌کرد. بعد از افزایش partitionها از ۱۲ به ۲۴، consumerها رویدادهای خارج از ترتیب می‌بینند. چرا؟

Accepted Answer

نگاشت `hash(key) % partitions` عوض شده و رویدادهای جدید یک سفارش به partition دیگری می‌روند

Answer

Kafka بعد از افزایش partition ترتیب را در همه partitionها به‌هم می‌ریزد

Answer

replication factor topic به‌طور خودکار کاهش یافته است

Answer

consumer groupها بعد از افزایش partition از ابتدای topic می‌خوانند

Question 47

سرویس A روی leader می‌نویسد و سپس event می‌فرستد. سرویس B با دریافت event از read replica می‌خواند و داده را پیدا نمی‌کند. بهترین اصلاح کدام است؟

Accepted Answer

قرار دادن داده لازم یا موقعیت commit (LSN) در خود event تا B از آن یا از replica به‌روز استفاده کند

Answer

اضافه کردن `sleep` ثابت قبل از خواندن در سرویس B

Answer

ارسال event قبل از commit تراکنش برای سرعت بیشتر

Answer

افزایش تعداد read replicaها تا lag کمتر شود

Question 48

در یک ring با RF=3، replicaهای هر key روی ۳ node بعدی ring قرار می‌گیرند. بعد از قطعی یک AZ برخی keyها کاملاً از دسترس خارج می‌شوند. ایراد طراحی چیست؟

Accepted Answer

انتخاب replica آگاه از AZ/rack نیست، پس هر ۳ node بعدی ممکن است در یک AZ باشند

Answer

RF=3 برای هیچ سیستم توزیع‌شده‌ای کافی نیست

Answer

consistent hashing ذاتاً با چند AZ سازگار نیست

Answer

تعداد vnodeها بیش از حد زیاد است

Question 49

Spanner با TrueTime برای هر commit یک «commit wait» به اندازه عدم قطعیت ساعت انجام می‌دهد. این کار چه تضمینی می‌دهد؟

Accepted Answer

ترتیب timestampها با ترتیب واقعی commitها در سراسر regionها یکی است (external consistency)

Answer

هیچ replicaی هرگز lag نخواهد داشت

Answer

نیاز به Paxos برای replication از بین می‌رود

Answer

نوشتن‌ها بدون هیچ تأخیری در همه regionها commit می‌شوند

Question 50

failover در ۱۰ ثانیه کامل می‌شود، ولی برخی سرویس‌ها تا چند دقیقه همچنان به leader قدیمی (حالا read-only) وصل‌اند و نوشتن‌هایشان خطا می‌دهد. محتمل‌ترین علت و راه‌حل؟

Accepted Answer

cache شدن DNS یا connection poolهای ماندگار؛ استفاده از proxy آگاه از topology (مثل ProxySQL/PgBouncer) یا TTL کوتاه همراه با بستن اتصال‌های قدیمی

Answer

leader جدید هنوز replication log را اعمال نکرده؛ باید semi-sync را فعال کرد

Answer

fencing بیش از حد سخت‌گیرانه است؛ باید آن را غیرفعال کرد

Answer

replication factor کم است؛ باید replica بیشتری اضافه کرد