کلیت ماجرای load balancer خیلی ساده اس و حتی با 100 خط میشه جمش کرد. یه سرور بین ارتباط کلاینت و سرور میاد و رکویست هایی که از سمت کلاینت میاد رو با توجه به استراتژی که داره ارسال میکنه. همین.

چی پیچیده اش میکنه؟

1- پیاده سازی caching:
لود بالانسر باید بتونه ریسپانس رو کش کنه، فرض کنید کاربر وارد سایت فروشگاهی ایکس میشه و رکویست صفحه ی اصلی رو میفرسته، لود بالانسر اون رو میگیره و به سرور اصلی میفرسته و بعد از اینکه ریسپانس رو گرفت اون رو کش میکنه تا کاربر بعدی که درخواست صفحه ی اصلی رو فرستاد بدون اینکه به سرور اصلی رکویست بفرسته از کش خودش به کاربر جواب رو برگردونه. حالا خود این کش کردن هم یه عالمه داستان داره که از کجا بخونه؟ ردیس؟ فایل؟ ... پس اینم یه پیچیدگی جدی اضافه میکنه که باید پیاده سازی بشه.
2- انتخاب مقصد بر اساس پروتکل باید باشه: لود بالانسری که من دارم مینویسم توی لایه ی 4 ام کار میکنه و با کانکشن های TCP سر و کار داره، تو این لایه نمیتونیم رکویست هایی که از سمت کاربر میاد رو بر اساس هدر یا ادرس url به سرور بالادستی بفرستیم چون هنوز داده رو باز نکردیم ببینیم قراره به کجا ارسال بشه 👇

پس اگر میخواییم که مسیریابی بر اساس داده ای که توی رکویست هست انجام بشه باید بیاییم پرتوکل مدنظرمون رو پیاده کنیم تا مسیریابی انجام بشه. به طور مثال: ما میخواییم توی کانفیگ لودبالانسرمون بنویسیم که اگر کاربر میخواست به x.com/users رکویست بفرسته اون رو به سمت سرور A هدایت کن، وقتی میخواست به x.com/feed رکویست فرستاد اون رو به سرور B بفرست. از اونجایی که این رکویست ها برای پروتکل HTTP هست و روی TCP نشسته(اینجا گفتم) ، ما باید اول از TCP داده رو بخونیم بعد با قوانین HTTP ببینیم رکویست قراره به کجا بره. حالا باید HTTP 2 و HTTP 3 رو هم پیاده سازی کنیم، حتی باید UDP رو هم پیاده سازی کنیم. پس عملا داریم به کد پیچیدگی اضافه میکنیم.

3- باید منابع رو درست مصرف کنه:
فکر کنید ما برای هر رکویست یه ترد باز کنیم (اینجا گفتم چرا بده)، اونوقت تعداد زیادی ترد داریم که منتظر IO موندن و هیچ کاری نمیکنن، یعنی از سیستم ریسورس گرفتن ولی میخورن و میخوابن. یا وقتی که کلاینت داده رو میفرسته ما یه بار اون رو توی یوزراسپیس از کرنل کپی کنیم و دوباره بعد از انتخاب سرور بالادستی اون رو به کرنل بفرستیم. پس باید بیاییم معماری درستی بچینیم که بیشترین استفاده رو از منابع سیستم ببریم.

4- باید روی همه ی سرورا اجرا بشه:
تعداد زیادی از شرکتای تجاری روی سرورای ماکروسافت کار میکنند(واقعا wtf) و ویندوز سیستم محبوبشونه، پس کد ما باید هم روی ویندوز کار کنه هم روی یونیکس و لینوکس. این هم پیچیدگی به کد اضافه میکنه.

یادتون نره ایده ی اصلی اینه که در نهایت بار روی یه سرور نباشه و لودبالانسر وظیفه اش برداشتن بار از روی سرور های بالادستی یا توزیع بار با توجه به درخواست یا هرچیز دیگه ای هست.

@knowpow

وقتایی که بقیه ترسیدن، من کنجکاو بودن رو انتخاب میکنم 🤘

