פרסינג נתוני בורסות קריפטו: REST API, WebSocket, CCXT

מדוע פרסור של בורסות קריפטו נשבר בעומסי שיא

עומס שיא על הבורסה אינו רק עלייה במספר העסקאות. מנוי זרימה לספר הפקודות בדקות כאלה מחזיר פי כמה יותר הודעות, והערוץ נקרע: החיבור נסגר על ידי הפלטפורמה עצמה, והלקוח מגלה על כך רק בפסק הזמן, ומאבד כל מה שלא הספיק לשמור. קטיעת זרם הנתונים כמעט לעולם אינה נראית כמו שגיאה — היא נראית כמו שקט.

הכשל השני הנפוץ — מגבלות על בקשות. שיטות ציבוריות סופרות את תדירות הפניות לפי מפתח וכתובת, ובחריגה הפלטפורמה לא רק מסרבת, אלא חוסמת גישה לפרק זמן הולך וגדל. שאילת היסטוריית מחירים ונרות באותו רגע נעצרת כולה, וחלון שנפל על החסימה כבר לא ניתן לשחזר.

גם כשהערוץ חי, ספר הפקודות מספיק להתפצל מהמציאות. תמונת מצב של ספר הפקודות וזרם העדכונים מגיעים בנתיבים שונים, ובאובדן הודעה אחת העותק המקומי מגיע בשקט לחוסר התאמה מול זה של הבורסה.

חוסר סנכרון כזה של ספר הפקודות אינו נראה עד לעסקה הראשונה במחיר שגוי — ובינתיים בלוגיקת המסחר כבר התקבלה החלטה.

היקר ביותר הם הפערים בהיסטוריית המחירים. לאחר התחברות מחדש הזרם משוחזר מהרגע הנוכחי, ואיש אינו מחזיר את הקטע שהוחמץ — יש לבקש אותו בנפרד ולחבר ידנית. הנרות נאספים עם חורים, ועליהם נשבר כל המשך השרשרת: חישוב שווי התיק, אינדיקטורים, בדיקת אסטרטגיות על נתוני עבר.

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

מה נותן איסוף נתוני שוק מסודר

פורמט נתונים אחיד מסיר את הכאב העיקרי — כל בורסה מחזירה סכימה משלה: באחת הנפח במטבע הבסיס, באחרת במטבע המצוטט, ובשלישית הזמן במילישניות במקום בשניות.

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

עמידות האיסוף נבנית על כמה מעגלים. ערוצי זרימה מחזיקים חיבור קבוע עם התחברות מחדש אוטומטית והשהיה הולכת וגדלה, הפערים בזמן הניתוק מושלמים מההיסטוריה דרך נקודות שאילתה, ורשומות כפולות ומחוץ לתור נחתכות לפי מזהה העסקה וחותמת הזמן.

שיעור העדכונים שאבדו יורד מאחוזים לשברי אחוז, וכל זאת כאשר בכל ערוץ הוא נמדד בנפרד — נראה היכן פלטפורמה מסוימת מדרדרת, ולא «האיסוף נשבר כולו».

צמצום ההפעלות מחדש הידניות הוא תוצאה ישירה של יכולת הניטור. התהליך עצמו עוקב אחר טריות העדכון האחרון ואחר עומק ספר הפקודות, במקרה של קיפאון מקים את החיבור מחדש, ולמפעיל הוא כותב רק כאשר האוטומציה לא הצליחה.

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

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

הספרייה CCXT מטפלת בהבדלים האופייניים בין הממשקים של הפלטפורמות, ושכבה עצמאית מעליה אחראית על נורמליזציה, בקרת שלמות והתחברות מחדש — דברים שלגבי איסוף ציטוטים חשובים יותר מהגישה עצמה ל-API.

פרסור בורסות קריפטו: בקשות תקופתיות או חיבורי זרימה

מצב האיסוף קובע מה בכלל ניתן לבנות מעל הנתונים: דיווח מחושב או תמונה חיה של השוק. בקשות תקופתיות מחזירות פרוסה לרגע הקריאה — ספר הפקודות, היסטוריית עסקאות, יתרת החשבון. חיבורי זרימה שולחים כל שינוי עם הופעתו ומחזיקים מצב ללא שאילתות.

