نوشته های محمد حسین خداخواه

RUST ( اصن چی میگه؟؟؟)

محمد حسین خداخواه — Fri, 05 Jun 2026 14:11:42 +0330

چرا rust ساخته شد؟؟؟؟برای خاطر اینکههههه : «داشتن سرعت و قدرت زبان C++، بدونِ دردسرها و خطاهای امنیتی آن.»داستان چی بود اصن؟؟؟؟*گریدون هور(سازنده rust) توی موزیلا کار میکرده ، از قضا یروز که میرفته خونه آسانسور ساختمونشون خراب میشه مجبور میشه ۲۱ طبقه با پله بره بالا 😂😂 بعدش میشینه فک میکنه وات د فاک آخه یی چیییییی؟؟؟تو این حرص و جوش و فکر کردنش به یه سری نتایج میرسه(عین وقتی که سیبه خورد تو سر نیوتون) که دلیلِ بیشترِ این خرابی‌ها (و کرش کردن مرورگرها)، باگ‌های مربوط به مدیریت حافظه در زبان C++ است.بعدش اومد rust رو ساخت تا ابزاری داشته باشه که: مثل C++ سریع باشد. مثل Python خوانا باشد. و برخلاف هر دو، اجازه نده اشتباهِ مهلکی در حافظه رخ دهد.*یکم عمیق تر rust رو باز کنیم بینیم اصن چه گلی به سرمون زده*۱. حل مشکل memory corruption (Memory Safety)*در زبان‌های قدیمی مثل C و ++C، مدیریت حافظه دست خودِ برنامه‌نویسه بدبخته. اگر یادت بره حافظه‌ای رو آزاد کنی، مالیدی و سیستم کرش می‌کند (Memory Leak). همینطور اگر زود آزاد کنی یا اشتباه استفاده کنی، بازم مالیدییی و هکرها می‌تونن از اون حفره امنیتی بسازن و بیلاخو بکشن بهت.حالا rust چی میگه : میگه که باباااااا شاید برنامه نویس اصن شافتک باشه سیستم که نباید اجازه بده برنامه‌نویس اشتباه کنه. rust با مفهومی به اسم Ownership (مالکیت)، در همان زمانِ نوشتن کد (قبل از اجرا)، یقه ی برنامه‌نویس رو می‌گیره و نمیزاره کدِ ناامنی نوشته بشه که باعث کرش یا باگ امنیتی بشه و همه رو باهم به خاااااک بده.*۲. انتزاع بدون هزینه (Zero-cost Abstractions)*در زبان‌هایی مثل پایتون یا جاوا، کار با زبان خیلی راحته «سطح بالا»، اما در عوض سرعت فدای این راحتی شده. ینی تو راحت میشنیی کد میزنی و فک میکنی داری آتیش میندازی تو برف (که خب شوخیه ممکنه واقعا آتیش بندازی تو برف) ولی درواقع سرعت رو قربانی کردن برای تو که بتونی راحت کد بزنی حالا rust چی میگه : میگه که نباس بین «راحتیِ کدنویسی» و «سرعتِ اجرا» یکی رو انتخاب کرد اصن چه معنی میده؟؟؟ باید خر و خرمارو باهم داشته باشیم و تبعیض قائل نشیم به مولا rust ابزارهای پیشرفته‌ای به تو می‌ده که وقتی کد میزنی عشق کنیییییییییااااااااا ینی انگار از بچگی دوس داشتی با rust کد بزنی، اما وقتی کد رو کامپایل می‌کنی، خروجی آن به اندازه کد دستی نوشته شده در C سریعهه . یعنی «هزینه‌ای» برای امکانات پیشرفته‌اش پرداخت نمی‌کنی و مفتی مفتی در اختیارت گذاشتن.*۳. حذف race condition (Safe Concurrency)*امروزه همه پردازنده‌ها چند هسته‌ای ان. نوشتن برنامه‌ای که همزمان از چند هسته استفاده کند (Concurrency) در زبان‌های قدیمی کابوسه به ابلفضل؛ چون ممکنه دو بخش برنامه همزمان بخوان یه دیتا رو تغییر بدن و همه چیز مالیده بشه. حالا Rust چی میگه : rust با همون قوانین مالکیت (Ownership)، تضمین می‌کنه که دیتاها در محیط‌های چندرشته‌ای (Multi-threaded) با هم تداخل پیدا نکنن. اصن حدیث داره rust تو این بخش که میفرماید “Fearless Concurrency” یا «همزمانیِ بدون ترس».

Delivery Patterns in kafka (delivery semantics). . .

محمد حسین خداخواه — Tue, 19 May 2026 19:40:38 +0330