@knowpow

پیاده سازی لود بالانسر Vortex با IO Uring

توی این کامیت دو تا کار جالب کردم:


۱- اومدم تو io uring از روشی استفاده کردم که تعداد سیستم کال هارو به حداقل برسونه. یعنی اگر توی روش قبلی ۱۰۰ تا سوکت به صورت همزمان به سرور وصا میشدن، باید ۱۰۰ تا سیستم کال انجام میدادیم، ولی الان توی یک سیستم کال همشون رو پردازش میکنیم:

while (true) {
    io_uring_submit_and_wait(&ring_, 1);
    unsigned cqe_count = 0;
    unsigned head;
    io_uring_for_each_cqe(&ring_, head, cqe) {
        ++cqe_count;
        auto *request = static_cast<io_request *>(io_uring_cqe_get_data(cqe));
        if (request) {
            switch (request->type()) {
            case io_request::request_type::accept:
                request->socket().on_accept(request, cqe->res);
                prepare_accept(request->socket());
                break;
            default:
                core::logger::error("Unknown request type");
                break;
            }
            delete request;
        }
    }
    io_uring_cq_advance(&ring_, cqe_count);
}

وقتی که 1 رو به io_uring_submit_and_wait میدیم، این متد منتظر فقط یک ایونت میشه تا ترد من رو ازاد کنه و لوپ اصلی شروع به کار کنه. خب مگه نگفتیم یک ایونت؟ پس چطور ممکنه ۱۰۰ تا سوکت رو همزمان داشته باشیم؟! این یک که گفتم به این معنی نیست که اگه فقط یک ایونت اتفاق بیفته تنها همون ایونت توی صف باشه، در واقع io_uring این قابلیت رو داره که چندین ایونت (مثلاً چندین درخواست از سوکت‌های مختلف توی یک لحظه) رو توی یه مرحله جمع‌آوری کنه. یعنی اگه چندتا سوکت همزمان به به سرور من درخواست بفرستن، io_uring تمامی اوتارو توی یه سیستم کال مدیریت میکنه و همشون رو به صف completion queue اضافه میکنه. در نتیجه وقتی io_uring_submit_and_wait حداقل منتظر یه ایونته‌ احتمالاً چندین ایونت به صف اضافه شده و توی لوپ با ماکرو io_uring_for_each_cqe همه‌ی این ایونت ها رو بدون نیاز به سیستم کال جدید پردازش میکنیم.

۲- اومدم یکم دیزاین پترن و اینترفیس ریختم تو پروژه، طوری که الان هسته ی نوتیفیکیشن بر اساس io uring کار میکنه، ولی اگه خواستم فردا روی epoll یا هرچیز دیگه ای ببرم راحتتر انجام بشه

لینک فایلای تغیر داده شده:
https://github.com/aabolfazl/Vortex/pull/3/files

نظری یا سوالی اگه بود بهم بگین.

@knowpow

ما توی مدل های چند پروسس/ترد میاییم روی یه پورت با چندین سوکت گوش میدیم، ولی کرنله که میاد تصمیم میگیره که کانکشن جدید رو به کدوم ترد بده. یعنی اگه من ۳ تا ترد داشته باشم و توی سه تاشونم به یک پورت گوش بدم، کرنل تصمیم میگیره که کانکشن جدید رو کدوم ترد هندل کنه و بر اساس اون میاد سوکت مورد نظرش رو کال میکنه. عملا داره یه لودبالانسینگ انجام میده.

@knowpow

درود دوستان

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

مرتضی عزیز لطف داره به من و منم ایشون رو با VPN و کانالی که توی یوتیوب دارن شناختم، ممنونم ازتون و خوش اومد میگم به دوستان جدیدی که عضو کانال شدن 🖖

روش پیاده سازی ACK پروتکل TCP توی کرنل

