Project Reactor - מישהו מכיר?

[Guy Yafe]

Project Reactor - מישהו מכיר?

מדובר בפרוייקט של Spring/Pivotal שמציע מימוש של Reactor, ומאפשר עבודה אסינכרונית מסוגים שונים.
ספציפית אנחנו צריכים את זה כדי לתמוך בעשרות חיבורי TCP בו זמנית.
נראה כמו מערכת מאוד מורכבת ואולי OverKill.
האם למישהו יש נסיון במערכת הזו ויוכל להמליץ עליה או נגדה?

גיא

 

[פרסאוס]

אולי שכחת משהו?

כמו למשל איזה צורך (לא, מה שכתבת לא עונה על כלום. מה עושים החיבורים הללו?)

 

[Guy Yafe]

צודק

מקווה שאצליח להסביר יותר טוב:
אנחנו מקבלים "הודעות" דרך TCP: הלקוח מתחבר לשרת שלנו ומזרים בתים.
הודעה לדוגמה: 8 בתים ראשונים הם MAGIC, לאחר מכן 4 בתים של אורך ההודעה, לאחר מכן 8 בתים של מזהה ההודעה וכו'.
אנחנו קוראים את הבתים האלה ומפרסרים אותם להודעה, לאחר מכן עוברים להודעה הבאה וכן האלה.
&nbsp
השאלה היא איך מנהלים את החיבורים האלה?
התשתית הקיימת פותחת ServerSocket, וכל Socket חדש מועבר ל - Thread משלו.
שימוש ב - Reactor Design Pattern הוא כמובן יותר נכון, ומכאן אני שואל אם המערכת שציינתי (Project Reactor) יכולה לעזור לנו ואם יש טעם להיכנס לזה או לממש Reactor עם NIO וזהן?

 

[פרסאוס]

עדיין לא אמרת כלום.

מה עושים עם ההודעות? (ולמה צריך כזה סינטקס מוזר, אבל זה כבר סיפור אחר)
NIO אפשרות מצויינת. שיפור גדול בביצועים.
התכנות הסינכרוני מזמן לא מהווה אפשרות ריאלית לשרת.
NIO גם פשוט מאוד לשימוש, למרות שאישית אני מעדיף C++ (אם כבר מדברים על ביצועים).
אם עיבוד ההודעות פשוט - אל תכניס עוד מסגרת. לא שווה את זה.
אם יש משהו בעיבוד שצריך לעשות - זה כבר סיפור אחר.

 

[Guy Yafe]

תוכל למקד אותי?

אוסיף על מידע שחסר.
ההודעות קצרות למדי: עשרות בודדות של בתים. כל הודעה מכילה מידע גיאוגרפי (מיקום במישור, ערכי שגיאה וקצת Meta-data).
את ההודעות אני קורא והופך למבני נתונים JAVA-ים, ואותם מכנס לתוך pipeline. שם הם כבר עובדים עיבוד מסיבי מאוד, עם אלגוריתמיקה מאוד רצינית (Data Fusion). אבל זה קורה בקונטקסט אחר לגמרי ובצורה אסינכרונית.
הפירסור של ההודעות וההכנסה של המידע ל - pipeline מאוד פשוט ולא כולל עוד שום דבר מעבר למה שציינתי.
&nbsp
מטרת התחביר היא להעביר מידע בצורה הכי שלמה והכי קצרה שאפשר. אשמח לשמוע על דרכים יותר נכונות להעביר את המידע הנ"ל: זרם של הודעות שכל אחת מייצגת מידע גיאוגרפי.
פסלנו מידע טקסטואלי (JSON, XML) כי רוחב הפס קריטי ואנחנו שומרים על חיבור TCP קבוע מאותה סיבה.
&nbsp

 

[פרסאוס]

XML זה מוגזם, אבל גם JSON לא?

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

 

[Guy Yafe]

JSON מוגזם באותה מידה

בגלל זה פסלנו גם JSON ואנחנו עובדים בפורמט בינרי (זרם של בתים).
העיבוד מתבצע בקונטקסט אחר. יש לנו thread pool שמנהל את העיבוד, וזה עיקר העומס על המכונה.
&nbsp
בגדול, המצב כפי שתיארת: אנחנו קוראים את ההודעות, הופכים אותן למבני נתונים JAV-י, ומכניסים אותם לתור שממנו האלגוריתם לוקח את המידע ומעבד.
&nbsp
יש טעם ללכת על FW מורכב או פשוט למממש משהו פשוט עם NIO?

 

[פרסאוס]

אין טעם להסתבך.