تخصیص اتمی کم‌استفاده‌ترین پروکسی در Redis

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

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

local chosen = redis.call('ZRANGE', KEYS[1], 0, 0)[1]
if not chosen then
    return nil
end

redis.call('ZINCRBY', KEYS[1], 1, chosen)
return chosen

کلید مجموعه مرتب را به‌عنوان تنها آرگومان کلید اسکریپت از طریق رابط EVAL کلاینت Redis خود بفرستید. استخر خالی نتیجه null تولید می‌کند که برنامه باید بدون ارسال درخواست آن را مدیریت کند.

چرا دو فرمان را ترکیب کنیم؟

خواندن و افزایش جداگانه باعث می‌شود دو کارگر پیش از به‌روزرسانی توسط هرکدام، کمینه یکسان را ببینند. Redis اسکریپت Lua را اتمی اجرا می‌کند، پس کارگر دیگری نمی‌تواند میان خواندن و افزایش این اسکریپت انتخابی درج کند. اسکریپت را کوتاه نگه دارید، چون اجرای آن کار دیگر Redis را مسدود می‌کند.

ZRANGE کمترین امتیاز را اول برمی‌گرداند؛ امتیازهای برابر با ترتیب اعضا حل می‌شوند، نه به‌صورت تصادفی. ZINCRBY امتیاز عضو انتخاب‌شده را برای تخصیص بعدی یک واحد بالا می‌برد.

معنای امتیاز را تعریف کنید

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

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

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