مستقیم میرم سر اصل مطلب دیگه . . .اصلا نیازی نیست حاشیه برم چون این موضوع شفافهچطوری پیام های ارسال شده توسط producer توسط consumer مصرف میشه1) At-most-onceاینجا میگیم که آقا جان حداکثر یبار، ینی این پیام اومد لطفا تمومش کن هر چی شدممکنه پیام از دست بره، ولی تکراری نمیشهههههه هرگززززز، تو این حالت consumer اول offset رو پردازش میکنه بعدش میگه خب حالا بریم سراغ کاری که پیامه ازم خواسته ببینم چه تسکی داریم پردازش کنیمتو این حالا اگر بعد از commit کردن offset پردازش انجام نشه به هر دلیلی و یا کرش کنه دیگه پیام خونده نمیشه ، این یارو به درد پیام های کم اهمیت و لاگ های کم اهمیت میخوره و در کل میگن برای event هایی خوبه که از دست رفتنشون قابل تحمله برامون(ینی اگر از دست رفتن سکته نمیکنیم)2) At-least-onceدر اینجا شاهد رایج ترین حالت توی کافکا هستیم، وقتی اتفاق میوفته که بگی آقا جان حداقللللللللللل یه بار پیام منو پردازش کن دیگهههه، در نتیجه consumer اول پیام رو پردازش میکنه و در صورت موفق بودن پردازش میاد و offset رو commit میکنه خیلی شیک و مجلسی اگر پردازش به ارور بخوره در نتیجه اون offset دیگه commit نمیشه و و اینطوری میشه که باز دوباره از اول خونده میشه، صف مسدود میشه پیام ها پشت این یارو منتظر میمونن تا این انجام بشه(من بدبخت همین سه روز پیش با این موضوع داشتم سرو کله میزدم) و بعدش بیان انجام بشن، حالا موضوعی که هست اینه که این پترن وقتی خوبه که شما idempotency رو رعایت کنی که مباااااااادااااااااااااااا duplicate اتفاق بیوفته یه وقت خدایی نکرده3) Exactly-onceاین ینی پیام دقیقا یه بار پردازش بشهینی نه از دست بره و تکراری پردازش بشهحالا این چطوری انجام میشه؟؟؟؟کافکا اینو با ترکیب چیز میزای زیر مدیریت میکنه شیک:Idempotent ProducerTransactionsمدیریت دقیق offset و commitکجا به درد میخوره؟؟؟ ساده بگم حاجی مهمترین جاها، پردازش های مالی، pipeline های حساس، و در کل بخام بگم هرجایی که duplicate و یا loss data هردو مشکل ساز میشن و یقتونو میگیرهExactly-once در Kafka به‌صورت end-to-end همیشه ساده نیست، و معمولاً باید کل زنجیره‌ی پردازش درست طراحی شود.(توی مقاله بعدی در مورد این قراره مفصللللل صحبت کنیم)4) Broadcast / Fan-outاین بیشتر برای وقتیه که میخای چنتا سرویس مختلف یه event رو ببینن و از یه event مطلع بشن،مثلا یارو کاربر ثبت نام کرد خب نا خودآگاه یه ولت میخاد و یه سبد خرید دیگه مثلا پس یه event میفرستیم که فلانی اومد ثبت نام کرد هم ولت دریافتش کنه هم مثلا سفارشات (که سبد خرید توشه)5) Load balancing داخل یک Consumer Groupاین بیشتر برا وقتیه که چنتا consumer داری که تو یه group هستن، ینی دقیقا یه groupId دارندر این شرایط کافکا اگر برای producer یه partition تعریف شده باشه مسیج هارو فقط توی همون partition میفرسته و قانون طلایی کافکا <هر partition فقط به یک consumer در group مشخص متصل میشود> باعث میشه که علنا بقیه ی consumer ها بی فایده بشینن و مسیج ها همه به consumer اول برهدر نتیجه این روش میاد میگه آقا جان بیا به تعداد دوبرابر consumer های موجود در یک group هنگام ساخت اون topic پارتیشن تعریف کن دیگهههههههاینجوری میتونید load balancing انجام بدید، و یا خود کافکا به صورت دیفالت (اگر key نداشته باشید) round-robin هست انجام میده و هر پیام رو تو یه پارتیش ارسال میکنه.مقاله بعدی قراره در مورد سومین پترن حرف بزیممقاله بعد ترش میخام درمورد load balancing در کافکا حرف بزنممن حسینم و امیدوارم کمی به دیدتون نسبت به کافکا کمک کرده باشمدوستون دارم همچنین میتونید منو توی بله هم پیدا کنید(به امید اینترنت آزاد و تلگرام)https://ble.ir/sungeek

DLQ(Dead Letter Queue) در کافکا

محمد حسین خداخواه — Wed, 06 May 2026 21:40:24 +0330

فرض کن یه مسیج از producer رفته به consumerبه هر دلیلی (که خب الان شاید مهم نباشه ولی بعدا مهمه) پردازش این مسیج توی consumer به مشکل میخورهخب چی میشه؟؟؟هیچی دیگه وقتی مسیج توسط consumer شما commit نشه اول صف توی پارتیشن مربوطه میمونه و هی خودشو هل میده توی consumerconsumer هی میگه بابا نمیتونم برو دیگه ولی کافکا نمیفهمه که تا وقتی این consumer این تسک رو انجام نده ول کن نیست دیگهنتیجه ی عمل چیه؟؟؟؟صف مسدود شده و پیام های دیگه پشت بر پشت توی صف منتظرن این یارو کارش راه بیوفته اما دریغ ازینکه راه بیوفتهچرا؟چون خطا دارهخب نمیشه که بقیه ی تسکارو یه عمر نگه داری؟؟؟پس بهترین کار این یارو DLQ هستمیگه چی؟میگه یه قانون retry یا همون pattern retry خودمون رو اجرا کنبیا تعریف کن اگر این یارو مسیجه سه بار اومد خطا خورد بفرستش تو یه تاپیکی با عنوان consumer-topic.DLQ که حداق بقیه تسکا بین جلو کارشون راه بیوفتهبعد برو سراغ این تسکه فلک زده ببین چه مرگش بودهاین خیلی خوب میشهاما ما دونوع خطا داریم داریم توی کافکا:1️⃣ Message-specific Error (خطای مربوط به پیام)2️⃣ Systemic Error (خطای سیستمی)توی خطا های مدل اول این الگوی DLQ عالیهههههههههههههههههههههههه اصلا نمونههههههههههههههههاما تو خطاهای مدل دوم : نه دیگه این الگو باعث این میشه که پایین میزارم:❌ پیام ۱ → DLQ❌ پیام ۲ → DLQ❌ پیام ۳ → DLQ❌ …❌ صدها تراکنش به DLQ میرن 💀راه حل این مصیبت چیه؟؟؟؟هوم؟؟؟circuit breaker patternتو مقاله بعدی درموردش صحبت میکنممن حسینم همچنین میتونید منو توی بله هم پیدا کنید

کافکا، بهینه با معماری میکروسرویس

محمد حسین خداخواه — Wed, 06 May 2026 21:13:31 +0330

توی کافکا، خیلی مهمه که بر اساس تعداد نمونه های یک consumers دقت کنیممثلا اگر ۵ تا نمونه از سرویس ولت وجود داره، در نتیجه توی ساخت producer ، ده تا پارتیشن درست کنیم،اینجوری خود کافکا برامون به صورت اتوماتیک لود بالانسینگ انجام میده(البته مهمه که حتما پارتیشنینگ به صورت دستی ست بشه موقع ساخت topic و اینکه هر پنج نمونه سرویس ولت همه به یه topic گوش بدن، مثلا همه به groupId : 'wallet-consume گوش بدن')مثال واقعی ترproduct : consumer ایشون سرویس پروداکته که داره گوش میده و ۵ تا نمونه ازش روی سرور بالاستwallet:producerایشون سرویس ولته که پرودیوسره و اصلا به عنوان پرودیوسر اهمیت نداره چنتا نمونه ازش ران شده روی سرور(تو این مورد البته)خب به ازای پنج تا نمونه سرویس پروداکت که consumer هست باید توی ساخت topic ولت به عنوان producer ده تا پارتیشن درست کنیم(البته باید که نه ولی اگر میخاید معماری تمیز کار کنه باید)حالا این ده تا پارتیشن چطور کار میکنن؟؟؟Producer Instance 1 ──→ Partition 0 ✅Producer Instance 2 ──→ Partition 1 ✅Producer Instance 3 ──→ Partition 2 ✅Producer Instance 4 ──→ Partition 3 ✅Producer Instance 5 ──→ Partition 4 ✅Partition 5 → 😴 بیکار (هنوز پیامی نیومده)Partition 6 → 😴 بیکارPartition 7 → 😴 بیکارPartition 8 → 😴 بیکارPartition 9 → 😴 بیکاربه این صورت producer که همون سرویس ولت هست پیاماشو ارسال میکنه و Partition 0 → Consumer Instance 1Partition 1 → Consumer Instance 1Partition 2 → Consumer Instance 2Partition 3 → Consumer Instance 2Partition 4 → Consumer Instance 3 ✅Partition 5 → Consumer Instance 3 ✅Partition 6 → Consumer Instance 4Partition 7 → Consumer Instance 4Partition 8 → Consumer Instance 5Partition 9 → Consumer Instance 5به این صورت سرویس پروداکت که consumer هست پارتیشن هارو میخونهحالا اگر مثلا نمونه ۳ از سرویس ولت داون بشه، چه اتفاقی میوفته؟؟؟ خب نکته همینجاست اگر مثلا instance 3 به درک واصل بشه بقیه نمونه ها جاشو پر میکنن Partition 0 → Consumer Instance 1Partition 1 → Consumer Instance 1Partition 2 → Consumer Instance 1 ← جدیدPartition 3 → Consumer Instance 2Partition 4 → Consumer Instance 2 ← جدیدPartition 5 → Consumer Instance 2 ← جدیدPartition 6 → Consumer Instance 4Partition 7 → Consumer Instance 4Partition 8 → Consumer Instance 5Partition 9 → Consumer Instance 5اینجوری میشه 👆من حسینم، میتونید منو توی بله هم پیدا کنید.@sungeek

