سوالات مصاحبه سازگاری، CAP و اجماع سطح سینیور (50 سوال)

Question 1

نتیجه FLP impossibility دقیقاً چه می‌گوید؟

Accepted Answer

در مدل کاملاً asynchronous، هیچ الگوریتم قطعی نمی‌تواند با حتی یک crash، هم safety و هم termination را تضمین کند

Answer

consensus در هر مدل شبکه‌ای، حتی synchronous، با یک crash غیرممکن است

Answer

با بیش از یک‌سوم نود Byzantine، هیچ سیستمی نمی‌تواند داده را durable نگه دارد

Answer

در زمان partition نمی‌توان هم‌زمان consistency و availability داشت

Question 2

Raft و Paxos در عمل چگونه با محدودیت FLP کنار می‌آیند؟

Accepted Answer

safety را همیشه حفظ می‌کنند و liveness را فقط در دوره‌های partial synchrony با timeout تضمین می‌کنند

Answer

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

Answer

safety را در زمان partition فدا می‌کنند تا همیشه تصمیم بگیرند

Answer

از ساعت اتمی برای حذف کامل عدم قطعیت زمانی استفاده می‌کنند

Question 3

Spanner با TrueTime چرا قبل از اعلام commit یک «commit wait» انجام می‌دهد؟

Accepted Answer

تا مطمئن شود timestamp تراکنش قطعاً در گذشته است و ترتیب timestampها با زمان واقعی سازگار باشد

Answer

تا منتظر بماند همه replicaها در همه قاره‌ها داده را روی دیسک بنویسند

Answer

تا ترافیک write را در طول زمان یکنواخت کند و از overload جلوگیری کند

Answer

تا deadlockهای احتمالی بین تراکنش‌ها خودبه‌خود حل شوند

Question 4

اگر عدم قطعیت ساعت (ε) در TrueTime از ۴ به ۴۰ میلی‌ثانیه برسد، چه اثری روی Spanner دارد؟

Accepted Answer

correctness حفظ می‌شود اما latency هر commit به‌دلیل commit wait طولانی‌تر بیشتر می‌شود

Answer

external consistency از بین می‌رود و تراکنش‌ها ممکن است بی‌ترتیب شوند

Answer

Spanner به‌طور خودکار به eventual consistency تغییر حالت می‌دهد

Answer

هیچ اثری ندارد، چون TrueTime فقط برای logging استفاده می‌شود

Question 5

CockroachDB که ساعت اتمی ندارد، وقتی هنگام read مقداری با timestamp داخل «uncertainty interval» ببیند چه می‌کند؟

Accepted Answer

timestamp تراکنش را بالا می‌برد و read را restart می‌کند تا آن مقدار را به‌درستی ببیند

Answer

مقدار را نادیده گرفته و نسخه قدیمی‌تر را بی‌صدا برمی‌گرداند

Answer

کل cluster را تا همگام‌سازی ساعت‌ها متوقف می‌کند

Answer

مثل Spanner برای هر write به اندازه max offset صبر می‌کند

Question 6

چرا گفته می‌شود linearizability یک ویژگی «local» یا composable است؟

Accepted Answer

اگر هر object جداگانه linearizable باشد، کل سیستم شامل آن objectها هم linearizable است

Answer

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

Answer

چون serializability را برای تراکنش‌های چند-object هم تضمین می‌کند

Answer

چون نیازی به هماهنگی بین replicaهای یک object ندارد

Question 7

دو پزشک کشیک هم‌زمان بررسی می‌کنند «حداقل یک نفر دیگر کشیک است» و هر دو مرخصی می‌گیرند. تحت snapshot isolation چه رخ داده است؟

Accepted Answer

write skew؛ هر تراکنش ردیف متفاوتی نوشته و SI این را تشخیص نمی‌دهد

Answer

dirty read؛ یکی داده commit‌نشده دیگری را خوانده است

Answer

lost update؛ هر دو یک ردیف یکسان را بازنویسی کرده‌اند

Answer

phantom read ناشی از نبود index روی جدول

Question 8

در یک store با N=3، `W=2` و `R=2` و LWW، چرا حتی بدون sloppy quorum هم linearizability تضمین نمی‌شود؟

Accepted Answer

write در حال انجام ممکن است برای یک reader دیده و برای reader بعدی دیده نشود، مگر read repair همزمان انجام شود

Answer

