VPS Bot Dagangan: Perkara Yang Sebenarnya Penting

Keperluan bot dagangan daripada VPS

VPS untuk bot dagangan dinilai berdasarkan empat perkara: adakah proses kembali berjalan selepas terhenti, adakah masa sistem tepat, adakah kunci API (antara muka pengaturcaraan aplikasi) sukar dicuri, dan adakah anda mengetahui apabila proses itu berhenti. Kelajuan mentah berada jauh di bawah senarai itu bagi bot runcit, kerana bahagian laluan pesanan anda yang paling perlahan ialah broker anda dan jarak kepadanya, bukannya hos yang menjalankan Python.

Ini ialah panduan kejuruteraan. Kandungan ini bukan nasihat kewangan, dan tiada strategi dibincangkan.

Masa aktif ialah disiplin mulakan semula, bukan angka pada halaman jualan

Setiap hos di dunia mengiklankan masa aktif 99.9 peratus. Angka itu menerangkan hypervisor, bukan bot anda. Bot terhenti akibat pengecualian yang tidak dikendalikan, websocket yang tidak pernah bersambung semula atau pembunuh OOM (kehabisan memori), manakala pelayan kekal aktif sepanjang masa. Jadi, soalan yang berguna ialah perkara yang berlaku dalam tempoh sepuluh saat selepas proses anda terhenti.

Jalankan bot sebagai perkhidmatan systemd dan biarkan sistem init mengurus mulakan semula. Fail unit melakukan perkara ini dalam enam baris.

[Unit]
Description=Trading bot
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=0

[Service]
Type=simple
User=bot
WorkingDirectory=/opt/tradingbot
EnvironmentFile=/etc/tradingbot/api.env
ExecStart=/opt/tradingbot/venv/bin/python -m tradingbot
Restart=always
RestartSec=10
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/tradingbot

[Install]
WantedBy=multi-user.target

StartLimitIntervalSec=0 ialah baris yang sering terlepas pandang. Secara lalai, systemd berhenti mencuba selepas 5 kali mula semula dalam tempoh 10 saat dan membiarkan unit dalam keadaan failed selama-lamanya. Tingkah laku ini tidak diingini pada 03:00. Menetapkannya kepada 0 melumpuhkan had kadar, jadi bot yang terus mengalami gelung ranap akan terus mencuba dan bukannya terhenti tanpa bunyi. RestartSec=10 menghentikan gelung itu daripada membebankan bursa dengan percubaan sambungan semula.

Semak fail itu sebelum mempercayainya, kemudian mulakannya:

sudo systemd-analyze verify /etc/systemd/system/tradingbot.service
sudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
systemctl status tradingbot

enable ialah bahagian yang kekal selepas mula semula, dan kemas kini kernel memerlukan mula semula. Untuk melihat sama ada bot telah terhenti secara senyap, minta systemd memaparkan kaunter mula semula:

systemctl show tradingbot -p NRestarts
journalctl -u tradingbot --since "24 hours ago" | tail -50

NRestarts=0 selepas seminggu menunjukkan bot yang sihat. NRestarts=812 bermaksud anda telah berdagang menggunakan proses yang bersambung semula sepanjang malam. Anatomi lengkap fail unit, termasuk pemasa untuk tugas berjadual seperti laporan harian, diterangkan dalam menjalankan program sebagai perkhidmatan systemd.

Tetapkan jam kepada UTC dan sahkan bahawa ia disegerakkan

API bursa menandatangani permintaan dengan cap masa dan menolak permintaan yang berada di luar tetingkap, selalunya 5 saat atau kurang. Jam yang menyimpang menghasilkan ralat yang kelihatan seperti kegagalan pengesahan. Oleh itu, pengguna mungkin menukar key selama berjam-jam sebelum menyemak waktu. Pada API gaya Binance, mesejnya adalah literal: Timestamp for this request was 1000ms ahead of the server's time.

Tetapkan pelayan kepada UTC. Zon waktu tempatan boleh menyebabkan perubahan waktu musim panas yang berlaku pada pertengahan sesi dagangan.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu disertakan dengan systemd-timesyncd, iaitu klien SNTP (simple network time protocol). Klien ini memadai untuk log, tetapi kurang sesuai untuk apa-apa yang perlu kekal dalam julat beberapa milisaat kerana ia meninjau satu pelayan dan tidak melaraskan jam secara berterusan. Sebaliknya, gunakan chrony:

sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony
chronyc tracking
chronyc sources -v

Baris yang perlu dibaca daripada chronyc tracking ialah System time, contohnya System time : 0.000031415 seconds fast of NTP time. Nilai di bawah beberapa milisaat adalah sihat. Jika nilainya Leap status : Not synchronised, chrony belum berjaya mencapai pelayan, biasanya kerana UDP 123 keluar disekat. Tunggu seminit, kemudian semak sekali lagi sebelum mengubah peraturan firewall.

Jangan letakkan kunci API di tempat yang anda salin

Kunci bursa yang bocor lebih berbahaya daripada kunci SSH yang bocor kerana kebenaran pengeluaran boleh menukarkannya kepada wang dengan serta-merta. Dua amalan dapat mengurangkan kebanyakan risiko.

