מדוע הבוט מאבד קשר עם Bitget API ואיך זה שובר את המסחר
חיבור קבוע ל-Bitget הוא החוליה השבירה ביותר בבוט מסחר. ערוץ העדכונים שותק, והשוק באותו רגע לא עומד מלכת: כל עוד הלוגיקה לא מבדילה בין השהיה טכנית לבין שקט במכשיר, הבוט ממשיך להתייחס לספר הפקודות המקומי כמעודכן ומגיש פקודות לפי מחירים שכבר לא קיימים. ניתוק החיבור לבורסה יוצר כניסות במחיר שגוי וסטופים שמופעלים מאוחר מהנדרש.
התקלה השנייה יקרה יותר בתוצאות — כפילות פקודות. התשובה להצבת הפקודה לא הגיעה בזמן שהוקצה, והבוט, בלי לדעת אם הפקודה התקבלה, חוזר על הבקשה. בלי מזהה לקוח לפקודה ובלי בדיקת סטטוס לפני החזרה, בבורסה נוצרות שתי פקודות במקום אחת, והפוזיציה נפתחת כפול מהמתוכנן.
השלישי — חוסר סנכרון במצב החשבון: ביצועים חלקיים, עמלות, תיקונים ידניים במסוף. המודל המקומי מציג נפח אחד, הבורסה — אחר, והבוט סוחר במה שכבר אין ביתרה.
נפרט כיצד זה נסגר ברמת האינטגרציה עם Bitget API: בקרת חיות הערוץ והשהיות זמן, בקשות חוזרות עם הגנה מכפילויות ובדיקה תקופתית של מצב החשבון מול הבורסה.
האפקט של בנייה מחדש של האינטגרציה: השהיות, סירובים, עומס
לפני העיבוד מחדש, שכבת הקישור לבורסה עבדה בסקרים תקופתיים: השהיית התגובה לאירוע נמדדה בשניות, וחלק מאירועי השוק כלל לא הגיעו. בין שני סקרים המחיר הספיק לעבור רמה, והפקודה נשלחה במחיר מיושן. ניתוק החיבור לא היה מנוטר — הזרם קפא בשקט, המצב המקומי סטה מהבורסה, והשחזור הופעל ידנית.
לאחר מעבר לחיבור קבוע עם זרם אירועים מ-Bitget השהיית התגובה הצטמצמה לשברי שנייה, ושיעור האירועים האבודים ירד מיחידות אחוזים לאפס בהרצה יומית. ספר הפקודות המקומי נבנה מעדכונים מצטברים ומושווה לתמונת מצב בכל התחברות מחדש — חוסר הסנכרון אינו מצטבר.
יציבות החיבור הפסיקה להיות תלויה במהנדס תורן. בקרת החיות של הזרם לפי השהיית שקט, התחברות מחדש אוטומטית עם שחזור המנוי ובדיקה חוזרת של המצב מסירות את החלון שבו הבוט סחר בנתונים מיושנים. קודם לכן אפיזודה כזו הסתיימה בסדרה של פקודות שנדחו ותיקון ידני של פוזיציות.
העומס על הערוץ ירד בסדר גודל: במקום זרם מתמשך של סקרים פועל ערוץ מנויים אחד עם קריאות שירות נדירות. המלאי שהתפנה מופנה לחישוב האסטרטגיה ולא לתקשורת עם הבורסה, ולכן התגובה נשמרת גם בשיאי עומס, כשתדירות העדכונים עולה פי כמה.
אפשרויות אינטגרציה עם Bitget API: חיבור ישיר וזרם
Bitget API מספק נתונים בשני ערוצים בלתי תלויים: בקשות סינכרוניות לבורסה וזרם אירועים קבוע. סכימת החיבור קובעת כיצד הבוט שורד השהיות רשת, ניתוקי חיבור ופערים בין תמונת השוק שלו לבין מצב החשבון בפועל.
הסכימות אינן מחליפות זו את זו — הן סוגרות משימות שונות. חיבור ישיר מתאים במקום שבו החלטות מתקבלות לעתים רחוקות ולפי לוח זמנים; זרם נחוץ לתגובה לתנועת מחיר בתוך שנייה; היברידי עם מטמון מקומי של פקודות סוגר את רוב האסטרטגיות העובדות.
| סכימה | מתי מתאימה | מגבלות |
|---|---|---|
| בקשות ישירות לבורסה | פעולות נדירות לפי לוח זמנים: בדיקת יתרה, הצבת פקודות בודדות, השוואת היסטוריית עסקאות | מגבלות קשיחות על תדירות הפניות, השהיה בכל קריאה, עם גידול במספר זוגות המסחר הבוט מקבל סירובים |
| זרם אירועים קבוע | תגובה מיידית לספר הפקודות ולעסקאות: סקלפינג, ארביטראז', מעקב אחר מחיר | החיבור נקרע, אירועים מגיעים עם חסרים, לאחר התחברות מחדש יש להרכיב את המצב מחדש |
| סכימה היברידית עם מטמון מקומי של פקודות | מצב עבודה של רוב האסטרטגיות: הזרם מחזיק את תמונת השוק, המטמון — פוזיציות ופקודות פעילות, בקשות נשלחות רק לפעולות | קוד מורכב יותר, נדרשת השוואה תקופתית של המטמון מול הבורסה וכללי הכרעה בפערים |
קריטריון בחירה מעשי — תדירות ההחלטות, לא נפח המסחר: אסטרטגיה שמסתכלת על השוק פעם בדקה אינה זקוקה לחיבור קבוע עם עיבוד מלא של הזרם.
שלבי הטמעה: מביקורת אינטגרציה ועד מסירה לתפעול
את העבודה על מודול המסחר מובילים בשלבים: למסחר אוטומטי יש מחיר טעות גבוה, ולכן כל שלב מסתיים בארטיפקט ניתן לבדיקה, ולא ב"מוכן" מילולי. להלן הסדר שאנו מקפידים עליו באינטגרציה עם Bitget ובהעברת לוגיקה שכבר עובדת.
- ביקורת מודול המסחר. מפרקים את הקוד הנוכחי: כיצד נוצרות ומבוטלות פקודות, היכן נשמר מצב הפוזיציות, אילו צמתים שורדים הפעלה מחדש של התהליך ואילו מאבדים נתונים בעת תקלה.
- סכימת זרימות נתונים. קובעים מה נדרש באופן חד-פעמי ומה מוחזק בערוץ שערים קבוע, כיצד משחזרים את הזרם לאחר ניתוק והיכן נדרשת השוואה של המצב המקומי מול הבורסה.
- הגדרת מפתחות ומגבלות. מפרידים הרשאות קריאה והרשאות מסחר, מגדירים תדירות בקשות עם מרווח עד המגבלות, וקובעים כללי עיגול נפח ומחיר לפי מסנני המכשיר.
- הרכבה על קו בדיקה של הבורסה. מריצים מחזור מלא: הצבה, ביצוע חלקי, ביטול, כניסה חוזרת. בנפרד בודקים התנהגות בעת ניתוק חיבור ובעת פקודה שנדחתה.
- בדיקה בשוק אמיתי בנפח מוגבל. בוחנים ביצוע בפועל, פער בין מחיר מחושב למחיר אמיתי, והשהיה בין האות להצבת הפקודה.
- מסירה לתפעול. מוסרים תיעוד תצורה, נוהל עצירה והפעלה מחדש, סט מדדים ויומנים שלפיהם התורן רואה את מצב הבוט בלי לקרוא קוד.
אפשר לעצור בכל שלב: אם הביקורת מראה שזול יותר לכתוב את המודול מחדש מאשר לתקן, תדעו זאת לפני תחילת העבודה.
מה הלקוח מקבל לידיו: תצורות, סכימות, נהלים
מסירה היא לא ארכיון קבצים, אלא סביבת עבודה שהצוות שלכם מתחזק בלעדינו. כל מה שנבנה בפרויקט מתואר כך שמהנדס שלא השתתף בפיתוח יריץ את מודול הקישור ל-API המסחר של Bitget, יחזור על ההרכבה ויבין היכן לחפש את סיבת התקלה.
- מודול קישור עובד לבורסה: חיבור, טיפול במגבלות תדירות בקשות, ניסיונות חוזרים, שחזור זרם נתוני שוק לאחר ניתוק.
- תצורות: פרמטרים של אסטרטגיות, רשימת זוגות מסחר, מגבלות נפח וסיכון — נערכים בלי הרכבה מחדש ובלי הפעלה מחדש של קו המסחר.
- סכימות זרימות: כיצד אות הופך לפקודה, היכן מושווים פוזיציות ויתרה, אילו אירועים נכנסים ליומן.
- מדיניות גישה למפתחות: הרשאות מסחר בלי משיכת כספים, מפתחות נפרדים לקו בדיקה ולקו ייצור, רוטציה ואחסון במאגר סודות מאובטח.
- תיעוד אינטגרציה: ייעוד המתודות, פורמטי תגובות, קודי שגיאה והתנהגות המערכת בעת כשלים בצד הבורסה.
- נוהל שחזור: סדר פעולות שלב אחר שלב בעת ניתוק חיבור, עצירת הבוט ופער בפוזיציות, עם נקודות השוואה מפורשות.
- סט בדיקות קבלה: תרחישים שבהם אתם משתכנעים בעצמכם שלאחר כל שינוי קו המסחר עובד כשורה.
כל ארטיפקט מלווה ברשומה קצרה בתיעוד הכללי: לשם מה הוא נחוץ, מה יישבר בשינוי שלו ולאן להסתכל קודם.
מקרה בוחן: צמצמנו השהיית תגובה והסרנו כפילות פקודות
המודול עבד עם Bitget דרך בקשות תקופתיות ל-API: מצב הפקודות והיתרה נסקרו פעם בכמה שניות. בתנועת מחיר חדה זה יצר השהיית תגובה של עד שתי שניות, וניתוק חיבור קצר הוביל לשליחה חוזרת של פקודות שכבר התקבלו — ביומן הופיעו כפילויות ופוזיציות לא מתוכננות שהיה צריך לפרק ידנית.
מה שינינו
את הקישור העברנו לערוצי זרם: ספר פקודות מקומי עם בקרת מספרים סידוריים ופיד אירועים פרטי לפי פקודות ועסקאות במקום סקר תקופתי. כל פקודה מקבלת מזהה לקוח משלה, שנרשם ביומן לפני השליחה, — חזרה עם אותו מפתח נדחית על ידי הבורסה ככפילות ולא מבוצעת פעם שנייה.
מה התוצאה
השהיית התגובה הצטמצמה מ-1.5–2 שניות לשברי שנייה — המודול מספיק לבטל פקודה לפני שהשפל פוגע בה. שיעור הכפילויות ירד לאפס, ופירוקי תקלות ידניים פסקו. השחזור לאחר ניתוק ערוץ אורך 2–4 שניות ומתבצע בלי מעורבות מפעיל: המודול מושך תמונת מצב, משווה אותה ליומן ושולח מחדש רק אירועים שאבדו.
מספר העצירות בגלל פער בין המצב המקומי למצב הבורסה הצטמצם פי כמה: קודם כל פער דרש השוואה ידנית והפעלה מחדש.
במה זרם אירועים שונה מבקשות ישירות ומה לבחור?
בקשה ישירה — סכימה סינכרונית: הלקוח מחליט בעצמו מתי לשאול. התשובה מעודכנת לרגע קבלתה, ומכאן הנתונים מתיישנים בדיוק לפי מרווח הסקר. כדי לתפוס תנועת מחיר בתוך שנייה יהיה צורך לסקור כל מכשיר פעם בשנייה — ולהתקל במגבלות תדירות, ולקבל סירוב במקום נתונים.
זרם אירועים הופך את המודל: השרת עצמו שולח שינויים לפי מנוי, והשהיית העדכון נקבעת לפי זמן המסירה ולא לפי קצב הסקר. המחיר לכך הוא ניהול מצב החיבור: ניתוקים, רצפים חסרים, שחזור לאחר תקלה וסינון הודעות מיושנות.
בפועל סכימה טהורה נדרשת לעתים רחוקות. תמונת מצב מלאה של הספר נלקחת בבקשה ישירה בהתחלה ולפי לוח זמנים, הזרם מיישם עליה שינויים, ובעת ניתוק לוקחים תמונה מחדש וממשיכים מנקודה נקייה. היברידי כזה נותן רעננות של זרם וצפיות של בקשות ישירות.
קריטריון הבחירה פשוט: נתונים שמשתנים כל הזמן וחשובים ברגע — זרם; ספרי עזר, היסטוריה, מגבלות מכשיר — בקשות ישירות. Bitget מספק את שתי הסכימות ב-API אחד, ולכן את הארכיטקטורה מכתיבה האסטרטגיה ולא נוחות החיבור.
בנפרד בודקים התנהגות בעת דעיכה: הרשת נעלמה, הזרם שותק, והאסטרטגיה ממשיכה לחשב. כאן נדרשת בקרת רעננות — אם תמונת המצב ישנה מהסף שהוגדר, המסחר נעצר ולא עובד על שערים מיושנים.
ספקות טכניים: מגבלות, סירובים, אבטחת מפתחות
לפני ההתחלה בדרך כלל עולים אותם שאלות: האם נתקל במגבלת תדירות בקשות, מה יקרה בעת תקלה בבורסה או ברשת, עד כמה מפתחות הגישה מוגנים וכיצד להגביל את הרשאות הבוט. להלן כיצד זה נפתר בארכיטקטורה, ולא בתיאור.
כיצד הבוט נכנס למגבלות הבורסה?
הבורסה מחשבת משקל של כל בקשה בתוך חלון זמן, ובחריגה היא מסרבת לכל הקריאות ברצף — כולל הדחופות. לפני הלקוח שמים מגביל עם תור ושומרים מרווח עד הגבול; נתוני שוק עוברים בזרם WebSocket, ובבקשות — רק הצבה וביטול של פקודות.
מה קורה בעת ניתוק חיבור או קריסת תהליך?
כל פקודה נשלחת עם המזהה שלה, ולכן חזרה לאחר ניתוק אינה יוצרת כפילות. לאחר השחזור הבוט לא משלים את המצב מהדמיון, אלא קורא מחדש פוזיציות ויתרה מהבורסה. בעת סדרת שגיאות רצופה מופעלת הגנה: מעבר למצב קריאה בלבד בלי פקודות חדשות.
היכן נשמרים מפתחות הגישה ומי רואה אותם?
סודות אינם נמצאים בקוד ואינם שכנים ללוגיקה: מאגר נפרד, גישה לפי תפקידים, יומן פניות. המפתח מונפק רק למסחר, בלי זכות למשיכת כספים, עם הצמדה לכתובות מורשות. רוטציה ושלילה — לפי נוהל, והיומנים מנוקים מכותרות אימות.
האם אפשר לצמצם את הרשאות הבוט עצמו?
כן. עבור הבוט פותחים תת-חשבון נפרד: רשימת מכשירים מוגבלת, תקרת גודל פוזיציה, סטופ יומי לפי הפסד ומגבלת פקודות בדקה. שגיאה בלוגיקת האסטרטגיה נשארת שגיאה של האסטרטגיה, ולא סיכון לכל החשבון.
נדבר על המשימה: מה להכין להערכה ולתוכנית עבודה
כדי לחזור עם הערכה ותוכנית, ולא עם שאלות הבהרה בעוד שבוע, אנחנו צריכים נתוני פתיחה בארבעה צירים: מה כבר עובד, אילו תרחישים הבוט משרת, כיצד הוא מקבל גישה לבורסה ואילו סירובים נחשבים בלתי קבילים.
ככל שנתוני המקור קונקרטיים יותר, כך ההערכה לפי לוחות זמנים והיקף מדויקת יותר — ופחות תיקונים באמצע העבודה. להלן מה לשלוח במייל או מה ניקח יחד בסקירה קצרה.
- מודול נוכחי: מאגר או ארכיון עם קוד, באיזו שפה נכתב, היכן נמצאים מפתחות הגישה וכיצד הבוט מופעל כיום — ידנית, לפי לוח זמנים או כשירות. זה מספיק כדי להבין את היקף השדרוג, ולא את הכתיבה מחדש מאפס.
- תרחישי מסחר: זוגות עבודה, סוגי פקודות, לוגיקת כניסה ויציאה, קיום אסטרטגיות רשת או ממוצעות, מגבלות יומיות לפי סיכון ועומס סימולטני מקסימלי.
- מצב גישה לבורסה: רק קריאת נתוני שוק או פעולות מסחר דרך מפתחות, אילו הרשאות הוענקו, האם יש קו בדיקה ואילו מגבלות תדירות בקשות אנחנו חייבים לכבד.
- דרישות לעמידות בתקלות: מה לעשות בעת ניתוק חיבור — לחשב מחדש פוזיציה, לחזור על פקודה או לעצור את המסחר; לאן נכתב יומן האירועים וכיצד התורן לומד על תקלה.
- תשתית אירוח: היכן הבוט יחיה, מי אחראי על השרת והעדכונים, אילו חיבורים יוצאים מותרים בקו שלכם.
- קריטריוני קבלה: לפי אילו מדדים אנו מחשיבים את העבודה להשלים — פער פוזיציות מול הבורסה, היעדר פקודות תקועות, זמן שחזור לאחר תקלה.
- סדר אינטראקציה: עם מי מתאמים שינויים, באיזה ערוץ מתנהלת התכתבות, כיצד מעבירים הרשאות ובאיזו תדירות מציגים תוצאה ביניים.