منبع یابی رویداد: اصول اولیه

منبع یابی رویداد چیست

Event Sourcing (ES) یک روش ذخیره سازی وضعیت اشیاء دامنه نه به عنوان «خط فعلی» بلکه به عنوان یک رویداد غیرقابل تغییر است که همه چیز را توصیف می کند. وضعیت فعلی مجموع با بالا بردن (پخش) رویدادهای آن به دست می آید و هر دیدگاه خوانده شده به عنوان پیش بینی ها در بالای این ورودی ساخته می شود.

• تاریخ «منبع اصلی حقیقت» است، دولت طرح ریزی تاریخ است.
• هر کشوری می تواند تکرار، بررسی و توضیح داده شود (حسابرسی).
• اضافه کردن نماها و تجزیه و تحلیل های جدید نیازی به مهاجرت «عکس های فوری» قدیمی ندارد - کافی است رویدادها را از دست بدهید.

شرایط اساسی

Aggregate - واحد سازگاری دامنه با متغیرهای روشن (سفارش، پرداخت، UserBalance).

رویداد - یک واقعیت بدون تغییر که در گذشته رخ داده است ("پرداخت. مجاز '،' سفارش. حمل می شود.)

فروشگاه رویداد ضمیمه تنها ورود به سیستم فراهم می کند که منظور از حوادث در واحد است.
نسخه Aggregate تعداد آخرین رویداد اعمال شده (برای همزمانی خوش بینانه) است.
Snapshot - یک تصور دوره ای از حالت برای سرعت بخشیدن به کانولوشن.
طرح ریزی (مدل خواندنی) - نمای تحقق یافته برای خواندن/جستجو/گزارش (اغلب ناهمزمان).

چگونه کار می کند (موضوع → رویدادها → پیش بینی ها)

1. مشتری یک دستور («CapturePayment»، «PlaceOrder») ارسال می کند.
2. مجموع ناورداها را تأیید می کند و اگر همه چیز خوب باشد، رویدادها را تولید می کند.
3. رویدادها به صورت اتمی به فروشگاه رویداد با تأیید نسخه (همزمانی خوش بینانه) اضافه می شوند.
4. پردازنده های پروجکشن به جریان رویداد مشترک می شوند و مدل های خواندن را به روز می کنند.
5. هنگامی که aggregate برای دستور زیر بارگذاری می شود، وضعیت به snapshot (در صورت وجود) → رویداد بعد از snapshot بازگردانده می شود.

طراحی رویداد

ویژگی های مورد نیاز (هسته)

json
{
"event_id": "uuid",
"event_type": "payment. authorized. v1",
"aggregate_type": "Payment",
"aggregate_id": "pay_123",
"aggregate_version": 5,
"occurred_at": "2025-10-31T10:42:03Z",
"payload": { "amount": 1000, "currency": "EUR", "method": "card" },
"meta": { "trace_id": "t-abc", "actor": "user_42" }
}

• نام گذاری: دامنه فعالیت. v {سرگرد}.
• Additivity: زمینه های جدید اختیاری هستند، بدون تغییر معنای قدیمی.
• مینیمالیسم: فقط حقایق، بدون تکرار اطلاعات قابل بازیابی به راحتی.

قراردادها و طرح ها

اصلاح طرح ها (Avro/JSON Schema/Protobuf) و بررسی سازگاری در CI.
برای تغییرات «breaking» - نسخه اصلی جدید رویداد و انتشار موازی «v1 »/« v2» برای دوره مهاجرت.

دسترسی رقابتی: همزمانی خوش بینانه

قانون: رویدادهای جدید تنها زمانی میتوانند نوشته شوند که 'expected _ version = = current_version' باشد.

pseudo load: snapshot(state, version), then apply events > version new_events = aggregate. handle(command)
append_to_store(aggregate_id, expected_version=current_version, events=new_events)
//if someone has already written an event between load and append, the operation is rejected -> retray with reload

بنابراین ما یکپارچگی ناورداها را بدون معاملات توزیع شده تضمین می کنیم.

عکس های فوری (شتاب کانولوشن)

یک عکس فوری از هر N رویداد یا تایمر بگیرید.
Храните 'snapshot _ state', 'aggregate _ id', 'version', 'created _ at'.
همیشه رویدادهای بعد از عکس فوری را بررسی کنید (فقط به بازیگران اعتماد نکنید).
حذف عکس های فوری به طوری که آنها را می توان از ورود به سیستم دوباره (ذخیره نمی «سحر و جادو» زمینه).

پیش بینی ها و CQRS

• Write-model = aggregates + فروشگاه رویداد.
• خواندن مدل ها = پیش بینی های به روز شده توسط رویدادها (کارت های Redis، OpenSearch برای جستجو، ClickHouse/OLAP برای گزارش).
• پیش بینی ها بی نظیر هستند: پردازش مجدد همان «event _ id» نتیجه را تغییر نمی دهد.

تکامل مدار و سازگاری

افزودنی اول: اضافه کردن زمینه ها ؛ نوع/معانی را تغییر ندهید.
برای تغییرات پیچیده، انواع رویدادهای جدید را منتشر کنید و projection migrators را بنویسید.
برای دوره انتقال یک ورودی دوگانه («v1» + «v2») را حفظ کنید و زمانی که همه پیش بینی ها آماده هستند، «v1» را شلیک کنید.

امنیت، PII و «حق فراموش شدن»

• به حداقل رساندن PII در رویدادها (شناسه ها به جای داده ها، جزئیات در طرف محافظت شده).
• Crypto-erase: فیلدها را رمزگذاری می کند و هنگامی که برای حذف درخواست می شود، کلید را از بین می برد (رویداد باقی می ماند، اما داده ها در دسترس نیستند).
• رویدادهای بازبینی: "کاربر. به عمل آورد. v1 "با جایگزینی زمینه های حساس در پیش بینی ها (تاریخ واقعیت ویرایش را حفظ می کند).
• سیاست های نگهداری: برای برخی از دامنه ها، برخی از رویدادها را می توان به ذخیره سازی WORM بایگانی کرد.

عملکرد و مقیاس

پارتیشن بندی: ترتیب در داخل aggregate مهم است - پارتیشن بندی توسط 'agregate _ id'.
شروع سرد: عکس های فوری + کانولوشن دوره ای «فشرده سازی».
ضمیمه دسته ای - رویدادهای گروه در یک معامله.
فشار پشتی و DLQ برای پردازنده های طرح ریزی ؛ اندازه گیری تاخیر (زمان و تعداد پیام ها).
نمایه سازی فروشگاه رویداد: دسترسی سریع توسط '(aggregate_type، aggregate_id) و با زمان.

تست کردن

تست مشخصات برای aggregates - «دستورات → رویدادهای مورد انتظار» سناریو.
تست های پروجکشن: جریان رویداد را تغذیه کنید و وضعیت/شاخص های تحقق یافته را بررسی کنید.
تست های تکرارپذیری: پیش بینی ها را از ابتدا بر روی پایه بازسازی کنید - اطمینان حاصل کنید که نتیجه مطابقت دارد.
هرج و مرج/تاخیر: تاخیر تزریق و طول می کشد، بررسی idempointence.

نمونه هایی از دامنه ها

1) پرداخت

رویدادها: "پرداخت. آغاز شده، پرداخت. مجاز، پرداخت. پرداخت شده است. بازپرداخت شده است ".
ثابت: شما نمی توانید بدون «مجاز» گرفتن ؛ مقادیر منفی نیستند ؛ ارز بدون تغییر است.
پیش بینی ها: «کارت پرداخت» (KV)، جستجوی معامله (OpenSearch)، گزارش (OLAP).

2) سفارشات (تجارت الکترونیک)

رویدادها: "سفارش. قرار داده شده «،» سفارش. پرداخت، سفارش. بسته بندی شده، سفارش. حمل و نقل، سفارش. تحویل داده شد.
تغییرناپذیر: انتقال وضعیت نمودار حالت ؛ لغو قبل از «حمل» امکان پذیر است.
پیش بینی ها: لیست سفارشات کاربر، تخته SLA بر اساس وضعیت.

3) ترازنامه (امور مالی/iGaming)

وقایع: "تعادل. سپرده، تعادل. پرداخت شده، تعادل. اعتبار، تعادل. تنظیم شده است.
متغیر سخت: تعادل از بین نمی رود <0 ؛ دستورات 'operation _ id' هستند.
عملیات بحرانی به طور مستقیم از مجموع (سازگاری سخت)، UI - از طرح ریزی (نهایی) خوانده می شود.