معماری ؟؟؟ خب معلومه میکروسرویس . . .(۲) الهام گرفته از کتاب جناب سم نیومن و کریس ریچاردسون

محمد حسین خداخواه — Fri, 17 Oct 2025 20:15:44 +0330

یک معماری میکروسرویس اصولی باید در ابتدا از دو اصل مهم پیروی کنه.۱) loosely coupling۲) high cohesionاولی میگه که سرویس ها به هیچ عنوان نباید به هم وابستگی شدید یا (tight coupling) داشته باشند. سرویس ها نباید جزئیاتشون برای مصرف کننده هاشون (consumers) شفاف باشه. در این صورت تغییر در یک سرویس مصرف کننده هاشو از کار نمیندازه. پس در همون مرحله اول ایجاد معماری میکروسرویس که میتونه تعیین مرز های سرویس ها باشه (service boundary) باید این موضوع در نظر گرفته بشه که سرویس ها نباید از جزئیات همدیگه اطلاع داشته باشن.به نظرم تا وارد این مسئله تعیین مرز های سرویس ها شدیم خوبه به یادآوری بشه که تعیین مرز های سرویس ها یکی از مهم ترین مراحل چیدن معماری میکروسرویس برای یک پروژه است. غالبا شما وقتی میخاین یه معماری رو از صفر بچینید و یا حتی یه معماری monolithic رو بشکونید و تبدیل به میکروسرویس ها کنید (که به این کار decomposition میگن) در ابتدای امر احساس نیاز شدیدی خواهید کرد در مورد اینکه خب کدوم فیچر ها و کدوم بخش ها باید به عنوان یه سرویس جدا کار کنند . کدوم فیچر ها باید باهم باشن و کدوم یکی ها باید جدا بشن. این کار به دو روش میتونه صورت بگیره.آقای کریس ریچاردسون ( chris richardson ) در کتاب microservice patterns میفرماید که میکروسرویس هاتونو یا بر اساس بیزنس لاجیک و قابلیت کسب و کار تجزیه کنید یا بر اساس ساب دامنه ها اگر یکم متمرکز بخایم به معماری میکروسرویس نگاه کنیم میبینم که خیلی روی اصل مستقل بودن و انجام یک کار به خصوص به نحو احسن همانطور که جناب سم نیومن میفرماید (Small, and Focused on Doing One Thing Well) تاکید داره.از طرف دیگه هم عمو باب (robert c. martin) میگه که همه چیزایی که به یک دلیل تغییر میکنن رو یه جا نگه دار و همه چیزایی که به دلایل متفاوت تغییر میکنن رو جدا کن از هم. اگر این صحبت و اون دید آقای سم نیومن رو بزاریم کنار هم میبینم که درواقع سرویس ها خیلی راحت بر اساس بیزنس لاجیک تقسیم میشن. اما در تعیین مرز میکروسرویس ها باید به چنتا نکته مهم توجه بشه. میکروسرویس ها باید کوچک باشند. فلسفه میکروسرویس به ما اجازه این رو نمیده که سرویس هامون خیلی بزرگ بشن و توصیه میکنه که تا حد ممکن سرویس هارو کوچک کنیم.آنقدر کوچک که فقط یه کار انجام بدن.(یک کار منظور یه بخش از بیزنس لاجیک)آنقدر کوچک که در صورت به مشکل خوردن فقط یه بخش کوچک از پروژه از کار بیوفتد.آنقدر کوچک که در دو هفته قابل بازنویسی باشد (jon evas)آنقدر کوچک که تیمی که روش کار میکنه با یه پیتزا سیر بشه(Amazon)انقدر کوچک که دیگه حس بزرگی نداشته باشیم بهش.ولی از نظر منطقی و به نظر من یه میکروسرویس وقتی به اندازه کافی کوچک شده که نیاز به یه تیم بزرگ برای توسعه و مدیریتش نداشته باشیم. اگر یه میکروسرویس با ی تیم کوچک مدیریت نشه باید اونه تکه تکه کرد.درواقع هرچی سرویس کوچکتر باشد معایب میکروسرویس ها کمتر / بهره وری بیشتر میشه و مزایای وابستگی متقابل (interdependency) افزایش می یابد ولی خب ازین مسئله قافل نشیم که تعداد سرویس ها با کوچکتر شدنشون بیشتر میشه و نگهداری (maintenance) سخت تر میشه.سرویس ها باید ایزوله باشن.تمامی ارتباطات سرویس ها باید از طریق شبکه باشه تا از (tight coupling) جلوگیری شود.سرویس ها باید به صورت جدا از هم تغییر کنند و مستقر شوند.باید به صورت روشن و شفاف بدانیم که هر سرویس چه چیزهایی را باید expose کند برای مصرف کننده هاش و چه چیزهایی رو باید مخفی کند. اگر اشتراک گذاری با سرویس مصرف کننده زیاد باشد . سرویس مصرف کننده به نمایش داخلی سرویس خیلی وابسته میشه و اصل loosely coupling نقض میشه. وقتی سرویس ها tight coupled باشند باعث کاهش خودمختاری سرویس ها میشه زیرا در هنگام تغییر نیاز به هماهنگی اضافی با مصرف کننده های اون سرویس به شدت حس میشه.در واقع باید به decoupling زیاد فکر کنیم در تعیین مرز های سرویس هامون.قاعده طلایی ::: آیا میتوانید تغییر در یک سرویس ایجاد کنید و بدون تغییر در سرویس دیگری آن را دیپلوی کنید؟؟؟؟؟؟؟ 'سم نیومن'در تعیین مرز های سرویس ها باید خیلی زیاد به resilience engineering دقت کنیم. تاب آوری سرویس ها بسیار مهم هستند. در نهایت باید به گونه ایی سرویس ها مدل سازی شده باشند که در صورت خراب شدن هرکدوم فقط یه بخش کوچک از پروژه خراب شده باشه و بقیه پروژه به کار خودشون ادامه بدن.تصور کنید یه سیستم یکپارچه بزرگ دارید (monolithic) و میخاید یه تغییر روش اعمال کنید.خب در ابتدا ده خط کد رو تغییر میدید و به عنوان ورژن اول تغییر اعمال میکنید.سپس یه بخش دیگه رو تغییر میدید و چندین تا تغییر روی هم انباشه میشه و یکجا دیپلوی میکنید. سرویس رو ریستارت میکنید و بوم . . . همه چیز داون میشه. چون یه اشتباهی در یکجا اتفاق افتاده که مربوط به یکی از ده تغییر قبلی شما بوده.و الان کللللل پروژه داون شده. خب مسلما با سرعت هرچه تمام مشکل رو پیدا میکنید و حل میکنید و باز سرویس رو ران میکنید و احتمالا مشکل برطرف شده اما همچنان احتمال این وجود داره که در تلاش برای این مشکل یه مشکل دیکه بوجود آورده باشید. و حتی اگر مشکلی هم بوجود نیاورده باشید استرس وارد شده و ترس ایجاد شده از تغییر و اپدیت پروژه به خودی خود سرسام آور است. این مشکل رو در نظر داشته باشید و با درک این شرایط به طراحی معماری میکروسرویس خود بپردازید. چون اگر در طراحی و مدل سازی سرویس ها اشتباه کنید و یا اصول رو رعایت نکنید در واقع یه distributed monolithic میسازید که علاوه بر مشکلات معماری یکپارچه یه سری مشکلات دیگه اعم از پیچیدگی و نگهداری سخت رو هم بدنبال میاره.ینی اگر در همون معماری مونولیت بمونید تا خرخره توی monolithic hell هستید و اگر وارد یه معماری میکروسرویس بد بشید از چاله دراومدید افتادی داخل چاه.پس در تعیین مرزهای میکروسرویس ها و مدل سازی میکروسرویس ها و مشخص کردن api ها دقت کافی رو به خرج بدید.