چون `R + W > N` ریاضیاً هیچ هم‌پوشانی‌ای بین مجموعه‌ها ایجاد نمی‌کند

Answer

چون LWW همیشه قدیمی‌ترین write را نگه می‌دارد و جدیدترها را حذف می‌کند

Answer

چون readها در این سیستم‌ها هرگز به بیش از یک نود ارسال نمی‌شوند

Question 9

در Cassandra با `QUORUM`، تیمی hinted handoff را فعال دارد و گمان می‌کند همیشه آخرین write را می‌خواند. کجای این استدلال اشتباه است؟

Accepted Answer

write که timeout شده ممکن است روی برخی replicaها نشسته و rollback نشود، پس readهای quorum بعدی بین مقدار قدیم و جدید نوسان می‌کنند

Answer

`QUORUM` در Cassandra فقط برای writeها اعمال می‌شود و readها همیشه `ONE` هستند

Answer

hinted handoff باعث می‌شود همه readها مستقیماً از coordinator پاسخ داده شوند

Answer

Cassandra هیچ‌وقت write را روی بیش از یک replica ذخیره نمی‌کند

Question 10

چرا leader جدید Raft نمی‌تواند یک entry از term قبلی را فقط با شمردن replicaهایش روی majority، committed اعلام کند؟

Accepted Answer

چون آن entry ممکن است بعداً توسط leaderی با log متفاوت بازنویسی شود؛ فقط entry از term جاری با شمارش commit می‌شود

Answer

چون entryهای term قبلی همیشه باید روی همه نودها ذخیره شوند

Answer

چون entryهای قدیمی پس از تغییر term به‌طور خودکار حذف می‌شوند

Answer

چون شمارش replica فقط توسط followerها مجاز است

Question 11

چرا leader تازه انتخاب‌شده در Raft معمولاً یک entry خالی (no-op) در ابتدای term خود append می‌کند؟

Accepted Answer

تا سریعاً یک entry از term جاری commit کند و بفهمد کدام entryهای قبلی committed هستند

Answer

تا به کلاینت‌ها اعلام کند cluster برای مدتی read-only است

Answer

تا حجم log را برای snapshot بعدی کاهش دهد

Answer

تا ساعت فیزیکی followerها را با خودش همگام کند

Question 12

چرا تغییر مستقیم cluster از ۳ به ۵ نود در یک قدم (بدون joint consensus یا تغییر تک‌نودی) خطرناک است؟

Accepted Answer

چون در لحظه گذار ممکن است دو majority مجزا (قدیم و جدید) هم‌زمان دو leader انتخاب کنند

Answer

چون نودهای جدید هرگز نمی‌توانند log را از leader دریافت کنند

Answer

چون Raft حداکثر از سه نود پشتیبانی می‌کند

Answer

چون باید همه داده‌ها قبل از تغییر پاک شوند

Question 13

یک نود Raft که مدتی partition شده بود برمی‌گردد و با term بسیار بالا leader سالم را برکنار می‌کند. کدام مکانیزم برای جلوگیری از این طراحی شده است؟

Accepted Answer

Pre-Vote؛ نود قبل از افزایش term بررسی می‌کند آیا majority حاضر به رأی دادن است

Answer

افزایش heartbeat interval leader به چند ثانیه

Answer

غیرفعال کردن election timeout روی همه followerها

Answer

استفاده از LWW برای انتخاب leader بر اساس timestamp

Question 14

leader lease read در Raft (پاسخ read بدون رفت‌وبرگشت به majority) بر چه فرضی تکیه دارد؟

Accepted Answer

محدود بودن clock drift بین نودها؛ وگرنه leader جدید ممکن است قبل از انقضای lease قدیمی انتخاب شود

Answer

اینکه همه کلاینت‌ها فقط از یک دیتاسنتر درخواست بفرستند

Answer

اینکه هیچ writeای در طول lease انجام نشود

Answer

اینکه followerها هرگز crash نکنند

Question 15

کلاینت یک write غیرidempotent (مثل `increment`) به cluster Raft می‌فرستد و timeout می‌گیرد. retry ساده چه خطری دارد و راه‌حل چیست؟

Accepted Answer

ممکن است write اول commit شده باشد و دوباره اعمال شود؛ باید با client ID و sequence number در state machine dedupe کرد

Answer

هیچ خطری ندارد، چون Raft تضمین می‌کند writeهای timeout‌شده هرگز commit نمی‌شوند

