ساختن یک سکوی تجارت الگوریتمی در زنگ زدگی

تقریباً یک سال است که من در حال ایجاد یک بستر معاملاتی الگوریتمی هستم که می توانم از آن برای ایجاد استراتژی های خودکار برای تجارت استفاده کنم. این به عنوان یک آزمایش شروع شد - فقط یک ایده کوچک سرگرم کننده که می توانم آن را کشف کنم ، اما به سرعت در یک پروژه در مقیاس کامل منفجر شد که من صدها ساعت ریختم.

من در حال حاضر در نسخه 4 پلتفرم هستم. نسخه های 1 ، 2 و 3 کاملاً جدا از هم بودند ، هر یک از آنها از ابتدا دوباره نوشتند و معمولاً از یک زبان ، ایده یا مفهوم طراحی متفاوت از نمونه قبلی استفاده می کردند. من از این تلاشهای ناکام چیزهای زیادی آموختم و معتقدم که آنها بخش مهمی از پیشرفت من به سمت آنچه اکنون دارم.

اگر بیشتر به سمت فنی علاقه مندید که چگونه از زنگ زدگی استفاده کردم تا این همه ممکن باشد ، به بخش فنی بروید.

تکرار فعلی این سکو در درجه اول در زنگ زدگی نوشته شده است. من آن را به دلیل ویژگی های قابل تحسین سرعت و دوام انتخاب کردم که هر دو برای یک محیط تجاری خودکار بسیار مهم هستند.

این پلتفرم از چندین ماژول به هم پیوسته تشکیل شده است که تقریباً مانند میکروسرویس ها عمل می کنند. پردازنده (های) Tick وظیفه پردازش داده های زنده از بازار را در قالب کنه ها دارند. کنه ها اساساً فقط قطعات کوچکی از داده ها هستند که به سیستم عامل حاوی حداقل یک زمان سنج (معمولاً دقیق به میکرو ثانیه) ، نماد دارایی و پیشنهاد و پیشنهاد و قیمت می پردازند. پردازنده های Tick برای این به روزرسانی قیمت ها گوش می دهند و مجموعه ای از شرایط را که توسط Optimizer تعیین شده است ، ارزیابی می کنند. اگر این شرایط برآورده شود ، آنها با باز ، بسته شدن یا تغییر موقعیت با کارگزار اقدام می کنند.

بهینه ساز تقریباً مغز سکو است. این داده ها را از انواع مکان ها (به روزرسانی های قیمت خام ، شاخص ها ، الگوریتم های یادگیری ماشین و غیره) ارزیابی می کند و از آنها برای تعیین شرایط باید در پردازنده های کنه استفاده کند.

دو ماژول آخر که پلت فرم فعلی را تشکیل می دهند ، SPAWNER/MANAGER و MM هستند. Spawner مسئول پیگیری همه موارد در حال اجرا و تخم ریزی/کشتن آنها در صورت لزوم است. این نقطه ورود به سیستم عامل است و اولین کاری که پس از اولیه سازی انجام می دهد ، تخم ریزی یک نمونه MM است.

MM ماژول رابط انسانی پلت فرم است. این مخفف برای مدیریت/نظارت است و به کاربر اجازه می دهد تا از فعالیت های شروع معاملات ، شروع به کار ، وضعیت پلتفرم را مشاهده کرده و نمودارهایی را برای شاخص های داخلی پلتفرم و اطلاعات قیمت زنده ایجاد کند.

These instances communicate with a custom protocol built on top of Redis PubSub and use a PostgreSQL database as a main storage system. The entire system is built to offload computationally expensive operations away from the actual trading systems in order to keep the data>زمان عمل تا حد ممکن کم است.

یکی از مهمترین مواردی که هنگام طراحی این نسخه از این پلتفرم در نظر گرفتم ، برنامه نویسی ناهمزمان بود. با توجه به یک پیش زمینه مبتنی بر NodeJS ، من به روش وعده/پاسخ به برنامه نویسی با عملیات مسدود کننده که در پس زمینه اتفاق می افتد با برنامه رایگان برای انجام کارهای دیگر علاقه مند شدم ، در حالی که به عنوان مثال منتظر پاسخ دادن به پایگاه داده است.

من در هر جنبه ای از توسعه من در اینجا بسیار گسترده از جعبه های Futures-rs استفاده می کنم. همه چیز از پرس و جوهای پایگاه داده گرفته تا پردازش داده ها تا پروتکل ارتباطی بین مدلی در بالای آینده ساخته شده و به گونه ای طراحی شده است که ناهمزمان باشد.

