حدیث روز
➖➖➖➖➖➖➖➖
🕊 @gopher_academy

✍️تکنیک "Shifting Left" یا "چپ‌برداری" یک رویکرد در توسعه نرم‌افزار و مدیریت پروژه است که به معنای جابجایی برخی فعالیت‌ها به مراحل اولیه‌تر فرآیند توسعه اشاره دارد. این اصطلاح بیشتر در زمینه تضمین کیفیت (QA) و امنیت نرم‌افزار مورد استفاده قرار می‌گیرد. هدف اصلی این تکنیک، شناسایی و رفع مشکلات و نقص‌ها در مراحل ابتدایی‌تر توسعه است، که می‌تواند منجر به کاهش هزینه‌ها و زمان صرف شده برای رفع مشکلات در مراحل بعدی شود.

🥂مفهوم و اصول Shifting Left

🔹خط زمانی توسعه: فرآیند توسعه نرم‌افزار را می‌توان به صورت یک خط زمانی تصور کرد که از مرحله نیازسنجی شروع شده و به تحویل محصول نهایی و نگهداری آن ختم می‌شود.

🔹چپ‌برداری: اشاره به انتقال فعالیت‌های خاص به سمت چپ این خط زمانی، یعنی به مراحل اولیه‌تر توسعه دارد.

🎂اصول و مزایا:

🔹شناسایی زودهنگام مشکلات:
با انتقال فعالیت‌های QA و امنیت به مراحل اولیه توسعه، مشکلات و نقص‌ها زودتر شناسایی و رفع می‌شوند.

🔹کاهش هزینه‌ها:
رفع مشکلات در مراحل اولیه توسعه معمولاً هزینه کمتری نسبت به رفع آنها در مراحل پایانی دارد.

🔹افزایش کیفیت محصول:
با انجام تست‌ها و ارزیابی‌های مکرر در مراحل مختلف، کیفیت نهایی محصول افزایش می‌یابد.

🔹بهبود همکاری تیم‌ها:
تیم‌های توسعه، QA و امنیت بیشتر با هم در تعامل هستند و این بهبود همکاری می‌تواند منجر به تولید محصولی با کیفیت بالاتر شود.

🫡کاربردها در عمل
تضمین کیفیت (QA):
تست‌های واحد (Unit Testing):
اجرای تست‌های واحد توسط توسعه‌دهندگان در مراحل ابتدایی کدنویسی.
تست‌های یکپارچگی (Integration Testing):
اطمینان از اینکه ماژول‌های مختلف به درستی با هم کار می‌کنند در همان مراحل اولیه یکپارچگی.
امنیت:
تست‌های امنیتی اولیه:
اجرای تست‌های امنیتی و ارزیابی‌های آسیب‌پذیری در مراحل اولیه توسعه به جای انجام آنها در مراحل پایانی.
کدنویسی امن:
پیاده‌سازی بهترین شیوه‌های کدنویسی امن از ابتدای پروژه.
🥹DevOps:
استفاده از CI/CD:
پیاده‌سازی فرآیندهای یکپارچگی و تحویل مستمر (CI/CD) که تست‌ها و ارزیابی‌های مختلف را در چرخه توسعه به صورت خودکار اجرا می‌کنند.

🚬نتیجه‌گیری
تکنیک Shifting Left با جابجایی فعالیت‌های مهم به مراحل اولیه توسعه، امکان شناسایی و رفع مشکلات را زودتر فراهم می‌کند. این رویکرد می‌تواند به بهبود کیفیت محصول، کاهش هزینه‌ها و زمان توسعه، و افزایش همکاری بین تیم‌ها منجر شود. با اتخاذ این رویکرد، تیم‌های توسعه نرم‌افزار می‌توانند محصولاتی با کیفیت بالاتر و امنیت بیشتر را به بازار عرضه کنند.
➖➖➖➖➖➖➖➖
🕊 @gopher_academy

🔵در سیستم‌های کامپیوتری و شبکه‌ای، مفاهیم "Best Effort" و "Retry" دو رویکرد متفاوت برای مدیریت ارسال و دریافت داده‌ها هستند. هر یک از این رویکردها مزایا و معایب خود را دارند و برای موقعیت‌ها و نیازهای مختلفی مناسب هستند. در ادامه به بررسی این دو مفهوم می‌پردازیم:

🔴Best Effort
🟢تعریف:
این Best Effort به رویکردی گفته می‌شود که در آن سیستم سعی می‌کند داده‌ها را با بهترین تلاش خود ارسال کند، اما تضمینی برای تحویل موفقیت‌آمیز وجود ندارد.
این روش بیشتر در پروتکل‌های بدون تضمین ارسال داده‌ها مانند UDP (User Datagram Protocol) استفاده می‌شود.

🟢ویژگی‌ها:
🔻بدون تضمین: هیچ تضمینی برای تحویل داده‌ها وجود ندارد. بسته‌ها ممکن است در طول انتقال گم شوند یا به مقصد نرسند.
🔻بدون تصحیح خطا: هیچ مکانیزم داخلی برای تصحیح خطا یا دریافت مجدد بسته‌های گمشده وجود ندارد.
🔻کارایی بالا: به دلیل عدم وجود مکانیزم‌های پیچیده تصحیح خطا و تایید تحویل، کارایی بالاتری در شرایط خاص دارد.
🔻استفاده در موارد خاص: مناسب برای کاربردهایی که نیاز به سرعت بالا دارند و از دست دادن چند بسته داده مشکلی ایجاد نمی‌کند، مانند استریم ویدیو یا تماس‌های صوتی.
🔴Retry
🟢تعریف:
این Retry به رویکردی گفته می‌شود که در آن سیستم تلاش می‌کند در صورت ناکامی در ارسال داده، دوباره آن را ارسال کند. این روش معمولاً در پروتکل‌های تضمینی مانند TCP (Transmission Control Protocol) استفاده می‌شود.

🟢ویژگی‌ها:
🔻تضمین تحویل: سیستم تضمین می‌کند که داده‌ها نهایتاً به مقصد می‌رسند. اگر یک تلاش ناموفق باشد، تلاش‌های دیگری انجام می‌شود.
🔻تصحیح خطا: دارای مکانیزم‌های داخلی برای تشخیص و تصحیح خطا و درخواست مجدد بسته‌های گمشده.
🔻تاخیر بیشتر: به دلیل تلاش‌های مجدد و مکانیزم‌های تصحیح خطا، ممکن است تاخیر بیشتری نسبت به Best Effort داشته باشد.
🔻استفاده در موارد حساس: مناسب برای کاربردهایی که نیاز به دقت و صحت داده‌ها دارند، مانند انتقال فایل‌ها، ارسال ایمیل یا تراکنش‌های مالی.

🎯مقایسه:
1. کارایی:
Best Effort:
کارایی بالا به دلیل نبود مکانیزم‌های پیچیده تصحیح خطا و تایید تحویل

Retry:
کارایی کمتر به دلیل نیاز به تلاش‌های مجدد و مکانیزم‌های تصحیح خطا.

2. قابلیت اطمینان:
Best Effort:
بدون تضمین تحویل داده‌ها.
Retry:
تضمین تحویل داده‌ها.

3. پیچیدگی:
Best Effort:
سادگی در پیاده‌سازی.
Retry:
پیچیدگی بیشتر در پیاده‌سازی به دلیل نیاز به مکانیزم‌های تصحیح خطا و تلاش‌های مجدد.

4. موارد استفاده:
Best Effort:
مناسب برای کاربردهایی که نیاز به سرعت بالا دارند و از دست دادن برخی داده‌ها مشکلی ایجاد نمی‌کند.
Retry:
مناسب برای کاربردهایی که نیاز به صحت و دقت بالای داده‌ها دارند.

🥂نتیجه‌گیری:
انتخاب بین Best Effort و Retry بستگی به نیازمندی‌های خاص کاربرد شما دارد. اگر به سرعت بالا و سادگی نیاز دارید و از دست دادن برخی داده‌ها مشکلی ایجاد نمی‌کند، Best Effort مناسب است. اما اگر نیاز به تضمین تحویل و صحت داده‌ها دارید، رویکرد Retry مناسب‌تر خواهد بود.

➖➖➖➖➖➖➖➖
🕊 @gopher_academy

📌 Golang Software Engineer

📝 Visa Sponsorship: ✅

🌍 Relocation Package: ✅