Pertama, jangan berikan kebenaran pengeluaran kepada kunci bot. Jika bursa menyokongnya, hadkan kunci kepada alamat IP pelayan anda. Kawalan ini paling berkesan untuk menjadikan kunci yang dicuri hampir tidak berguna.

Kedua, jangan simpan rahsia dalam direktori kod. Apa-apa sahaja dalam /opt/tradingbot lambat-laun akan masuk ke repositori git atau arkib sandaran. Letakkannya dalam fail milik root yang hanya dibaca oleh systemd:

sudo install -d -m 750 -o root -g bot /etc/tradingbot
sudo install -m 640 -o root -g bot /dev/null /etc/tradingbot/api.env
sudo nano /etc/tradingbot/api.env

Fail ini mengandungi baris KEY=value biasa tanpa tanda petikan dan tanpa export. Mod 640 dengan kumpulan bot membolehkan pengguna perkhidmatan membacanya dan menghalang pengguna lain daripada berbuat demikian. Sahkan dengan sudo -u bot cat /etc/tradingbot/api.env, kemudian cuba dengan pengguna lain. Percubaan itu mesti gagal dengan Permission denied.

Bot itu sendiri tidak sepatutnya berjalan sebagai root atau sebagai pengguna log masuk anda. Cipta akaun sistem tanpa shell dan tanpa direktori home untuk digunakan semasa log masuk:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /var/lib/tradingbot --create-home bot

Sebab bagi setiap flag tersebut, serta sejauh mana ProtectSystem=strict benar-benar berfungsi, diterangkan dalam menjalankan perkhidmatan sebagai pengguna tanpa keistimewaan. Konfigurasi asas pelayan yang selebihnya, iaitu kunci SSH dan firewall, diterangkan dalam sepuluh minit pertama pada VPS baharu.

Ketahui sistem terhenti sebelum broker anda mengetahuinya

systemctl status menunjukkan bahawa proses sedang berjalan. Ia tidak menunjukkan bahawa bot sedang melakukan apa-apa. Proses yang tersekat dalam gelung percubaan semula terhadap websocket yang tidak lagi berfungsi akan lulus semua pemeriksaan yang boleh dilakukan oleh systemd.

Sebaliknya, gunakan degupan jantung. Uptime Kuma mempunyai monitor push: ia menjangka bot anda memanggil URL mengikut jadual dan memberikan amaran apabila panggilan itu tidak lagi diterima. Letakkan panggilan tersebut pada penghujung gelung utama, selepas bahagian yang membuktikan bot masih hidup, seperti bacaan data pasaran yang berjaya.

curl -fsS "http://monitor.example.com:3001/api/push/YOUR_TOKEN?status=up&msg=loop_ok"

Tetapkan selang monitor kepada kira-kira dua kali tempoh gelung supaya turun naik biasa tidak mencetuskan halaman amaran. Jalankan monitor pada pelayan yang berbeza daripada bot, kerana monitor yang terhenti bersama perkara yang dipantaunya tidak akan melaporkan apa-apa. Persediaan diterangkan dalam pemantauan status yang dihos sendiri dengan Uptime Kuma.

Tambahkan amaran cakera juga. Bot yang menulis log terperinci akan memenuhi sistem fail root dalam beberapa minggu, dan cakera yang penuh akan menghentikan penulisan pangkalan data, bukan panggilan rangkaian. Oleh itu, gejalanya kelihatan pelik. journalctl --vacuum-time=14d dan baris SystemMaxUse= dalam /etc/systemd/journald.conf memastikan journal kekal dalam had.

Bahagian yang jujur: kependaman kebanyakannya bukan disebabkan oleh hos anda

Di sinilah pasaran produk VPS untuk perdagangan tidak lagi bersifat teknikal. Halaman pemasaran memetik angka di bawah satu milisaat dan memberi gambaran bahawa hos ialah faktor yang memisahkan anda daripada pelaksanaan pesanan. Bagi hampir semua bot runcit, perkara itu tidak benar.

Pesanan anda bergerak daripada bot ke titik akhir bursa atau broker melalui internet awam. Laluan itu banyak dipengaruhi oleh jarak fizikal dan hubungan peering antara penyedia anda dengan penyedia mereka. Pelayan di Frankfurt yang berkomunikasi dengan titik akhir di Tokyo mempunyai masa pergi balik kira-kira 250 milisaat, tanpa mengira kelajuan CPU. Kemudian, sistem broker sendiri menambah masa untuk giliran, pemeriksaan risiko dan had kadar. Bagi akaun runcit, masa ini biasanya diukur dalam puluhan atau ratusan milisaat.

Buat pengukuran dan jangan membuat andaian. curl melaporkan masa sambungan dan masa bait pertama untuk titik akhir sebenar:

curl -s -o /dev/null -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s\n' \
  https://api.kraken.com/0/public/Time
mtr -rwzc 100 api.kraken.com