خب وقتی اسم TCP میاد وسط اولین چیزی که به ذهنمون خطور میکنه اینه که TCP برعکس UDP گارانتی میکنه که پکت ارسالی شما نهایت به مقصدش برسه. یکی از راه هایی که میاد میفهمه چیزی ارسال شده یا نه اینه که به ازای دریافت هر پکت داده به گیرنده بگه که این پکتی که فرستادی رو گرفتمش(ACK).

خب تا اینجای ماجرا ما یه فرستنده داریم که داده میفرسته و گیرنده به ازای هر دریافت پکت به فرستنده میگه که پکت ارسال شده رو گرفتم، اینو بزاریم کنار بریم توی کد سمت سرور:

من یه سوکت میسازم، بایند میکنمش به پورت ۸۰۸۰، شروع میکنم به گوش دادن و وقتی کانکشن جدید میاد اکسپتش میکنم و ارتباط بین کانکشن کلاینت و من برقرار میشه:

listener := net.Listen("tcp", "localhost:8080")

fmt.Printf("Server listening on %s\n", address)

conn := listener.Accept()

fmt.Printf("Accepted connection from %s\n", conn.RemoteAddr().String())

// اینجا کلاینت داره برای ما داده میفرسته ولی ما نمیخونیم. نخوندن ما به معنی ارسال نکردن ACK توسط کرنل نیست.

حالا کلاینت شروع میکنه برای ما دیتا میفرسته ولی ما هیچ دیتایی رو با سیستم کال read() نمیخونیم، سوالی که پیش میاد اینه که ایا کلاینت بدون اینکه من read انجام بدم ACK رو دریافت میکنه؟ جواب بله اس، بله دریافت میکنه!

هنگامی که یک بسته میرسه، استک TCP کرنل بلافاصله اون رو توی بافر دریافت مینویسه و یه ACK برای فرستنده میفرسته. این ACK تایید می کنه که بسته به کرنل رسیده و برای خوندن از سمت برنامه ی من که از طریق Go نوشتم آماده است. با این حال دیگه TCP منتظر نمیمونه تا برنامه قبل از تایید بیاد و داده ها رو پردازش کنه، این جدایی بین لایه های انتقال و برنامه دقیقا چیزیه که TCP رو بهینه و سریع و پاسخگو نگه میداره و تضمین میکنه که فرستنده میتونه بدون منتظر بودن پردازش داده توسط برنامه(کد ما که بالا نوشته شده) به ارسال داده ادامه بده.

- خب پس داده ها کجان؟
+ اینجا این بافر رو یادتونه؟ کرنل دقیقا وقتی دیتا رو میگیره اون رو داخل این بافر میریزه و به فرستنده که کلاینت باشه ACK رو میفرسته. و دیگه منتظر برنامه نمیمونه تا تایید بده

@knowpow

بدون هیچ فریمورکی از متد main شروع کردن همیشه سخت بوده، منم چندتا چندتا اشتباه بزرگ کردم توی این پروژه:

‏۱- لایه ها رو از هم جدا نکردم
‏۲- معماری روی کاغذ براش طراحی نکردم صرفا تو ذهنم بود و برای همین نقاط کور رو نمیدیذم
‏۳- مستقیم شروع کردم به کد زدن
‏۴- از بقیه ی پروژه ها ایده نگرفتم(خیلی کم گرفتم)

‏خلاصه که برگردیم به اول ماجرا و بورسیم که ما چی میخواییم و داریم چیکار میکنیم؟ یکم دیگه نتایج کارایی که برای حل مشکلات بالا انجام دادم میگم

@knowpow

خب، یه طراحی بسیار زیبا، چیزی که تو ذهنمه اینه که سه تا کامپوننت اصلی داریم که لاجیک برنامه توی اوناست:

‏1- Listener
‏2- Balancer(cluster of backends)
‏3- Health Checker

‏کامپوننت اول، Listener: این کامپوننت بر اساس کانفیگ میاد روی پورتی که هست ساخته میشه و شروع میکنه به اکسپت کردن کانکشن جدید، کانکشن هایی که اکسپت میشن رو به کامپوننت بعدی که بالانسر باشه میفرسته.