Answer

retry باعث split brain دائمی می‌شود؛ باید cluster را restart کرد

Answer

write دوم همیشه reject می‌شود؛ باید term کلاینت را افزایش داد

Question 16

نقد اصلی Martin Kleppmann به Redlock برای کاربردهای وابسته به correctness چیست؟

Accepted Answer

fencing token تولید نمی‌کند و safety آن به فرض‌های زمانی (محدود بودن pause، drift و delay) وابسته است

Answer

چون از بیش از یک نود Redis استفاده می‌کند، throughput آن بسیار پایین است

Answer

چون lock را در دیسک ذخیره می‌کند و latency بالایی دارد

Answer

چون فقط با Redis Cluster کار می‌کند و نه با instanceهای مستقل

Question 17

سرویسی fencing token را از etcd می‌گیرد اما آن را به S3 که هیچ شرط نسخه‌ای را بررسی نمی‌کند ارسال می‌کند. نتیجه چیست؟

Accepted Answer

fencing بی‌اثر است؛ token فقط وقتی کار می‌کند که منبع نهایی آن را بررسی و token قدیمی را رد کند

Answer

etcd به‌طور خودکار writeهای کهنه را در S3 rollback می‌کند

Answer

S3 به‌طور پیش‌فرض token را از header خوانده و مقایسه می‌کند

Answer

fencing همچنان کامل کار می‌کند چون lock در etcd linearizable است

Question 18

در ZooKeeper، کلاینت A یک write انجام داده و از طریق کانال دیگری به کلاینت B خبر می‌دهد. B از follower دیگری می‌خواند و مقدار قدیمی را می‌بیند. چرا و راه‌حل چیست؟

Accepted Answer

readهای ZooKeeper محلی و ممکن است کهنه باشند؛ B باید قبل از read از `sync()` استفاده کند

Answer

ZooKeeper writeها را async replicate می‌کند و ممکن است گم شوند؛ باید `fsync` را فعال کرد

Answer

B باید session جدیدی باز کند تا cache آن پاک شود

Answer

این رفتار bug است و ZooKeeper همیشه readهای linearizable می‌دهد

Question 19

در etcd، تفاوت read با `--consistency=s` (serializable) و حالت پیش‌فرض linearizable چیست؟

Accepted Answer

serializable از نود محلی بدون هماهنگی quorum پاسخ می‌دهد؛ سریع‌تر ولی ممکن است کهنه باشد

Answer

serializable به majority نیاز دارد و linearizable فقط از leader می‌خواند

Answer

هیچ تفاوتی ندارند و فقط نام‌گذاری متفاوت است

Answer

serializable فقط برای کلیدهای دارای lease قابل استفاده است

Question 20

یک cluster دیتابیس دو‌نودی با failover خودکار دارید. اگر لینک بین دو نود قطع شود، بهترین طراحی برای جلوگیری از split brain چیست؟

Accepted Answer

افزودن یک witness/tie-breaker سوم در failure domain جداگانه تا فقط سمت دارای majority فعال بماند

Answer

اینکه هر دو نود پس از قطع ارتباط خودشان را primary اعلام کنند

Answer

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

Answer

ارسال heartbeat روی همان لینک با دو برابر فرکانس

Question 21

یک cluster پنج‌نودی Raft را بین دیتاسنترها پخش می‌کنید. کدام چیدمان از دست رفتن کامل هر یک دیتاسنتر را تحمل می‌کند؟

Accepted Answer

۲-۲-۱ در سه دیتاسنتر

Answer

۳-۲ در دو دیتاسنتر

Answer

۴-۱ در دو دیتاسنتر

Answer

هر ۵ نود در یک دیتاسنتر با دو zone

Question 22

در Basic Paxos دو proposer مدام با شماره‌های بالاتر همدیگر را preempt می‌کنند و هیچ مقداری انتخاب نمی‌شود. راه‌حل رایج چیست؟

Accepted Answer

انتخاب یک distinguished leader (Multi-Paxos) به‌همراه backoff تصادفی

Answer

کاهش تعداد acceptorها به یک نود برای سرعت بیشتر

Answer

حذف فاز prepare و ارسال مستقیم accept

Answer

انتخاب مقدار بر اساس timestamp فیزیکی proposerها

Question 23

در Paxos، اگر proposer در پاسخ‌های promise ببیند برخی acceptorها قبلاً مقداری را accept کرده‌اند، چه باید بکند؟

Accepted Answer

مقدار مربوط به بالاترین proposal number accept‌شده را پیشنهاد دهد، نه مقدار خودش را

Answer

مقدار خودش را با شماره بالاتر پیشنهاد دهد تا جایگزین شود

Answer

مقداری را که بیشترین acceptor پذیرفته‌اند انتخاب کند

Answer

کل فرایند را abort کرده و منتظر proposer دیگر بماند

Question 24

برای تحمل f نود Byzantine (که ممکن است دروغ بگویند) در consensus، حداقل چند نود لازم است و Raft چه وضعیتی دارد؟

Accepted Answer

`3f+1` نود؛ Raft فقط crash fault را تحمل می‌کند و در برابر Byzantine امن نیست

Answer

`2f+1` نود؛ Raft هر دو نوع خرابی را به‌طور کامل تحمل می‌کند

Answer

`f+1` نود؛ Raft فقط با ساعت اتمی Byzantine را تحمل می‌کند

Answer

`4f` نود؛ Raft با رمزنگاری پیام‌ها Byzantine-safe می‌شود

Question 25

Spanner با وجود استفاده از 2PC چگونه مشکل blocking ناشی از crash شدن coordinator را کاهش می‌دهد؟

Accepted Answer

coordinator و participantها هر کدام یک Paxos group هستند، پس state تصمیم replicate شده و با failover ادامه می‌یابد

Answer

Spanner به‌جای 2PC از 3PC استفاده می‌کند که هیچ‌وقت block نمی‌شود

Answer

participantها بعد از timeout به‌طور یک‌طرفه commit می‌کنند

Answer

Spanner اصلاً تراکنش بین چند shard را پشتیبانی نمی‌کند

Question 26

در 3PC، partitionی رخ می‌دهد که برخی participantها pre-commit را دریافت کرده‌اند و برخی نه. بدترین نتیجه چیست؟

Accepted Answer

هر سمت بر اساس timeout تصمیم متفاوتی (commit در برابر abort) می‌گیرد و atomicity نقض می‌شود

Answer

همه participantها برای همیشه block می‌شوند، دقیقاً مثل 2PC

Answer

coordinator به‌طور خودکار partition را تشخیص داده و همه را abort می‌کند

Answer

تراکنش با موفقیت روی همه commit می‌شود چون pre-commit کافی است

Question 27

در یک Saga، مرحله «ارسال SMS به مشتری» قابل جبران نیست. بهترین جای این مرحله در ترتیب Saga کجاست؟

Accepted Answer

بعد از pivot transaction، به‌عنوان مرحله retriable که تا موفقیت تکرار می‌شود

Answer

در ابتدای Saga تا مشتری زودتر مطلع شود

Answer

هم‌زمان با همه مراحل دیگر به‌صورت موازی

Answer

قبل از هر مرحله‌ای که ممکن است شکست بخورد

Question 28

Saga «رزرو موجودی» یک کالا را کم می‌کند و بعد به‌دلیل شکست پرداخت compensate می‌شود. در این فاصله، کاربر دیگری پیام «ناموجود» دیده است. کدام countermeasure مناسب است؟

Accepted Answer

semantic lock یا رزرو موقت (وضعیت `RESERVED`) که بقیه بتوانند آن را از فروش قطعی تمایز دهند

Answer

تبدیل Saga به یک تراکنش 2PC بین همه microserviceها

Answer

حذف compensating action برای جلوگیری از تغییر موجودی

Answer

افزایش timeout پرداخت تا شکست‌ها کمتر شوند

Question 29

سرویسی ابتدا در PostgreSQL commit و سپس به Kafka publish می‌کند. اگر بین این دو crash کند چه می‌شود و راه‌حل مقاوم چیست؟

Accepted Answer

رویداد هرگز منتشر نمی‌شود؛ outbox در همان تراکنش به‌همراه CDC (مثل Debezium) آن را حل می‌کند

Answer

Kafka به‌طور خودکار رویداد را از WAL دیتابیس بازیابی می‌کند

Answer

PostgreSQL تراکنش را rollback می‌کند چون Kafka تأیید نداده است

Answer

ترتیب را برعکس کنید؛ اول Kafka سپس DB، که مشکل را کاملاً حل می‌کند

Question 30

