تشخیص و حل تعارض

1) چه چیزی در نظر گرفته شده است

تعارض وضعیتی است که در آن دو یا چند منبع تغییر، حالتهای ناسازگار یک نهاد، منبع یا ناوردا را ادعا میکنند.

Syntactic: تغییرات همپوشانی در یک فایل/کلید (تداخل ادغام در Git، برخورد پچ در Kustomize).
معنایی: یک سند صحیح با توجه به طرح، ناوردا کسب و کار را نقض می کند (مقدار بدهی ≠ اعتبار، حد مجاز بیش از حد).
عملیاتی/زمانی: مسابقات نوشتن/خواندن، رویدادهای تکراری، اختلاف علت و معلول.
دامنه: عملیات رقابتی در منابع (فروش دو بلیط، کالاهای بیش از حد).

وظیفه: برای شناسایی درگیری در اسرع وقت، توضیح علت آن و با خیال راحت یکی از اقدامات را انتخاب کنید: بازیابی خودکار، بازپرداخت، ادغام، جبران خسارت، تشدید.

2) مکانیسم های تشخیص

2. 1 نسخه و مقایسه دولت

ETag/If-Match در REST، rowversion/xmin در DB - تشخیص به روز رسانی از دست رفته.
ادغام 3 طرفه (پایه، ما، آنها) - برجسته کردن ویرایش های ناسازگار.
Checksum/Hash by field/document - مقایسه ارزان.

2. 2 برچسب های زمان و علت

ساعت Lamport: کل سفارش «تقریبی در زمان».

2. ۳ تغییرناپذیر و محدودیتها

طرحها و اعتبارسنجها (JSON Schema/OpenAPI) - اعتبار نحوی.
ثابت: منحصر به فرد، غیر منفی، تعادل، قوانین ACL.
بررسی یکپارچگی: شاخص های FK/UNIQUE/EXCLUDE، محدودیت های جزئی.
دامنه در کد/سیاست ها (OPA/Kyverno/Conftest) ادعا می کند.

2. 4 تشخیص در جریان رویداد

Idempotency کلید/Dedup فروشگاه (به عنوان مثال Redis/DB با TTL): رد طول می کشد.
تراکنش/دقیقا یک بار در جریان: شناسه تراکنش، دوره تولید کننده، جبران مصرف کننده.
تشخیص شکاف توالی: شکافها، تکرارها (n، n + 1، n + 1).

2. 5 قابلیت مشاهده و زنگ هشدار

خطا/برخورد/بازپرداخت پرومتریکس.

3) استراتژی های قطعنامه

3. 1 کاملا اتوماتیک (با تعریف ایمن)

CRDT (انواع داده های کپی شده بدون درگیری): G-Counter، PN-Counter، OR-Set، LWW-Register، Map/Graph CRDT.

تضمین همگرایی بدون هماهنگی ؛ انتخاب معانی از دست دادن/حفظ مهم است.
عملیات تعویض: در هر سفارش (افزایش، ورود به سیستم پیوست) اعمال می شود.
کنترل کننده های بی نظیر: تکرار نتیجه را تغییر نمی دهد (upsert توسط کلید، قرار دادن اگر وجود ندارد).
ادغام خوش بینانه ساختارها: «ادغام عمیق + سیاست» با نظم قطعی.

3. 2 نیمه اتوماتیک (با سیاست)

3-way merge + array rules ('replace' append 'uniqueBy (key) | patchBy (key)').
LWW (Last-Write-Wins): ساده اما خطر از دست دادن صحت علت و معلولی.
اولویت های منابع عبارتند از «interactive input> config from file> default».
قوانین کسب و کار: «اگر محدودیت بیش از حد باشد - تایید جزئی/جبران خسارت».

3. ۳ هماهنگی

OCC/MVCC (بلوک خوش بینانه/چند نسخه): آشتی نسخه، retray.
قفل های بدبینانه: "انتخاب... برای به روز رسانی، قفل های توزیع شده (Redlock/DB-lock/etcd).
اجماع (قایق/Paxos): یک رهبر تصمیم می گیرد سفارش ؛ درگیری های کمتری وجود دارد، قیمت تاخیر است.

3. 4 شخص در حلقه (HITL)