معماری ؟؟؟ خب معلومه میکروسرویس . . .

محمد حسین خداخواه — Fri, 17 Oct 2025 00:10:33 +0330

حقیقتا کمتر دیدم کسی در لایه عمل به معماری پروژه زیاد اهمیت بده یا شایدم من جاهایی کار کردم که علم معماری فقط برعهده system designer یا به قول جناب سم نیومن عزیز در کتاب building microservices معمار سیستم بوده.من به عنوان کسی که تا الان معماری تمام پروژه هایی که انجام دادم رو شخص خودم طراحی کردم و همانطور که دور از انتظار نیست خیلی مشکلات ایجاد کردم و حل کردم و حتی مشکلاتی هم بوده که نتونستم حل کنم و نفهمیدم چه خاکی به سرم بریزم اما در نهایت همه تجربیات بدی که در طراحی معماری داشتم منجر به این تصمیم شد که برم کتاب بخونم . . .سرچ چیزیو دوا نمیکنه. کتاب بخونم و کتاب بخونم از جمله کتابهای مورد علاقم کتاب building microservice نوشته جناب سم نیومن که بنظرم خیلیییییییییییییییییی دید جامع و جالبی به آدم میده.تصمیم گرفتم یه بخش هایی ازش رو اینجا بزارم خلاصه و نکات قابل توجهش رو.ابزارها و تکنیک‌های در دسترس ما تغییر می‌کنند. چیزهایی که ما ایجاد می‌کنیم نقاط ثابتی در زمان نیستند. پس از راه‌اندازی در مرحله تولید، نرم‌افزار ما با تغییر نحوه استفاده از آن، به تکامل خود ادامه خواهد داد. برای اکثر چیزهایی که ایجاد می‌کنیم، باید بپذیریم که وقتی نرم‌افزار به دست مشتریانمان می‌رسد، باید واکنش نشان دهیم و خود را با آن وفق دهیم، نه اینکه یک مصنوع بی‌تغییر باشد. بنابراین، معماران ما باید تفکر خود را از ایجاد محصول نهایی بی‌نقص دور کنند و در عوض بر کمک به ایجاد چارچوبی تمرکز کنند که در آن سیستم‌های مناسب بتوانند ظهور کنند و با یادگیری بیشتر، به رشد خود ادامه دهند.. اریک دورننبرگ ابتدا این ایده را در میان گذاشت که ما باید نقش خود را بیشتر به عنوان برنامه‌ریزان شهر در نظر بگیریم تا معماران محیط ساخته شده. نقش برنامه‌ریز شهر باید برای هر یک از شما که قبلاً SimCity بازی کرده‌اید، آشنا باشد. نقش یک برنامه‌ریز شهر این است که به منابع اطلاعاتی متعدد نگاه کند و سپس تلاش کند تا طرح یک شهر را به گونه‌ای بهینه کند که به بهترین وجه با نیازهای شهروندان امروز، با در نظر گرفتن استفاده‌های آینده، مطابقت داشته باشد. با این حال، نحوه تأثیر او بر نحوه تکامل شهر جالب است. او نمی‌گوید: «این ساختمان خاص را در آنجا بسازید»؛ در عوض، او یک شهر را منطقه‌بندی می‌کند. بنابراین، مانند SimCity، می‌توانید بخشی از شهر خود را به عنوان یک منطقه صنعتی و بخش دیگری را به عنوان یک منطقه مسکونی تعیین کنید. سپس به عهده دیگران است که تصمیم بگیرند دقیقاً چه ساختمان‌هایی ساخته شوند، اما محدودیت‌هایی وجود دارد: اگر می‌خواهید یک کارخانه بسازید، باید در یک منطقه صنعتی باشد. برنامه‌ریز شهری به جای نگرانی بیش از حد در مورد آنچه در یک منطقه اتفاق می‌افتد، زمان بسیار بیشتری را صرف بررسی چگونگی جابجایی مردم و خدمات از یک منطقه به منطقه دیگر می‌کند.تشبیه معمار سیستم به برنامه ریز شهر خیلی پوینت جذابیه. ماها به عنوان معماران سیستم بیشتر تمرکز خود را باید صرف ارتباط بین بخش های یک شهر و ارتباط بخش ها و وظیفه های هر بخش کنیم تا اتفاقات خاصی که در اون شهر میوفته.ینی عین برنامه ریزی شهری ما باید مشخص کنیم که حد و مرز (service boundary)هر منطقه در شهر کجاست.این مناطق شهری (services) با گذشت زمان تغییر میکنند. نیاز به بزرگتر شدن دارن و با افزایش تعداد ساکنان هر بخش نیاز به بهبود عملکرد دارن.

