بازگشت به کتابخانهکتابخانه10.1تراکنش واقعی، MVCC و تغییر امن داده
طراحی سیستم نرم‌افزاریSYSTEM DESIGNاز صفر تا تسلط
v1.0.0
01مبانی و تصویر بزرگ
02Scalability و ظرفیت
03لایه داده
04Cache، Queue و جریان
05معماری نرم‌افزار
06قابلیت اطمینان و عملیات
07متد طراحی
08Case Study های واقعی
09سیستم‌های توزیع‌شده عمیق
10مهندسی تولید: داده، امنیت و کارایی
11تمرین پیشرفته و کیس‌استادی‌های مکمل
12زیر کاپوت دیتابیس و معماری داده
13وب بلادرنگ و پروتکل‌های مدرن
14سیستم‌های توزیع‌شده پیشرفته
15SaaS ،SRE ،امنیت و شبکه پیشرفته
16طراحی سیستم در عصر AI
17Case Study های تکمیلی
LESSON 10.1فصل ۱۰مهندسی تولید: داده، امنیت و کارایی

تراکنش واقعی، MVCC و تغییر امن داده

  • ~۱۶ دقیقه
  • ۲ پرسش
  • متن را انتخاب کن تا هایلایت شود

ACID فقط اسم چهار قانون دیتابیس است؛ به‌تنهایی جلوی همه باگ‌ها را نمی‌گیرد. برای جلوگیری از فروشِ دوبارهٔ یک کالا، گم‌شدن تغییر هم‌زمان و خراب‌شدن گزارش‌ها باید بدانیم دیتابیس دقیقاً چه چیزی را قفل می‌کند و هر transaction چه چیزی را می‌بیند.

MVCC
خواننده نسخه سازگار از سطر می‌بیند و معمولاً نویسنده را قفل نمی‌کند؛ نسخه‌های قدیمی تا پایان transaction لازم‌اند.
Read Committed
هر statement داده commit‌شده را می‌بیند؛ non-repeatable read ممکن است.
Repeatable Read
خواندن‌های یک transaction snapshot یکسان می‌بینند؛ در بعضی DBها write skew هنوز ممکن است.
Serializable
رفتار معادل اجرای ترتیبی؛ DB ممکن است transaction را abort کند و client باید retry امن داشته باشد.
Optimistic locking
ستون version در UPDATE شرطی؛ اگر version عوض شده، تعارض را به caller نشان می‌دهد.

مهاجرت schema بدون downtime

  • Expand: ستون/جدول/ایندکس جدیدِ backward-compatible اضافه کن؛ index بزرگ را concurrent یا online بساز.
  • Migrate: کد جدید هم زمان با قدیمی بخواند/بنویسد؛ backfill را rate-limit و قابل توقف کن.
  • Contract: بعد از حذف تمام خواننده‌های قدیمی و مشاهده metrics، ستون قدیمی را حذف کن.
  • برای تغییر داده بین سیستم‌ها از transactional outbox یا CDC استفاده کن؛ dual-write بدون recovery path منبع ناسازگاری است.

به زبان ساده

دیتابیس مدرن چند نسخه از هر سطر را نگه می‌دارد تا خواندن و نوشتن هم‌زمان قاطی نشود؛ و تغییر ساختار جدول را سه‌مرحله‌ای انجام می‌دهیم تا نسخه قدیمی برنامه نسوزد.

مثال واقعی

ستون شماره موبایل را اگر یک‌شبه اجباری کنی، نسخه قدیمی اپ روی بعضی سرورها crash می‌کند؛ اول ستون اختیاری، بعد deploy، بعد پرکردن آرام، و در آخر اجباری‌کردن.

دانش‌سنجی

آزمون درس

۲ Q
01
برای یک slot نوبت که فقط یک‌بار باید رزرو شود، کدام ابزار مستقیم‌تر است؟
02
چرا migration حذف ستون را قبل از deploy همه نسخه‌ها انجام نمی‌دهیم؟