نصب و پیکربندی کش با Redis و Memcached

پیاده‌سازی کش با Redis و Memcached یکی از مؤثرترین راه‌ها برای کاهش بار دیتابیس و افزایش چشمگیر سرعت پاسخ‌گویی برنامه‌های وب است. هر دو ابزار، داده‌ها را در حافظهٔ رم نگه می‌دارند و به‌همین دلیل زمان دسترسی به داده را از میلی‌ثانیه‌های دیسک به میکروثانیه‌های رم می‌رسانند. در این راهنمای عملی، تفاوت این دو فناوری، نحوهٔ نصب، پیکربندی امن و اتصال آن‌ها به وردپرس، لاراول و جنگو را با فرمان‌های واقعی بررسی می‌کنیم تا بتوانید انتخاب درستی برای معماری خود داشته باشید.

ایدهٔ اصلی کش آبجکت ساده است: به‌جای اینکه در هر درخواست کاربر، دیتابیس یک کوئری سنگین را دوباره اجرا کند، نتیجهٔ آن یک بار محاسبه و در حافظه ذخیره می‌شود. درخواست‌های بعدی مستقیماً از حافظه پاسخ می‌گیرند. در سایت‌های پرترافیک، این کار می‌تواند بار دیتابیس را تا ۸۰ درصد کاهش دهد و زمان پاسخ صفحات را چند برابر سریع‌تر کند.

تفاوت Redis و Memcached چیست؟

وقتی صحبت از کش با Redis و Memcached می‌شود، اولین سؤال این است که کدام را انتخاب کنیم. هر دو کلید-مقدار (key-value) و مبتنی بر حافظه‌اند، اما تفاوت‌های مهمی دارند که انتخاب را به سناریوی شما وابسته می‌کند.

ویژگی	Redis	Memcached
نوع داده	رشته، لیست، هش، مجموعه، sorted set	فقط رشته
پایداری (Persistence)	دارد (RDB و AOF)	ندارد
چند‌نخی	عمدتاً تک‌نخی (با I/O چندنخی)	چندنخی
Replication	دارد (master-replica)	ندارد
Pub/Sub و صف	دارد	ندارد
مصرف حافظه	کمی بیشتر	بسیار بهینه برای داده‌های ساده

به‌طور خلاصه، اگر فقط به کش سادهٔ رشته‌ای با کمترین سربار نیاز دارید و چندین هستهٔ CPU در اختیار دارید، Memcached عملکرد فوق‌العاده‌ای دارد. اما اگر به ساختارهای دادهٔ پیچیده، صف کار (job queue)، pub/sub، یا پایداری داده نیاز دارید، Redis انتخاب همه‌کاره‌تری است. در عمل امروزه Redis به‌دلیل انعطاف بیشتر، محبوب‌تر است.

نصب و پیکربندی Redis

در توزیع‌های مبتنی بر دبیان و اوبونتو، نصب Redis تنها چند فرمان است. توصیه می‌شود همیشه از مخزن رسمی برای دریافت نسخهٔ پایدار جدید استفاده کنید:

sudo apt update
sudo apt install redis-server -y
sudo systemctl enable --now redis-server
redis-cli ping

اگر پاسخ PONG دریافت کردید، Redis آماده است. اکنون باید فایل پیکربندی را برای محیط تولید بهینه کنیم.

تنظیمات کلیدی redis.conf

فایل پیکربندی معمولاً در مسیر /etc/redis/redis.conf قرار دارد. سه تنظیم مهم را باید بررسی کنید: محدودیت حافظه، سیاست حذف و امنیت:

maxmemory 512mb
maxmemory-policy allkeys-lru
bind 127.0.0.1 ::1
requirepass "YourStrongPasswordHere"
appendonly yes
appendfsync everysec

پارامتر maxmemory سقف حافظهٔ Redis را تعیین می‌کند تا از پرشدن رم سرور جلوگیری شود. سیاست allkeys-lru یعنی وقتی حافظه پر شد، کلیدهایی که کمتر استفاده شده‌اند حذف می‌شوند؛ این سیاست برای کش ایده‌آل است. حتماً requirepass را با یک رمز قوی تنظیم کنید و bind را روی localhost نگه دارید مگر اینکه واقعاً به دسترسی از راه دور نیاز داشته باشید.

هشدار امنیتی: یک نمونهٔ Redis بدون رمز و باز روی اینترنت، یکی از رایج‌ترین علل نفوذ به سرور است. مهاجمان به‌طور خودکار پورت ۶۳۷۹ را اسکن می‌کنند. همیشه رمز بگذارید و در فایروال این پورت را ببندید.

تست عملکرد Redis

پس از پیکربندی، می‌توانید با ابزار داخلی benchmark عملکرد را بسنجید:

redis-benchmark -h 127.0.0.1 -p 6379 -a YourStrongPasswordHere -q -t set,get -n 100000

روی یک سرور مجازی معمولی، انتظار داشته باشید Redis بتواند بیش از ۱۰۰ هزار عملیات SET و GET در ثانیه انجام دهد. اعداد بسیار پایین‌تر می‌تواند نشانهٔ محدودیت CPU یا مشکل شبکه باشد.

نصب و پیکربندی Memcached

نصب Memcached نیز ساده است. علاوه بر خود سرویس، به افزونهٔ PHP آن هم نیاز دارید:

sudo apt install memcached libmemcached-tools php-memcached -y
sudo systemctl enable --now memcached

پیکربندی Memcached در فایل /etc/memcached.conf انجام می‌شود. مهم‌ترین پارامترها میزان حافظه و آدرس گوش‌دادن است:

-m 256
-l 127.0.0.1
-p 11211
-c 1024
-t 4

در اینجا m- حافظهٔ اختصاص‌یافته به مگابایت، l- آدرس محلی برای امنیت، c- حداکثر اتصالات هم‌زمان و t- تعداد نخ‌ها (متناسب با هسته‌های CPU) است. برخلاف Redis، Memcached واقعاً چندنخی است و می‌تواند از چند هسته به‌طور مؤثر استفاده کند.

اتصال کش با Redis و Memcached به برنامه‌ها

حالا که سرویس‌ها آماده‌اند، باید برنامهٔ وب را به آن‌ها متصل کنیم. نحوهٔ اتصال بسته به فریم‌ورک یا CMS متفاوت است.

وردپرس

برای وردپرس، افزونهٔ Redis Object Cache محبوب‌ترین گزینه است. پس از نصب افزونه، این خطوط را به wp-config.php اضافه کنید:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_PASSWORD', 'YourStrongPasswordHere' );
define( 'WP_CACHE_KEY_SALT', 'mysite_' );
define( 'WP_REDIS_MAXTTL', 3600 );

سپس از داشبورد افزونه، گزینهٔ Enable Object Cache را فعال کنید. در سایت‌های شلوغ وردپرسی، فعال‌کردن کش آبجکت Redis می‌تواند تعداد کوئری‌های دیتابیس در هر بارگذاری صفحه را از چند صد به چند ده کاهش دهد.

لاراول

لاراول از هر دو درایور پشتیبانی می‌کند. کافی است در فایل .env مقادیر را تنظیم کنید:

CACHE_DRIVER=redis
SESSION_DRIVER=redis
QUEUE_CONNECTION=redis
REDIS_HOST=127.0.0.1
REDIS_PASSWORD=YourStrongPasswordHere
REDIS_PORT=6379

سپس در کد می‌توانید به‌سادگی از فسادِ Cache استفاده کنید. مزیت Redis در لاراول این است که همان سرویس هم برای کش، هم نشست کاربران و هم صف کارها استفاده می‌شود.

جنگو (Django)

برای جنگو، پکیج redis کافی است و از نسخهٔ ۴ به بعد، بک‌اند کش Redis به‌صورت داخلی پشتیبانی می‌شود. در settings.py:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": "redis://:YourStrongPasswordHere@127.0.0.1:6379/1",
    }
}

پس از این تنظیم می‌توانید از دکوریتور cache_page برای کش کل نمای یک صفحه، یا از توابع cache.set و cache.get برای کش دستی نتایج کوئری‌های سنگین استفاده کنید.

الگوهای رایج و اشتباهات مهلک کش

پیاده‌سازی درست کش به اندازهٔ نصب آن اهمیت دارد. چند الگو و اشتباه رایج را باید بشناسید.

• Cache Stampede: وقتی یک کلید پرطرفدار منقضی می‌شود، ده‌ها درخواست هم‌زمان سعی می‌کنند آن را بازسازی کنند و به دیتابیس هجوم می‌آورند. راه‌حل، استفاده از قفل (lock) یا بازسازی زودهنگام (early recomputation) است.
• تعیین نادرست TTL: TTL خیلی کوتاه بازده کش را کم می‌کند و TTL خیلی طولانی باعث نمایش دادهٔ کهنه می‌شود. برای داده‌های نیمه‌ثابت، مقادیر ۵ تا ۶۰ دقیقه معمولاً تعادل خوبی است.
• عدم باطل‌سازی (Invalidation): پس از تغییر داده در دیتابیس، باید کلید کش مرتبط را حذف کنید، وگرنه کاربر دادهٔ قدیمی می‌بیند.
• کش‌کردن دادهٔ کاربر خاص در کلید عمومی: این اشتباه می‌تواند اطلاعات یک کاربر را به کاربر دیگر نشان دهد؛ همیشه شناسهٔ کاربر را در کلید کش بگنجانید.

برای پایش نرخ اصابت کش (hit rate)، در Redis می‌توانید از فرمان زیر استفاده کنید:

redis-cli -a YourStrongPasswordHere info stats | grep keyspace

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

یک اصل مهم دیگر، تعیین کلید کش خوانا و ساختارمند است. استفاده از پیشوندها و جداکننده‌های استاندارد مثل user:1024:profile به شما کمک می‌کند کلیدها را دسته‌بندی کنید، به‌راحتی گروهی از آن‌ها را باطل کنید و در زمان اشکال‌زدایی سریع‌تر بفهمید هر کلید مربوط به چیست. بی‌نظمی در نام‌گذاری کلید در پروژه‌های بزرگ به‌سرعت به یک کابوس مدیریتی تبدیل می‌شود.

پایداری داده و پشتیبان‌گیری در Redis

یکی از تفاوت‌های مهم Redis با Memcached، قابلیت پایداری داده روی دیسک است. Redis دو مکانیزم برای این کار دارد: RDB که به‌صورت دوره‌ای عکس فوری (snapshot) از کل داده می‌گیرد، و AOF که هر عملیات نوشتن را در یک فایل لاگ ثبت می‌کند. انتخاب بین این دو به نیاز شما بستگی دارد.

RDB برای پشتیبان‌گیری و بازیابی سریع عالی است و سربار کمی دارد، اما در صورت خرابی ممکن است داده‌های بین دو snapshot از دست برود. AOF ایمن‌تر است چون تقریباً هر نوشتن را ثبت می‌کند، اما فایل آن بزرگ‌تر می‌شود و به بازنویسی دوره‌ای نیاز دارد. برای بسیاری از کاربردها، فعال‌کردن هر دو با هم بهترین تعادل بین ایمنی و عملکرد را می‌دهد:

save 900 1
save 300 10
save 60 10000
appendonly yes
appendfilename "appendonly.aof"
aof-use-rdb-preamble yes

خط save 900 1 یعنی اگر در ۹۰۰ ثانیه حداقل یک تغییر رخ داد، snapshot گرفته شود. توجه کنید اگر Redis را صرفاً به‌عنوان کش خالص (بدون نیاز به پایداری) استفاده می‌کنید، می‌توانید هر دو مکانیزم را غیرفعال کنید تا عملکرد نوشتن حداکثر شود؛ در این حالت اگر سرویس ری‌استارت شود، کش از نو ساخته می‌شود که مشکلی نیست.

مانیتورینگ حافظه و کارایی

برای اطمینان از سلامت سرویس کش، باید مصرف حافظه و رفتار حذف کلیدها را پایش کنید. دستور info memory تصویر دقیقی از وضعیت می‌دهد:

redis-cli -a YourStrongPasswordHere info memory | grep -E "used_memory_human|maxmemory_human|mem_fragmentation_ratio"

شاخص mem_fragmentation_ratio اهمیت زیادی دارد؛ اگر این عدد به‌طور مداوم بالای ۱.۵ باشد، یعنی حافظه به‌شدت پراکنده شده و رم بیش از حد لازم مصرف می‌شود. همچنین اگر تعداد کلیدهای حذف‌شده (evicted_keys) به‌سرعت بالا می‌رود، یعنی حافظهٔ اختصاص‌یافته کافی نیست و باید maxmemory را افزایش دهید یا TTL کلیدها را بازبینی کنید.

انتخاب سرور مناسب برای کش

سرویس‌های کش کاملاً وابسته به رم هستند. پیش از پیاده‌سازی، مطمئن شوید سرور شما رم کافی برای هم برنامه و هم داده‌های کش دارد. یک قانون سرانگشتی این است که حداقل ۲۵ درصد رم سرور را برای لایهٔ کش کنار بگذارید. برای پروژه‌های در حال رشد، انتخاب سروری با امکان ارتقای آسان رم اهمیت دارد؛ می‌توانید برای خرید سرور مجازی با رم اختصاصی و پرسرعت اقدام کنید و در آینده بدون مهاجرت، منابع را افزایش دهید. راهنماهای بیشتر را نیز در مقالات رپیدو سرور بیابید.

سناریوهای پرکاربرد فراتر از کش ساده

Redis به‌دلیل ساختارهای دادهٔ متنوعش، کاربردهایی فراتر از کش سادهٔ کوئری دارد که می‌تواند معماری برنامهٔ شما را ساده‌تر کند. شناخت این سناریوها به شما کمک می‌کند از یک سرویس واحد برای چند هدف استفاده کنید و پیچیدگی زیرساخت را کاهش دهید.

• مدیریت نشست (Session): ذخیرهٔ نشست کاربران در Redis به‌جای فایل یا دیتابیس، سرعت را افزایش می‌دهد و امکان مقیاس‌پذیری افقی چند سرور را فراهم می‌کند، چون همهٔ سرورها به یک منبع نشست مشترک دسترسی دارند.
• محدودسازی نرخ (Rate Limiting): با شمارنده‌های اتمی Redis می‌توانید تعداد درخواست‌های هر کاربر یا IP را در بازهٔ زمانی محدود کنید و از سوءاستفاده جلوگیری کنید.
• صف کار (Job Queue): لیست‌های Redis برای پیاده‌سازی صف کارهای پس‌زمینه مثل ارسال ایمیل یا پردازش تصویر ایده‌آل‌اند و بار را از درخواست اصلی کاربر برمی‌دارند.
• رتبه‌بندی و جدول امتیازات (Leaderboard): ساختار sorted set امکان نگهداری فهرست مرتب بر اساس امتیاز را با کارایی بالا فراهم می‌کند که برای بازی‌ها و سیستم‌های امتیازدهی عالی است.

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

در جمع‌بندی، Redis و Memcached ابزارهایی بلوغ‌یافته و اثبات‌شده‌اند که در دل بزرگ‌ترین وب‌سایت‌های جهان کار می‌کنند. با نصب درست، پیکربندی امن و رعایت الگوهای صحیح کش، می‌توانید بار دیتابیس را به‌شدت کاهش دهید و تجربهٔ کاربری بسیار سریع‌تری ارائه کنید. کلید موفقیت، شروع ساده، اندازه‌گیری نرخ اصابت و بهبود تدریجی استراتژی کش بر اساس داده‌های واقعی است.

سوالات متداول

برای وردپرس، Redis بهتر است یا Memcached؟

برای وردپرس معمولاً Redis توصیه می‌شود، چون افزونه‌های بالغ‌تری دارد، از پایداری داده پشتیبانی می‌کند و می‌تواند علاوه بر کش آبجکت برای نشست‌ها و صف نیز استفاده شود. Memcached هم کار می‌کند اما برای سناریوهای پیچیده‌تر انعطاف کمتری دارد.

آیا می‌توانم Redis و Memcached را هم‌زمان استفاده کنم؟

بله، اما در بیشتر موارد لازم نیست. برخی معماری‌ها از Memcached برای کش سادهٔ صفحه و از Redis برای صف و ساختارهای داده استفاده می‌کنند. برای اکثر سایت‌ها، انتخاب یکی از این دو کافی است و مدیریت آن ساده‌تر خواهد بود.

چقدر رم برای Redis کافی است؟

این کاملاً به حجم داده‌های کش بستگی دارد. برای یک سایت وردپرسی متوسط، ۲۵۶ تا ۵۱۲ مگابایت اختصاصی معمولاً کافی است. حتماً maxmemory را تنظیم کنید تا Redis از حد مشخصی فراتر نرود و رم برنامهٔ اصلی را نبلعد.

اگر سرویس Redis از کار بیفتد، سایت من از کار می‌افتد؟

در پیاده‌سازی درست، کش باید به‌عنوان لایهٔ بهبود عملکرد عمل کند نه وابستگی حیاتی؛ یعنی اگر کش در دسترس نباشد، برنامه باید به دیتابیس بازگردد (هرچند کندتر). اکثر افزونه‌ها و فریم‌ورک‌ها این رفتار fallback را به‌صورت پیش‌فرض دارند، اما بهتر است آن را تست کنید.