🏢 Company: xm

📍 Location: GREECE

⌨️ Category: #Programming

🔗 Tags: #nosql #golang #grpc #aws #microservices #terraform #cloud #sql

#موقعیت_شغلی
➖➖➖➖➖➖➖➖
🕊 @gopher_academy

✍️این"Corner case" (یا "edge case") به وضعیتی در سیستم‌های نرم‌افزاری یا سخت‌افزاری اشاره دارد که در آن شرایط غیرمعمول یا نادر رخ می‌دهد که می‌تواند به مشکلات یا رفتارهای غیرمنتظره منجر شود. این شرایط معمولاً در مرزهای ورودی‌های قابل قبول یا در ترکیب‌های غیرمعمول داده‌ها یا حالات سیستم رخ می‌دهند.

🎃مثال‌هایی از Corner Case‌ها

🔻عدد بزرگ یا کوچک در ورودی:
در برنامه‌ای که با اعداد صحیح کار می‌کند، ممکن است حالتی وجود داشته باشد که عددی بسیار بزرگ یا بسیار کوچک به عنوان ورودی داده شود که ممکن است به سرریز (overflow) یا زیرریز (underflow) منجر شود.

🔻ورودی‌های خالی یا بسیار طولانی:
مثلاً در یک فرم ثبت نام، ممکن است کاربر نام بسیار طولانی یا خالی وارد کند. این می‌تواند به مشکلات اعتبارسنجی داده‌ها یا خرابی برنامه منجر شود.

🔻مقادیر مرزی:
به عنوان مثال، در تابعی که باید اعداد بین 1 تا 100 را بپذیرد، اعداد 0، 1، 100 و 101 ممکن است به عنوان موارد مرزی بررسی شوند.

🔻ترکیب‌های غیرمعمول داده‌ها:
فرض کنید برنامه‌ای دارید که دو تاریخ شروع و پایان را دریافت می‌کند. یک حالت مرزی می‌تواند زمانی باشد که تاریخ پایان قبل از تاریخ شروع باشد.

😳اهمیت تست Corner Case‌ها
تست و شناسایی corner case‌ها در توسعه نرم‌افزار بسیار مهم است زیرا این حالات ممکن است به خطاهای جدی یا آسیب‌پذیری‌های امنیتی منجر شوند. به همین دلیل، باید تست‌های دقیقی برای پوشش این شرایط نادر و مرزی طراحی شود.

🤔چگونه Corner Case‌ها را شناسایی کنیم؟
🔻تحلیل دقیق نیازمندی‌ها:
بررسی دقیق نیازمندی‌های سیستم و شناسایی شرایط و محدودیت‌های خاص.
🔻بررسی ورودی‌ها:
تحلیل انواع ورودی‌هایی که سیستم دریافت می‌کند و شناسایی مقادیر مرزی و غیرمعمول.
🔻بررسی ترکیب‌های حالات:
تحلیل ترکیب‌های مختلف حالات سیستم و شناسایی حالات نادر و غیرمعمول.
🔻تست براساس تجربه:
استفاده از تجربیات گذشته و بهترین شیوه‌های صنعتی برای شناسایی و تست corner case‌ها.

💋نتیجه‌گیری
درواقع corner case‌ها به شرایط نادری اشاره دارند که ممکن است به رفتارهای غیرمنتظره یا خطاهای نرم‌افزاری منجر شوند. شناسایی و تست این حالات در فرآیند توسعه نرم‌افزار بسیار مهم است تا اطمینان حاصل شود که سیستم در تمامی شرایط ممکن به درستی عمل می‌کند.
➖➖➖➖➖➖➖➖
🕊 @gopher_academy

🥂دوستانی که Open to work هستند می توانند رزومه خودشون رو برام بفرستند تا داخل کانال منتشر کنیم

💋فقط استک گولنگ پروموت میکنیم.

🤝موارد زیر را به همراه فایل pdf رزومه بفرستید:



نام و نام خانوادگی (اجباری)
مدت سابقه کار (اجباری)
لینکدین (اختیاری)
گیتهاب (اختیاری)
محل سکونت (اجباری)
امکان نقل مکان برای کار دارم یا خیر (اجباری)

