מערך שיעור: Redis ו-Cache-Aside

משך: 2 שעות אקדמיות (100 דקות).

מטרת השיעור: הסטודנטים יבינו למה Redis מהיר, ויישמו תבנית Cache-Aside אמיתית מעל DB קיים.

בסוף השיעור הסטודנטים צריכים: להסביר למה זיכרון מהיר מדיסק, לממש Cache-Aside עם Cache Hit/Miss, ולהסביר את הסיכון של קאש מיושן (Cache Invalidation).

דגש קריטי: מדידת זמן תגובה אמיתית (Cache Hit מול Miss) היא ההוכחה החיה הכי חזקה בשיעור הזה — הקדישו לה זמן.

מהלך השיעור#

דגשים להעברת השיעור#

• השלב הכי נשכח: הרישום ב-Program.cs. סטודנטים נוטים לדלג ישר לקוד עם ConnectionMultiplexer.Connect בכל מקום, בלי DI — הדגישו למה AddSingleton ולא ליצור חיבור חדש בכל בקשה.
• מדידת זמן תגובה אמיתית (עם Task.Delay מלאכותי לדימוי DB “איטי”) היא הרגע החשוב ביותר — מספרים קונקרטיים (למשל “500ms → 2ms”) משכנעים בהרבה מהסבר תיאורטי.
• הדגישו בתקיפות את סיכון ה-Cache Invalidation — עדכון DB בלי לעדכן/למחוק קאש הוא באג נפוץ ומסוכן בקוד production אמיתי.
• קשרו TTL ל-TTL Index ב-MongoDB מהשיעור הקודם — אותו רעיון בדיוק, כלי אחר.

מושגים#

Cache — אחסון זמני של תוצאות מחושבות. Redis Data Types — String/Hash/List/Set. TTL — זמן חיים לערך בקאש. Cache-Aside Pattern — בדוק קאש→Miss→שלוף+שמור→Hit הבא.

תרגיל חשיבה#

שאלת פתיחה: “עדכנתם מחיר מוצר ב-DB, אבל שכחתם למחוק את הערך המתאים ב-Redis. מה יראה משתמש שמבקש את המוצר הזה עכשיו — ולמה זה מסוכן במיוחד למחיר?”

מהלך: הובילו לתובנה: המשתמש יראה את המחיר הישן (מהקאש), לא העדכני — עד שה-TTL יפוג. עבור מחיר, זו לא רק אי-נוחות — זה עלול להיות נזק עסקי ממשי (מכירה במחיר שגוי). זו הדגמה מצוינת לכך ש-Cache Invalidation הוא לא “פרט טכני קטן” אלא חלק קריטי מהתכנון.

מה המרצה מראה בסוף: הריצו תרחיש מלא: שליפה ראשונה (Cache Miss, שומר בקאש) → עדכון “ידני” של הנתון ב-DB בלבד (בלי לגעת בקאש) → שליפה שנייה (Cache Hit — מציגה את הערך הישן, השגוי) → תיקון עם מחיקת מפתח הקאש בעדכון → שליפה שלישית (Miss מחדש, מציגה את הערך הנכון).