GenStage در الکسیر

درود خدمت دوستان من داشتم همینطور سرچ می کردم در مورد پروسز ها در الکسیر که یک دفعه به مبحثی برخورد کردم به نام GenStage ولی متوجه نشدم این دقیقا چی هست و چرا باید استفاده بشه

ترجمه از گوگل ترنسلیت

مرحله ها مراحل مبادله داده ها هستند که ارسال و یا دریافت اطلاعات از مراحل دیگر.

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

انواع مرحله
علاوه بر مصرف هر دو نقش تولید کننده و مصرف کننده، یک مرحله ممکن است به عنوان «منبع» نامیده شود، در صورتی که تنها موارد را تولید می کند یا به عنوان «سینک» نامیده می شود، اگر تنها موارد مصرف شود.

و همینطور اومدم اینجا برای خوندن اطلاعات بیشتر
https://hexdocs.pm/gen_stage/GenStage.html

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

لازم به ذکره مثال هایی خود داکیومنت زده از نحوه انتقال که کمی متوجه شدم چی هست

با تشکر

#به روز رسانی
اطلاعیه انتشار این مورد در سایت الکسیر

1 Likes

GenStage برای مبادله پیام (event) بین process هاست GenStage برای حل مشکل Back pressure ,
GenEvent وجایگزین کرده
Back pressure: اگر یک سرور که داده رو تولید میکنه Producer بیش از توانایی مصرف کننده ها consumer پیام تولید کنه
consumer ها عقب میافتند و به مرور یکی یکی crash میکنند
برای حل این مشکل در GenStage
consumer ها مقدار پیام که میتونن بگیرند demand و به یک process واسط مفرستن به اسم ProducerConsumer و اون پیام هارو به صورت اتومات تقسیم میکنه

https://engineering.spreedly.com/blog/how-do-i-genstage.html

Reactive Streams در Akka هم همین کارو انجام میده

3 Likes

یک سوال اینجا برام ایجاد می شه در کد ها مثلا می یاند

max_demand

مشخص می کنند این چه معنی می ده؟ مگه هر پروسه که اوکی می شه نمی ره تو صف پس این ‍‍max_demand چه معنی می ده ؟

1 Likes

demand در حالت نرمال تعداد پیام ها که خونده میشه رو کنترل میکنه
max demand حداکثر تعداد پیام که پردازش میشه در یک اکتور کنترل می کنه
فرض کن به هر دلیلی سیستم پایین بوده و ۱۰ میلیون پیام عقب افتاده، اگه فقط demand گذاشته باشی احتمال داره این کم باشه و هیچوقت سیستم به شرایط نرمال برنگرده و همیشه چند ساعت عقب باشه اما اگه max demand نباشه احتمال داره consumer تمام یک میلیون پیام یک جا پردازش کنه و بره پایین. Max demand همیشه باید از سرعت تولید پیام ها ۲-۳ برابر بیشتر باشه ولی در حد معقولی باشه که سرور بتونه پردازش کنه
سپارک هم همین پارامتر هارو داره max offsets per trigger

2 Likes

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

1 Likes
1 Likes
2 Likes

مثل اینکه سام عزیز خیلی هم ازش تعریف کردن

2 Likes

دوستان من این کتاب دیروز خریدم به نظرم ضروری هست هر کسی که الیکسیر کار می کنه این کتاب رو بخره

می تونی یاد بگیری که بعدا spark و flink کارکنی :smiling_imp:

2 Likes

سام عزیز اونا مرحله آخرند :smiley: داخل این کتاب rabbitMQ رو یاد می ده . بالاخره مجبور شدیم یاد بگیریم پول دادیم برای کتاب حروم نشه :joy: :joy:

5 Likes

دوستان عزیز اگر کد تخفیف می خواند برای این کتاب اینجا استفاده کنند

من زود خریدم حیف شد :smiley:

1 Likes

اینم یک مقاله خوب برای درک بهتر

1 Likes

مرتبط با این قضیه، امروز این پست رو دیدم و جالب بود:

1 Likes

