Redis מול Memcached מול Valkey – מדריך לשכבת ה-Cache שמאחורי כל אתר מהיר

פורסם על-ידי צוות SPD Hosting

הקדמה

"תוסיפו Redis והאתר יטוס" – משפט שנשמע לא פעם, נכון רק לעיתים, ומסתיר סדרה של החלטות מהותיות: איזה מנוע קאש לבחור, באיזו ארכיטקטורה, בשרת שלכם או כשירות מנוהל בענן – ומה בעצם התרחש בשוק ב-2024, כשענקיות הענן נטשו את Redis והקימו פרויקט חדש בשם Valkey.

במאמר הקודם שלנו, על שיפור מהירות האתר באמצעות תוספי Cache, עסקנו בשכבה שהגולש פוגש – ה-Page Cache. הפעם נרד קומה אחת למטה, אל שכבת ה-Object Cache וה-Session Storage: השכבה שבה Redis, Memcached ו-Valkey מבצעים את העבודה בפועל.

מהי שכבת קאש, ומדוע היא קריטית

כל אתר דינמי – WordPress, Magento, Laravel ואחרים – פועל על אותו עיקרון: בקשה מגיעה, הקוד רץ, מסד הנתונים נשאל עשרות (ולעיתים מאות) שאילתות, והתשובה נבנית מחדש. הבעיה: רוב השאילתות מחזירות שוב ושוב את אותה תשובה. תפריט האתר לא השתנה מאז הבקשה הקודמת, רשימת המוצרים הפופולריים לא השתנתה, וההגדרות – ודאי שלא.

שכבת קאש היא זיכרון מהיר (RAM) שממוקם בין האפליקציה למסד הנתונים ומחזיר תשובות שכבר חושבו, במקום לחשב אותן מחדש. ההבדל בביצועים דרמטי: שליפה ממסד נתונים על דיסק נמדדת במילישניות; שליפה מקאש בזיכרון נמדדת במיקרו-שניות – מהירות גבוהה פי מאות עד אלפי מונים.

בעולם האתרים, שכבת הקאש משרתת שני תפקידים עיקריים:

• Object Cache – שמירת תוצאות של שאילתות, אובייקטים וחישובים כבדים, כדי להימנע מפנייה למסד הנתונים בכל בקשה.
• Session Storage – שמירת סשנים של גולשים (עגלת קניות, התחברות, העדפות). כאשר פועלים מספר שרתי אפליקציה, הסשנים חייבים לשבת במקום מרכזי ומהיר – אחרת גולש שעבר לשרת אחר יאבד את העגלה שלו.

חשוב להדגיש: קאש אינו גיבוי ואינו מסד נתונים ראשי. הנתונים בו נדיפים (Volatile) – אם השרת קורס, המידע נמחק, והאפליקציה בונה אותו מחדש. זו בדיוק הסיבה שהוא מסוגל להיות כה מהיר.

רקע: שלושה מנועים, שלושה סיפורים

Memcached – הוותיק והיציב (2003)

Memcached נולד בשנת 2003 ב-LiveJournal, אחת הרשתות החברתיות הראשונות, שהתקשתה לעמוד בעומס. הרעיון היה פשוט וממוקד: מילון ענק בזיכרון – מפתח נכנס, ערך יוצא. ללא טיפוסי נתונים מתוחכמים, ללא שמירה לדיסק, ללא תוספות. פייסבוק, טוויטר, ויקיפדיה ויוטיוב בנו עליו את שכבות הקאש הענקיות שלהן, וחלקן משתמשות בו עד היום. הפרויקט מתוחזק באופן פעיל למעלה מ-20 שנה – הישג נדיר בפני עצמו.

Redis – העשיר ביכולות, ופרשת הרישיון (2009)

Redis נכתב ב-2009 על ידי המפתח האיטלקי סלבטורה סנפיליפו (antirez), שביקש לבנות פתרון מתקדם ממילון פשוט: מבני נתונים אמיתיים בזיכרון – רשימות, קבוצות ממוינות, Hash-ים, מונים, Pub/Sub ועוד. בתוך שנים ספורות הפך Redis למסד הנתונים בזיכרון הפופולרי בעולם, וכמעט לכל שפת תכנות ומערכת CMS קיימת אינטגרציה אליו.

במרץ 2024 שינתה חברת Redis Ltd. את הרישיון מקוד פתוח מלא (BSD) לרישיון מגביל, שנועד בעיקר למנוע מספקיות ענן למכור את Redis כשירות ללא תשלום. הקהילה הגיבה בחריפות, ובתוך ימים ספורים נולד Valkey. ראוי לציין שבמאי 2025, עם גרסה 8.0, החזירה Redis אפשרות לרישיון קוד פתוח (AGPLv3) – במידה רבה בתגובה להצלחת Valkey. אולם את המהלך שכבר יצא לדרך קשה היה לעצור.

Valkey – ה-Fork שאימצו ענקיות הענן (2024)

Valkey הוא Fork של Redis 7.2.4 – הגרסה האחרונה שיצאה תחת רישיון BSD החופשי – שהוקם תחת קרן Linux Foundation, בגיבוי AWS, Google Cloud, Oracle, Ericsson ואחרות. המשמעות המעשית: תאימות מלאה לפקודות ולפרוטוקול של Redis (החלפה כמעט Drop-in), לצד ניהול קהילתי פתוח וללא חשש משינויי רישיון עתידיים. בתוך שנתיים בלבד הפך Valkey מפרויקט מחאה לשחקן מוביל, וענקיות הענן מציעות אותו כברירת המחדל בשירותים המנוהלים שלהן.

שחקנים נוספים בשוק

בשולי השוק קיימים כמה שמות נוספים: Dragonfly – מימוש מרובה-ליבות תואם Redis, המכוון לעומסים כבדים במיוחד על שרת יחיד; KeyDB – Fork מרובה-Threads ותיק יותר של Redis (נרכש על ידי Snap, וקצב הפיתוח בו האט משמעותית); ו-Garnet של מיקרוסופט – מנוע מחקרי מהיר, תואם פרוטוקול RESP. כולם ראויים לציון, אך בפועל Redis, Valkey ו-Memcached הם שלושת המנועים שתפגשו ב-99% מסביבות הייצור – ובהם נתמקד.

השוואה: ההבדלים בפועל

קריטריון	Memcached	Redis	Valkey
מודל נתונים	מפתח/ערך בלבד (מחרוזות)	מבני נתונים עשירים: רשימות, Sets, Hashes, Streams, JSON, Vector ועוד	זהה ל-Redis + מודולים קהילתיים (JSON, Search, Bloom)
ריבוי ליבות (Multi-thread)	כן, מהיסוד – מצטיין בניצול שרתים חזקים	ליבה אחת לביצוע פקודות + I/O Threads שהשתפרו מאוד ב-8.x	ליבה אחת + מערך I/O Threads אגרסיבי שהוצג ב-8.0 והכפיל ביצועים
שמירה לדיסק (Persistence)	אין (קיימת הרחבת extstore לאחסון "קר")	כן – RDB snapshots ו-AOF	כן – זהה ל-Redis
רפליקציה וקלאסטר	אין מובנה – הפיזור בצד הלקוח	רפליקציה, Sentinel ו-Cluster מובנים	זהה ל-Redis + שיפורי Cluster משמעותיים
רישיון	BSD – קוד פתוח מלא	רישיון משולש: RSALv2 / SSPLv1 / AGPLv3	BSD – קוד פתוח מלא תחת Linux Foundation
מתאים במיוחד ל…	קאש טהור, פשוט ועצום בנפח, בפריסה רב-שרתית	קאש + סשנים + תורים + Pub/Sub + חיפוש וקטורי – פתרון רב-תכליתי	כל יכולות Redis, בקוד פתוח מלא ועם דגש על ביצועי Cluster

יתרונות וחסרונות – בשורה התחתונה

Memcached – יתרונות: פשטות יוצאת דופן, ניצול מלא של כל ליבות המעבד, צריכת זיכרון יעילה ויציבות מוכחת של עשרות שנים. חסרונות: אין רפליקציה, אין שמירה לדיסק, אין מבני נתונים – נפילת שרת מוחקת את הקאש, וכל הבקשות פונות בבת אחת למסד הנתונים (תופעה המכונה Cache Stampede).

Redis – יתרונות: העושר הפונקציונלי הרחב ביותר, אקוסיסטם עצום, כלי ניהול מתקדמים (RedisInsight) וקצב פיתוח מהיר. חסרונות: סוגיית הרישיון מרתיעה ארגונים מסוימים, וחלק מהיכולות המתקדמות שמורות לגרסה המסחרית.

Valkey – יתרונות: תאימות מלאה ל-Redis, קוד פתוח מלא בגיבוי ענקיות הטכנולוגיה, וביצועים מרשימים בזכות ארכיטקטורת ה-Threads החדשה. חסרונות: פרויקט צעיר יחסית, וחלק מהכלים והתוספים בשוק עדיין מפותחים בראייה של Redis (גם אם הם פועלים מולו ללא תקלות).

מה חדש בגרסאות האחרונות

שלושת הפרויקטים מתקדמים בקצב מהיר, וזו נקודה מהותית: מי שמריץ כיום Redis 6 או Valkey 7.2 מוותר על שיפורי ביצועים משמעותיים.

• Redis 8.x (הסדרה הנוכחית, כולל 8.4 ו-8.6, וגרסה 8.8 שיצאה לאחרונה): יכולות ה-Stack – חיפוש, JSON, TimeSeries ווקטורים – שולבו בליבה ללא צורך במודולים; שיפור של למעלה מ-30% בתפוקה בעומסי קאש טיפוסיים לעומת 8.2; פקודת CLUSTER MIGRATION להעברת Slots אטומית ללא השבתה; פקודות Compare-and-Set אטומיות; חיסכון משמעותי בזיכרון ב-JSON; ובגרסה 8.6 – מנגנוני Idempotency ל-Streams ומדיניות פינוי (Eviction) חדשה.
• Valkey 9.0 ו-9.1 (אוקטובר 2025 ומאי 2026): המשך מהלך ה-Multi-threading שהחל ב-8.0 והקפיץ את התפוקה באופן דרמטי; בגרסה 9.1 נוספה תמיכה ב-Atomic Slot Migration בקלאסטר; מודל תמיכה ארוך-טווח מסודר (3 שנות תחזוקה לכל גרסת מינור + 5 שנות עדכוני אבטחה); וספריית הלקוח הרשמית Glide קיבלה Client-Side Caching מלא.
• Memcached 1.6.42 (מאי 2026): קצב שחרורים יציב, מנתח פרוטוקול משוכתב, שיפורים ל-Proxy המובנה (המאפשר פיזור ושכפול בצד השרת ללא כלים חיצוניים), וחשוב במיוחד – תיקוני אבטחה ל-CVE-2026-47783/47784 במנגנון ההזדהות SASL. מי שמריץ Memcached בגרסה חשופה – מומלץ לעדכן בהקדם.

ובהקשר האבטחה – הדברים נכונים לכלל המנועים: בתחילת 2026 פורסמו מספר חולשות RCE שתוקנו במקביל ב-Redis וב-Valkey (בהן CVE-2026-23479 ו-CVE-2026-25243). שרת קאש אינו "רק קאש" – הוא שירות רשת לכל דבר, וחשיפתו לאינטרנט ללא הגנה מהווה סיכון ממשי. אצלנו זהו עיקרון יסוד: שכבת הקאש פועלת ברשת פנימית בלבד, עם הזדהות, ומתעדכנת באופן שוטף.

ארכיטקטורות: משרת בודד ועד קלאסטר

1. שרת יחיד (Standalone)

המבנה הפשוט והנפוץ ביותר: תהליך אחד של Redis/Valkey/Memcached, לרוב על שרת האפליקציה עצמו או על שרת ייעודי קטן. מתאים לרוב המוחלט של האתרים – כאשר הקאש הוא אכן רק קאש, נפילה שלו פוגעת בביצועים אך אינה משביתה: האתר ממשיך לפעול, איטי יותר, עד שהקאש מתמלא מחדש. היתרון: מורכבות אפסית. החיסרון: נקודת כשל יחידה ותקרת ביצועים של מכונה אחת.

2. רפליקציה + Failover אוטומטי

שרת ראשי (Primary) המקבל כתיבות, ולצידו עותק אחד או יותר (Replica) המסונכרנים אליו באופן שוטף. ב-Redis/Valkey מוסיפים לכך מנגנון Sentinel – תהליכי ניטור המשגיחים על השרת הראשי, ובמקרה של נפילה מקדמים Replica להיות הראשי החדש בתוך שניות. זו הארכיטקטורה המתאימה כאשר הקאש הפך קריטי – לדוגמה, כשהוא מחזיק את הסשנים של חנות מסחר: כאן נפילה אינה רק האטה, אלא עגלות קניות שנעלמות באמצע תהליך רכישה. ב-Memcached, כאמור, אין רפליקציה מובנית – ולכן בתרחישי סשנים נעדיף כמעט תמיד Redis או Valkey.

3. קלאסטר (Cluster)

כאשר נפח הנתונים או קצב הפעולות עוברים את יכולתה של מכונה אחת, עוברים ל-Cluster: המידע מפוצל אוטומטית בין מספר צמתים (Sharding לפי 16,384 "סלוטים"), כאשר לכל צומת ראשי רפליקות משלו. כך מתקבלים גם פיזור עומס וגם שרידות. המחיר: מורכבות תפעולית גבוהה יותר, מגבלות על פעולות מרובות-מפתחות, וצורך בלקוחות (Clients) תומכי Cluster. החדשות הטובות: זהו בדיוק התחום שהשתפר במידה הרבה ביותר – גם Redis 8.4 וגם Valkey 9.1 הוסיפו העברת Slots אטומית, ההופכת הרחבת קלאסטר תוך כדי פעילות לפעולה שגרתית.

כלל אצבע שאנו מציגים ללקוחות: אין לעבור לקלאסטר לפני שקיים צורך אמיתי. רוב האתרים בישראל – כולל חנויות גדולות – פועלים היטב על שרת יחיד או זוג ברפליקציה. קלאסטר הוא כלי לבעיית Scale אמיתית, לא ברירת מחדל.

שימושים מעשיים: WordPress, Magento ומערכות נוספות

WordPress ו-WooCommerce

WordPress מגיעה עם Object Cache שחי רק למשך הבקשה הבודדת – כלומר, כמעט חסר ערך. חיבור Redis/Valkey באמצעות תוסף כגון Redis Object Cache (או באמצעות W3 Total Cache ו-LiteSpeed Cache, התומכים גם ב-Memcached) הופך אותו לקאש מתמיד (Persistent) של ממש. ההשפעה מורגשת במיוחד באזורים שה-Page Cache אינו מכסה: הפאנל הניהולי, עמודי WooCommerce דינמיים (עגלה, חשבון, תהליך רכישה), אתרים עם משתמשים מחוברים וחיפושים. אתר WooCommerce עמוס יכול לקצר את זמן התגובה של דפים דינמיים בעשרות אחוזים מהמהלך הזה בלבד. מאחר ש-Valkey תואם פרוטוקול, כל התוספים הללו פועלים מולו באופן זהה.

Magento / Adobe Commerce

Magento היא אולי הדוגמה המובהקת ביותר לחשיבותה של שכבת קאש נכונה, והיא תומכת בכך באופן מובנה ורשמי: Redis (ומקביליו) משמש בה לשלושה תפקידים נפרדים – קאש קונפיגורציה ובלוקים, Full Page Cache (כאשר לא נעשה שימוש ב-Varnish) ואחסון סשנים. ההמלצה המקצועית שלנו, מניסיון עם עשרות חנויות Magento: להפריד את שלושת התפקידים למופעים (Instances) נפרדים, או לכל הפחות למסדי נתונים לוגיים נפרדים, עם מדיניות זיכרון שונה לכל אחד – משום שפינוי (Eviction) של סשן פעיל משמעו לקוח שמנותק באמצע רכישה, בעוד שפינוי של בלוק קאש הוא אירוע חסר משמעות.

מערכות נוספות

Laravel משתמש ב-Redis/Valkey לקאש, לסשנים ולתורי עבודות (Queues); Drupal ו-Joomla נהנים מ-Object Cache באותו אופן כמו WordPress; Nextcloud ממליץ עליו רשמית ל-File Locking; ובעולם ה-AI המתפתח, Redis ו-Valkey משמשים גם כ-Vector Store וכ-Semantic Cache לתשובות של מודלי שפה – תחום המקבל דגש משמעותי בגרסאות האחרונות של שניהם.

ענן ציבורי מול ניהול עצמי: ElastiCache, Memorystore ואחרים

כל ספקיות הענן הגדולות מציעות את שכבת הקאש כשירות מנוהל: Amazon ElastiCache (Valkey, Redis OSS ו-Memcached – כאשר AWS מתמחרת את גרסת ה-Valkey בזול משמעותית ומקדמת אותה באופן פעיל), Google Cloud Memorystore (Valkey, Redis ו-Memcached, כולל תמיכה מלאה ב-Valkey 9), ו-OCI Cache של אורקל, הבנוי אף הוא על Valkey מנוהל.

	שירות מנוהל בענן	ניהול עצמי (על שרת/VM)
יתרונות	אפס תפעול – עדכונים, גיבויים ו-Failover באחריות הספק; הקמה בדקות; SLA מוגדר; שילוב טבעי עם שאר שירותי הענן; קלות בהגדלה והקטנה	שליטה מלאה בגרסה ובקונפיגורציה; אפשרות לשבת על שרת האפליקציה עם Latency אפסי; עלות נמוכה משמעותית בעומסים קבועים; ללא Vendor Lock-in
חסרונות	עלות גבוהה לאורך זמן; מגבלות על פקודות וקונפיגורציות (לדוגמה, פקודת CONFIG חסומה ומודולים מוגבלים); Latency רשת בין האפליקציה לשירות; חלונות תחזוקה כפויים; גרסאות מתעדכנות בקצב הספק	האחריות עליכם: עדכוני אבטחה (וכפי שראינו – יש מה לעדכן), ניטור ושרידות; דורש ידע תפעולי ממשי

נקודה שרבים מפספסים: בשירותים המנוהלים קיימות לעיתים מגבלות ביצועים והגדרות שאינן מופיעות בדף המחיר – פקודות ניהול חסומות, פרמטרים של זיכרון ופינוי נעולים, Baseline ביצועים התלוי בגודל המכונה שנבחרה, ורשת המוסיפה מאיות מילישנייה לכל פעולה. דווקא בקאש, שכל מהותו מיקרו-שניות, התוספת הזו עשויה להיות מורגשת. מנגד, כאשר נדרש Failover בשלוש לפנות בוקר – יתרון משמעותי שהוא מתבצע אוטומטית. אין תשובה אחת נכונה; יש תשובה נכונה לכל מערכת.

היכן אנחנו נכנסים לתמונה

כאן בדיוק היתרון של SPD: אנחנו ספק מוסמך של שלושת העננים הגדולים – OCI, GCP ו-AWS – ובמקביל מפעילים תשתיות אחסון וענן משלנו בישראל. איננו "מוכרים ענן" ואיננו "מוכרים שרתים" – אנחנו מתאימים ללקוח את הפתרון הנכון עבורו:

• חנות WooCommerce ישראלית עם עומס יציב? ככל הנראה Valkey מנוהל על ידינו, צמוד לאפליקציה, ב-Latency מינימלי ובעלות סבירה.
• מערכת עם תנודות עומס קיצוניות ופריסה גלובלית? ייתכן ש-ElastiCache או Memorystore הם הבחירה הנכונה – ואנחנו נקים, נקשיח ונתפעל.
• Magento כבדה עם דרישות רגולציה ונתונים בישראל? ארכיטקטורת רפליקציה מנוהלת אצלנו, עם הפרדת סשנים מקאש, ניטור 24/7 וה-SOC שלנו השומר על הסביבה כולה.

ומכיוון שסייבר הוא ה-DNA שלנו – כל פריסת קאש אצלנו מגיעה מוקשחת כברירת מחדל: רשת פנימית בלבד, הזדהות, הצפנה היכן שנדרש ועדכוני אבטחה שוטפים (כולל ה-CVE-ים שהוזכרו במאמר זה, שטופלו אצל לקוחותינו עוד לפני פרסומו).

סיכום

שכבת הקאש היא אחד המכפילים המשתלמים ביותר בביצועי אתר – אך רק כאשר הבחירה נעשית נכון: Memcached כשנדרש קאש טהור, פשוט ומהיר; Redis כשנדרש הפתרון העשיר והרב-תכליתי ביותר; ו-Valkey כשמעוניינים בכל היכולות הללו בקוד פתוח מלא, בגיבוי ענקיות התעשייה. את ההחלטה בין שרת יחיד, רפליקציה או קלאסטר – ובין ענן ציבורי לניהול ייעודי – כדאי לקבל עם מי שמתמחה בכך ביום-יום.

רוצים לדעת איזו שכבת קאש מתאימה למערכת שלכם? דברו איתנו – SPD Hosting, טלפון 03-6221258. נשמח לבחון יחד את הארכיטקטורה ולהתאים פתרון מדויק.