הרצאה: Message Queue

הקדמה – הבעיה שאנחנו מנסים לפתור

עד עכשיו עבדנו עם מערכות יחסית פשוטות:

• Client → API → Database
• בקשה נכנסת → קוד רץ → תשובה חוזרת
  זה עובד מצוין…
  עד שזה מפסיק לעבוד.

דוגמאות לבעיות נפוצות:

• פעולה כבדה שלוקחת זמן (שליחת מיילים, יצירת דוח, עיבוד תמונות)
• עומס – 1,000 בקשות נכנסות בבת אחת
• שירות אחד נופל ומפיל איתו את כל המערכת
• תלות חזקה מדי בין חלקי המערכת

כלומר:
יותר מדי דברים קורים בזמן אמת, באותו תהליך, ובאותו thread.

מה זה Message Queue (MQ)?

הMessage Queue היא תור הודעות.

במקום:

שירות אחד קורא לשירות אחר ומחכה לתשובה

אנחנו עושים:

שירות אחד שולח הודעה → מישהו אחר יטפל בה מתי שהוא יכול

הגדרה פשוטה:

הMessage Queue = היא מערכת שמאפשרת לשלוח הודעות, לשמור אותן בתור, ולצרוך אותן מאוחר יותר.

---

מי המשתתפים במערכת MQ?

בכל מערכת Message Queue יש שלושה תפקידים בסיסיים:

Producer (מפיק)

• שולח הודעה
• לא אכפת לו מי יקבל אותה
• לא מחכה לתשובה

Queue / Broker (המתווך)

• מחזיק את ההודעות
• שומר סדר
• דואג שאף הודעה לא תלך לאיבוד

Consumer (צרכן)

• מקבל הודעות
• מעבד אותן
• יכול להיות אחד או רבים

---

למה זה טוב? (היתרונות הגדולים)

1. חלוקה לשירותים שונים (Decoupling)

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

בלי MQ:

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

---

2. טיפול בעומסים (Load Spikes)

נניח:

• מגיעות 10,000 בקשות בבת אחת

בלי MQ:
- השרת קורס
- Timeout
- משתמשים כועסים

עם MQ:

• כל הבקשות נכנסות לתור
• Consumers מטפלים בקצב שלהם
• המערכת נשארת יציבה

---

3. עבודה אסינכרונית (Async Processing)

דוגמאות קלאסיות:
- שליחת מייל
- יצירת PDF
- עדכון מערכת חיצונית
- עיבוד נתונים

ה-API:
- מחזיר תשובה מיידית
- העבודה האמיתית קורית ברקע

---

דוגמה מעשית בלי קוד

מערכת הזמנות טיולים (TRIP)

בלי MQ:
1. משתמש מזמין טיול
2. API:
- שומר הזמנה
- שולח מייל
- מעדכן CRM
- מחייב אשראי
3. אם אחד נכשל → הכל נכשל

עם MQ:

1. API שומר הזמנה
2. API שולח הודעה:
   "order_created"
3. Services נפרדים:
   • Email Service
   • Billing Service
   • CRM Service
4. כל אחד מטפל בזמן שלו

---

Message Queue ≠ Database

Database	Message Queue
שומר מידע לטווח ארוך	שומר הודעות זמניות
CRUD	Push / Pull
Query	Consume
State	Events

MQ לא מחליף DB
הוא מחליף קריאות סינכרוניות בין שירותים

---

בעיות שמתחילות להופיע (חשוב להבין)

סדר הודעות

• האם חשוב סדר?

• האם מותר עיבוד מקבילי?

כפילויות

• מה אם הודעה מעובדת פעמיים?

• המערכת צריכה להיות idempotent

כשלי Consumer

• מה אם consumer נופל באמצע?

• האם ההודעה חוזרת לתור?

אלה שאלות שמובילות אותנו לפתרונות מתקדמים יותר.

איזה כיף לשמוע 🙂
אז אני משאיר את ההרצאה כמו שהיא, ומוסיף פרק המשך ארוך ומעמיק על Kafka, עם חיבור ישיר לפרויקט שלכם בפייתון, בלי להניח ידע קודם ב־Message Queue מעבר למה שכבר הסברנו.

---

שירות הApache Kafka – לעומק, מה זה ואיך עובדים עם זה בפייתון

מה זה Kafka בעצם? (במילים פשוטות)

מערכת Kafka היא תור הודעות מאוד מבוזר.
מאפשרת לנו לחלק את הקוד שלנו להמון שירותים שונים (ממש פרויקטים שונים), או בשפה המקצועית "microservice-ים"
שיודעים לדבר אחד עם השני (ממש כשירות הודעות) באמצעות קפקה.

---

למה Kafka נולדה?

הMQ קלאסי (RabbitMQ, Redis Queue וכו’) טוב ל:

• משימות
• עבודה ברקע
• הודעה → טיפול → מחיקה

אבל מה אם:

• אני רוצה לקרוא שוב אירועים ישנים?
• כמה מערכות שונות רוצות לקרוא את אותם אירועים?
• יש לי מאות אלפי אירועים בשנייה?

כאן Kafka מנצחת.

אבני הבניין של Kafka

1. Topic

• ערוץ לוגי של אירועים

• למשל:

  • order_created

  • user_registered

  • trip_updated

אין “תור אחד” — יש Topics

---

2. Message / Event

אירוע הוא לרוב:

• key

• value

• timestamp

דוגמה ל־value:

{
  "trip_id": "123",
  "user_id": "42",
  "action": "created"
}

Kafka לא אכפת מה הנתונים —
רק להעביר ולשמור.

---

3. Partition

כל Topic מחולק ל־Partitions.

למה?

• סקייל

• מקביליות

• סדר בתוך partition

כלל חשוב:

Kafka מבטיחה סדר רק בתוך partition

---

4. Producer

• שולח events ל־topic

• לא יודע מי יקרא אותם

• לא מחכה לתשובה

---

5. Consumer

• קורא events

• שומר offset (איפה הוא נמצא)

• יכול לקרוא לאט או מהר

---

6. Consumer Group

כמה consumers שעובדים יחד:

• כל partition נקרא ע״י consumer אחד בלבד בקבוצה

• מאפשר סקייל אופקי

---

Kafka בפרויקט שלנו – למה זה מתאים?

ניקח את מערכת הטיולים שלכם (TRIP):

אירועים טבעיים במערכת:

• trip_created

• trip_updated

• booking_created

• hotel_added_to_trip

• flight_attached

במקום:

• לקרוא לשירותים אחרים

• או לבצע הכל ב־request אחד

אנחנו:

• פולטים אירוע

• מערכות אחרות מגיבות

---

ארכיטקטורה טיפוסית

FastAPI (Producer)
      |
      v
    Kafka
      |
      +--> Email Service
      |
      +--> Analytics Service
      |
      +--> Notification Service

כל שירות:

• עצמאי

• ניתן לפריסה נפרדת

• לא תלוי ב־API הראשי

---

עבודה עם Kafka בפייתון – עקרונות

ספרייה נפוצה

בפייתון משתמשים לרוב ב:

• kafka-python

• או confluent-kafka

בדוגמאות נשתמש בקונספט, לא בהתקנה.

---

Producer בפייתון (קונספט)

שליחת אירוע מתוך FastAPI

תרחיש:
משתמש יוצר טיול → נשלח event

from kafka import KafkaProducer
import json

producer = KafkaProducer(
    bootstrap_servers="localhost:9092",
    value_serializer=lambda v: json.dumps(v).encode("utf-8")
)

def publish_trip_created(trip):
    producer.send(
        "trip_created",
        {
            "trip_id": trip.id,
            "name": trip.name,
            "created_at": trip.created_at
        }
    )

שימו לב:

• אין await

• אין בדיקה מי צורך

• אין תלות

---

Consumer בפייתון

שירות נפרד (למשל Email Service)

from kafka import KafkaConsumer
import json

consumer = KafkaConsumer(
    "trip_created",
    bootstrap_servers="localhost:9092",
    value_deserializer=lambda v: json.loads(v.decode("utf-8")),
    group_id="email-service"
)

for message in consumer:
    event = message.value
    send_email_about_trip(event)

Kafka:
- זוכר שה־consumer הזה קרא
- אם הוא נופל- ממשיך מאיפה שעצר

אז איך הפרויקט שלנו יראה עם קפקה?

נניח ונרצה להוסיף service-ים לפרויקט שלנו, כמו service לשליחת מיילים

קפקה היא הדרך שבה הmicroservice-ים יכולים לדבר ולבקש משימות אחד מהשני.