UI برای ادغام دستی/داوری (به خصوص محتوا, تعرفه, کاتالوگ).
پیش نمایش diffa، توضیح سیاست، دکمه ها: «پذیرش ما/آنها»، «ادغام زمینه ها»، «ایجاد جبران».

4) الگوهای لایه های معماری

4. 1 API/REST/gRPC

همزمانی خوش بینانه: 'If-Match: <etag>'، 409/412 در صورت درگیری → مشتری با در نظر گرفتن ETag تازه جمع می شود.
Idempotency-کلید در POST (پرداخت/سفارشات).
معنایی 409: ارتباط دلیل و اقدامات پیشنهاد شده است.

4. 2 انبار داده

RDBMS: MVCC (جداسازی عکس فوری)، شاخص های منحصر به فرد، شاخص های جزئی.
فروشگاه های KV/Doc: نسخه/تجدید نظر (rev)، مقایسه و تعویض (CAS).
تکثیر چند کارشناسی ارشد: استفاده از/CRDT یا نوشتن به رهبر فقط برای نهادهای مهم.

4. 3 صف/جریان

دقیقا یک بار (عملا - «به طور موثر یک بار»): تولید کننده معاملات + اتمی نوشتن به سینک.
Dedup در کنسول: ذخیره آخرین N id، منطق upsert/merge.
الگوی صندوق ورودی/صندوق ورودی: انتشار رویداد سازگار.

4. 4 تنظیمات و IAc

ادغام 3 طرفه در GitOps، دروازه های سیاست (OPA/Kyverno) قبل از استفاده.
Kustomize/Helm: استراتژیهای ادغام قطعی و ممنوعیت «کلیدهای ناشناخته».
Terraform: برنامه-تفاوت به عنوان یک «رانش در مقابل می خواستم» سیگنال درگیری.

5) الگوریتم ها و مثال ها

5. 1 ادغام 3 طرفه (ساده شده)

text resolve(base, ours, theirs):
diff1 = delta(base, ours)
diff2 = delta(base, theirs)
if independent(diff1, diff2): return apply(base, diff1 ⊕ diff2)
if conflictsOnlyInArrays: return arrayPolicyMerge(...)
else:
return CONFLICT with hunks

5. 2 OCC برای منابع REST

http
Client reads
GET /accounts/42 -> ETag: "v17", body: {balance: 100}

Trying to write off
PUT /accounts/42
If-Match: "v17"
{balance: 50}

If someone has managed before
HTTP/1. 1 412 Precondition Failed
{error: "version_mismatch", currentEtag: "v18"}

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

5. 3 تعارض معنایی (ثابت)

pseudo on Debit(accountId, amount):
current = read(accountId)
if current. balance - amount < 0:
return REJECT ("insufficient _ funds") # write early detection (accountId, version = current. version+1, balance=current. balance - amount)

5. 4 CRDT: OR-تنظیم (طرح)

عناصر با یک برچسب منحصر به فرد، حذف - برای برچسب خاص اضافه شده است.
تضاد «add vs remove» با استفاده از برچسبهای حذف برای حذف تنها برچسبهای قابل مشاهده قابل حل است.

6) سیاست قطعنامه: نحوه رسمی کردن

1. زنجیره اولویت

2. استراتژی های نوع داده: scalars/objects/arrays/multimedia.

3. مدل Causal: آیا شما از نسخه ها، Lamport، ساعت های بردار استفاده می کنید.

4. معناشناسی از دست دادن: چه چیزی میتواند در LWW از دست برود، جایی که اجماع مورد نیاز است.

5. پنجره های زمان: TTL برای deduplication، پنجره های idempotency.

6. تشدید: هنگامی که خودکار قطعنامه ممنوع است، مورد نیاز برای UI/تایید.

7. جبران: استراتژی SAGA «لغو/جبران» برای مونتاژ مجدد invariants.

7) معیارها و SLO

conflicts_total{type} فرکانس بر اساس نوع است.
conflicts_resolved_auto_ratio - سهم مجوز خودکار.
mean_time_to_resolution زمان متوسط برای حل و فصل است.
lost_update_incidents - حوادث به روز رسانی از دست رفته.
idempotency_hit_rate - نسبت کلیدهای Idempotency که کار می کردند.
divergence_depth عمق واگرایی ماکت (بردار نسخه) است.