یک job استریم با Flink و checkpoint «exactly-once» برای هر رویداد یک webhook خارجی فراخوانی می‌کند. پس از failure و بازگشت از checkpoint چه اتفاقی ممکن است بیفتد؟

Accepted Answer

webhookهای بعد از آخرین checkpoint دوباره فراخوانی می‌شوند، مگر sink تراکنشی یا idempotent باشد

Answer

هیچ webhookی تکرار نمی‌شود چون exactly-once برای همه خروجی‌ها تضمین شده است

Answer

همه webhookها از ابتدای job دوباره ارسال می‌شوند

Answer

Flink فراخوانی‌های قبلی را به‌طور خودکار از webhook پس می‌گیرد

Question 31

consumer شناسه پیام‌ها را برای dedupe فقط ۱۰ دقیقه نگه می‌دارد. کدام سناریو باعث پردازش تکراری می‌شود؟

Accepted Answer

producer پس از یک outage طولانی، پیامی را بعد از ۳۰ دقیقه دوباره ارسال می‌کند

Answer

دو پیام با شناسه متفاوت در یک ثانیه می‌رسند

Answer

broker پیام را بلافاصله پس از ack گم می‌کند

Answer

consumer پیام را در کمتر از یک میلی‌ثانیه پردازش می‌کند

Question 32

دو درخواست با idempotency key یکسان هم‌زمان می‌رسند. پیاده‌سازی «اول SELECT کن، اگر نبود پردازش کن» چه مشکلی دارد؟

Accepted Answer

هر دو کلید را نمی‌بینند و هر دو پردازش می‌کنند؛ باید ابتدا کلید را با unique constraint درج و سپس پردازش کرد

Answer

SELECT روی جدول کلیدها همیشه deadlock ایجاد می‌کند

Answer

درخواست دوم همیشه پاسخ درخواست اول را دریافت می‌کند

Answer

مشکلی ندارد چون idempotency key ذاتاً thread-safe است

Question 33

قوی‌ترین مدل consistency که می‌تواند در زمان network partition در دسترس (به معنای CAP) بماند کدام است؟

Accepted Answer

causal consistency (به‌همراه session guarantees با کلاینت‌های sticky)

Answer

linearizability

Answer

sequential consistency

Answer

strict serializability

Question 34

کدام نقد به استفاده رایج از CAP برای دسته‌بندی دیتابیس‌ها صحیح است؟

Accepted Answer

CAP فقط linearizability یک register و partition کامل را مدل می‌کند و latency، خرابی جزئی و مدل‌های میانی را نادیده می‌گیرد

Answer

CAP ثابت می‌کند هر دیتابیس باید دقیقاً دو ویژگی از سه را برای همیشه انتخاب کند

Answer

CAP فقط برای دیتابیس‌های رابطه‌ای تک‌نود معتبر است

Answer

CAP نشان می‌دهد سیستم‌های AP هیچ تضمین consistency ندارند

Question 35

دیتابیسی strongly consistent با replicaها در اروپا، آمریکا و آسیا دارید و هیچ partitionی وجود ندارد. چرا writeها همچنان کند هستند؟

Accepted Answer

چون هر write به تأیید majority نیاز دارد که حداقل یک رفت‌وبرگشت بین‌قاره‌ای است (سمت EC در PACELC)

Answer

چون strong consistency فقط در زمان partition هزینه دارد و این یک bug است

Answer

چون replicaها داده را قبل از write فشرده‌سازی سنگین می‌کنند

Answer

چون clock skew بین قاره‌ها writeها را به‌طور کامل block می‌کند

Question 36

در یک store مبتنی بر vector clock که هر کلاینت یک entry در vector دارد، با میلیون‌ها کلاینت چه مشکلی پیش می‌آید و راه‌حل رایج چیست؟

Accepted Answer

vectorها بی‌نهایت بزرگ می‌شوند؛ استفاده از شناسه replica سرور (یا dotted version vectors) به‌جای شناسه کلاینت

Answer

vectorها overflow می‌کنند؛ باید از اعداد ۱۲۸ بیتی استفاده کرد

Answer

کلاینت‌ها دیگر نمی‌توانند read کنند؛ باید LWW را جایگزین کرد

Answer

هیچ مشکلی ندارد چون vector clock اندازه ثابت دارد

Question 37

یک replica پس از چند روز خرابی برمی‌گردد. چرا اتکای صرف به read repair برای همگرا کردن آن کافی نیست؟

