שדרוג OKEx ברק 2.0

מערכת מסחר מהדור הבא המספקת ביצועים מהירים יותר

I. פיתוח מערכת המסחר האלקטרוני

דרישות גוברות לטכנולוגיות הליבה של סחר בנכסים שיקפו את הצמיחה המהירה של התעשייה הפיננסית העולמית במחצית הראשונה של המאה ה -20. בשנות ה -50 קונים ומוכרים נסחרים במשא ומתן ומחירי השאלות נרשמו באופן ידני על הנייר. על רקע סוגי ניירות ערך מגוונים ונפח המסחר העולה, דרך זו להתמודד עם הצעות מחיר יצרה בהדרגה משבר ניירת במהלך שנות ה 60-70 בגלל חוסר היעילות והעלות הגבוהה שלה. לבורסת ניו יורק (NYSE) לא נותרה אלא להפסיק את המסחר בכל יום רביעי ולקצץ שעות בימי מסחר אחרים כדי להגביל את פעילותה. עם יכולתם ללא תחרות לעבד מספר עצום של עסקאות בו זמנית, המחשבים החלו להיכנס לשחק. תהליך ללא נייר, או מהפכה אלקטרונית, היווה נקודת מפנה מכרעת בהיסטוריה הפיננסית העולמית. עסקאות עברו לפלטפורמות מסחר אלקטרוניות, והציעו פעולות מהירות וזולות יותר ללא זמן או חסמים גיאוגרפיים.

המשבר ללא נייר בארה”ב בשנות ה -70

ברחבי העולם צצו מערכות מסחר אלקטרוניות, כולל Currenex של סטייט סטריט, INET של HKEX, EBS Spot Ai של ICAP ו- LIFE CONNECT של LIFFE. מכיוון שנכסי קריפטו קיימים בצורה אלקטרונית בלבד, הם קשורים באופן טבעי לפלטפורמות מסחר אלקטרוניות, אך הדרישות למסחר קריפטו ומערכות מסחר מסורתיות שונות במקצת. בסך הכל, מערכת מסחר בקריפטו צריכה להיות בעלת המאפיינים הבאים:

א. זמן אחזור ותפוקה גבוהה

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

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

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

ב. יכולת תחזוקה ומדרגיות

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

II. מערכת ברקים של OKEx 2.0: ביצועי Lightspeed

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

מסגרת שדרוג ברק 2.0

1. שינון

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

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

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

יתר על כן, יחידות עיבוד מרכזיות מודרניות (מעבדים) ניגשות לנתונים בזיכרון במהירות נמוכה מהצפוי. על פי א מִבְחָן, לוקח רק 1/7 זמן לאחזר נתונים מהמטמון L2 של מעבד בהשוואה לטכניקת ההתאמה בזיכרון. על מנת לצמצם עוד יותר את ההשהיה, חשוב להבין כיצד לעשות שימוש טוב במטמון המעבד. יחידת העברת הנתונים היא קו המטמון, שהוא בדרך כלל 64 בתים. בעוד שהמעבד טוען נתונים בזיכרון, הוא מעביר נתונים סמוכים ב -64 בתים למטמון. בהתאם לכך, ביצענו את השיפורים הבאים במערכת הברק שלנו על ידי שליטה בהפצת נתוני הזיכרון:

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

2. מודל פרסום – מנוי ופרוטוקול בינארי

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

השוואה בין ברק 1.0 לברק 2.0

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

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

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

שני סוגים נפוצים של פורמטים של הודעות: מבוסס טקסט & בינארי

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

3. קנה מידה אופקי

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

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

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

4. שינוי גודל המערכת

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

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

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

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

III. ביצועי נתונים של ברק 2.0

השלמנו שדרוג מקיף של מערכת ה- Lightning 2.0 במחצית השנייה של 2019. כיצד השתפרו הביצועים בהשוואה ל- Lightning 1.0?

הנה הנתונים הסטטיסטיים האחרונים של בדיקת השרתים שלנו בהונג קונג בנובמבר:

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

שלושת האינדיקטורים הבאים משמשים לבדיקת זמן ההשהיה של המערכת:

שלושה אינדיקטורים נפוצים לבדיקת חביון: ACK, Live ו- Cancel

השתמשנו בנתוני בדיקה מספטמבר ונובמבר כדי להשוות את הביצועים לפני השדרוג ואחרי השדרוג של מערכת המסחר שלנו (ראה להלן). כפי שצוין להלן, חביון ה- ACK הממוצע ירד מ- 50 אלפיות השנייה ל- 25 אלפיות השנייה, זמן ההשהיה הממוצע של Live עבר מ- 134 אלפיות השנייה ל- 63 אלפיות השנייה, והממוצע של ביטול ההשהיה הצטמצם מ- 230 אלפיות השנייה ל- 180 אלפי שניות.

זה מראה שלמערכת המסחר שלנו ברק 2.0 יש חביון נמוך יותר.

לפני השדרוג / לאחר השדרוג

IV. מובילה בתעשייה בתחום הטכנולוגיה

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

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

עקוב אחר OKEx ב:

סטמיט: https://steemit.com/@okex-official

אתר: https://www.okex.com

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Social Links
Facebooktwitter
Promo
banner
Promo
banner