Jalankan perintah itu daripada pelayan calon sebelum membuat keputusan. Jika connect ialah 0.180 saat, anda berada di benua yang salah dan perkara itu wajar diperbaiki. Jika connect ialah 0.004 saat dan ttfb ialah 0.140 saat, kelewatan yang selebihnya datang daripada pemprosesan broker dan perubahan hos tidak akan mengurangkannya.

Jadi, bilakah hos penting? Apabila anda ditempatkan bersama atau disambungkan terus kepada venue dan bersaing untuk kedudukan dalam giliran. Ini ialah perniagaan yang berbeza dengan belanjawan yang berbeza. Hos juga penting apabila kod anda sendiri menjadi kesesakan. Bot yang mengira semula penunjuk berdasarkan keseluruhan sejarah pada setiap tick boleh menggunakan 200 milisaat masa CPU bagi setiap gelung. Itulah kependaman sebenar yang boleh anda kawal tanpa kos. Buat profil terhadap gelung itu sebelum mencari pelayan yang lebih pantas.

Faktor yang penting dalam pemilihan hos ialah lokasi geografi, rangkaian yang stabil dan memori yang mencukupi supaya OOM killer tidak pernah perlu bertindak. Setakat July 2026, bot Python dengan satu strategi dan beberapa ratus simbol dalam memori boleh berjalan dengan baik menggunakan 2 GB RAM dan 2 vCPU. Tambah memori jika anda menyimpan sejarah tick dalam pangkalan data setempat.

Senarai semak ringkas sebelum pelancaran

1. systemctl is-enabled tradingbot mencetak enabled, dan perkhidmatan terus berjalan selepas sudo reboot.
2. chronyc tracking melaporkan perbezaan masa sistem kurang daripada beberapa milisaat.
3. Kunci API mempunyai kebenaran dagangan, tanpa kebenaran pengeluaran, serta senarai benarkan IP jika bursa menyediakannya.
4. Menghentikan proses dengan sudo systemctl kill -s SIGKILL tradingbot menyebabkan proses itu berjalan semula dalam tempoh RestartSec.
5. Pemantau denyutan memaklumkan anda dalam satu selang apabila anda menghentikan bot dengan sengaja.
6. Log mempunyai had saiz, dan sistem fail root mempunyai ruang lebihan dalam df -h.

Jalankan keseluruhan sistem dalam sandbox bursa atau dalam mod kertas selama seminggu sebelum menggunakan dana sebenar. Setiap item di atas akan gagal sekurang-kurangnya sekali dalam tempoh seminggu itu. Itulah tujuan tempoh seminggu tersebut.

FAQ

Adakah bot dagangan memerlukan pelayan kependaman rendah atau bare metal?

Hanya jika anda bersaing dari segi kelajuan pelaksanaan dengan peserta automatik lain di tempat dagangan yang sama. Dalam keadaan itu, colocation biasanya lebih sesuai berbanding VPS serba guna. Bagi bot runcit, masa pergi balik banyak dipengaruhi oleh lokasi geografi dan pemprosesan broker sendiri. Oleh itu, pilih pelayan yang dekat dengan titik akhir API dan buat pengukuran menggunakan curl dan mtr sebelum membayar perkhidmatan yang lebih pantas.

Berapa banyak RAM dan CPU yang diperlukan oleh bot dagangan?

Kebanyakan bot dengan satu strategi terikat pada rangkaian dan tidak aktif antara kejadian. Setakat Julai 2026, 2 vCPU dan 2 GB RAM mencukupi untuk bot Python yang menjejaki beberapa ratus instrumen. Memori menjadi kekangan apabila anda menyimpan sejarah tick dalam proses atau menjalankan pangkalan data setempat. Oleh itu, pantau free -h dan jurnal untuk mesej OOM kill, bukannya membuat anggaran.

Mengapakah API bursa saya menolak permintaan dengan ralat cap masa?

Jam pelayan telah tersasar di luar tetingkap tandatangan bursa, biasanya beberapa saat. Pasang chrony, sahkan bahawa chronyc tracking menunjukkan offset System time yang kecil serta status leap yang disegerakkan, dan tetapkan mesin kepada UTC supaya perubahan waktu musim panas tidak mengubah masanya. Menukar API key tidak menyelesaikan masalah jam.

Bagaimanakah saya boleh menghalang bot daripada terhenti semalaman tanpa saya sedari?

Jalankan bot di bawah systemd dengan Restart=always dan StartLimitIntervalSec=0 supaya gelung ranap terus mencuba semula dan tidak berhenti secara kekal. Kemudian, tambahkan heartbeat yang dihantar oleh bot pada akhir setiap gelung yang berjaya. Mekanisme mula semula mengendalikan proses tersebut. Heartbeat mengesan keadaan apabila proses masih hidup tetapi tersekat.

Bolehkah saya menjalankan bot dan pemantauan saya pada VPS yang sama?

Boleh, tetapi pemantauan itu akan memberikan maklumat yang salah pada hari ia paling diperlukan. Gangguan yang menyebabkan bot terhenti juga akan menyebabkan pemantauan terhenti. Simpan sistem amaran pada mesin berasingan, sebaik-baiknya dengan penyedia atau rantau yang berbeza, dan gunakan pelayan bot hanya untuk bot serta lognya.