כיצד התראות פוש של בוט מסחר מגיעות באופן מיידי

מדוע התראות push של בוט מסחר מגיעות באיחור

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

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

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

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

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

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

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

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

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

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

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

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

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

דרכי מסירה: השוואת אפשרויות אינטגרציה

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

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

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

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

איך אנחנו בונים את מסירת התראות ה-push של בוט המסחר

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

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

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

תצורות, תרשימים ונהלים בתוצר הסופי

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

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

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

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

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

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

מדדנו את המדדים לפני השינויים: השהיית מסירה ממוצעת של אות — כ-12 שניות, בעומסי שיא — עד 40. שיעור האותות שנמסרו לאחר 5 שניות עמד על 18%. בנפרד ספרנו את שיעור ההתראות שאבדו — המערכת לא הבחינה אם ההודעה הגיעה למכשיר או נשארה בתור.

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

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

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

השהייה קוצרה פי 4, ושיעור האותות המאוחרים ירד ביותר מפי ארבעה. הסוחר מקבל את האות בעודו סחיר, והצוות רואה את הירידה במסירה לפי גרף, ולא לפי תלונות.

במה שונה התראת push מהודעת in-app?

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

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

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

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

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

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

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

ספקות טכניים ותשובות מהנדסים

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

מדוע מערכת חיסכון הסוללה «הורגת» התראות וכיצד זה נעקף?

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

מה קורה אם המשתמש נכנס ממספר מכשירים?

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

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

עד כמה מאובטחת העברת נתוני מסחר בהתראות?

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

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

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

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

מה שמועיל לצרף לתיאור המשימה:

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

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