💘دوستان لطفا پی دی اف رزومه رو که میفرستید فرم بالارو کامل کنید موارد اجباری رو تشکر
🕊Admin:
@mrbardia72


➖➖➖➖➖➖➖➖
🕊 @gopher_academy

✍️قانون "Chesteron's Fence" یا "حصار چسترتون" یک مفهوم مهم در اصول حفظ وضعیت موجود و تغییرات محافظه‌کارانه است که از نویسنده و فیلسوف انگلیسی، جیلبرت کیث چسترتون (G.K. Chesterton) گرفته شده است. این مفهوم به ما می‌گوید که قبل از تغییر یا حذف یک چیز موجود، باید دلیل وجود آن را به طور کامل درک کنیم.

❇️شرح قانون Chesteron's Fence
چسترتون این مفهوم را در قالب یک داستان توضیح می‌دهد:
🥸فرض کنید که دو نفر در حال پیاده‌روی در یک روستا هستند و به یک حصار قدیمی می‌رسند. نفر اول می‌گوید: "من نمی‌فهمم چرا این حصار اینجا است؛ بیایید آن را خراب کنیم." نفر دوم پاسخ می‌دهد: "اگر دلیل وجود این حصار را نمی‌دانی، بهتر است آن را دست نزنیم. وقتی فهمیدی چرا این حصار اینجا است، آن وقت می‌توانی در مورد برداشتن آن صحبت کنی."

🥂کاربرد قانون Chesteron's Fence
💃سیاست و حکومت‌داری:
قبل از اصلاح یا حذف قوانین و مقررات، باید دلیل اصلی وضع آن‌ها را درک کنیم. این قانون به تصمیم‌گیرندگان هشدار می‌دهد که نباید به سادگی قوانین موجود را بدون تحلیل دقیق و شناخت کامل دلیل وجود آن‌ها تغییر دهند.

🎊مدیریت تغییرات در سازمان‌ها:
قبل از ایجاد تغییرات بزرگ در سازمان‌ها، باید فهمید که چرا فرآیندها و ساختارهای فعلی وجود دارند و چه مشکلی را حل می‌کنند.

💢مهندسی و طراحی سیستم‌ها:
در توسعه نرم‌افزار و مهندسی سیستم‌ها، قبل از حذف یا تغییر یک قطعه کد یا طراحی، باید فهمید که هدف اصلی و نقش آن چیست.

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

❤️‍🔥نتیجه‌گیری
قانون "Chesteron's Fence" به ما یادآوری می‌کند که تغییرات نباید بدون شناخت و درک کامل از دلیل وجود وضعیت فعلی انجام شوند. این قانون به تحلیل دقیق و توجه به زمینه تاریخی و منطقی امور تأکید دارد تا از تصمیمات ناآگاهانه و احتمالی جلوگیری شود. این اصل می‌تواند به حفظ تعادل و جلوگیری از اشتباهات ناشی از ناآگاهی کمک کند و باعث شود که تغییرات با دقت و بررسی‌های لازم انجام شوند.
➖➖➖➖➖➖➖➖
🕊 @gopher_academy

به‌روش‌های استفاده از Redis
خیلی مطلب کامل و جامعی بود و از مدیریت ممور یردیس، نحوه استفاده از ساختمان داده‌های مختلف و طراحی کلید‌ها تا دیپلوی روی کلاد توضیح داده بود.
اگه از ردیس روی پروداکشن استفاده می‌کنید از دستش ندید به نظرم.
https://www.dragonflydb.io/guides/redis-best-practices
#terminal_stuff
➖➖➖➖➖➖➖➖
🕊 @gopher_academy

📌 BackEnd (Golang) Engineer

📝 Visa Sponsorship: ✅

🌍 Relocation Package: ✅

🏢 Company: moon active

📍 Location: POLAND

⌨️ Category: #Programming

🔗 Tags: #python #golang #redis #rabbitmq #gcp #grpc #sqs #c #server #kubernetes #aws #docker #devops #cloud #scrum #sql

#استخدام
➖➖➖➖➖➖➖➖
🕊 @gopher_academy

حجم در ایمیج داکر اهمیت زیادی داره،
با analyze بسته های داخلی یک ایمیج به وسیله docker-phobia و Visualize کردن آنها میتونیم راحتر بفهمیم هر بسته چقدر از حجم ایمیج را به خودش اختصاص داده
https://github.com/remorses/docker-phobia
در عکس node و بعد Perl بیشترین حجم را گرفته

DevTwitter | <MehrdadLinux/>
➖➖➖➖➖➖➖➖
🕊 @gopher_academy

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


https://github.com/kuchin/awesome-cto

DevTwitter | <Ai_Tv/>
➖➖➖➖➖➖➖➖
🕊 @gopher_academy

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

http://www.algoanim.ide.sk/

DevTwitter
➖➖➖➖➖➖➖➖
🕊 @gopher_academy

فرق سشن و کوکی
➖➖➖➖➖➖➖➖
🕊 @gopher_academy

این کتاب به گونه‌ای طراحی شده که آسان‌خوان باشد. از جهش‌های فکری بزرگ اجتناب کرده ام. هر زمان که مفهوم جدیدی مطرح می‌شود، آن را توضیح می‌دهم یا به شما میگویم که چه زمانی آن را توضیح خواهم داد. مفاهیم اصلی با تمرین‌ها و توضیحات متعدد تقویت می‌شوند تا بتوانید مفروضات خود را بررسی کنید و مطمئن شوید که موضوعات را متوجه شده‌اید.

مطالب کتاب به دقت تنظیم شده است. نیازی به نوشتن کتابی نیست که همه‌ی الگوریتم‌های مرتب‌سازی را پوشش بدهد - به همین دلیل است که ما ویکیپدیا و خان‌آکادمی را داریم. تمام الگوریتم‌هایی که در این کتاب گنجانده‌ام کاربردی هستند و من از آنها در شغلم به عنوان یک مهندس نرم‌افزار استفاده میکنم.این‌ها پایه‌ی خوبی برای موضوعات پیچیده‌تر فراهم می‌کنند.


این کتاب با اجازه مترجم "جناب مهران افشار نادری" در سایت اسکای‌بوک منتشر می‌شود.

(ایمیل: mehranafsharnaderi@gmail.com)


🛒 لینک خرید نسخه زبان اصلی

🛒 لینک خرید نسخه ترجمه شده
➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

🔴چندتا مقاله جالب که امروز توی golang weekly منتشر شده

🟢 توی این مقاله میگه چرا مردم اکثر از ویژگی ورژن 1.23 ناراضی هستن و دلایلش چی می تونه باشه
🔵 https://www.gingerbill.org/article/2024/06/17/go-iterator-design/


🟢 یه سری انتی پترن های عمومی که توی وب اپلیکیشن های گولنگ باید مدنظر قرار داد
🔵 https://threedots.tech/post/common-anti-patterns-in-go-web-applications/

🟢 اگر میخوای در مورد context ها توی گولنگ بیشتر بدونی این مقاله خوبیه
🔵 https://blog.meain.io/2024/golang-context/



#golang_weekly
➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

اگر دنبال اطلاعاتی همچون استان ها و شهرستان های ایران به همراه مختصات جغرافیایی و پیش شماره تلفن می باشید
این گزینه خوبیه

https://github.com/shimadotdev/iran-regions/blob/main/resources/json/data.json
➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

✍️ Massimo Dev

منظور از gRPC چیه؟

ساختار gRPC یه جور تکنولوژی و ابزار برای برنامه‌نویس‌هاست که کمک می‌کنه دو تا برنامه یا سرویس مختلف بتونن با هم حرف بزنن، حتی اگه روی سرورهای مختلفی باشن. انگار که این دو تا برنامه دارن تو یه اتاق با همدیگه صحبت می‌کنن، ولی در واقع هر کدومشون تو یه شهر دیگه‌ن.

✳️ چطوری کار می‌کنه؟

فرض کن دو تا برنامه داریم، یکی که می‌خواد یه کار خاص انجام بده و یکی دیگه که قراره اون کار رو براش انجام بده:

1. تعریف کارها:
- اول از همه، باید تعریف کنیم که چه کارهایی باید انجام بشه. مثلاً برنامه A می‌خواد از برنامه B بپرسه که "اسم من چیه؟" و برنامه B باید جواب بده "اسم تو فلانه."

