Queue پیامک چیست؟ چرا پیام‌ها در صف می‌مانند و چگونه گلوگاه را پیدا کنیم؟
صف پیامک یا SMS Queue بخشی از مسیر ارسال است که درخواست‌های پذیرفته‌شده را تا زمان پردازش و واگذاری به مسیر بعدی نگه می‌دارد. اگر پیام‌ها سریع‌تر از ظرفیت پردازش یا پذیرش مسیر اپراتوری وارد شوند، صف رشد میکند و زمان انتظار بالا می‌رود. برای پیدا کردن گلوگاه، نرخ ورود و خروج، تعداد پیامهای آماده، عمر قدیمیترین پیام، زمان پردازش و خطاهای هر مسیر را کنار هم ببینید.
وقتی سامانه پیام «با موفقیت ثبت شد» نشان می‌دهد اما کد تأیید دیر می‌رسد، نخست باید بدانیم موفقیت در کدام مرحله رخ داده است. ثبت درخواست، خروج از صف، پذیرش درگاه اپراتوری و تحویل به گوشی چهار رویداد متفاوت‌اند. این راهنما برای مدیر فنی، تیم عملیات و صاحبان محصول نوشته شده تا با نشانه‌های قابل اندازه‌گیری، علت ماندن پیام‌ها در صف را تشخیص دهند. برای شناخت جایگاه صف در کل زیرساخت، راهنمای معماری SMS Gateway سازمانی را نیز ببینید.
Queue پیامک چیست و در مسیر ارسال چه میکند؟
Queue یا صف، درخواست‌های ارسال را میان تولیدکننده و پردازش‌گر نگه می‌دارد. تولیدکننده می‌تواند وب‌سایت، سامانهٔ بانکی یا نرم‌افزار پشتیبانی باشد؛ پردازش‌گر پیام را از صف برمی‌دارد، اعتبارسنجی و مسیریابی را انجام می‌دهد و آن را به اتصال بالادستی می‌سپارد. صف، جهش کوتاهمدت درخواست را جذب میکند و به بخش ورودی اجازه می‌دهد مستقل از سرعت لحظه‌ای مسیر خروجی کار کند. با این حال، صف ظرفیت بی‌نهایت ایجاد نمی‌کند: اگر نرخ ورود برای مدتی از نرخ خروج پایدار بیشتر باشد، عقبماندگی یا backlog زیاد میشود.
یک پیام ممکن است در وضعیت «آمادهٔ پردازش» باشد یا توسط پردازش‌گر برداشته شده اما هنوز تأیید نهایی نشده باشد. مستندات RabbitMQ این دو را با شاخص‌های ready و unacknowledged جدا میکند. نام و معنای شاخص‌ها در فناوری‌های دیگر فرق دارد؛ برای عیب‌یابی، مهم این است که پیامهای منتظر را از پیامهای در حال پردازش جدا ببینید. افزایش تعداد پیام در حال پردازش همراه با خروجی کم می‌تواند نشانهٔ کندی پردازش‌گر یا سرویس وابسته باشد، حتی اگر شمار پیام آماده ظاهراً ثابت بماند.
چرا پیام‌ها در صف ارسال می‌مانند؟
۱. ورود پیام از ظرفیت خروجی بیشتر است
در کمپین، رخداد فروش یا افزایش درخواست رمز یکبارمصرف، نرخ ورود ممکن است به‌سرعت بالا برود. اگر پردازش و مسیر خروجی نتوانند با همان آهنگ پیش بروند، طول صف و عمر پیامهای قدیمی زیاد میشود. این وضعیت را با مقایسهٔ نرخ ورودی و خروجی در بازه‌های یکسان تشخیص دهید، نه با یک عدد لحظه‌ای از تعداد پیام‌ها. در یک جهش کوتاه، صف می‌تواند پس از فروکش بار تخلیه شود؛ در بار پایدارِ بیش از ظرفیت، تأخیر هر دقیقه بدتر خواهد شد. مقالهٔ گلوگاه‌های Peak Traffic پیامکی مسیر بررسی کل سامانه را توضیح می‌دهد.
۲. پردازش‌گر یا Backend کند شده است
پیام ممکن است پس از خروج از صف برای دریافت قالب، بررسی مجوز، خواندن تنظیمات مشتری یا ذخیرهٔ رویداد به سرویس دیگری وابسته باشد. تأخیر پایگاه داده، محدودیت اتصال، قفل، مصرف بالای CPU یا خطای وابستگی، زمان هر پردازش را طولانی میکند. تنها افزودن پردازش‌گر زمانی مفید است که گلوگاه در خود پردازش باشد و سرویس وابسته توان پاسخ‌گویی به بار بیشتر را داشته باشد. زمان پردازش، خطا و تعداد پیامهای در حال پردازش را به تفکیک هر مرحله ثبت کنید.
۳. مسیر اپراتوری یا ارائه‌دهنده پذیرش کندی دارد
گاهی پردازش‌گر آماده است اما اتصال خروجی، پیام را با سرعت کافی نمی‌پذیرد یا موقتاً خطا می‌دهد. در این حالت صف می‌تواند فقط برای یک اپراتور، نوع فرستنده یا مسیر خاص رشد کند. نرخ پذیرش، زمان پاسخ، خطا و محدودیت قراردادی هر مسیر را جدا بسنجید. افزودن سرور داخلی، ظرفیت مسیر بالادستی را خودبه‌خود بیشتر نمی‌کند. پیش از تغییر مسیر، محدودیت‌های سرویس، مجوز و رفتار گزارش تحویل را بررسی کنید.
۴. Retry پیامهای خطادار را دوباره وارد صف میکند
تلاش دوباره برای خطای گذرا لازم است، اما اگر چند لایه هم‌زمان یک پیام را تکرار کنند، بار اضافی و حتی ارسال تکراری ایجاد میشود. خطای دائمی مانند دادهٔ نامعتبر نباید بی‌پایان retry شود. شمار تلاش، فاصلهٔ تلاش‌ها، علت خطا و سن پیام را ثبت کنید. برای خطاهای گذرا، تأخیر افزایشی و سقف تلاش با نیاز کسبوکار هماهنگ کنید؛ پیامهای حل‌نشده را به مسیر بررسی یا dead-letter queue بفرستید. مهلت اعتبار رمز یکبارمصرف نیز مهم است: ارسال بسیار دیرهنگام، هرچند از نظر فنی موفق، برای کاربر بی‌فایده است.
۵. اولویت‌بندی و تنظیم صف مناسب نیست
اگر پیامهای تراکنشی و کمپین در یک صف و با یک ظرفیت مشترک پردازش شوند، حجم کمپین می‌تواند پیام حساس به زمان را پشت خود نگه دارد. صف یا سهم ظرفیت جداگانه برای کلاس‌های پیام، همراه با سیاست شفاف اولویت، به کنترل تأخیر کمک میکند. اولویت‌بندی را با وعدهٔ ترتیب مطلق اشتباه نگیرید: رفتار صف، پردازش هم‌زمان و بازگشت پیام به صف می‌تواند ترتیب مشاهده‌شده را تغییر دهد. برای هر کلاس، حداکثر زمان انتظار مطلوب و رفتار پیام منقضی را مشخص کنید.
چک‌لیست عیب‌یابی صف پیامک: گلوگاه را چگونه پیدا کنیم؟
با یک شناسهٔ رهگیری برای هر پیام، زمان پذیرش، ورود به صف، شروع و پایان پردازش، واگذاری به مسیر و دریافت وضعیت تحویل را ثبت کنید. سپس در یک بازهٔ زمانی مشخص، شاخص‌ها را برای مشتری، نوع پیام و مسیر جدا کنید. تصویر زیر شش ایستگاه بررسی را خلاصه میکند؛ توضیح کامل آن در جدول آمده است.
| گام | چه چیزی را بسنجیم؟ | اگر غیرعادی بود، چه بپرسیم؟ |
|---|---|---|
| ۱. جریان ورودی و خروجی | تعداد پیام پذیرفته و خارج‌شده در بازهٔ یکسان | آیا بار ورودی برای مدتی از توان پردازش بیشتر است؟ |
| ۲. عمق و عمر صف | پیام آماده، پیام در حال پردازش و عمر قدیمیترین پیام | صف فقط پر است یا انتظار واقعی نیز طولانی شده؟ |
| ۳. پردازش‌گر | زمان پردازش، خطا، تعداد worker و وابستگی Backend | آیا سرویس وابسته سرعت خروج را محدود میکند؟ |
| ۴. مسیر خروجی | نرخ پذیرش، زمان پاسخ و خطا به تفکیک اپراتور | آیا کندی تنها در یک مسیر دیده میشود؟ |
| ۵. تلاش دوباره | تعداد retry، علت خطا و پیامهای صف خطا | آیا پیام تکراری یا خطای دائمی ظرفیت را مصرف میکند؟ |
| ۶. تجربهٔ کاربر | زمان درخواست تا sent و delivered، به تفکیک کلاس پیام | آیا تأخیر پیش از واگذاری است یا پس از آن؟ |
عمر قدیمیترین پیام در بسیاری از رخدادها از طول صف گویا‌تر است: صفی با پیامهای فراوان اما خروج سریع ممکن است سالم باشد، در حالی که تعداد کمِ پیامهای بسیار قدیمی نشان‌دهندهٔ گیرکردن پردازش است. البته پیاده‌سازی این شاخص در سامانه‌های صف متفاوت است؛ مستندات Amazon SQS نیز دربارهٔ تقریبی بودن برخی سنجه‌ها و اثر پیامهای تکراری یا خطادار هشدار می‌دهد. شاخص صف را همواره با رویدادهای برنامه و مسیر خروجی تطبیق دهید.
Capacity، Retry و اولویت‌بندی را چگونه تنظیم کنیم؟
برای برنامه‌ریزی ظرفیت، نرخ ورود در ساعت عادی و اوج، نرخ خروج پایدار هر مسیر و زمان مجاز انتظار را جدا اندازه بگیرید. ظرفیت را فقط با تعداد worker تعریف نکنید؛ پردازش Backend، اتصال، محدودیت اپراتور و زمان پاسخ هم سقف واقعی می‌سازند. اگر نرخ خروج در همهٔ مسیرها پایین است، به لایهٔ مشترک نگاه کنید. اگر تنها یک مسیر عقب می‌ماند، همان مسیر و سیاست مسیریابی را بررسی کنید. در هر دو حالت، تغییر را با آزمون بار کنترل‌شده و پایش پس از اجرا ارزیابی کنید.
برای پیامهای حساس به زمان، کلاس سرویس و سیاست انقضا تعریف کنید؛ برای مثال پیام منقضی نباید پس از پایان اعتبار به‌عنوان ارسال موفقِ مفید گزارش شود. Retry باید به نوع خطا وابسته باشد: خطای گذرا با فاصله و سقف مشخص، خطای دائمی با توقف و ثبت برای بررسی. شناسهٔ یکتای پیام و ثبت هر تلاش، تشخیص ارسال تکراری و ریشهٔ خطا را ساده‌تر میکند. پیامهای صف خطا را با فرآیند روشن بررسی و در صورت مجاز بودن دوباره‌پردازش کنید؛ بازگرداندن همهٔ آنها در یک لحظه می‌تواند همان گلوگاه را بازسازی کند.
هشدار نیز باید به تجربهٔ کاربر وصل باشد. تنها آستانهٔ «تعداد پیام در صف» کافی نیست؛ عمر قدیمیترین پیام، نرخ ورود/خروج، نسبت خطا و فاصلهٔ درخواست تا واگذاری را برای هر کلاس پیام پایش کنید. برای تشخیص تأخیر تحویل، زمان sent تا delivered را جدا گزارش دهید. این تفکیک نشان می‌دهد تیم داخلی، ارائه‌دهنده یا مسیر اپراتوری در کدام بخش باید اقدام کند.
پرسش‌های رایج دربارهٔ صف پیامک
آیا ماندن پیام در Queue همیشه نشانهٔ خرابی است؟
خیر. صف برای جذب نوسان کوتاهمدت طراحی میشود. مسئله زمانی جدی است که عمر پیام و حجم عقبماندگی پیوسته افزایش یابد یا زمان ارسال از نیاز کسبوکار فراتر برود.
چرا API موفق است ولی پیامک دیر می‌رسد؟
پاسخ موفق API ممکن است فقط پذیرش درخواست را نشان دهد. پیام سپس در صف، پردازش، مسیریابی و مسیر اپراتوری حرکت میکند. زمان هر مرحله و وضعیت تحویل را با شناسهٔ واحد بررسی کنید.
افزودن worker همیشه صف را کوتاه میکند؟
خیر. اگر گلوگاه پایگاه داده، سرویس Backend یا محدودیت پذیرش مسیر اپراتوری باشد، worker بیشتر ممکن است فقط فشار روی همان بخش را افزایش دهد.
برای مانیتورینگ صف پیامک چه شاخصهایی مهماند؟
نرخ ورود و خروج، پیامهای آماده و در حال پردازش، عمر قدیمیترین پیام، زمان پردازش، خطا و retry، پذیرش هر مسیر و زمان رسیدن به وضعیت sent و delivered را کنار هم ببینید.
صف جدا برای پیامهای تراکنشی چه فایدهای دارد؟
صف یا سهم ظرفیت جدا کمک میکند بار انبوه کمپین، پیامهای حساس به زمان مانند رمز یکبارمصرف را پشت خود نگه ندارد. سیاست اولویت باید با ظرفیت واقعی و رفتار انقضا هماهنگ باشد.
برای یافتن گلوگاه، مسیر پیام را یکجا ببینید
اگر صف پیامک در ساعات اوج رشد میکند، ابتدا لایهٔ محدودکننده و مسیرهای درگیر را با داده مشخص کنید. صفحهٔ راهکار تلیرکو اجزای SMS Gateway سازمانی و مسیر بررسی زیرساخت را معرفی میکند.
منابع فنی: RabbitMQ: Queues، RabbitMQ: Monitoring، AWS SQS: Queue metrics، Twilio: Outbound message status. این منابع برای توضیح اصول عمومی صف و وضعیت پیام هستند و بیانگر استفادهٔ تلیرکو از فناوری یا سرویس خاصی نیستند.