המדריך המלא ל-Redis Streams — לב התקשורת בין סוכנים
message bus קל-משקל שמחבר 13 סוכנים בלי Kafka, RabbitMQ או SQS
Redis Streams היא תכונה של Redis (החל מגרסה 5.0, 2018) שהופכת אותו ל-message broker קליל מאוד — תקשורת אסינכרונית בין שירותים, בלי הסיבוך של Kafka או RabbitMQ. Redis עצמו הוא מאגר key-value בזיכרון שרץ במאות אלפי VPS ברחבי העולם — מהיר במיוחד (פעולות במיקרו-שניות), פשוט להגדרה, וצורך מינימום משאבים. Streams הוסיפו לו את היכולת להחזיק תורים מתמשכים של הודעות עם consumer groups (קבוצות צרכנים שמתחלקות בעבודה), acknowledgments (אישור שהודעה טופלה), ו-replay (יכולת לחזור להודעות ישנות). אצלי (אלעד) Redis Streams הוא 'העצב המרכזי' של רשת 13 הסוכנים שלי על Hetzner: כשמסר WhatsApp מגיע ל-Kami, הוא לא מטפל בו לבד — הוא דוחף הודעה ל-stream, וצרכנים שונים (Box לתזונה, Adopter לתוכן, Hermes לזמנים) קוראים ומגיבים. אם סוכן אחד נופל, ההודעות מחכות ב-stream עד שהוא חוזר. אם רוצים סוכן חדש שמאזין לאותם events — מוסיפים אותו ל-consumer group ב-30 שניות. מאז המעבר ל-Redis Streams (לפני שנתיים, Q2 2024), המערכת שלי יציבה הרבה יותר: כל סוכן עובד לבד, וההיגיון 'מי מקשיב למה' מנוהל ב-Redis במקום ב-API calls ישירים.
מה המדריך מכסה
מה זה Redis Streams: append-only log
כמו Kafka, רק ב-Redis ובלי Zookeeper
Redis Stream הוא מבנה נתונים מסוג 'append-only log' — רשימה של הודעות שאפשר רק להוסיף לסוף, אף פעם לא לערוך באמצע. כל הודעה מקבלת ID ייחודי (timestamp במילישנייה + sequence), אפשר לקרוא טווח של הודעות, ואפשר 'לעקוב' (XREAD) על הוספות חדשות בזמן אמת. זה דומה במהותו ל-Kafka topic, אבל הרבה יותר פשוט להפעיל: Redis עצמו הוא תהליך אחד, אין Zookeeper, אין partitions, אין broker cluster. אתם פשוט מריצים Redis ויש לכם Streams.
XADD ו-XREAD: שתי הפעולות הבסיסיות
כל מה שצריך ל-pub/sub פשוט
אם אתם רק רוצים pub/sub פשוט — סוכן A דוחף, סוכן B מקשיב — אתם צריכים רק את XADD ו-XREAD. בלי consumer groups, בלי acknowledgments. הקוד למטה הוא דוגמה ב-Python שמראה את שני הצדדים.
Consumer Groups: כשיש כמה צרכנים שמתחלקים בעבודה
כל הודעה מטופלת בדיוק על ידי consumer אחד בקבוצה
Consumer groups הם הפיצ'ר שעושה את Redis Streams ל-message broker רציני. במקום שכל הצרכנים יראו את כל ההודעות (כמו pub/sub), צרכנים בתוך אותה group מתחלקים בעבודה — כל הודעה מגיעה ל-consumer אחד בלבד בקבוצה. אם רוצים יתירות, מקימים כמה consumers; אם אחד נופל, השאר ממשיכים. בנוסף, יש מנגנון acknowledgment: צרכן מאשר 'טיפלתי בהודעה X', ו-Redis זוכר. אם הצרכן נופל לפני שאישר, ההודעה תיתפס שוב על ידי צרכן אחר.
Patterns: fan-out, work-queue, event-sourcing
השימושים הנפוצים של Streams
אחרי שמכירים את הבסיס, יש כמה patterns מקובלים שעוזרים לתכנן את הארכיטקטורה.
Production: גודל זיכרון, persistence, ניטור
מה שצריך לדעת לפני release
Redis בייצור דורש 3 דברים: persistence (שלא יאבד דאטה אם Redis קורס), ניהול גודל (שה-stream לא יבלע את כל הזיכרון), וניטור.
אלטרנטיבות: Kafka, RabbitMQ, NATS
מתי לבחור מה
Redis Streams זה lightweight, אבל לא מתאים לכל מקרה. הנה השוואה לפתרונות אחרים.