הבחירה במצב האיסוף כמעט לעולם אינה בינארית. הסכמה העובדת היא היברידית: הזרם אחראי על עדכניות, ובקשה תקופתית משלימה את הקטע שהוחמץ לאחר ניתוק ומשמשת השוואה בלתי תלויה לבקרת אי-התאמות.

מתאמים מאוחדים

נוח יותר לרסן את ההבדלים בין הפלטפורמות בכניסה, ולא בלוגיקה העסקית. מתאם מאוחד מביא את השדות לסכימה משותפת — מכשיר, צד, נפח, זמן — מטפל בעצמו בעימוד, בחזרות ובמגבלות תדירות הפניות, וכן מתרגם הודעות זרימה לאותו פורמט שבו מגיעות תשובות השאילתה.

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

שלבי היישום: מביקורת המקורות ועד מסירת הנהלים

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

1. ביקורת מקורות ומגבלות. משווים את רשימת הבורסות וזוגות המסחר, בודקים את המגבלות בפועל על תדירות ומשקל הבקשות, את עומק ההיסטוריה הזמין ואת פורמטי התשובות. בתפוקה — מפת מקורות עם עדיפויות ורשימת אי-התאמות בין הפלטפורמות.
2. סכימת זרמי נתונים. מחליטים מה נלקח במנוי, מה בשאילתה, היכן נקודות האיגוד והאחסון. קובעים מודל אירוע אחיד, כדי שנתונים מבורסות שונות ייכנסו למבנה אחד ולא לגן חיות של פורמטים.
3. הגדרת תורים והפרדות. מפרידים בין הקליטה לעיבוד: התור מחליק את קפיצות העומס ומאפשר להפעיל מחדש את המעבד ללא אובדן נתונים. כאן גם — ניסיונות חוזרים, דה-דופליקציה ושחזור לאחר ניתוק החיבור.
4. השוואה ותיקוף. משווים דגימות מול אמת מידה, מנתחים פערים ואי-התאמות בנפחים ובזמן. פער בהיסטוריה מסוכן מניתוק החיבור — מבחינים בו רק לפי החישובים הסופיים.
5. בדיקת קבלה בתקלות. מנתקים את הערוץ, יוצרים קפיצת עומס, מכניסים השהיות בתשובות הפלטפורמה ובודקים כיצד המערכת מדביקה את מה שהוחמץ. קובעים את זמן השחזור ואת שיעור האירועים שאבדו.
6. מסירת נהלים. מוסרים את מפת המקורות, את מדיניות המגבלות, את הוראות ההפעלה, את סט המדדים ואת ספי ההתראות — התחזוקה אינה תלויה במחבר הקוד.

תוצאת השלב — זרם ששורד תקלות שגרה של הפלטפורמות ללא התערבות ידנית, ותיעוד שאפשר לפתח לפיו.

קונפיגורציות, סכימות זרמים ותיעוד: מה נשאר אצלכם

הפרויקט נמסר לא כדוח, אלא כמעגל עובד שממשיך לחיות בתשתית שלכם. הקונפיגורציות, הסכימות, כללי הגישה וההוראות נמצאים במאגר שלכם ואינם דורשים את השתתפותנו כדי לשנות את רשימת הבורסות או להוסיף זוג מסחר. להלן — הרשימה המלאה של מה שנשאר אצלכם לאחר השקת הפרסור של בורסות קריפטו.