مثال SLO: «≥ 99٪ از درگیری های نحوی به طور خودکار در ≤ 5 ثانیه حل می شود، درگیری های معنایی در ≤ 15 دقیقه با HITL».

8) سناریوهای عملی

8. 1 پرداخت ها

کلید: Idempotency-Key، OCC در تعادل، SAGA برای مراحل برگشت پذیر.
تعارض: دوبار نوشتن → dedup + بررسی نسخه ترازنامه → جبران جزئی.

8. 2 موجودی/بلیط

گزینه ها: قفل اسلات/صندلی بدبینانه ؛ رزرو خوش بینانه با TTL منقضی ؛ مقایسه و رزرو صف.

8. 3 محتوا/کاتالوگ

ادغام 3 طرفه + HITL: ویرایشگر کل را انتخاب می کند ؛ قوانین خودکار برای زمینه های «امن» (برچسب های SEO که قیمت را تحت تاثیر قرار نمی دهند)

8. 4 GitOps/کوبرنتیز

ارائه و اعتبارسنجی قبل از درخواست ؛ رد کردن کلیدهای ناشناخته ؛ ممنوعیت «--force» بدون بررسی.
تشخیص رانش و عقب نشینی سیاست.

9) ضد الگوهای

LWW در همه جا: سادگی به قیمت از دست دادن علیت.
Retrays پنهان بدون idempotency: بهمن مانند تکراری.
بدون سیاست آرایه صریح - از دست دادن خاموش نقاط پیکربندی.
mutexes جهانی در بالای شبکه: SPOF و قفل طولانی است.
غرامت «کور» بدون حسابرسی علت: درگیری های مکرر.

10) چک لیست پیاده سازی

• تعریف انواع درگیری دامنه و ناوردا.
• مکانیسم نسخه بندی (ETag/xmin/vector clock) را انتخاب کنید.
• فعال کردن idempotency در POST بحرانی/دستورات.
• سیاست ادغام را با نوع داده (scalars/arrays/objects) تنظیم کنید.
• اعتبار سنج های طرح و چک های دامنه قبل از ارتکاب را فعال کنید.
• پیکربندی برخورد و معیارهای هشدار.
• برای نهادهای مهم - رهبر/اجماع، و یا CRDT.
• کار HITL جریان و UX (تفاوت، نظرات، ورود به سیستم حسابرسی).
• سند SLO ها و روش های جبران خسارت (SAGAs).

11) سوالات متداول

س: چه زمانی CRDT را انتخاب کنیم و چه زمانی اجماع را انتخاب کنیم ؟

A: CRDT مناسب است زمانی که انطباق نهایی قابل قبول است و در دسترس بودن بالا/ورودی های محلی مهم است. اجماع - برای داده هایی با متغیرهای سفت و سخت و نظم دقیق عملیات (مانده نقدی، حقوق دسترسی).

س: آیا LW کافی است ؟

A: برای انبارها، معیارها و شاخص های ثانویه - اغلب بله. برای داده های کاربر و پول، تقریبا همیشه نیست.

س: چگونه یک پنجره deduplication را انتخاب کنم ؟

A: تمرکز بر حداکثر تاخیر تحویل مجدد انتظار می رود + جرقه شبکه، اضافه کردن حاشیه 3-5 × مورد 99.

س: آیا همیشه باید HITL را انجام دهید ؟

پاسخ: نه. ترک HITL برای اختلاف/درگیری ارزش خودکار و ورود به سیستم بقیه.

12) مجموع

تشخیص و حل تعارض مؤثر ترکیبی از نسخه بندی، برچسب های علی، ناوردایی و سیاست روشن است که با الگوریتم های مناسب (CRDT/OT/OCC/MVCC/اجماع) و مشاهده پذیری تکمیل می شود. سیستم هایی که در آن درگیری یک وضعیت «عادی» است، قابل دسترسی و قابل پیش بینی است ؛ سیستم هایی که در آن درگیری یک «استثنا» است، در بدترین زمان ممکن شکسته می شوند. یک مدل را انتخاب کنید، قوانین را رسمی کنید و نتیجه را اندازه گیری کنید.