تو این کتاب در بخش آخر نسخه B1 به مبحث ConsumerSupervisor اشاره می کنه که خیلی جالب به نظر می یاد. ولی کم نوشته کاشکی مثال های خیلی زیادی می زد

در کل برای من که این GenStage سخت هست مبحثش فکر می کنم به این بر می گرده که چطوری و با چه پروژه ای بتونی جایگاهشو تو کدت پیدا کنی اون موقع هست که قشنگ درک می شه

1 Likes

دوستان نسخه جدید کتاب اومده که فصل
“Processing Collections with Flow”

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

*Added Chapter 4, Processing Collections with Flow.

		
*Added Inspecting Supervisors at Runtime.

		
*Fixed various errata.

در فصل آخر کتاب در مورد broadway هست که تاپ لول جن استیج نوشته شده و ارتباط خیلی راحت بدون دردسر با RabbitMQ داره . من امشب بالاخره موفق به خواندن کاملش شدم. بسیار لذت بخش و جالب هست.

من فقط یک مورد متوجه نشدم. مورد ساخت صف و … که مشخص هست به واسطه RabbitMQ اوکی می شه کار انجام می شه

ولی بخش مربوط به اینکه شما یک پیام می فرستی و بخش هایی مثل سیستم حساب داری و ارسال ایمیل گوش وای می ایستند داخل چنل که اطلاعات ثبت شد هر کدوم یک بخش هایی از اطلاعات بگیرند یکمی برای من قابل درک نبود @samdvr . پیرو پست های گذشته که سوال پرسیدم

مثلا در ثبت یک تکیت برای یک مجموعه هنری ما یک همچنین کدی داریم

  def handle_batch(_batcher, messages, batch_info, _context) do
    IO.puts("#{inspect(self())} Batch #{batch_info.batcher}
      #{batch_info.batch_key}")

    messages
    |> Tickets.insert_all_tickets()
    |> Enum.each(fn message ->
      channel = message.metadata.amqp_channel
      payload = "email,#{message.data.user.email}"
      AMQP.Basic.publish(channel, "", "notifications_queue", payload)
    end)

    messages
  end

می یاد از ‍‍handle_batch استفاده می کنه هر چندتا چندتا جمع شد با یک تایم اوت بفرست و در

AMQP.Basic.publish(channel, "", "notifications_queue", payload)

می یاد در این بخش اطلاعات مربوط به ارسال ناتیفکیشن رو می سپاره به یک ماژول دیگه از broadway که در اون هر ۱۰ تا ۱۰ تا بعد از ۱۰ ثانیه ایمیل بشه که هم به سرور فشار ایمیل نیاد و هم ایمیل اسپم نشه.

لینک: Batching for Operations with Elixir and Broadway - DockYard


حالا سوال و موردی که من نفهمیدم چی هست؟؟؟!!! در حقیقت اینجا کار انجام می شه بر اساس اون استراتژی ولی مثلا چیزی گوش وایستاده نشده اینجا فکر کنم در مراحل کار باز باید مثلا یک GenServer درست بشه که استیت ایجاد بشه تا مثلا نافیکیشن رو هر ۱۰ تا جمع شد در ادمین هم نشون بده یعنی ارسال بکنه handl_info در بکگراند و اون بر اساس کد ها مثلا در سایت نشون بده درسته!؟
پس در حقیقت اینجا فقط در حد یک لوله هست که توش قرار هست آب بره و فقط مشخص می کنه چندتا چندتا بره و هر چند ثانیه بره و رفت چی بشه و اگر ارور داد چی بشه. اینکه استیت مدیریت بشه باز با GenServer هست اگر بد متوجه نشده باشم

تشکر

2 Likes

سلام شهریار عزیز
درست متوجه شدی. broadway و برنامه های این شکلی "steam processing " داده از یک سرچشمه stream میخونن و به صورت مرحله های مختلف و concurrent تغییر می دهند.

درسته یک کار مهم تو این نوع برنامه ها مدیریت backpressure که بالا توضیح دادم

2 Likes

درود و خیلی ممنون سام عزیز. یکمی باهاش کار کنم یک پروژه بزنم حتما یک پست جدا درست می کنم در موردش
دم شما گرم

2 Likes