انتشار و اشتراک گذاری

انتشار کننده

کد منبع کامل: github.com/ThreeDotsLabs/watermill/message/pubsub.go

// ...
type Publisher interface {
	// Publish تعدادی پیام را به موضوع داده شده انتشار می‌دهد.
	//
	// انتشار ممکن است همزمان یا ناهمزمان باشد - این بستگی به پیاده‌سازی دارد.
	//
	// بیشتر پیاده‌سازی‌های انتشار تایید انتشار اتمی پیام را پشتیبانی نمی‌کنند.
	// این بدان معنی است که اگر انتشار یکی از پیام‌ها شکست خورد، پیام بعدی انتشار نخواهد یافت.
	//
	// انتشار باید از رشته‌های متداول پشتیبانی کند.
	Publish(topic string, messages ...*Message) error
	// اگر انتشار ناهمزمان است، باید  Close باید پیام‌های ارسال نشده را پاک کند.
	Close() error
}
// ...

انتشار چند پیام

بیشتر پیاده‌سازی‌های انتشار تایید انتشار اتمی پیام را پشتیبانی نمی‌کنند. این بدان معنی است که اگر انتشار یکی از پیام‌ها شکست خورد، پیام بعدی انتشار نخواهد یافت.

انتشار ناهمزمان

انتشار ممکن است همزمان یا ناهمزمان باشد - این بستگی به پیاده‌سازی دارد.

Close()

اگر انتشار ناهمزمان است، باید Close پیام‌های ارسال نشده را پاک کند. فراموش نکنید که مشترک‌ها را ببندید. در غیر اینصورت، ممکن است برخی از پیام‌ها را از دست بدهید.

مشترک

کد منبع کامل: github.com/ThreeDotsLabs/watermill/message/pubsub.go

// ...
type Subscriber interface {
	// Subscribe یک کانال خروجی با پیام‌ها از موضوع داده شده را برمی‌گرداند. 
	// این کانال هنگامی که `Close()` روی مشترک فراخوانی شود بسته می‌شود.
	//
	// برای دریافت پیام بعدی، باید `Ack()` روی پیام دریافتی فراخوانی شود.
	// اگر پردازش پیام شکست خورد و پیام باید مجددا ارسال شود، باید `Nack()` فراخوانی شود.
	//
	// هنگامی که ctx ارائه شده لغو شود، مشترک اشتراک را می‌بندد و کانال خروجی را بسته می‌کند.
	// ctx ارائه شده برای تمام پیام‌های تولید شده تنظیم می‌شود. 
	// هنگامی که روی پیام Ack یا Nack فراخوانی می‌شود، context پیام لغو می‌شود.
	Subscribe(ctx context.Context, topic string) (
}

مکانیسم Ack/Nack

مشترک‌ها مسئول مدیریت Ack و Nack از مسدود. پیاده‌سازی مناسب باید منتظر Ack یا Nack قبل از مصرف پیام بعدی باشد.

نکته مهم پیاده‌سازی مشترک: مهم است که پس از مواجهه با Ack از پیام Watermill، Ack/offset به ذخیره‌سازی/عامل پیام ارسال شود. در غیر اینصورت، اگر فرایند قبل از پردازش پیام مرده است، احتمال از دست رفتن پیام وجود دارد.

Close()

Close تمام اشتراک‌ها و کانال‌های خروجی آن‌ها را می‌بندد و offsetها را اگر لازم است پاک می‌کند.

حداقل یکبار ارسال

Watermill با استفاده از سمانتیک تحویل حداقل یکبار ساخته شده است. این بدان معنی است که اگر هنگام پردازش پیام خطایی رخ دهد و امکان ارسال Ack وجود نداشته باشد، پیام مجددا ارسال خواهد شد.

شما باید این موضوع را در نظر داشته باشید و برنامه خود را برای پردازش ایدمپوتنت طراحی کنید یا مکانیسم تلاش مجددی را پیاده‌سازی کنید.

متأسفانه، ایجاد یک میان‌افزار تلاش مجدد عمومی امکانپذیر نیست، بنابراین ما شما را تشویق می‌کنیم که پیاده‌سازی خود را بسازید.

تست عمومی

هر Pub/Sub در بیشتر جنبه‌ها مشابه است. برای جلوگیری از نوشتن تست‌های جداگانه برای هر پیاده‌سازی Pub/Sub، ما یک مجموعه تست ایجاد کرده‌ایم که هر Pub/Sub باید پاس کند.

این تست‌ها را می‌توان در pubsub/tests/test_pubsub.go پیدا کرد.

داخلی سازی

برای بررسی پیاده‌سازی‌های موجود Pub/Sub، لطفا به Pub/Sub پشتیبانی شده مراجعه کنید.

پیاده‌سازی سفارشی Pub/Sub

برای دستورالعمل‌های مربوط به ارائه پشتیبانی برای یک Pub/Sub جدید، لطفا به "پیاده‌سازی سفارشی Pub/Sub" مراجعه کنید.