Accepted Answer

کلیدهایی که خوانده نمی‌شوند هرگز تعمیر نمی‌شوند و hintها ممکن است منقضی شده باشند؛ anti-entropy repair لازم است

Answer

read repair فقط روی leader اجرا می‌شود و replica را لمس نمی‌کند

Answer

read repair باعث حذف کامل داده replica برگشتی می‌شود

Answer

read repair فقط برای writeهای کمتر از یک ثانیه کار می‌کند

Question 38

در Cassandra، replicaای بیشتر از `gc_grace_seconds` خاموش بوده و سپس برمی‌گردد. چه خطری وجود دارد؟

Accepted Answer

tombstoneهای حذف روی بقیه پاک شده‌اند و داده حذف‌شده از replica قدیمی دوباره «زنده» می‌شود

Answer

replica به‌طور خودکار همه داده‌های جدید را رد می‌کند

Answer

cluster تا پاک شدن دستی replica قفل می‌شود

Answer

همه writeهای جدید بعد از بازگشت replica گم می‌شوند

Question 39

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

Accepted Answer

کالا در سبد می‌ماند؛ remove فقط تگ‌های add که دیده را حذف می‌کند (add-wins)

Answer

کالا حذف می‌شود چون remove همیشه بر add اولویت دارد

Answer

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

Answer

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

Question 40

یک سرویس انقضای lease را با مقایسه `expiresAt` (wall-clock timestamp دریافتی از سرور lock) با ساعت محلی بررسی می‌کند. مشکل اصلی چیست؟

Accepted Answer

به همگام بودن ساعت دو ماشین وابسته است؛ بهتر است مدت lease با monotonic clock محلی و حاشیه امن سنجیده شود

Answer

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

Answer

lock server هرگز نباید زمان انقضا را به کلاینت اعلام کند

Answer

مقایسه timestamp باعث افزایش شدید مصرف CPU می‌شود

Question 41

throughput write یک cluster سه‌نودی etcd به سقف رسیده است. افزودن نود به ۷ نود چه اثری دارد و راهکار بهتر چیست؟

Accepted Answer

throughput بدتر می‌شود چون quorum بزرگ‌تر است؛ بهتر است با batching یا shard کردن داده به چند consensus group کار کرد

Answer

throughput تقریباً ۲٫۳ برابر می‌شود چون writeها بین نودها پخش می‌شوند

Answer

throughput بدون تغییر می‌ماند ولی readها کندتر می‌شوند

Answer

etcd با بیش از ۵ نود خودبه‌خود به حالت AP تغییر می‌کند

Question 42

چند instance برای انتخاب leader از یک ردیف در PostgreSQL با `UPDATE ... SET owner=?, expires_at=? WHERE expires_at < now()` استفاده می‌کنند. چه چیزی برای امن کردن عملیات leader ضروری است؟

Accepted Answer

یک `epoch` افزایشی در همان ردیف که leader با هر write ارسال و منابع پایین‌دستی بررسی کنند

Answer

افزایش `expires_at` به چند ساعت تا leader به‌ندرت تغییر کند

Answer

اجرای کوئری با isolation level `READ UNCOMMITTED` برای سرعت بیشتر

Answer

اینکه هر instance قبل از کار یک بار دیگر ردیف را `SELECT` کند

Question 43

یک primary با async replication پس از تأیید چند write دچار crash می‌شود و replica عقب‌مانده promote می‌شود. علاوه بر گم شدن آن writeها، چه خطر ظریف‌تری وجود دارد؟

Accepted Answer

auto-increment IDهای گم‌شده دوباره صادر می‌شوند و با داده‌ای که سیستم‌های خارجی (مثل cache یا Redis) دیده‌اند تداخل پیدا می‌کنند

Answer

replica جدید همه جداول را به‌طور خودکار drop می‌کند

Answer

primary قدیمی هنگام بازگشت همیشه داده را به‌درستی merge می‌کند

Answer

همه کلاینت‌ها برای همیشه به primary قدیمی متصل می‌مانند

Question 44

یک سرویس ثبت‌نام global با دیتابیس multi-leader AP باید یکتا بودن username را تضمین کند. چه رویکردی صحیح است؟

Accepted Answer

رزرو username از طریق یک مسیر linearizable (consensus یا single-leader برای آن کلید)؛ چون uniqueness بدون هماهنگی ممکن نیست