tree Entities in typeOrm

محمد حسین خداخواه — Tue, 28 Jan 2025 10:27:59 +0330

سلام، گاهی اوقات ما یه سری مدل دیتای تودرتو و درختی داریم . . .چطوری اینارو بکنیم تو هم سیو کنیم؟؟؟توی مونگو دیبی خیلی راحته این کار اما میخام در مورد دیتا بیس های sql صحبت کنم مثل postgresql.و البته orm خفن typeOrm و treeEntity توش.======================================================================خب استفاده از tree entity در کل وقتی مفیده که نیاز به مدل سازی ساختار داده های تودرتو و یا درختی باشه.مثل نمودار های سازمانی سلسله مراتب دسته ها (به عنوان مثال، دسته های محصول)رشته های نظر (نظرات تودرتو)سیستم های فایل (پوشه ها و زیر پوشه ها)ساختارهای منو و ازین دسته دیتا ها . . .کلا typeorm با استفاده از الگو های Adjacency List, Closure Table, and Nested Set ساختار درختی هارو پشتیبانی میکنه.حالا انتخاب هرکدوم ازین الگو ها در جای مناسب خودش بسته به مدل دیتایی که داریم انجام میشه و خیلی مهمه که از هرکدوم در مناسب ترین جای ممکن استفاده کنیم البته این انتخاب کاملا بستگی به شخص خود شما دارد.=======================================================================یه گریز ریز بزنیم به این الگو ها : Adjacency List : در این مورد هر گره مرجع والدین خود را ذخیره میکند. و یک سلسله مراتب ساده با عمق محدود را ایجاد میکند. در نوشتن و طراحی سادست و برای درختان کم عمق مفید تر است.مشکلش هم دقیقا از همینجا میاد که اگر عمق درخت زیاد بشه ممکنه کند عمل کنه.مثال این adjacency list رو ببینیم با هم:import { Entity, Tree, TreeChildren, TreeParent, TreeLevelColumn } from 'typeorm'; @Entity() @Tree('adjacency-list') // Use Adjacency List pattern export class Category { @TreeChildren() children: Category[]; @TreeParent() parent: Category; @TreeLevelColumn() level: number; // Automatically tracks the depth of the node }Closure Table :در این یکی یک جدول جداگانه روابط بین گره هارو سیو میکنه و دارای سلسله مراتب پیچیده تری هست و کویری های متعددی ایجاد میکنه از فرزند و والد.درختان عمیق تر و خیلی موثر تر کنترل میکنه و کویری های سریعی میزنه به فرزندان و والد. ولی خب برای پیاده سازی پیچیده تره و یه تیبل جداگونه لازم داره برا خودشخب بریم مثال پیاده سازیشو ببینیم . . .import { Entity, Tree, TreeChildren, TreeParent, TreeLevelColumn } from 'typeorm'; @Entity() @Tree('closure-table') // Use Closure Table pattern export class Category { @TreeChildren() children: Category[]; @TreeParent() parent: Category; @TreeLevelColumn() level: number; // Automatically tracks the depth of the node }Nested Set:به هر گره یک مقدار چپ و یه مقدار راست داده میشه که جایگاهشو در درخت بفهمه و بیشتر برای سلسله مراتب های گنده گنده با بروز رسانی های خیلی کم استفاده میشه . و میگن توی کویری های فرزند و والد به شدت سریع عمل میکنه. امااااااااااااااااا متاسفانه توی بروز رسانی ها هزینه ی سنگینی داره .مثالشو ببینیم : import { Entity, Tree, TreeChildren, TreeParent, TreeLevelColumn } from 'typeorm'; @Entity() @Tree('nested-set') // Use Nested Set pattern export class Category { @TreeChildren() children: Category[]; @TreeParent() parent: Category; @TreeLevelColumn() level: number; // Automatically tracks the depth of the node }اما خب سوالی که ممکنه ایجاد بشه اینه که اصلا چرا باید ازین treeEntity استفاده کنیم؟؟؟جواب اینه که ببین عزیز دل من که داری دیتا بیس کار میکنی یا یاد میگیری یا هرچی اصلا ببین :معمولا به دلایلی استفاده میکنیم به عنوان مثال به خاطر کارآمدی(efficiently) کویری هایی که به دیتاهایی با ساختار درختی میزنیم.همچنین به دلیل مدیریت ساده تر روابط سلسه مراتبی دیتاهاهمچنین انعطاف پذیری (flexibility) چقد دیگه دلیل میخاین؟؟؟اصن همین که فکر کنید به ی دیتا با ساختار تودرتو بعد اینو در نظر بگیرید خودتون متوجه میشید دیگه.نتیجه گیری : انتیتی های درختی در TypeORM مدیریت داده های سلسله مراتبی را ساده می کنند و قابلیت های جستجوی کارآمدی را ارائه می دهند. با انتخاب الگوی درخت مناسب (فهرست مجاورت، جدول بسته یا مجموعه تودرتو)، می توانید برنامه خود را برای عملکرد و مقیاس پذیری بهینه کنید.

