برنامه نویسی

صف های پیام رسانی (Rabbitmq به عنوان کارگزار)

از آنجایی که توسعه باطن فراتر از ساخت برنامه های کاربردی CRUD است، من اینجا هستم تا یکی از مفاهیم اصلی توسعه باطن که صف پیام است را مورد بحث قرار دهم.

در DSA، صف ها اساساً ساختاری هستند که از قانون FIFO (First In First Out) پیروی می کنند. به این معنی که اولین عنصری که وارد می شود، اولین عنصری است که درست مانند صف در بانک ها، فروشگاه ها و غیره پردازش می شود.

صف پیام شکلی از ارتباط سرویس به سرویس ناهمزمان است که در معماری های بدون سرور و میکروسرویس استفاده می شود. پیام ها تا زمانی که پردازش و حذف شوند در صف ذخیره می شوند. هر پیام فقط یک بار توسط یک AWS مصرف کننده پردازش می شود.

امروز در مورد مواردی که برای داشتن نوعی سرور قابل اعتماد هنگام استفاده از Rabbitmq به عنوان بروکر پیام باید در نظر گرفته شود صحبت خواهم کرد.

  • تأیید پیام: انجام یک کار ممکن است چند ثانیه طول بکشد، ممکن است تعجب کنید که چه اتفاقی می‌افتد اگر یک مصرف‌کننده یک کار طولانی را شروع کند و قبل از اتمام آن پایان یابد. اساساً هنگامی که تولیدکننده ما پیامی را به مصرف کننده می دهد، آن را برای حذف علامت گذاری می کند. در این حالت، اگر یک کارگر را خاتمه دهید، پیامی که در حال پردازش بود از بین می رود. پیام هایی که به این کارگر خاص ارسال شده اما هنوز رسیدگی نشده اند نیز از بین می روند. اگر کارگری فوت کند، مایلیم کار به کارگر دیگری تحویل داده شود. به منظور جلوگیری از این اتفاق، Rabbitmq تأیید پیام را ارائه می دهد. اگر یک مصرف کننده بدون ارسال اک بمیرد (کانالش بسته شود، اتصال بسته شود یا اتصال TCP قطع شود)، RabbitMQ متوجه می شود که یک پیام به طور کامل پردازش نشده است و آن را دوباره در صف قرار می دهد. اگر به طور همزمان مشتریان دیگری به صورت آنلاین وجود داشته باشند، به سرعت آن را دوباره به مصرف کننده دیگری تحویل می دهد. به این ترتیب می توانید مطمئن باشید که هیچ پیامی از بین نمی رود، حتی اگر کارگران گهگاه بمیرند.

برای رسیدن به این هدف، این کار را انجام دهید

def callback(ch, method, properties, body):
    # your code
    ch.basic_ack(delivery_tag = method.delivery_tag)

channel.basic_consume(queue='hello', on_message_callback=callback)
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

  • ماندگاری پیام: ما یاد گرفته‌ایم که وقتی یک کارگر متوقف می‌شود چگونه وظایف را انجام دهیم. اگر کارگزار ما متوقف شود، چگونه با آنها رفتار کنیم؟ هنگامی که RabbitMQ خارج می شود یا از کار می افتد، صف ها و پیام ها را فراموش می کند، مگر اینکه به آن بگویید این کار را نکند. برای اطمینان از گم نشدن پیام‌ها، دو چیز لازم است: باید هم صف و هم پیام‌ها را به‌عنوان ماندگار علامت‌گذاری کنیم. این باید هم برای تولید کننده و هم برای مصرف کننده (یا کارگر) انجام شود.
channel.queue_declare(queue='queue_name', durable=True)
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

اگر قبلاً صفی ایجاد کرده‌اید که بادوام نیست، به‌روزرسانی آن تغییری در آن ایجاد نمی‌کند، بنابراین بهتر است در ابتدا این کار را انجام دهید.

در آن مرحله، ما مطمئن هستیم که حتی اگر RabbitMQ دوباره راه اندازی شود، صف task_queue از بین نخواهد رفت. اکنون باید پیام‌های خود را به‌عنوان پایدار علامت‌گذاری کنیم – با ارائه یک ویژگی delivery_mode با مقدار pika.DeliveryMode.Persistent

channel.basic_publish(
    exchange="",
    routing_key="queue_name",
    body=message,
    properties=pika.BasicProperties(delivery_mode=pika.DeliveryMode.Persistent),
)
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

  • ارسال منصفانه: به طور پیش‌فرض، اگر چندین کارگر/مصرف‌کننده در حال اجرا داشته باشیم، rabbitmq سعی می‌کند وظایف را به طور یکنواخت با این کارگران با استفاده از الگوریتم دورگرد (RRA) به اشتراک بگذارد، اما چه می‌شود اگر یک کارگر قبلاً کارش را انجام داده باشد و بقیه انجام نشده باشند چه می‌شود. اما به دلیل RRA، نوبت آن نیست، بنابراین بیکار می شود و درخواست به کارگر دیگری که در حال پردازش یک کار است اضافه می شود. برای رفع این مشکل باید از اعزام منصفانه در کارگر استفاده کنید.
channel.basic_qos(prefetch_count=1)
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا