سرور MCP را امن کنید؛ stdio به‌تنهایی sandbox نیست
هوش مصنوعی و خودکارسازی
Redis یا Valkey؛ مجوز دوباره باز شد، اما مسیر دو پروژه یکی نیست
برای کش موجود، فهرست مجوزهای Redis نشان می‌دهد که Redis از نسخهٔ 8 گزینهٔ AGPLv3 مورد تأیید OSI را در کنار RSALv2 و SSPLv1 ارائه می‌کند؛ بنابراین تغییر مجوز به‌تنهایی دیگر دلیل کافی برای مهاجرت نیست. انتخاب میان Redis و Valkey به نسخهٔ مبدأ، داده و فرمان‌های مصرفی، رفتار زیر بار و شیوهٔ استقرار بستگی دارد.
Valkey بنا بر معرفی رسمی پروژه با مجوز BSD و پشتیبانی بنیاد لینوکس توسعه می‌یابد. برای کشی که داده‌اش بازسازی‌پذیر است و از امکانات مشترک دو پروژه استفاده می‌کند، مهاجرت به آن می‌تواند انتخابی معقول باشد. برای دیتاستوری که به قابلیت‌های جدیدتر Redis یا سرویس مدیریت‌شدهٔ فعلی وابسته است، هزینهٔ ماندن و مهاجرت را باید جداگانه سنجید.
مجوز و حکمرانی چه اثری بر انتخاب دارند؟
AGPLv3 یک مجوز متن‌باز کپی‌لفت است و BSD مجوزی سهل‌گیرانه‌تر برای تغییر و توزیع کد به شمار می‌رود. اگر سازمان فقط نسخهٔ تغییریافته‌ای را از راه شبکه در اختیار کاربران می‌گذارد، تعهدات AGPLv3 دربارهٔ دسترسی آنان به کد همان نسخه اهمیت پیدا می‌کند. برای تیمی که نرم‌افزار را بدون تغییر و برای مصرف داخلی اجرا می‌کند، وزن این تفاوت ممکن است کمتر باشد؛ کاربرد واقعی کد تعیین‌کننده است.
تولیدکنندهٔ سرویس مدیریت‌شده مسئلهٔ دیگری دارد: محدودیت RSALv2 برای عرضهٔ نرم‌افزار به‌صورت سرویس و تعهدات SSPLv1 باید در مدل کسب‌وکار او بررسی شود. خریدار یک سرویس مدیریت‌شده نیز علاوه بر مجوز موتور، با قرارداد عرضه‌کننده، سطح پشتیبانی، امکان خروج و مسئولیت پشتیبان‌گیری روبه‌روست. نام مجوز مخزن کد به‌تنهایی پاسخ این پرسش‌ها را نمی‌دهد.
حکمرانی دو پروژه هم یکسان نیست. Valkey زیر چتر بنیاد لینوکس پیش می‌رود و Redis مسیر محصول خود را از طریق شرکت توسعه‌دهنده‌اش تعیین می‌کند. برای انتخابی چندساله، این تفاوت را می‌توان در کنار نظم انتشار نسخه‌های قابل پشتیبانی، رسیدگی به اشکال‌ها و دسترس‌پذیری ابزارها و متخصصان سنجید؛ هیچ مدل حکمرانی به‌تنهایی نتیجهٔ عملکرد یا هزینهٔ نگهداری را تضمین نمی‌کند.
مرز سازگاری از کدام نسخه می‌گذرد؟
راهنمای مهاجرت Valkey می‌گوید فایل‌های RDB و AOF، پیکربندی و پروتکل Redis OSS تا نسخهٔ 7.2 در مسیر مستند مهاجرت قرار دارند، اما فایل‌های دادهٔ تولیدشده با Redis Community Edition از نسخهٔ 7.4 به بعد مستقیماً با Valkey سازگار نیستند. این مرز دربارهٔ خواندن فایل داده است؛ راهنما امکان روش‌های دیگر انتقال را منتفی نمی‌داند، اما آن‌ها را پوشش نمی‌دهد.
برای کشی که پس از تعویض دوباره پر می‌شود، ناسازگاری فایل ممکن است به زمان گرم‌شدن کش و فشار موقت بر پایگاه دادهٔ اصلی تبدیل شود. برای دیتاستوری که اطلاعات ماندگار نگه می‌دارد، همان مرز به مسئلهٔ انتقال داده و بازیابی پس از خطا بدل می‌شود. در این حالت، موفقیت اتصال کلاینت به سرور تازه هنوز نشان نمی‌دهد که دادهٔ موجود سالم منتقل شده است.
سازگاری پروتکل نیز همهٔ رفتار برنامه را پوشش نمی‌دهد. فهرست فرمان‌های واقعی، اسکریپت‌ها، ماژول‌ها، تنظیمات ماندگاری و رفتار کلاینت هنگام جابه‌جایی گره باید با مقصد سنجیده شوند. هزینهٔ مهاجرت زمانی روشن‌تر می‌شود که مسیر بازگرداندن ترافیک و وضعیت داده هم مشخص باشد؛ برای کش و دیتاستور ماندگار، این دو مسیر لزوماً یکسان نیستند.
چرا مسیر قابلیت‌ها از هم جدا می‌شود؟
اشتراک تاریخی Redis و Valkey به معنی همسان ماندن انتشارهای بعدی نیست. قابلیتی که برنامه امروز استفاده نمی‌کند، شاید در ارتقای بعدی اهمیت پیدا کند؛ از سوی دیگر، داشتن قابلیت بیشتر در یک موتور برای کاری که فقط کش کلید و مقدار می‌خواهد مزیت عملی ایجاد نمی‌کند. معیار مناسب، مجموعهٔ فرمان‌ها و امکاناتی است که برنامه واقعاً مصرف می‌کند یا برای آن برنامه‌ریزی قطعی دارد.
این تمایز برای سرویس‌های مدیریت‌شده پررنگ‌تر می‌شود. عرضه‌کننده ممکن است نسخهٔ موتور، فرمان‌ها، افزونه‌ها و زمان ارتقا را جدا از پروژهٔ بالادستی تعیین کند. بنابراین مقایسهٔ مخزن‌های اصلی، پاسخ نهایی دربارهٔ دو سرویس قابل خرید نیست؛ محدودیت و تعهد هر عرضه‌کننده بخشی از همان انتخاب زیرساختی است.
اعداد عملکرد چه می‌گویند؟
در مجموعهٔ آزمون منتشرشدهٔ centminmod، روی میزبان چهار vCPU با بار عمدتاً خواندنی memtier، چهار رشتهٔ کلاینت و pipeline برابر یک، Redis 8.0.2 و Valkey 8.1.1 به‌ترتیب ۱۲۵٬۵۲۴ و ۹۸٬۱۱۹ عملیات در ثانیه ثبت کردند و p99 آن‌ها ۷٫۶۵ و ۱۰٫۰۵ میلی‌ثانیه بود؛ در آزمون جداگانهٔ تک‌رشته‌ای PHP همان مجموعه، نرخ دو موتور به ۱۶٬۶۰۵ و ۱۶٬۵۶۱ عملیات در ثانیه نزدیک شد. این اعداد نتیجهٔ همان نسخه‌ها، کلاینت‌ها و تنظیمات‌اند.
تفاوت دو بار نشان می‌دهد رتبه‌بندی خام توان عملیاتی برای انتخاب کش کافی نیست. اگر برنامه منتظر پاسخ هر درخواست می‌ماند، تأخیر دنباله هنگام اوج بار می‌تواند مهم‌تر از نرخ کل عملیات باشد؛ اگر درخواست‌ها را دسته‌بندی می‌کند، طول pipeline نتیجه را تغییر می‌دهد. TLS، اندازهٔ مقدارها و نسبت خواندن به نوشتن نیز باید مطابق ترافیک برنامه باشند.
چندریسمانی‌شدن I/O در Valkey امکان استفاده از هسته‌های بیشتر برای بخشی از کار شبکه و پردازش درخواست را فراهم می‌کند، اما اجرای اصلی فرمان‌ها همچنان ترتیبی است. از این ویژگی نمی‌توان به‌تنهایی برتری عملکرد در هر بار کاری را نتیجه گرفت. مصرف CPU و حافظه را هم باید کنار توان عملیاتی دید، زیرا افزایش ظرفیت ممکن است در محیطی با محدودیت منابع، هزینهٔ عملیاتی متفاوتی داشته باشد.
آزمون منصفانه چه چیزهایی را یکسان نگه می‌دارد؟
راهنمای valkey-benchmark توضیح می‌دهد اجرای پیش‌فرض ابزار از pipelining استفاده نمی‌کند و سقف توان سرور را نشان نمی‌دهد؛ مقایسهٔ معتبر باید عملیات، تعداد اتصال‌ها و شیوهٔ دسته‌بندی درخواست‌ها را در دو مقصد یکسان نگه دارد. طول pipeline نیز باید به رفتار کلاینت برنامه نزدیک باشد، وگرنه آزمون بیشتر ظرفیت یک پیکربندی فرضی را نشان می‌دهد.
برای کش موجود، بار آزمون باید توزیع کلید، اندازهٔ مقدار، انقضای داده و نسبت خواندن به نوشتن را بازتاب دهد. گزارش مفید فقط عملیات در ثانیه نیست: تأخیر دنباله، خطا، مصرف CPU و حافظه و اثر عملیات پس‌زمینه نیز در تصمیم نقش دارند. در Kubernetes، محدودیت CPU، جای‌گیری پردازش‌ها و مسیر شبکه بخشی از شرایط آزمون‌اند؛ در سرویس مدیریت‌شده، همین شرایط را عرضه‌کننده تعیین می‌کند.
ماتریس تصمیم برای محیط اجرا
پس از تعیین نسخهٔ مبدأ و نیازهای برنامه، محل استقرار مشخص می‌کند کدام هزینه بیشترین وزن را دارد. این سه وضعیت نقطهٔ شروع مقایسه‌اند، نه حکم عملکرد برای همهٔ بارهای کاری.
- میزبانی شخصی: Valkey برای کشی با مسیر مهاجرت سازگار، فرمان‌های مشترک و ترجیح مجوز سهل‌گیرانه نامزد مناسبی است. اگر برنامه به امکانات جدیدتر Redis وابسته باشد، ماندن روی آن می‌تواند تبدیل و آزمون دوباره را حذف کند. در هر دو مسیر، وصله‌ها، پشتیبان‌گیری، پایش و بازیابی بر عهدهٔ تیم میزبان می‌ماند؛ تفاوت این هزینه‌ها را باید با ظرفیت واقعی تیم سنجید.
- سرویس مدیریت‌شده: نسخه و فرمان‌های عرضه‌شده، قرارداد پشتیبانی، سیاست پشتیبان‌گیری، تأخیر شبکه و امکان خروج را برای سرویس‌های مشخص مقایسه کنید. اگر سرویس فعلی نیاز برنامه را برآورده می‌کند، تغییر نام موتور به‌خودی‌خود صرفه‌جویی ایجاد نمی‌کند. اگر گزینهٔ مبتنی بر Valkey شرایط بهتری دارد، هزینهٔ انتقال داده و رفتار برنامه پس از انتقال باید در همان مقایسه وارد شود.
- Kubernetes: نتیجه به ترکیب موتور، منابع اختصاص‌یافته، ابزار استقرار، حجم‌های ماندگار و رفتار برنامه هنگام جابه‌جایی گره وابسته است. موتوری که در آزمون جداگانه سریع‌تر است، ممکن است با محدودیت CPU یا مسیر شبکهٔ این خوشه همان نتیجه را ندهد. انتخاب مناسب، پیکربندی‌ای است که شرط تأخیر و بازیابی برنامه را با مصرف منابع قابل قبول برآورده کند.
بیشتر بخوانید:
مقالات مرتبط
Moodle 5.3 به نسخهٔ LTS رسید؛ ارتقا بدون PHP 8.3 متوقف می‌شود
راهنماهای کاربردی
Tailscale یا ZeroTier؛ انتخاب واقعی میان هویت کاربر و شبکهٔ مجازی است
راهنماهای کاربردی 1
Docker یا Podman؛ سرعت تقریباً برابر است، مدل دسترسی تصمیم را عوض می‌کند
راهنماهای کاربردی
GKE Agent Sandbox عمومی شد؛ آغاز محیط تا ۴۵ برابر سریع‌تر است
هوش مصنوعی و خودکارسازی 1
Bun یا Node.js؛ سرعت بیشتر با حفره‌های سازگاری معاوضه می‌شود
راهنماهای کاربردی 1
عضویت در خبرنامه
تازه‌ترین اخبار Web3، هوش مصنوعی و رمزارز را مستقیم در صندوق ایمیل خود دریافت کنید.
0