ورکر ها در نود جی اس (workers in node js ) part 2

محمد حسین خداخواه — Tue, 24 Dec 2024 01:02:53 +0330

به نام خداسلام علیکمپیرو مطلب قبلی در مورد ورکر ها که خبر دادیم رفتیم اومدم کامل ترش کنم. . .اول از همه یه چیزی بگم که خیلی مهمه . . . node js یه قانون مهم و حیاتی داره میگه که آقا لطفا هرکاری میکنید بکنید ولی حلقه ی رویداد رو (event loop) رو مسدود نکنید تورو به ابلفضل. چکار کنه دیگه بنده خدا. . .اینو داشته باشین تا یه مثال کوچولو بزنم برا شروع :فرض کنید چی داریم ؟‌ داریم دوتا پردازش. یکی سنگین که مثلا ده ثانیه طول میکشه و یکی سبک که مثلا ایکی ثانیه کار جمعه.حالا اگر سیستم مشغول انجام کار سنگینه باشه که ده ثانیه طول میکشه نمیتونه که به اون یکی درخاست کوچولوعه رسیدگی کنه سریعا.دقت کنید گفتم سریعا. ینی در نهایت که کارو میکنه مگر در موارد دیگر ولی خب چون مشغول کار سنگینه هست نمیتونه سریعا کار سبکه رو جمع کنه.حالا اینجا چی شد؟؟؟ ما اومدیم با این حرکت حلقه ی رویداد(event loop) رو مسدود کردیم که کار بسیار ناپسندیست.خب ما که میدونیم نود جی اس سینگل ترد(single thread) تشریف دارن و این کارا واسمون گرون تموم میشه.ولی این آیا ینی اینکه ما نباید کارهای سنگین باهاش انجام بدیم؟؟نه خیر هرگز . . .نود جی اس ورژن 10.5.0 کانسپت worker thread رو از طریق ماژول worker_threads رو معرفی کرد که خب بعد از ورژن 12 نود جی اس به یک عملکرد پایدار تبدیل شد. یه تعریف کوچولو هم بگیم از همزمانی به نقل از جناب آقای Rob Pike : همزمانی (Concurrency) به معنای برخورد همزمان با خیلی چیز میزاست. و در مقابلش موازی گرایی(parallelism) یعنی انجام خیلی کارا به طور همزمان.خب تا اینجا میدونیم که (حداقل امیدوارم که خوب رسونده باشم که) انجام چندین کار با یک رشته در مقایسه با اجرای آنها به صورت موازی روی رشته های مستقل زمان بیشتری رو میطلبه.پس اینجای مطلب دیگه وقتشه که جناب worker وارد صحنه بشه و بگه که آقایون شما میتونید کارهای فشرده که هزینه زمانی زیادی دارن رو به من بسپارید و این در حالیه که وظایف نسبتا کوچولو تر روی رشته ی اصلی اجرا می شن. پس دیگه اونا کاری به اینا ندارن. متوجه هستید؟؟؟یادم باشه در مورد processes and threads هم یه مقاله تهیه بنمایم . . .بنظرم تا اینجا بسته چون این قصه سر درااااااااز دارد . . . بعد از این دیگه میریم سر وقت کد زدن و ساختن و پرداختن به ورکر های عزیزمون.من حسینم مرسی ازینکه مقالمو خوندین . . .