Futures-RS چندین شیء ابزار را فراهم می کند که عملکرد آینده و جریان را گسترش می دهد تا استفاده از آنها در موقعیت های تخصصی آسان تر شود. به عنوان مثال ، عملکرد فرستنده و گیرنده به عنوان نقاط پایانی در یک کانال که می تواند برای برقراری ارتباط داده ها بین دو موضوع استفاده شود. آنها شبیه به کانال سنتی MPSC Rust هستند اما جریان ها را گسترش می دهند و امکان استفاده از آنها به صورت غیر همزمان امکان پذیر است. در اینجا بخشی از اجرای من از عملکردی است که تمام پیام های دریافت شده از طریق یک کانال Redis را از طریق یک کانال Futures ارسال می کند:

/// گیرنده ای را که به پیام های جدید دریافت شده در یک کانال PubSub برطرف می شود ، برمی گرداند میخانه fn کانال فرعی(میزبان: &str,کانال PS_CHANNEL: &استاتیک str) > گیرندهرشته, ()>  اجازه دهید (tx,RX) = کانال::رشته, ()>(); اجازه دهیدPS= get_pubsub(میزبان,کانال PS_CHANNEL); اجازه دهید کلهnew_tx=TX; نخ::تخم مرغ(حرکت ||  در حالی که اجازه دهید Ok(_new_tx) = get_message_outer(new_tx, &ps) new_tx=_new_tx; > println!("اشتراک کانال منقضی شد"); >);RX>

این یک کانال جدید ایجاد می کند که رشته ها را می پذیرد و نمونه ای از شنونده PubSub را ایجاد می کند. سپس موضوع جدیدی را ایجاد می کند که به طور دائم در انتظار دریافت پیام از طریق کانال PubSub مسدود شده و پس از دریافت پیام ، آن را از طریق کانال ارسال می کند.

نکته مهمی که باید در مورد فرستنده Futures-RS به آن توجه داشته باشید این است که پیام های ارسال شده بر روی آنها باید قبل از ارسال دیگری مصرف شوند. در حقیقت ، عملکرد Stream. send () فرستنده را مصرف می کند و آینده ای را ارائه می دهد که پس از دریافت گیرنده مربوطه پیام ، به فرستنده جدید برطرف می شود. در کد من ، GET_MESSAGE_OUTER () تماس می گیرد. WAIT () در آینده تولید شده از Send (). صبر کنید () تا زمانی که آینده را حل کند که خوب کار می کند ، مسدود می شود زیرا تنها هدف از این موضوع ، استفاده از تماس های عملکرد مسدود کردن است و به طور غیر همزمان نتایج را برای پردازش به موضوع اصلی ارسال می کند.

من از این روش استفاده از مسدود کردن عملیات در موضوعات کارگر و برقراری ارتباط نتایج آنها به صورت غیر همزمان در سراسر پلتفرم خود استفاده می کنم. برای برقراری ارتباط بین مدلی ، باید یک زمان زمانی ایجاد کنم که پس از گذشت مدت زمان مشخصی انجام شود. با این حال ، تمام روش های انجام این کار نیاز به نظرسنجی مداوم یک عملکرد مانند get_time یا برای مسدود شدن نخ دارد.

برای غلبه بر این ، من نوعی "سرور زمان" را روی یک موضوع متفاوت تخم ریزی می کنم. من یک دسته را به صورت فرستنده نگه می دارم که می تواند برای ارسال درخواست های زمان بندی استفاده شود. درخواست Timeout شامل مقدار زیادی از زمان خوابیدن و یک Oneshot است که توسط سرور Timeout استفاده می شود تا مشخص شود زمان پایان زمان پایان یافته است (Oneshot S در اصل کانال هایی هستند که فقط پیام را ارسال می کنند).

با زنجیر کردن آینده های آینده و بارگیری عملیات مسدود کننده به موضوعات کارگر ، ایجاد سیستم های واقعاً پیشرفته امکان پذیر است. من طرفدار عظیمی از جعبه های Futures-rs هستم. این واقعاً برای سیستم من یکپارچه است و هدف من از پردازش داده های ناهمزمان و پر سرعت را ممکن می سازد.

من در آینده پست های خاص و عمیق تری برای مؤلفه های فردی این سکو ارائه خواهم داد. امیدوارم این برنامه نویسی را مفید و شاد داشته باشید!