‏کامپوننت دوم، Balancer: این کامپوننت وظیفه داره تا سرور های بالادستی رو بهشون وصل بشه و یه استخری از کانکشن های سرورهای بالادستی داشته باشه، وضعیت سرورها رو از کامپوننت Health Checker بگیره و بر اساس اونا و کانفیگی که شده ترافیک رو روت کنه. لاجیک اصلی تصمیم گیری برای انتخاب سرور بالادستی اینجا پیاده سازی میشه.

‏کامپوننت سوم، Health Checker: این کامپوننت سوکت های خودش رو بر اساس کانفیگ روی سرور های بالادستی باز میکنه و مدام وضعیت سرورهای بالادست رو چک میکنه و اگه خبری بود به Balancer اطلاع میده تا توی انتخاب لحاظش کنه.

‏یک سری کامپوننت هم داریم که بیزینس سیستم توشون نیست و صرفا دارن کمک میکنند که سیستم به هدفش برسه و بین همه ی اینا مشترکه:
‏1- EventLoop(epoll, io uring)
‏2- Buffer Poll
‏3- Config
‏4- etc.

‏حالا دلیل زیبایی این مدل چیه؟

‏شما میتونید یه لیستی از لیسنرها داشته باشید و اون رو به یک کلاستر از بالانسر بفرستین، یعنی روی ۱۰ تا پورت گوش بدین و ترافیک اون رو فقط به یک بالانسر ارسال کنید، یا برعکسش، شما ممکنه یک لیسنر داشته باشید ولی بخوایید همزمان به چند تا سرور بفرستین.

‏دلیل اینم که health checker بیرون از کلاستره اینه که ممکنه سرورا بین کلاسترا مشترک باشه

@knowpow

🚀خب میخواستم TCP رو پیاده سازی کنم ولی آرین ایده ی بهتری داد، قرار شد با Rust بیام و یه جدول هش توزیع شده با الگوریتم Kademlia کادملیا رو پیاده سازی کنم، هم فاله هم تماشا،
هم rust یاد میگیرم هم با نتورکینگ e2e بازی میکنم. این الگوریتم توی IPFS و Ether هم استفاده شده.

داستان چیه؟ فرض کنید یه HashMap داریم و اون رو بین سرورهای مختلف توزیع میکنیم و از نتورک p2p استفاده میکنیم تا به دیتامون برسیم. کادملیا به یه روش بهینه میاد اینکارو میکنه(خودمم زیاد بلد نیستم و فقط یه ایده‌ی کلی ازش دارم). کادملیا از دو بخش استوریج و روتینگ تشکیل شده، بخش استوریج وظیفه‌ی اینو داره که بیاد داده هایی که ماژول روتینگ بهش میده رو put یا get کنه، جدا از این ماژول روتینگ وظیفه ی اینم داره که به بقیه ی نود ها به پیدا کردن نود مورد نظرشون کمک کنه، به ping ها جواب بده و بیاد شبکه رو برای تغییرات مانیتور کنه، ایده ای که این پیاده سازی رو متفاوت میکنه اینه که بیاییم روتینگ رو توی کرنل اسپیس پیاده سازی کنیم، اینجوری پرفورمنس بالاتری داریم و دیگه نیازی نیست تا لایه ی کاربر بریم بالا. ولی استوریج همونجا میمونه و به کارش ادامه میده.
برای شروع دوتا ماژول استوریج و روتینگ رو با Rust توی userspace مینویسم، بعد روتینگ رو به کرنل با C بازنویسی میکنم.
بزودی ادرس ریپو رو میزارم. پروژه ی vortex هم کنار همین ادامه پیدا میکنه.

#kdht

توضیحات آرین در مورد کادملیا:
https://ariyan-eghbal.github.io/posts/kademlia/

@knowpow

پیپر اصلی کادملیا که توی ۲۰۰۲ منتشر شده😎

@knowpow

همونطور که گفتم پروژه رو تبدیل به دوتا ماژول کردم، ماژول اول وظیفه‌ی پیاده سازی بخش روتینگ رو داره، و ماژول دوم استوریج. ایده ی اصلی کادملیا توی ماژول روتینگ پیاده سازی میشه.