ورکر ها در نود جی اس ,workers in node js

محمد حسین خداخواه — Sun, 22 Dec 2024 00:30:07 +0330

کارگر ؟؟ بعله کارگر . . .کارگر داریم توی نود جی اس . . .البته توی کل جاوااسکریپت داریم ولی خب حالا نمیخام دیپ بشم روشاما در کل کارگر چیه؟؟؟ببین اگر پایتونو بشناسی میدونی که مولتی ترده(multi threads) اما جاوااسکریپت نه. هی روزگار چرا نه ؟ جاوا اسکریپت کلا سینگل ترده دیگه اینو همه میدوننتماااااام کد رو یه ترد(thread) اجرا میشه به ترتیبی که خودش میدونه (به ما مربوط نیست!)اماااااا. . .اما اینجاش قشنگه که درسته که جاوااسکریپت single thread میباشد و همه چی رو یه نخ یا ترد اجرا میشه ولی میتونیم یه جورایی مولتی ترد بنویسیمش.با چی؟ با کی؟ چطوری؟؟با حمالای جاوااسکریپت یا همون (worker threads) .ورکر ها اجرای موازی کد جاوا اسکریپت رو با استفاده از رشته ها ساده میکنه و به طرز عجیب و جالب و واااااوی سریعتر و کارآمد تره والا.به دلیل ویژگی های زیر(به نقل از https://www.simplilearn.com/tutorials/nodejs-tutorial/nodejs-worker-threads) به درد میخورن : این یک فرآیند واحد را با چندین رشته اجرا می کند.یک نمونه موتور JS را در هر رشته اجرا می کند.یک حلقه رویداد را در هر رشته اجرا می کند.یک نمونه Node.js را در هر رشته اجرا می کند.برای شروع، باید Node.js خود را به نسخه جدیدتر به روز کنیم.دلایل بالا رو کپی کردم.(گفتم که حلال باشه)این یه مثال از وروکر ساختنهconst { WorkerData, parentPort } = require('worker_threads')parentPort.postMessage({ welcome: WorkerData })حالا اینو ساختیم یه جا باید صداش بزنیم در هر صورت دیگه. صداش میزنیم که اینم شروع کنه به کار اما رو یه رشته یا نخ یا ترد یا هرچی دیگه کاری که ما میخایم جدا از پردازش اصلیمون انجام بشه رو برامون انجام بده.اینم اونجایی که مثلا میشه کد پردازش اصلیمون و اون حمالمونو صدا میزنیم. . .const { Worker } = require('worker_threads')const runService = (WorkerData) => {return new Promise((resolve, reject) => {const worker = new Worker('./workerExample.js', { WorkerData });worker.on('message', resolve);worker.on('error', reject);worker.on('exit', (code) => {if (code !== 0)reject(new Error(`stopped with ${code} exit code`));})})}const run = async () => {const result = await runService('hello node.js')console.log(result);}run().catch(err => console.error(err))توضیحات بیشتر رو تو مقاله های بعدی خواهم داد.اما خب برا اونا که نمیدونستن بگم که کلییییییییی خوش به حالتونه ازین به بعد که میدونید. قراره کلی عشق کنید.مرسی ازینکه مقالمو خوندین. . .مقاله ی خاصی هم نبود بیشتر شبیه یه خبر بود اما خب قراره مقاله ی بعدی تا فی ها خالدونشو بریزم بیرون براتون.من حسینم . یه بک اند کار ساده . . .یا علی