9.4.5 الگو Drop

9.4.5.1 توضیحات #

الگوی Drop یا Drop Overflow یکی از الگوهای حیاتی برای سیستم‌هایی است که ممکن است با موجی از درخواست‌ها روبرو شوند که بیش از ظرفیت واقعی سیستم است. در این الگو، زمانی که صف یا ظرفیت پردازش درخواست‌ها (مثلاً یک کانال یا بافر) پر می‌شود، به جای اینکه سیستم را دچار ازدحام، توقف یا crash کند، به سادگی درخواست‌های اضافی (یا جدیدتر یا قدیمی‌تر، بر اساس سیاست) را حذف (Drop) می‌کند. این کار باعث می‌شود سرویس همواره پایدار و قابل اطمینان باقی بماند و منابع اصلی به خاطر یک سناریوی غیرعادی یا حمله دچار مشکل نشود.

کاربرد این الگو به‌خصوص در سرویس‌های زیرساختی حیاتی مانند DNS، load balancer، یا حتی سیستم‌های realtime که نمی‌خواهند به هیچ قیمتی دچار backlog و تاخیر بالا شوند، بسیار رایج است. به عنوان مثال، در یک سرور DNS وقتی تعداد درخواست‌ها از ظرفیت کانال یا worker pool بیشتر شود، درخواست‌های جدید بلافاصله drop می‌شوند تا latency پایین بماند و سرور همچنان responsive بماند. این الگو به عنوان بخشی از استراتژی کلی Backpressure نیز به کار می‌رود و برای معماری‌هایی که تحمل “از دست رفتن بعضی درخواست‌ها” بهتر از “کُند شدن یا قطع کامل سرویس” است، ایده‌آل محسوب می‌شود.

در پیاده‌سازی‌های Go معمولاً یک کانال بافر دار تعریف می‌شود و اگر هنگام ارسال داده به کانال، با پر بودن مواجه شویم (مثلاً با select غیر بلوک‌کننده)، درخواست به راحتی Drop می‌شود و کنترل به سرعت به کد اصلی بازمی‌گردد. این تکنیک ساده، موثر و بسیار idiomatic در پروژه‌های تولیدی Go است و به حفظ کیفیت خدمات و جلوگیری از overload شدن سیستم کمک شایانی می‌کند.

9.4.5.2 دیاگرام #

9.4.5.3 نمونه کد #

package main

import (
	"fmt"
	"sync"
	"time"
)

func main() {
	const bufferSize = 3
	const numData = 10

	in := make(chan int, bufferSize)
	out := make(chan int, bufferSize)
	var wg sync.WaitGroup

	// تولیدکننده: تولید داده با Drop در صورت پر بودن کانال
	wg.Add(1)
	go func() {
		defer wg.Done()
		for i := 1; i <= numData; i++ {
			select {
			case in <- i:
				fmt.Printf("[Producer] Sent: %d\n", i)
			default:
				fmt.Printf("[Producer] Drop: %d (buffer full)\n", i)
			}
			time.Sleep(100 * time.Millisecond)
		}
		close(in)
	}()

	// مصرف‌کننده: مصرف داده با Drop اگر مصرف‌کننده بعدی نتواند داده را بپذیرد
	wg.Add(1)
	go func() {
		defer wg.Done()
		for data := range in {
			select {
			case out <- data:
				fmt.Printf("[Consumer] Forwarded: %d\n", data)
			default:
				fmt.Printf("[Consumer] Drop: %d (output buffer full)\n", data)
			}
			time.Sleep(150 * time.Millisecond)
		}
		close(out)
	}()

	// جمع‌آوری خروجی
	for result := range out {
		fmt.Printf("[Result] Received: %d\n", result)
	}

	wg.Wait()
}

در این مثال از الگوی Drop Overflow، یک سناریوی واقعی‌تر برای مدیریت بار بیش از ظرفیت در سیستم‌های concurrent نمایش داده شده است. ابتدا دو کانال بافر‌دار (یکی برای ورودی و دیگری برای خروجی) تعریف شده‌اند تا شبیه‌ساز صف‌هایی با ظرفیت محدود باشند. یک goroutine به عنوان تولیدکننده، داده‌هایی با مقادیر مختلف (از ۱ تا ۱۰) تولید می‌کند و در تلاش است آن‌ها را وارد کانال ورودی کند. اگر ظرفیت کانال ورودی پر باشد، داده جدید بدون معطلی Drop شده و پیام مناسبی در لاگ چاپ می‌شود؛ این رفتار باعث می‌شود که goroutine تولیدکننده هیچگاه بلاک نشود و سیستم دچار اختلال یا توقف نگردد.

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

در انتهای برنامه، خروجی‌ها از کانال خروجی جمع‌آوری و چاپ می‌شوند تا وضعیت مصرف موفق داده‌ها قابل مشاهده باشد. با کمک sync.WaitGroup اطمینان حاصل شده که تمام goroutineها قبل از پایان برنامه به درستی خاتمه پیدا می‌کنند و هیچ goroutine سرگردان یا leak اتفاق نمی‌افتد. با افزودن تأخیرهای زمانی متفاوت در تولید و مصرف داده‌ها، سناریوهای متفاوتی از فشار و ترافیک شبیه‌سازی شده تا نقاط Drop مختلف به خوبی دیده شوند. این مثال نشان‌دهنده کاربرد عملی و idiomatic این الگو در Go است؛ جایی که Drop شدن بخشی از داده‌ها به جای کندی یا Crash سیستم، انتخابی هوشمندانه و تولیدی محسوب می‌شود، به ویژه در سیستم‌های real-time، سرویس‌های زیرساختی یا سناریوهایی با بار متغیر.

9.4.5.4 کاربردها #

• محدودسازی نرخ پردازش (Rate Limiting): زمانی که با حجم بالایی از داده‌های ورودی یا درخواست‌ها سروکار دارید، این الگو به شما کمک می‌کند تا تنها تعداد مشخصی داده را در هر لحظه بپذیرید و باقی داده‌های مازاد را Drop کنید؛ به این ترتیب، نرخ پردازش سیستم ثابت و قابل کنترل باقی می‌ماند و از overload یا کندی سیستم جلوگیری می‌شود.
• ثبت لاگ و مانیتورینگ (Logging/Monitoring): در سیستم‌های لاگ‌گیری یا مانیتورینگ با حجم بالای رویداد، ممکن است توان نوشتن روی دیسک یا ارسال داده به سرور مرکزی محدود باشد. با پیاده‌سازی Drop Pattern می‌توانید پیام‌های اضافی یا کم‌اهمیت را به سادگی حذف کنید تا ضمن حفظ پایداری سرویس، داده‌های کلیدی با کمترین تأخیر ثبت شوند.
• مدیریت صف و کنترل ازدحام (Queue Management & Congestion Control): هنگام استفاده از صف‌هایی که توسط کانال‌های بافر‌دار مدیریت می‌شوند، به جای مسدود شدن تولیدکننده یا ایجاد backlog زیاد، می‌توانید در صورت پر شدن صف، داده‌های جدید را Drop کنید. این رفتار به ویژه در سناریوهای با بار متغیر، باعث افزایش پایداری سیستم و کاهش سربار مدیریت صف می‌شود.
• کنترل ترافیک شبکه و ورودی (Traffic Shaping & Throttling): در سرورها یا سرویس‌هایی که با حجم بالای ترافیک یا درخواست همزمان مواجه می‌شوند (مانند API Gateway یا Load Balancer)، Drop Pattern کمک می‌کند که بخشی از ترافیک ورودی در صورت نبود ظرفیت حذف شود و کیفیت خدمات به کاربران باقی‌مانده حفظ شود. این رویکرد، راهکاری مؤثر برای جلوگیری از حملات DoS یا اسپایک‌های ناگهانی است.
• سیستم‌های بلادرنگ و حساس به تأخیر (Real-time & Low Latency Systems): در سیستم‌های real-time مانند سیستم‌های پردازش صدا، تصویر، یا تحلیل لحظه‌ای داده‌های حسگرها، معمولاً داده‌ها باید در بازه زمانی مشخص پردازش شوند. در صورت پر بودن بافر یا عدم توان مصرف داده، داده‌های جدید Drop می‌شوند تا latency پایین و پاسخ‌دهی سریع سیستم حفظ شود.
• سرویس‌های زیرساختی حیاتی (مانند DNS و پیام‌رسان‌ها): در زیرساخت‌هایی مثل DNS، صف‌های کاری باید کوتاه و پاسخ‌دهی سریع باشد. اگر صف پر شود، درخواست‌های جدید به سرعت Drop می‌شوند تا سرویس‌دهی پایدار باقی بماند و سیستم دچار اشباع یا توقف نشود.