• קונפיגורציות חיבורים. רשימת הבורסות וזוגות המסחר, תדירות הבקשות המרבית, זמן המתנה לתשובה, כללי החזרות וסדר המעבר למקור חלופי — נערכים בקובץ, ללא בנייה מחדש ופריסה.
• סכימות זרמי נתונים. הנתיב מהמקור ועד למאגר עם נקודות חוצץ, דה-דופליקציה ואיפוס: נראה היכן הזרם עשוי להיעצר ומאיזו נקודה מאושרת הוא ימשיך.
• מדיניות גישה למפתחות. הפרדה של מפתחות לקריאה בלבד, רוטציה לפי לוח זמנים, אחסון במאגר מאובטח, איסור על כניסת מפתחות למאגר הקוד וליומני העבודה.
• סכימת תורים ועמידות לתקלות. מה קורה בעת ניתוק החיבור: כמה נתונים נשמרים מקומית, כיצד פועלות החזרות, באילו תנאים מופעית התראה לתורן.
• תיעוד ונהלים. מדריך השדות, כללי הנורמליזציה של מקורות שונים למודל משותף, הוראה למשמרת התורן: מה ובאיזה סדר לבדוק בעת אי-התאמה.
• נוהל השחזור. הליך שלב-אחר-שלב להקמת הזרם מחדש לאחר תקלה, שחזור הקטע שהוחמץ והשוואת הנפחים מול הבורסה.
• סט תשובות אמת מידה. דוגמאות שמורות של תשובות לבדיקת הפירוק: שינוי בצד הבורסה נתפס לפני הפריסה, ולא לפי טבלאות ריקות.

מקרה בוחן: חוסר סנכרון של ספר הפקודות בשלוש פלטפורמות וכיצד הסרנו אותו

הלקוח אסף נתונים משלוש פלטפורמות בו-זמנית: ספר הפקודות, עסקאות, שיעורי מימון. חלק מהמקורות החזירו פרוסה בשאילתת REST, חלק — דרך מנויי זרימה, וכל פורמט היה צריך להביא ידנית לצורה משותפת.

דווקא במפגש שבין הזרמים לתמונות המצב צץ חוסר הסנכרון של ספר הפקודות: לאחר ניתוק קצר של החיבור הזרם המשיך לזרום, אך שחזור ההיסטוריה לא התרחש — תמונת המצב נמשכה מחדש, ואיש לא השווה את הפער בינה לבין הדלתות הראשונות.

לפני השיפוץ התמונה נראתה כך: בזוגות פעילים אבדו 4–6% מהעדכונים, חלון השחזור לאחר ניתוק ארך עד 30 שניות, וההשבתה הכוללת של האיסוף הגיעה לכשעתיים ביממה. משמרת התורן קיבלה 6–8 פניות בלילה ובכל פעם התמודדה איתן ידנית.

הרכבנו שכבת איסוף אחידה: CCXT טיפלה בשאילתה ב-REST ובאיחוד המדריכים, את מנויי הזרימה חיברנו ישירות, כדי לא לאבד את תור ההודעות בחוליה מתווכת.

העיקר — בקרת רציפות הרצפים: כל דלתה נושאת מספר, החוצץ מחזיק את ההודעות האחרונות, ובשעת ניתוק נשאלת רק תמונת המצב, והתור מודבק מהחוצץ, ולא מתחיל מאפס. את היסטוריית ספר הפקודות אנו כותבים למאגר מקומי, לכן השחזור כבר אינו תלוי בכך אם הזרם הספיק להדביק את עצמו.

לאחר מכן שיעור העדכונים שאבדו ירד מתחת ל-0,1%, חלון השחזור הצטמצם לכמה שניות, ההשבתות הסדירות של האיסוף נעלמו, ופניות משמרת התורן הצטמצמו לאחת-שתיים בשבוע — וגם אלה עקב תקלות חיצוניות של הפלטפורמות, ולא בחלק שלנו.

בנפרד הנחנו השוואה של נפחים מצטברים בין הפלטפורמות: אי-התאמה מעל הסף מרימה אות לפני שהיא מגיעה ללוגיקת המסחר.

במה נבדלים חיבורי זרימה מבקשות תקופתיות?

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

חיבור זרימה הופך את הסכמה: השרת עצמו שולח שינויים ברגע שהם מופיעים. השהיית הנתונים יורדת לזמן ההעברה, והעומס על המקור מפסיק להיות תלוי בתדירות הפניות שלנו. המחיר — שלמות ההיסטוריה: הזרם מחזיר אירועים רק מרגע החיבור, וניתוק החיבור משאיר חור שאינו נראה מבחוץ.