Answer

استفاده از LWW تا username دوم به‌طور خودکار جایگزین اولی شود

Answer

استفاده از CRDT از نوع G-Set که تکراری‌ها را خودش حذف می‌کند

Answer

بررسی وجود username در replica محلی قبل از ثبت

Question 45

یک producer تراکنشی Kafka دچار pause طولانی می‌شود و instance جایگزین با همان `transactional.id` بالا می‌آید. Kafka چگونه از write «zombie» قدیمی جلوگیری می‌کند؟

Accepted Answer

با `initTransactions` و افزایش producer epoch؛ broker درخواست‌های دارای epoch قدیمی‌تر را رد می‌کند

Answer

با حذف خودکار topic و ساختن دوباره آن برای instance جدید

Answer

با مقایسه wall-clock timestamp دو producer و نگه‌داشتن جدیدتر

Answer

با اجازه دادن به هر دو producer و حذف تکراری‌ها در consumer

Question 46

یک follower در Raft آن‌قدر عقب افتاده که entryهای مورد نیازش در leader به‌دلیل log compaction حذف شده‌اند. leader چه می‌کند؟

Accepted Answer

با `InstallSnapshot` یک snapshot از state machine می‌فرستد و سپس replication را از بعد از آن ادامه می‌دهد

Answer

follower را برای همیشه از cluster حذف و یک نود جدید اضافه می‌کند

Answer

log compaction را لغو و entryهای حذف‌شده را از دیسک بازیابی می‌کند

Answer

از follower می‌خواهد entryها را از کلاینت‌ها دوباره دریافت کند

Question 47

چرا controllerهای Kubernetes که با `Lease` object انتخاب leader می‌کنند، معمولاً هنگام از دست دادن lease کل process را خاتمه می‌دهند؟

Accepted Answer

تا کارهای در حال اجرا که فرض leader بودن داشتند فوراً متوقف شوند و دو leader هم‌زمان عمل نکنند

Answer

چون Kubernetes بدون restart نمی‌تواند lease جدیدی صادر کند

Answer

تا حافظه اشغال‌شده توسط cache از بین برود و مصرف RAM کم شود

Answer

چون etcd اتصال process را پس از انقضای lease برای همیشه مسدود می‌کند

Question 48

دیتابیسی serializable است اما strict serializable نیست. کاربر سفارشی ثبت می‌کند، پاسخ موفق می‌گیرد و بلافاصله صفحه سفارش‌ها را باز می‌کند ولی آن را نمی‌بیند. آیا این با تضمین‌ها سازگار است؟

Accepted Answer

بله؛ serializability فقط وجود یک ترتیب سریالی را تضمین می‌کند و read می‌تواند قبل از write مرتب شود

Answer

خیر؛ serializability همیشه ترتیب real-time تراکنش‌ها را تضمین می‌کند

Answer

خیر؛ این فقط با eventual consistency ممکن است و نشانه یک bug است

Answer

بله؛ اما فقط اگر دو تراکنش روی یک ردیف مشترک کار کنند

Question 49

در chain replication، writeها از head وارد و در طول زنجیره منتشر می‌شوند. readهای strongly consistent از کجا سرو می‌شوند و چرا؟

Accepted Answer

از tail، چون فقط writeهایی که به tail رسیده‌اند روی همه نودها replicate و تأیید شده‌اند

Answer

از head، چون جدیدترین writeها ابتدا به آن می‌رسند

Answer

از نود وسط زنجیره، برای تعادل بار بین head و tail

Answer

از هر نود تصادفی، چون همه نودها همیشه یکسان‌اند

Question 50

چرا دیتابیس‌های توزیع‌شده برای snapshot read در «زمان مشخص» (مثلاً `AS OF SYSTEM TIME '-10s'`) از HLC به‌جای Lamport clock خالص استفاده می‌کنند؟

Accepted Answer

چون HLC به wall clock نزدیک است و می‌توان آن را به زمان واقعی نگاشت، در حالی که شمارنده Lamport معنای زمانی ندارد

Answer

چون Lamport clock اصلاً ترتیب علّی را حفظ نمی‌کند

Answer

چون HLC نیازی به ارسال timestamp در پیام‌ها ندارد

Answer

چون HLC هم‌زمانی را مثل vector clock به‌طور کامل تشخیص می‌دهد