باید اول بدونین که کادملیا ۴ تا پروسیجر اصلی داره: PING, FIND_NODE, STORE, FIND_VALUE که سیستم ما باید یا اینارو بفرسته یا وقتی اینارو میگیره باید یه کاری رو در قبالش انجام بده.

حالا قرار هست چیکار کنیم؟ ما اینجا ۴ تا لایه داریم که از بالا به ترتیب:

۱- لایه ی Routing که اصلی ترین بخش سیستمه اینجاست، باید بیاییم بر اساس پیام هایی که میگیریم با ماژول استوریج ارتباط بگیریم، باکت گره ها رو بروزرسانی کنیم، به بقیه ی گره ها با یه فاصله ی زمانی پیام پینگ رو بفرستیم و با توجه به جواب باکت رو بروزرسانی کنیم. درخواست های بالا رو کش کنیم و به پیام های پینگ هم جواب بدیم(شاید اینو به لایه ی rpc منتقل کردم مطمئن نیستم)

۲- لایه ی RPC وظیفه ی اینو داره که بیاد با توجه به پیامی که گرفته یا نتیجه رو برگردونه یا خطا بده و باید rate limit رو چک کنه.

۳- لایه ی Serialization/Deserialization وظیفه ی اینو داره که بیاد پیام های باینری یا جیسون رو به struct یا بلعکسش تبدیل کنه.

۴-لایه ی Communication وظیفه ی اینو داره که با توجه به پرتکلی که داره بیاد listen کنه و اماده‌ی دریافت پیام باشه، یا به یه نود وصل بشه و پیام بفرسته. توی طراحی که انجام دادم هم TCP رو ساپورت میکنم هم UDP رو، احتمالا برای نسخه ی اول فقط با UDP پیش بریم.

#kdht

@knowpow

معماری برای ماژول روتینگ
#kdht

@knowpow

“Failure is an option here. If things are not failing, you are not innovating enough.”

-Elon Musk

@knowpow

ریپو رو ساختم و کانکشن udp رو نوشتم، برای async از توکیو استفاده میکنم و نیازی به io uring نیست

https://github.com/aabolfazl/kdht

@knowpow

چیزی که توی rust اذیتم میکنه عجیب بودن سینتکسشه، اورده از هر زبون یه چیزی رو استفاده کرده یه لحظه به خودت میایی میبینی داری توی rust با سی++ جاوا مینویسی 😂 یعنی حواست نباشه به فنا میری.

البته این نظر برای امروزمه و ممکنه ماه بعد بیام بگم ای بابا چقدر ساده بودی اینم نمیدونستی؟!

@knowpow

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

@knowpow

یه کتابخونه ی خوب از مجموعه‌ی توکیو توی راست پیدا کردم به اسم MIO که میاد پایینترین لایه ای که میشه روش ابسترکشن پیاده سازی کرد رو فراهم میکنه.
کتابخونه ی MIO روی مکانیزم‌های سیستم‌عامل(epoll توی لینوکس، kqueue توی macOS/BSD و IOCP توی ویندوز) تمرکز میکنه تا یه بدون درگیری با پیاده سازی notification system بیاییم و برنامه هامون رو بنویسیم.

حالا تفاوتش با async/await خود زبون چیه؟ اگه از رانتایم توکیو استفاده میکنید به احتمال زیاد داره از mio برای مدیریت io استفاده میکنه ولی بهتون یه اینترفیس تمیز بدون درگیری و پیاده سازی مدیریت ایونت ها رو به اسم async/await فراهم میکنه توی خود mio مستلزم پیاده سازی توسط خودتونه. mio کنترل بیشتری میده ولی پیچیدگی کدنویسی رو بالا میبره، شما باید همه چی رو دستی هندل کنید و ادامه ی ماجرا دیگه به نحوه ی پیاده سازی شما داره.

سورس کد پروژه برای ایده گرفتن:

https://github.com/tokio-rs/mio

@knowpow