Technology and Production # Redis: in-memory solution

רדיס: זיכרון פתרונות

1) היכן שרדיס מתאימה

• מטמון (קריאה דרך/בצד, TTL, SWR) והפעלות.
• מונים ומכסות: קצב מגביל, אנטי הונאה, מגבלות קמפיין.
• המלצות ”טופ N” (ראשי תיבות של Leaderboard/rating).
• תורים/אוטובוסים (Streams/PubSub), תיבת דואר אלקטרוני, מגשים מחדש.
• Idempotence (מפתחות עם TTL), de-dup webhooks.
• Geo (חיפוש אחר הנקודות הקרובות ביותר), Bitmap (דגלים, DAU).
• חייזרים/אסימונים ומטמון אישור קצר ימים.

2) מבני נתונים ומתי ליישם אותם

מחרוזת: ערכים/דלפקים (”INCRBY”), מפתחות אידמפוטנטים.
חשיש: אגרגטים של פרופילים/תצורות, אחסון של אובייקטים ”קלים”.
רשימה: תורים פשוטים (אך ללא שידור חוזר/קיזוז סמנטיקה).
סט: אלמנטים ייחודיים, שכפול.
ZSet: מיון לפי מהירות (לוחות ראשים, לוח שנה TTL - אירועים ”דחויים”).
זרם: תורים יציבים עם קבוצות צרכנים, 'XREADGROUP '/הילוך חוזר - עבור חוברות אינטרנט, CDC, מגשים מחדש.
GEOADD/GEORADIUS 'נקודות/סוחרים הקרובים ביותר.
Bitmap/Bitfield: סדרת דגלים (התחברות ביום, DAU/WAU).
HyperLogLog: קירוב ייחודי (UU) הוא זול בזיכרון.
בלום/קוקייה (מודולים): בדיקות זמינות מהירות, להפחית ”MISS” למקור.

• RedizJSON (מסמכי JSON), RediSearch (אינדקס/חיפוש), RedisBlom (מבנים הסתברותיים), Timetrics/aggregations.

3) מפתחות, TTL ומדיניות זיכרון

tenant:{t}:domain:{d}:{entity}:{id}:v{schema}    region={R}    currency={C}    lang={L}

Versioning ('vN'), כולל רק ממדים בעלי משמעות (אזור/מטבע/שפה/דייר).
לבודד את מרחבי המפתח לכל דייר.

• השתמש במטריצת TTL (sec/min/hr), הוסף ג 'יטר (net10-20%) כדי למנוע מנוסה.
• עבור מפתחות חמים - רענון קדימה וטיסה אחת (עדכונים מוביל אחד).

• 'Allkeys-lu/lfu' הוא מטמון משותף ללא תלות TTL.
• 'volatile-lru/lfu' - מפתחות רק עם TTL.
• 'לא פינוי' - לכתוב כישלון על עודף (בטוח יותר עבור תורים קריטיים/דלפקים).
• בחר עבור התסריט ותמיד תעקוב אחר "פינוי _ keys'.

4) עסקאות, צינורות ותסריטים

צינורות: להפחית RTT, קבוצה 10-100 קבוצות.
עסקאות (MULTI/EXEC) - אין לבודד את הקריאות, אלא לבצע את הצרור באופן אטומי.
נעילה אופטימלית: ”WATCH key” = בדיקת MULTI/EXEC.
תסריטי לואה: לוגיקה אטומית בצד השרת (הגבלת קצב, מנעולים, פעולות מורכבות).

5) תורים ואוטובוסים: רשימה נגד זרם

רשימה + 'BRPOP' - פשוט, אבל לא קבוצות צרכנים, קיזוז/שידור חוזר, התנגדות חלשה לטיפות.
זרם: 'XADD = XREADGROUP = XACK', retry-deadletter (לא נלקח ב N דקות), מחולק על ידי מפתח. מומלץ לחוברות אינטרנט PSP/KYC, דחיית תשלומים/הודעות.

תורים בעדיפות ראשונה: מספר זרמים לפי עדיפות, הצרכנים ”מוצצים” מלכתחילה.
משימות דחויות: ZSet שם ציון = חותמת זמן; תקופתית ZRANGEBYSCORE 'עכשיו = = הועבר לזרם.

6) זמינות גבוהה וקשקשים

שכפול: Master # העתק (read-scale).
כשל אוטומטי, מאסטר, תגלית, לקוח.
רדיס אשכול: 16384-חריץ, סולם אופקי החוצה. עטיפת מפתחות שמשתמשים במספר מבנים לפי סדר: 123 תגיות חשיש.

• עבור מטמון/מפגשים - אשכול/העתק, 'secient-side hassing' SDK נתמך.
• עבור תורים/זרמים - למזער פעולות חוצה חריצים; מחיצה באמצעות מפתחות תחומים.

7) התמדה: RDB, AOF וגיבויים

RDB (תמונות): מהיר יותר, חסכוני יותר; סיכון לאובדן של שניות/דקות אחרונות.
AOF (כתב עת): פחות הפסדים; 'everysec/תמיד' מצבי. דחיסה ואריזה תקופתית.
היברידי: RDB + AOF = התאוששות מהירה + הפסדים מתונים.
גיבויים: תמונות ועותקים של AOF לאחסון אובייקטים; בדוק התאוששות באופן קבוע.

עבור תורים קריטיים/אידמפוטנטיות, בחר AOF 'everysec' + שכפול.

8) בטיחות וציות

תפקידים לכל יישום, איסור על פקודות "מסוכנות" ("FLUSHALl'," מפתחות ").
TLS לשרת-לקוח וקישורים בין צומת; תיקן את האיי-פי של היציאה.
קטעי רשת: רשתות משנה פרטיות, SG/NACL; גישה רק מהשירותים/אספות השם הנדרשים.
אל תרשום סודות; PAN/PII ברדיס - אסימונים/נגזרות בלבד.
פקודות מפתח: להימנע 'מפתחות' - להשתמש 'סריקה'.

9) יכולת תצפית ו ־ SLO

• Latency (P95/P99), ”מיידית _ ops _ per _ sec”, ”מחוברים _ לקוחות”.
• יחס פגיעה, evicted_keys, expired_keys.
• זיכרון: בשימוש, יחס פיצול, RSS, סטטיסטיקות הקצאה.
• עיכוב שכפול, תדרי AOF/RDB וגדלים, זמן מזלג.
• זרמים: PEL (רשימת רישומים תלויה ועומדת), איחוי משלוח, ספירה חוזרת.

• פעולות רדיס P99 רשומות 5-10 ms.
• פינוי מצופה 1 %/שעה (מרווח מטמון).
• משלוח זרם P99 לפי 500/embly, קצב חזרה <2%.

10) פינוקים ותכנון משאבים

זיכרון הוא יקר: למדוד $/GB-חודש RAM נגד שמירת בקשות למקור/DB.
אפשר דחיסת ערך> 1-2 KB (ראה מעבד).
LFU יכול לתת להיט טוב יותר עם פחות נפח.
עבור תמונות/בועות גדולות - לא רדיס: השתמש ב ־ CDN + אחסון אובייקטים.

11) תבניות עבור iGaming/fintech

11. שיעור 1 מגביל (Lua)

רעיון: ”INCRBY” במפתח חלון + TTL; לואה בודקת אטומית את הגבול ומגדילה.

lua
-- KEYS[1]=key ARGV[1]=limit ARGV[2]=ttlSec ARGV[3]=inc local cur = redis. call('INCRBY', KEYS[1], ARGV[3])
if cur == tonumber(ARGV[3]) then redis. call('EXPIRE', KEYS[1], ARGV[2]) end if cur > tonumber(ARGV[1]) then return {0, cur} else return {1, cur} end

11. 2 מבקש אידמפוטנטיות

מפתח 'idemp: [בקשה _ id] עם TTL 24h, ערך - תוצאה/מצב. לפני ביצוע הניתוח, אנו בודקים לנוכחות.

11. 3 לוחות ראשים

ZINCRBY מוביל: משחק: () ניקוד משתמש: (u) ”” ZREVRANGE... עם סקרים.
עבור N העליון על ידי אזור/דייר - ZSet בודד או קידומת.

11. 4 תור Webhooks PSP

'XADD psp: ▪ קבוצת צרכנים ”XGROUP Creath psp: webhooks g1 $”.
מגשים מחדש של הודעות ”תקועות” באמצעות סריקת PEL (”XPENDING” # ”XCLAIM”).

11. 5 תשלומים דחויים

Zset 'payout: Design (ציון = epoch) = = העובד מעביר באופן תקופתי פריטים מוגמרים ל-Stream' payout: exec עם dauplication.

11. 6 מטר אנטי-פראוד

שילוב של תגי PFADD (ייחודי) + 'INCR' (עוצמה) + תגיות geo/ASN; מעורר לאימות ידני.

12) עבודה עם זיכרון וביצועים

בריכות חיבור ללקוח; להפחית RTT (לשמור-בחיים).
מעדיף צינורות על פני חבילת פקודות.
שימו לב למפתחות גדולים (”שימוש בזיכרון”, ”סרוק”) - עדיף לפצל חפצים.
חשיש עם מספר קטן של שדות הוא חסכוני יותר מאשר מפתחות בודדים רבים.
אפשר io-אשכולות (לקרוא-כבד) אם הרווח מאושר על ידי בדיקות.
הימנע ”FLUSHDB/ALL” בתבנית; לנהל באמצעות קידומות ו ”לא לינק” למחיקה בטוחה.

13) דייר רב ־ דייר ובידוד

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

14) נעילה ועקביות

הגדרת מפתח NX PX = tl - מוטקס פשוט.
רדלוק: השתמש בזהירות; עבור עסקאות ביקורתיות מבוזרות, עדיף להסתמך על ”מקור האמת” (DB/Ledger) ופעולות אידמפוטנטיות.
מעדיף פעולות אטומיות ולואה במקום מנעולים ”ארוכים”.

15) אנטי דפוסים

אחסון של בועות/תמונות גדולות - עומס יתר של RAM ורשתות.
אינווריאנטים פיננסיים (מאזן) רק ברדיס.
”מפתחות” ו ”סריקת העולם” בדבק.
אין טי-טי-אל/ג 'יטר - ערימת כלבים על תפוגה.
מדיניות 'allkeys-' על תורים קריטיים = איבוד נתונים בלחצים.
ערבוב תורים, מטמון והפעלות במקרה אחד ללא מכסות וסדרי עדיפויות.
תסריטי לואה שעובדים על המפתחות של מקומות שונים באשכול.

16) רשימת מימושים

1. הגדר תפקידים: מטמון/הפעלות, תורים/זרמים, דלפקים/גבולות - פוסט למקרים/אשכולות.
2. בחר מדיניות מקסמורי עבור המשימה; קבע גבולות ופינוי ניטור.
3. שמות מפתח, גרסאות מעגל, מטריצת TTL + jitter; טיסה אחת למפתחות העליונים.
4. עבור תורים - זרמים (קבוצות, מגשים מחדש, DLQ), עבור העברת ZSet +.
5. HA: שכפול + סנטינל או רדיס קלאסטר; בדוק את כישלונות הלקוח.
6. התמדה: RDB/AOF תחת תסריט; גיבויים רגילים ובדיקת התאוששות.
7. אבטחה: ACL, TLS, רשתות פרטיות, איסור פקודות מסוכנות.
8. יכולת תצפית: Latency, Ops/Sec, זיכרון, פינוי, שכפול לאג, זרם PEL.
9. FinOps: פרופילי זיכרון, מפתחות גדולים, דחיסה, LFU; הימנע redis לגושים גדולים.
10. תיעוד תבניות (מגבלת קצב, אידמפוטנטיות, לוחות מובילים) ומבחני טעינה.

תוצאות

רדיס היא ”סכין שוויצרית רב-תפקודית” של מהירות: מטמון, תורים, דלפקים, לוחות ראשים, מבנים גיאו והסתברותיים. חוזקו טמון בבחירה הנכונה של מבני נתונים, דיסציפלינת TTL/נכות, אטומיסיביות של פעולות, וחשיבה היטב HA/התמדה ותצפית. השתמש ב ־ Redis שבו חשובות אלפיות ־ שנייה ו ־ RPS גבוה, תוך השארת אינווריאנטים קריטיים (כסף, חשבונאות) ל ”מקור האמת” - כך הפלטפורמה תישאר מהירה ואמינה.