معماری Message Queue

Message Queue مفهومی در زمینه برنامه نویسی Async است. فرض کنید بعد از انجام یک عملیات مثل پرداخت باید یک پیامک یا ایمیل ارسال شود. در این صورت عملیات پرداخت نباید به ارسال ایمیل وابسته باشد. در واقع این عملیات های باید Async باشند. پرداخت انجام میشود و یک Task به اسم ایمیل در صف پرداخت قرار میگیرد که در اولین فرصت ایمیل ارسال شود. در مورد اینکه چرا باید از این معماری استفاده کرد یا مزایا یا معایب آن چیست صحبتی ندارم و میشود در اینترنت این موارد را جست.

اینجا معماری کلی آن را میبینیم که در اینترنت ممکن است مورد مفهومی دیده نشود.

عکس بالا رو ببینید:

اول از همه یک سری Task داریم. مثلا گزارش ماهانه مالی، ارسال ایمیل، تهیه thumbnail از عکس بارگزاری شده و.. اینها مثالهایی از تسک هایی هستند که باید Async انجام بشه. گزارش ماهانه که قراره سر ماه نصب شب آماده بشه که فردا صبح کارمندان ازش استفاده کنن باید مستقل از نرم افزار باشه و به صورت تسکی ماهانه انجام بشه.

این تسک ها توی یک صف قرار میگیرند که به ترتیب انجام شن. این صف رو Rabbit MQ یا Redis براموان فراهم میکنن.

بعد تسک ها به ترتیب به Worker هایی داده میشن. در واقع worker ها این تسک ها رو انجام میدن. توی پایتون از celery استفاده میشه معمولا. خود Task ها هم توابعی هستند که به Celery داده میشن.

بعد از اینکه تسک انجام شد ممکنه بخوایم خروجیش رو نگه داریم معمولا Redis گزینه خوبیه. اگر بخواهیم که به صورتی دایمی داشته باشیم خروجی رو توی یک دیتابیس باید ذخیره کنیم.

گفتیم مثلا اگر پرداخت انجام شد باید ایمیل ارسال بشه. خوب مشخصه توی این مثال بعد از انجام پرداخت تسک ارسال ایمیل فراخوانی میشه. اما بعضی تسک ها خود به خود توی بازه های زمانی خاصی باید انجام بشه. اینجا به Schedualer نیاز داریم. Celery قابلیتی داره به اسم Beat که برنامه ریزی با اون انجام میشه و تسک ها رو خودش triger میکنه.

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

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