בפועל הסכמה העובדת היא משולבת: הזרם נותן תגובה, הבקשות התקופתיות — שלמות ההיסטוריה ושחזור החלון שהוחמץ לאחר ניתוק. את ההבדלים בפורמטי הפלטפורמות מביאה לצורה אחת CCXT — במקום לקוח נפרד לכל בורסה.

בעת ניתוק אין די בהתחברות מחדש: יש לבקש את הקטע שהוחמץ לפי נרות ועסקאות, ולפסול כפילויות לפי המזהה. אחרת נותרות במאגר עסקאות מוכפלות, והפער בנתונים צף כבר בדוח המוגמר.

מה מבררים לפני ההתחלה: מגבלות, חסימות ואחסון היסטוריה

לפני ההערכה מריצים תרחיש על הפלטפורמות שלכם: בודקים את המגבלות על תדירות הבקשות, את עומק מסירת ההיסטוריה ואת כללי הפניות החוזרות. מזה תלוי מצב האיסוף — בקשות REST תקופתיות, מנויי WebSocket לזרימה או שילוב של השניים — וכמה צמתים נדרשים כדי לעמוד במגבלות ללא חסימות.

מה לעשות אם המנוי נקרע בלילה?

הניתוק נתפס בבדיקת החיות של הערוץ: אם המקור שותק זמן רב מהצפוי, המנוי נוצר מחדש, והקטע שהוחמץ מושלם מההיסטוריה. פער בין חותמת הזמן האחרונה שנרשמה לזו הנוכחית מעל הסף מרים התראה — ההפסקה לא תישאר בלתי מורגשת.

עד כמה עמוק נשמרת ההיסטוריה?

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

כיצד מחברים פלטפורמה חדשה?

המקור מתייצב כמודול נפרד מאחורי ממשק משותף: פירוק תשובה משלו וסכימת מגבלות משלו, והשאר — נורמליזציה, אחסון, מסירה — אינו משתנה. הרחבת רשימת הפלטפורמות אינה הופכת לפרויקט נפרד, ואין צורך לתקן את ליבת המערכת.

נדון במשימה שלכם ונחזור עם תוכנית יישום

כדי שאומדן היקף העבודה יישען על עובדות ולא על השערות, די בנתוני פתיחה על המשימה שלכם — בתגובה נשלח מסמך עם תוכנית, ולא הרהורים כלליים. מתחילים בדיון במשימה: אילו פלטפורמות ואילו נתונים דרושים — עסקאות, ספר הפקודות, נרות, שיעורי מימון, מדריכי מכשירים.

מה שמזרז באופן ניכר את ההערכה:

• רשימת המקורות: בורסות, אגרגטורים, שירותים פנימיים, מהם אנו שואבים את הנתונים
• עומק ההיסטוריה והגרעיניות — מאיזה רגע אנו משחזרים את העבר ובאיזה צעד
• מצב העבודה: שאיבה חד-פעמית, זרם רציף או סנכרון תקופתי
• סכמת הפריסה: המעגל שלכם, ענן או מקטע מבודד ללא רשת חיצונית
• דרישות לאחסון ולגישות: תוחלת חיי הנתונים, הפרדת הרשאות, עבודה עם מפתחות
• נקודות קבלה: אילו השוואות נפחים ודוחות אי-התאמות נחשבים להוכחת נכונות

לאחר קבלת נתוני הפתיחה הללו, מרכיבים תוכנית יישום: שלבים, מה עושים בכל אחד, באיזה שלב נדרשים ההרשאות שלכם ומי מקבל את התוצאה. את לוחות הזמנים להשקה מוסרים יחד עם התוכנית — תחילה מעגל קבלה על פלטפורמה אחת-שתיים, אחר כך הרחבה לשאר והעברה לתפעול קבוע. אם עולים אי-בהירויות בנוגע לנתונים או להרשאות, שואלים שאלות לפני ההתחלה, ולא באמצע העבודה.

תארו את המשימה — נחזור עם אומדן היקף העבודה, לוחות זמנים ותוכנית יישום לפי שלבים.