2. ارتباطات رو تنظیم می‌کنیم:
- باید یه روش ارتباطی مشخص کنیم که این دو تا برنامه چجوری باید با هم حرف بزنن. اینجا از gRPC استفاده می‌کنیم که یه جور زبان مشترکه برای ارتباط بین این برنامه‌ها.

3. تولید کدهای ارتباطی:
- خود gRPC به‌صورت خودکار کدهایی رو تولید می‌کنه که این برنامه‌ها بتونن راحت با هم ارتباط برقرار کنن. این کدها مثل پل‌هایی می‌مونن که ارتباط بین دو طرف رو برقرار می‌کنن.

4. اجرای سرویس:
- حالا برنامه B که قراره جواب بده، یه سرویس رو راه میندازه و گوش به زنگ می‌شه تا وقتی برنامه A ازش سوال می‌پرسه، جواب بده.

5. فراخوانی سرویس:
- برنامه A میاد و از طریق این پل‌های ارتباطی که gRPC ساخته، سوالش رو می‌پرسه و برنامه B جوابش رو می‌ده.

🚦چرا gRPC خوبه؟

1. سریع و کارآمد:
- خود gRPC خیلی سریعه و از روش‌های پیشرفته برای ارسال و دریافت داده‌ها استفاده می‌کنه که باعث می‌شه ارتباطات سریع و بدون معطلی باشن. در واقع فشرده سازی به خاطر شیوه ارسال داده (یه جور زیپ کردن) باعث میشه خیلی سریع بفرسته اطلاعات رو.

2. پشتیبانی از زبان‌های مختلف:
- با gRPC می‌تونی برنامه‌هایی که با زبان‌های برنامه‌نویسی مختلف نوشته شدن رو به هم وصل کنی. مثلاً یه برنامه با #پایتون و یه برنامه با #جاوا .

3. کم کردن کدهای اضافی:
- خود gRPC کدهای لازم برای ارتباط رو تولید می‌کنه و نیاز نیست برنامه‌نویس‌ها خودشون این کدها رو بنویسن، که این باعث می‌شه خطاها کمتر بشن و کارها سریع‌تر پیش برن.

4. استریمینگ:
- ابزار gRPC می‌تونه داده‌ها رو به صورت پیوسته و دنباله‌دار بفرسته و بگیره، که این خیلی به درد برنامه‌هایی می‌خوره که نیاز دارن دائم اطلاعات بفرستن و بگیرن، مثل استریم‌های ویدیو.

5. سازگاری و هم‌خوانی:
- سرویس‌های gRPC راحت با هم کار می‌کنن و نیاز نیست نگرانی زیادی بابت ناسازگاری‌های مختلف داشته باشی.

به طور کلی، gRPC یه ابزار عالیه برای اینکه برنامه‌ها و سرویس‌های مختلف بتونن به راحتی و با سرعت بالا با هم ارتباط برقرار کنن، حتی اگه از زبان‌ها و تکنولوژی‌های مختلفی استفاده کنن.

#طراحی_سیستم #دیتابیس #مهندس_نرم_افزار #سرور
➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

✍️ Massimo Dev
تفاوت Kafka و RabbitMQ چیه؟

🔵 کافکا یا Kafka

کافکا یه پلتفرم استریمینگ توزیع‌شده است که برای حجم بالای داده، تاخیر پایین و تحمل‌پذیری در برابر خرابی طراحی شده. اول توسط لینکدین توسعه داده شد و الان یه پروژه اپن سورس از بنیاد آپاچی است.

✳️ معماری کافکا بر اساس یه سرویس لاگ توزیع‌شده و پارتیشن‌بندی شده کار می‌کنه. پیام‌ها تو تاپیک‌ها (موضوعات) سازماندهی می‌شن و هر تاپیک به پارتیشن‌ها تقسیم می‌شه. تولیدکننده‌ها پیام‌ها رو به تاپیک‌ها می‌فرستن و مصرف‌کننده‌ها پیام‌ها رو از تاپیک‌ها می‌خونن.