ساختار فروشگاه رویداد معمولی (نوع DB)

رویدادها

'event _ id (PK)'، 'aggregate _ type'، 'aggregate _ id'، 'version'، رخ داده است _ at '،' event _ type '،' payload '،' meta '

فهرست: '(aggregate_type، aggregate_id، نسخه)'.

عکس های فوری

'aggregate _ type', 'aggregate _ id', 'version', 'state', 'created _ at'

فهرست: '(aggregate_type، aggregate_id)'.

consumers_offsets

'consumer _ id'، 'event _ id '/' position'، 'updated _ at' (برای پیش بینی ها و خرده فروشی).

سوالات متداول (FAQ)

آیا استفاده از ES در همه جا اجباری است ؟

نه، اينطور نيست ES زمانی مفید است که حسابرسی، متغیرهای پیچیده، تکرارپذیری و نمایش های مختلف داده ها مهم باشند. برای CRUD ساده، این کار اضافی است.

در مورد درخواستهای «وضعیت فعلی» چطور ؟

یا از طرح ریزی (به سرعت، نهایی) یا از واحد (گران تر، اما به شدت) بخوانید. عملیات بحرانی معمولا از مسیر دوم استفاده می کنند.

آیا به کارگزار کافکا/استریم نیاز دارم ؟

فروشگاه رویداد - منبع حقیقت ؛ کارگزار مناسب برای توزیع رویدادها به پروژکتورها و سیستم های خارجی است.

با «حق فراموش شدن» چه باید کرد ؟

به حداقل رساندن PII، رمزگذاری زمینه های حساس و اعمال رمزنگاری پاک کردن/redaction در پیش بینی.

چگونه اطلاعات قدیمی را انتقال دهیم ؟

یک اسکریپت برای تولید رویداد گذشته نگر («re- highstory») بنویسید یا با «state-as-is» شروع کنید و رویدادها را فقط برای تغییرات جدید منتشر کنید.

ضد ضربه

Event Sourcing «out of habit»: سیستم را بدون مزایای دامنه پیچیده می کند.
حوادث چربی: بارهای نفخ با PII و دو برابر - ترمز و مسائل مربوط به انطباق.

عدم همزمانی خوش بینانه: از دست دادن ناورداها هنگام مسابقه

پیش بینی های غیر قابل تجدید: بدون پخش/عکس های فوری → رفع دستی.
CDC های خام به عنوان رویدادهای دامنه: طرح های DB نشت شده و اتصال سخت.
مخلوط کردن رویدادهای داخلی و ادغام: یک «ویترین» تثبیت شده را در خارج منتشر کنید.

چک لیست تولید

• Aggregates، invariants و رویدادها (عناوین، نسخه ها، طرح ها) تعریف می شوند.
• فروشگاه رویداد نظم را در همروندی جمع و خوش بینانه فراهم می کند.
• عکس های فوری و طرح بازسازی آنها گنجانده شده است.
• پیش بینی ها بی نظیر هستند، DLQ ها و معیارهای تاخیر وجود دارد.
• طرح ها در CI تأیید می شوند، سیاست نسخه مستند شده است.
• PII به حداقل می رسد، زمینه ها رمزگذاری می شوند، یک استراتژی «فراموش کردن» وجود دارد.
• پخش مجدد روی نیمکت بررسی شد. یک برنامه بازیابی فاجعه دارد.
• داشبورد: سرعت برنامه، تاخیر طرح، خطاهای برنامه، نسبت retrays.

مجموع

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