🙋‍♂️ سوال
من ۲ تا microservice دارم که یک message broker بینشون هست.
سرویس اول یه worker داره که از یکی از جداول دیتابیس همه event هایی که وضعیت new دارند رو میخونه و داخل broker منتشر میکنه. بعد از انتشارشون وضعیت eventها رو آپدیت میکنه که دیگه ارسال نشن.
سرویس دوم مسئولیت پردازش eventهارو داره.
نگرانی من اینه اگه worker همه eventهارو داخل broker ریخت ولی نتونست وضعیتشون رو بروز کنه تو دیتابیس، خب دفعه بعد مجددا این eventهارو داخل broker میریزه و مشکل بوجود میاد، چیکار کنم؟


⚠️ پاسخ بسیار ناقص و احتمالا پر از غلط بنده
ببین شما باید idempotency رو رعایت کنی بین microservice هات. این خودکفایی یا همون idempotency اینو میگه که وقتی شما message driven کار میکنی سرویس هات باید انتظار اینو داشته باشن که یه unique message رو بیش از یکبار دریافت کنن ولی فقط یکبار proccess کنن. برای message broker ها سه تا service quality وجود داره
at most once delivery
exactly once delivery
at least once delivery

به خاطر همین مشکلات network و delivery و چیزهای دیگه exactly once delivery خیلی کار سختیه، حالت اول و سوم رایج تر بنظر میاد. در حالت at most delivery هر سرویس نهایتا یک بار یه event رو دریافت میکنه، پس اصلا نیاز نیست نگران idempotency باشه و بیشتر به درد بیزینس هایی میخوره که miss شدن یه event مشکلی ایجاد نکنه، مثلا notification های یه سایت خبری
حالت سوم که at least once delivery هست احتمال دریافت یه event بیش از یکبار وجود داره ولی خب تضمین میکنه حتما هر consumer یکبار اون event خاص رو حداقل دریافت میکنه.
در مورد چالش شما، شما حالت سوم رو لازم دارید، پس سرویس مقصد باید انتظار داشته باشه یه مسیج رو حتی چندبار دریافت کنه به خاطر مشکلاتی که گفتید، و این طبیعیه و مشکلی نداره. سمت سرویس consumer باید مثلا id پیام و job های process شده رو ذخیره کنه و با دریافت هر پیام جدید چک کنه آیا این پیام قبلا پردازش شده یا نه، اگه پردازش نشده بود پردازشش کنه.
اینطوری سرویس publisher دیگه نگران این نیست حالا اگه message تو broker رفت و جدول دیتابیس آپدیت نشد چی میشه، هیچی نمیشه، یه بار اضافه تر یه سری پیام رو میریزه تو broker که مشکلی نیست.
ضمنا یه سری broker ها مفهوم message deduplication دارن که برای اون حالت exactly once به کار میاد، اینطوریه که خود broker میاد id پیام های ریخته شده در broker رو نگه میداره (حتی تا مدتی بعد از consume شدنشون)، اینطوری اگه مجددا همون message رو با id تکراری بهش بدی خودش متوجه میشه و ignoreش میکنه

در مورد transactional outbox و idempotency و message deduplication سعی کن یه مطالعه ای داشته باشی، مرسی

https://segment.com/blog/exactly-once-delivery/

این پادکست هم شنیدنش شاید کمک کنه
Eventually consistent (managing data at scale)
https://changelog.com/gotime/206

#qa #distributed_systems

@gocasts