سلام به همه ،
در این مقاله ، من می خواهم به شما نشان دهم که چگونه می توانید از الگوی بازیگر در یک محیط AWS استفاده کنید. این امکان وجود دارد که شما در حال حاضر از مدل بازیگر استفاده کنید بدون اینکه متوجه شوید این رویکرد در واقع یک نام دارد – بازیگر.
بازیگر چیست؟
من کاملاً مطمئن هستم که نمی توانم بهتر از شخصی که مدل بازیگر را اختراع و رسمیت داده است ، توضیح دهم ، به همین دلیل من تماشای این فیلم را به شدت توصیه می کنم.
https://www.youtube.com/watch؟v=7erj1dv_tlo
بگذارید فقط یک مقاله سریع اضافه کنم و به شما نشان دهم که چگونه مدل بازیگر را در AWS پیاده سازی کنید.
مدل بازیگر یک مدل مفهومی است که در علوم کامپیوتر برای انجام محاسبات همزمان استفاده می شود. در این مدل ، یک بازیگر یک موجود محاسباتی است که در پاسخ به دریافت پیام ، می تواند:
-
انجام یک کار (به عنوان مثال ، داده های پردازش یا تصمیم گیری) ،
-
ارسال پیام به سایر بازیگران ،
-
بازیگران جدید ایجاد کنید ، و
-
وضعیت داخلی آن را به روز کنید.
هر بازیگر به طور مستقل فعالیت می کند و فقط با ارسال پیام ارتباط برقرار می کند ، که به جلوگیری از مسائل مربوط به حافظه مشترک کمک می کند و باعث می شود سیستم ها مقیاس و دلیل آن را آسان تر کنند. بگذارید دوباره از کلمات استفاده کنم.
بازیگر
- سبک وزن و ایجاد هزاران نفر از آنها آسان است
- حالت خاص خود را دارد
- دارای صندوق پستی خود (صف)
- فقط از طریق پیام ها می توانند با یکدیگر ارتباط برقرار کنند
- پیام ها به ترتیب FIFO پردازش می شوند
- فقط یک پیام را به طور هم زمان پردازش کنید
- جدا شده
در AWS ، می توانید الگوی بازیگر را با استفاده از خدماتی مانند:
- AWS Lambda (به عنوان بازیگران انفرادی)
- آمازون SQS یا SNS (برای ارسال پیام)
- توابع مرحله یا Eventbridge (برای ارکستراسیون)
- DynamoDB (به عنوان یک ذخیره سازی/حالت)
به نظر می رسد که مدل بازیگر به سادگی ترکیبی از یک سرویس صف است ، یک تابع لامبدا که توسط آن صف ایجاد شده است ، و یک جدول DynamoDB – و شما بیشتر درست خواهید بود. با این حال ، برخی از تفاوت های ظریف وجود دارد ، و من می خواهم شما را از طریق آنها طی کنم.
الزام
یک مورد استفاده معمولی مناسب برای مدل بازیگر یک سبد خرید در یک برنامه تجارت الکترونیکی است. شما به راحتی در بسیاری از مقالات این مثال را خواهید دید ، به همین دلیل به جای آن موارد کمی متفاوت را ارائه می دهم.
بیایید یک برنامه fintech را تصور کنیم که کاربر بتواند پول را به حساب خود واریز کند یا آن را به حساب دیگری منتقل کند. در دنیای fintech ، این عملیات به معاملات گفته می شود و به طور معمول در دو دسته قرار می گیرند: سپردن وت انتقالبشر
مثال دیگر فروشگاهی است که محصولات در هر زمان می توانند وارد شوند و از آنجا خارج شوند. برای جلوگیری از سقوط موجودی زیر صفر ، باید اطمینان حاصل کنیم که همه ورودی ها قبل از هرگونه عزیمت پردازش می شوند.
🎯 من از این دو سناریو استفاده می کنم تا نحوه اجرای یک راه حل مناسب ، مقیاس پذیر و از همیشه زیر صفر را با استفاده از منابع AWS و مدل بازیگر نشان دهم.
اکنون ما چیزهای زیادی برای پوشاندن داریم ، بنابراین بیایید به داخل پرش کنیم و بلافاصله شروع کنیم
راه حل
رویکرد اولیه: مقیاس پذیری محدود
ما می توانیم معاملات خود را به دو دسته تقسیم کنیم: اولی که فقط شامل معاملات سپرده گذاری می شود و دوم شامل معاملات انتقال. این دسته ها سپس برای پردازش به یک صف FIFO ارسال می شوند. با استفاده از همان گروه پیام برای همه پیام ها ، برای کمک به ما در پردازش معامله به ترتیب صحیح و پوشش سناریویی که کاربر قبل از انتقال آن به کاربر دیگری واریز می کند.
در ابتدا با محصولات همان ایده ، همه ورودی ها را پردازش می کنیم و فقط پس از آن عزیمت می کنیم.
بیایید نگاهی بصری به نحوه عملکرد جریان ما بیندازیم:
تصور کنید که Lambda 1 قبلاً محصولات/معاملات را مرتب و فیلتر کرده است و آنها را یکی یکی به صف ارسال می کند. Lambda 2 توسط صف ایجاد می شود و هر پیام را به صورت جداگانه پردازش می کند ، و اطلاعات مفیدی را مانند مقدار محصولات یا مانده نقدی مشتری در یک جدول DynamoDB ذخیره می کند. گردن بطری این رویکرد فرآیند لامبدا است زیرا همیشه فقط یک نمونه است.
راه حل مقیاس پذیر با استفاده از مدل بازیگر
برای حل این مسئله ، الگوی بازیگر مفید است. قبل از توصیف راه حل ، می خواهم دوباره تأکید کنم که هر بازیگر باید وضعیت خود را داشته باشد ، صف کند و یک کار را انجام دهد. در راه حل غیر قابل مقیاس ، عملکرد لامبدا پردازش تمام این خصوصیات را دارد و ممکن است مانند یک بازیگر به نظر برسد-اما وضعیت این بازیگر چیست؟ احتمالاً شما می گویید که این DynamoDB است ، و شما درست خواهید بود – اما این یک حالت مشترک برای کل برنامه است. کاری که من می خواهم در عوض انجام دهم این است که آن را به کوچکترین قطعات ممکن تقسیم کنید. در این حالت ، این می تواند مشتری یا productid باشد ، نمی تواند؟
بنابراین ، این به ما کمک می کند تا وظیفه خود را حل کنیم.
بنابراین ، بیایید اجرای بازیگر را تجزیه کنیم:
-
اولین عملکرد Lambda در حال حاضر دارای لیست مرتب شده ای از محصولات یا معاملات است و آنها را یک به یک به یک صف FIFO می فرستد و از MessageGroupId به عنوان ClientID یا ProductID استفاده می کند.
-
این صف چندین نمونه از عملکرد لامبدا پردازش را ایجاد می کند و آنها را در صورت لزوم ایجاد می کند. هر نمونه پیام های گروه بندی شده توسط MessageGroupId را پردازش می کند ، و به طور موثری جریان را برای هر مشتری یا محصول جدا می کند.
MessageGroupId در FIFO SQS:
- سفارش دقیق را در همان گروه پیام تضمین می کند.
- فقط یک لامبدا به طور همزمان یک گروه پیام را پردازش می کند.
- اگر دو پیام دارای یک پیامدهای یکسان باشند ، به ترتیب یک به یک پردازش می شوند.
- اگر دو پیام دارای گروههای مختلف پیام (به عنوان مثال ، مشتری -1 ، مشتری-2) باشند ، می توانند به طور همزمان توسط دعوت های جداگانه لامبدا پردازش شوند.
در نتیجه ، ما یک راه حل مقیاس پذیر داریم که در آن هر عملکرد لامبدا پردازش به سه ویژگی اصلی مدل بازیگر متناسب است.
💡 به عنوان یک جایزه اگر یک پیام در حال پردازش باشد (خطای Lambda) ، SQS پیام بعدی را در آن گروه ارائه نمی دهد تا زمانی که یک نفر شکست خورده با موفقیت اداره شود یا به DLQ منتقل شود.
درج کردن
🚀 مدل بازیگر یک الگوی قدرتمند برای ایجاد سیستم های مقیاس پذیر و همزمان است و AWS به ما ابزارهایی می دهد تا آن را به طور مؤثر پیاده سازی کنیم. با اختصاص دولت و صف برای هر بازیگر (به عنوان مثال ، در هر مشتری یا محصول) و ترکیب لامبدا با صف FIFO SQS ، می توانیم سیستم های قوی و تحمل گسل ایجاد کنیم که با زحمت مقیاس می یابد.
همچنین ، فراموش نکنید که هر حساب AWS دارای سهمیه لامبدا است – به ویژه در مورد اعدام های همزمان. توصیه می کنم قبل از تولید ، این محدودیت ها را به درستی پیکربندی کنید.
اگر می خواهید از کار من حمایت کنید ، می توانید مشترک شوید ، به من kudos بدهید یا بازخورد ارزشمند خود را به اشتراک بگذارید. پشتیبانی و بینش شما معنی زیادی دارد!