مزایا
🔺حجم بالا: کافکا می‌تونه میلیون‌ها پیام در ثانیه رو پردازش کنه.
🔹مقیاس‌پذیری: معماری توزیع‌شده کافکا اجازه می‌ده با اضافه کردن نودها و پارتیشن‌ها مقیاس رو بالا برد.
🔹دوام: پیام‌ها روی دیسک نوشته می‌شن و بین چند نود تکرار می‌شن، پس خیلی پایدارن.
🔹پردازش استریم: کافکا با فریم‌ورک‌های پردازش استریم مثل فیلینک و استورم خوب کار می‌کنه.
🔹گروه‌های مصرف‌کننده: کافکا اجازه می‌ده چند مصرف‌کننده از یه تاپیک بخونن و بار رو به طور مساوی توزیع کنن.

معایب
🔻راه‌اندازی پیچیده: کافکا نیاز به تنظیمات و پیکربندی دقیق داره، پس راه‌اندازی اولیه‌اش پیچیده‌س.
🔻نگهداری: مدیریت و نگهداری کلاسترهای کافکا پیچیده‌س و نیاز به تخصص داره.
🔻تاخیر: کافکا بیشتر برای حجم بالا بهینه شده و ممکنه تاخیر بیشتری نسبت به بعضی سیستم‌های دیگه داشته باشه.

🔵 ربیت یا RabbitMQ
ربیت‌ام‌کیو یه بروکر پیام هست که پروتکل AMQP رو پیاده‌سازی می‌کنه.

✳️ ربیت‌ام‌کیو از معماری مبتنی بر بروکر استفاده می‌کنه که در اون تولیدکننده‌ها پیام‌ها رو به اکسچنج‌ها می‌فرستن و اکسچنج‌ها اون‌ها رو بر اساس قوانین مسیریابی به صف‌ها می‌فرستن. مصرف‌کننده‌ها پیام‌ها رو از این صف‌ها می‌خونن.

مزایا
🔹سهولت استفاده: ربیت‌ام‌کیو برای راه‌اندازی و استفاده آسونه.
🔹انعطاف‌پذیری: از چندین پروتکل پیام‌رسانی (AMQP، MQTT، STOMP) و الگوهای مختلف (pub-sub، درخواست-پاسخ) پشتیبانی می‌کنه.
🔹تاخیر پایین: ربیت‌ام‌کیو برای پیام‌رسانی با تاخیر پایین بهینه شده.
🔹تحویل قابل اعتماد: ویژگی‌هایی مثل تاییدیه پیام و ماندگاری برای اطمینان از تحویل پیام داره.

معایب
🔻مقیاس‌پذیری: ربیت‌ام‌کیو می‌تونه مقیاس افقی داشته باشه، ولی به اندازه کافکا در پردازش حجم خیلی بالا کارآمد نیست.
🔻نقطه شکست واحد یا Single Point of Failure: معماری ربیت‌ام‌کیو می‌تونه دچار نقطه شکست واحد بشه، البته کلاسترینگ می‌تونه اینو کاهش بده.
🔻عملکرد: ربیت‌ام‌کیو ممکنه تو پردازش حجم بالای پیام‌ها به اندازه کافکا کارآمد نباشه.
🔻ترتیب پیام‌ها: اطمینان از ترتیب دقیق پیام‌ها تو سناریوهای مسیریابی پیچیده می‌تونه چالش‌برانگیز باشه.

موارد استفاده هرکدوم رو در ادامه میگم:

کافکا

1. استفاده از Event Sourcing: ضبط و پردازش جریان پیوسته رویدادها.
2. جمع اوری Log Aggregation: جمع‌آوری لاگ‌ها از منابع مختلف برای نظارت و تحلیل.
3. جمع‌آوری متریک‌ها: جمع‌آوری متریک‌ها از برنامه‌های توزیع‌شده برای تحلیل در زمان واقعی.
4. خطوط داده یا Data Pipeline: انتقال حجم بالای داده بین سیستم‌ها یا مراحل پردازش.

ربیت‌ام‌کیو
1. درخواست-پاسخ: پیاده‌سازی ارتباط همزمان بین سرویس‌ها.
2. پیام‌رسانی Real-time: پیام‌رسانی با تاخیر پایین برای برنامه‌های نیازمند به‌روزرسانی‌های زمان واقعی.
3. برنامه‌های IoT: مدیریت ارتباط بین دستگاه‌های IoT و سیستم‌های پشتیبان.

مشتی باشید!

#کافکا #ربیت #سیستم_دیزاین
➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost