Redis ו־Valkey: תאימות גרסאות, רישוי ותכנון מעבר

Redis ו־Valkey הם אפשרויות למבני נתונים בזיכרון ולמטמון. בחירה ביניהם דורשת בדיקת גרסאות מדויקות, רישיונות, התנהגות יישומית ודרישות תפעול; אף אחד מהם אינו שייך אוטומטית לכל קובץ docker-compose.yml.

ציר הזמן של הרישוי חשוב: Redis בגרסה 7.2 ומטה נותר ברישיון BSD-3-Clause; גרסה 7.4 משתמשת ב־RSALv2 או ב־SSPLv1. Redis 8 הוסיף AGPLv3 כאפשרות שלישית, כפי שהוכרז ב־1 במאי 2025. Valkey ממשיך בקו פיתוח נפרד ברישיון BSD. זהו סיכום גרסאות, לא קביעה שפריסה מסוימת עומדת בחובות הרישיון.

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

מהו Valkey, ולמה הוא חשוב?

Linux Foundation הכריזה על קהילת Valkey ב־28 במרץ 2024. ההודעה ציינה את AWS, Google Cloud, Oracle, Ericsson ו־Snap בין התומכות; זו תמיכה היסטורית בפרויקט, לא אישור לפריסה כלשהי.

Valkey התפצל מ־Redis OSS 7.2.4 ומשתמש ברישיון BSD-3-Clause. גרסאותיו המאוחרות כוללות שינויים הנדסיים מתועדים, אך תמיכה תאגידית לבדה אינה ראיה לביצועים טובים יותר ממוצר אחר.

למפתחים, Valkey מציע:

רישוי: BSD-3-Clause מעניק הרשאות בכפוף לתנאים, ובהם שמירת הודעות רישוי. הוא אינו מבטל עבודת עמידה בתנאים, עלויות שירות או אי־ודאות לגבי גרסאות עתידיות. יש לסקור את ההפצה ואת התלויות המדויקות.
תאימות פרוטוקול: Valkey תומך ב־RESP2 וב־RESP3, ולקוחות Redis רבים יכולים להתחבר אליו. עדיין יש לבדוק את הגרסה המדויקת של ioredis, redis-py או go-redis, את הפקודות, צורות התשובה, התסריטים, המודולים והטופולוגיה. תאימות פרוטוקול אינה שקילות יישומית אוניברסלית.
שיפורים תלויי־גרסה: Valkey 8.0 ו־8.1 מתעדים שינויים בקלט ופלט ובמבנה הזיכרון. התועלת תלויה בעומס ובהגדרות; אין להסיק שתכונות אלה קיימות בתג תמונת 7.2 שבמקור.

מאחורי הקלעים: היכן Valkey ו־Redis נפרדים

לתאימות יש גבול גרסאות. מדריך המעבר מכסה Redis OSS עד 7.2; הוא שולל במפורש שימוש ישיר בקובצי נתונים של Redis CE 7.4 ומעלה. פקודות ומודולים חדשים דורשים אימות נפרד, ולכן ״תאימות API של 100%״ אינה טענה גורפת מתאימה.

ארכיטקטורת תהליכונים וקלט ופלט

בתכנון המתועד של Valkey 8.0/8.1, תהליכוני קלט ופלט מטפלים במשימות כגון קריאת רשת, פענוח ותשובות, בעוד ביצוע הפקודות נשאר בתהליכון הראשי. אין מדובר בביצוע מקבילי כללי של כל הפקודות.

העברת עבודת קלט ופלט לתהליכונים אחרים יכולה לפנות זמן בתהליכון הראשי בעומסים מתאימים. תוצאות שהפרויקט פרסם קשורות לחומרה ולתנאי בדיקה מסוימים; הן אינן מוכיחות תפוקה טובה יותר לדולר בכל מופע Graviton, Tau או ענן אחר. המאמר אינו מספק מבחן ביצועים.

יעילות זיכרון

Valkey 8.0 מתעד מילונים לפי משבצת והטמעת מפתחות; 8.1 מתעד מימוש חדש של טבלת גיבוב. אלה שינויים ממשיים, לא הבטחה להשהיית p99 שטוחה או לצריכת זיכרון נמוכה יותר בכל מערך נתונים. יש להשוות זיכרון, התפלגויות השהיה והגדרות התמדה בעומסים מייצגים.

הפעלת Valkey מקומית: התחלה מהירה למפתחים

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

השוו את קטעי docker-compose.yml האלה. יציאות המארח שונות ומוגבלות במפורש לכתובת הלולאה המקומית. אין זה אימות או גבול בידוד מלא; יש לבדוק את הניתוב ואת חומת האש של Docker. Docker מתעד הסתייגות לגבי פרסום יציאות ב־localhost בגרסאות שלפני 28.0.0.

מפרט מעבדה נפרד ל־Redis 7.2

services:
  cache:
    image: "${REDIS_LAB_IMAGE:?Set a reviewed Redis 7.2 image digest}"
    command: ["redis-server", "--save", "", "--appendonly", "no"]
    ports:
      - "127.0.0.1:6380:6379"
    tmpfs:
      - /data

מפרט מעבדה נפרד ל־Valkey 8.1

services:
  cache:
    image: "${VALKEY_LAB_IMAGE:?Set a reviewed Valkey 8.1 image digest}"
    command: ["valkey-server", "--save", "", "--appendonly", "no"]
    ports:
      - "127.0.0.1:6381:6379"
    tmpfs:
      - /data

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

המחשת תאימות מוגבלת ב־Node.js

ההמחשה ב־CommonJS מיועדת ל־API ההגדרות של ioredis 5.8.2 שנבדק בתיעוד. היא מגדירה פונקציה אך אינה קוראת לה. רק לאחר הכנה נפרדת של מעבדת Valkey זמנית ומורשית, קריאה לפונקציה תתחבר ל־127.0.0.1:6381 ותכתוב שני מפתחות סינתטיים. יש לסקור את גרסת התלות לפני כל שימוש.

const Redis = require('ioredis');
const { randomUUID } = require('node:crypto');

async function runSyntheticDemo() {
  const client = new Redis({
    host: '127.0.0.1', port: 6381,
    lazyConnect: true,
    connectTimeout: 2000,
    commandTimeout: 2000,
    maxRetriesPerRequest: 0,
    retryStrategy: () => null,
    enableOfflineQueue: false,
  });
  client.on('error', () => {});
  const prefix = `sysseder:synthetic:${randomUUID()}`;
  const valueKey = `${prefix}:value`;
  const hashKey = `${prefix}:hash`;
  try {
    await client.connect();
    const value = JSON.stringify({ example: 'synthetic', count: 1 });
    if (await client.set(valueKey, value, 'EX', 60) !== 'OK') {
      throw new Error('Unexpected SET reply');
    }
    if (await client.get(valueKey) !== value) {
      throw new Error('GET mismatch');
    }
    await client.hset(hashKey, 'example', 'synthetic', 'count', '1');
    if (await client.expire(hashKey, 60) !== 1) {
      throw new Error('EXPIRE failed');
    }
    const fields = await client.hgetall(hashKey);
    if (fields.example !== 'synthetic' || fields.count !== '1') {
      throw new Error('HGETALL mismatch');
    }
    return 'Selected synthetic round-trip checks completed';
  } finally {
    client.disconnect();
  }
}

module.exports = { runSyntheticDemo };

אם תיבדק בהמשך, הדוגמה של SET, GET, HSET ו־HGETALL תכסה רק מקרים פשוטים אלה. אין תיעוד של הרצה מוצלחת. כתיבת הגיבוב וקביעת התפוגה הן פעולות נפרדות: הפרעה ביניהן עלולה להשאיר מפתח ללא TTL, ולכן הדוגמה דורשת מסד נתונים זמני. פסק זמן אינו מוכיח שהשרת לא החיל כתיבה.

תכנון מעבר בייצור, לא נוהל ביצוע

לפני מעבר בייצור יש לתכנן בדיקות תאימות, חומרי שחזור מאומתים, תיאום כתיבות ודרך חזרה. השכפול אסינכרוני; לא המתווה הזה ולא פקודת קידום מבטיחים אפס השבתה או אפס אובדן נתונים. טופולוגיות Cluster/Sentinel דורשות תוכנית נפרדת שעברה סקירה.

אפשרות 1: בחינת מעבר באמצעות שכפול תואם־גרסאות

מדריך Valkey מתאר מעבר באמצעות שכפול מגרסאות Redis OSS תואמות עד 7.2. אין להניח ששרת Redis ראשי חדש יותר, מודולים או נקודת קצה של שירות מנוהל יכולים להשתמש באותו נוהל. תחילה יש לאמת בסביבת קדם־ייצור את צמד גרסאות המקור והיעד ואת בקרות הגישה.

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

אפשרות 2: שחזור מתמונת מצב

מעבר באמצעות תמונת מצב דורש נתוני dump.rdb תואמים וחלון תחזוקה שנמדד עבור מערך הנתונים בפועל. זמן השחזור אינו תמיד דקות ספורות. יש להביא בחשבון כתיבות שאחרי תמונת המצב ואת הגדרות AOF והמודולים.

בחרו ואמתו נוהל מתאים ליצירת תמונת מצב. SAVE הוא סינכרוני וחוסם לקוחות אחרים; אין להפעילו כלאחר יד בשירות פעיל. גם שמירה ברקע כרוכה בשיקולי משאבים ועקביות.
אמתו שתמונת המצב הצפויה הושלמה ושאפשר לשחזר אותה בקדם־ייצור; הגנו על תוכנה ושמרו את חומרי ההתאוששות המקוריים לפי מדיניות השמירה של הארגון.
תאמו את נקודת סיום הכתיבות ואת חלון התחזוקה לפני עצירת שירות מקור מורשה כלשהו. אין להתייחס לפקודת עצירה כאל תוכנית העקביות כולה.
בדקו את תיקיית הנתונים המוגדרת ביעד, את הבעלות, את מצב ההתמדה ואת תאימות הפורמט לפני תכנון שחזור. לעולם אל תדרסו את מערך הנתונים היחיד שניתן לשחזר.
יעד תואם שהוגדר כראוי עשוי לטעון RDB בהפעלה; אם AOF מופעל, גם הקדימות שלו בזמן ההפעלה חשובה. יש לבדוק שגיאות טעינה, ערכי מפתחות, TTL והתנהגות יישומית לפני פתיחת תעבורה. לא בוצע כאן שחזור.

האם Valkey מוכן לייצור ארגוני?

המוכנות תלויה בדרישות שלכם. בחנו גרסאות נתמכות, מומחיות תפעולית, יעדי התאוששות, בקרות אבטחה וקבוצת הפקודות והמודולים הדרושה. אימוץ הפרויקט אינו תחליף להערכה הזאת.

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

למעבר יש עלויות הנדסיות ותפעוליות לצד שיקולי רישוי. החליטו לפי דרישות שאומתו, לא לפי חיסכון משוער או כיוון עתידי מובטח.

לסיכום

ממשל ורישוי משפיעים על התפתחות הפרויקט, אך אף אחד מהם אינו מבטיח תוכנה מאובטחת. יש להעריך את המודל הקהילתי של Valkey ואת אפשרויות הרישוי של Redis לצד תחזוקה, עדכוני אבטחה ובקרות פריסה.

בפרויקט חדש, השוו את Redis ואת Valkey מול אותן דרישות פונקציונליות, דרישות רישוי ודרישות תפעול. בדיקה מייצגת ותרגול התאוששות מועילים יותר מטענה אוניברסלית שמנוע מסוים מהיר יותר, זול יותר או האפשרות הפתוחה היחידה.

עכשיו תורכם: האם כבר עברתם ל־Valkey, או שאתם מתכננים מעבר בארגון? ספרו לי בתגובות למטה על מחשבות, חששות או סיפורי הצלחה!