Hola a tots! Em dic Sergey Kostanbaev, a la Borsa estic desenvolupant el nucli del sistema comercial.
Quan les pel·lícules de Hollywood mostren la Borsa de Nova York, sempre es veu així: multitud de gent, tothom crida alguna cosa, agita papers, està passant un caos complet. Això no ha passat mai aquí a la Borsa de Moscou, perquè la negociació s'ha realitzat electrònicament des del principi i es basa en dues plataformes principals: Spectra (mercat de divises) i ASTS (mercat de divises, accions i diners). I avui vull parlar de l'evolució de l'arquitectura del sistema de negociació i compensació ASTS, de diverses solucions i troballes. La història serà llarga, així que la vaig haver de dividir en dues parts.
Som una de les poques borses del món que negocia actius de totes les classes i ofereix una gamma completa de serveis d'intercanvi. Per exemple, l'any passat vam ocupar el segon lloc mundial pel que fa al volum de negociació de bons, el lloc 25 entre totes les borses, el lloc 13 en capitalització entre les borses públiques.
Per als participants professionals del comerç, paràmetres com el temps de resposta, l'estabilitat de la distribució del temps (jitter) i la fiabilitat de tot el complex són crítics. Actualment processem desenes de milions de transaccions al dia. El processament de cada transacció pel nucli del sistema triga desenes de microsegons. Per descomptat, els operadors mòbils de la nit de Cap d'Any o els mateixos cercadors tenen una càrrega de treball superior a la nostra, però pel que fa a la càrrega de treball, unida a les característiques esmentades, pocs es poden comparar amb nosaltres, em sembla. Al mateix temps, és important per a nosaltres que el sistema no s'alentiri ni un segon, funcioni de manera absolutament estable i tots els usuaris estiguin en condicions d'igualtat.
Una mica d'història
L'any 1994, el sistema australià ASTS es va posar en marxa a la borsa de divises interbancari de Moscou (MICEX) i des d'aquest moment es pot comptar la història del comerç electrònic rus. El 1998, es va modernitzar l'arquitectura d'intercanvi per introduir el comerç per Internet. Des d'aleshores, la velocitat d'implementació de noves solucions i canvis arquitectònics en tots els sistemes i subsistemes no ha fet més que agafar força.
En aquells anys, el sistema d'intercanvi funcionava amb maquinari d'alta gamma: servidors HP Superdome 9000 ultra fiables (creats a partir del), en què es duplicava absolutament tot: subsistemes d'entrada/sortida, xarxa, RAM (de fet, hi havia una matriu de RAM RAID), processadors (intercanviables en calent). Era possible canviar qualsevol component del servidor sense aturar la màquina. Vam confiar en aquests dispositius i els vam considerar pràcticament segurs. El sistema operatiu era un sistema HP UX semblant a Unix.
Però des de l'any 2010 aproximadament, ha sorgit un fenomen anomenat comerç d'alta freqüència (HFT) o negociació d'alta freqüència, simplement, robots de borsa. En només 2,5 anys, la càrrega dels nostres servidors ha augmentat 140 vegades.
Era impossible suportar aquesta càrrega amb l'arquitectura i l'equip antics. Calia adaptar-se d'alguna manera.
Начало
Les sol·licituds al sistema d'intercanvi es poden dividir en dos tipus:
- Transaccions. Si voleu comprar dòlars, accions o una altra cosa, envieu una transacció al sistema de comerç i rebeu una resposta sobre l'èxit.
- Sol·licituds d'informació. Si voleu conèixer el preu actual, consulteu el llibre de comandes o índexs i, a continuació, envieu sol·licituds d'informació.
Esquemàticament, el nucli del sistema es pot dividir en tres nivells:
- El nivell de client, on treballen els corredors i clients. Tots interactuen amb els servidors d'accés.
- Els servidors de passarel·les són servidors de memòria cau que processen localment totes les sol·licituds d'informació. Vols saber a quin preu es cotitzen actualment les accions de Sberbank? La sol·licitud va al servidor d'accés.
- Però si voleu comprar accions, la sol·licitud es dirigeix al servidor central (Trade Engine). Hi ha un servidor d'aquest tipus per a cada tipus de mercat, juguen un paper vital, és per a ells que hem creat aquest sistema.
El nucli del sistema comercial és una base de dades intel·ligent en memòria en la qual totes les transaccions són transaccions d'intercanvi. La base estava escrita en C, les úniques dependències externes eren la biblioteca libc i no hi havia cap assignació de memòria dinàmica. Per reduir el temps de processament, el sistema comença amb un conjunt estàtic de matrius i amb la reubicació de dades estàtiques: en primer lloc, totes les dades del dia actual es carreguen a la memòria i no es realitza cap altre accés al disc, tot el treball es realitza només a la memòria. Quan el sistema s'inicia, totes les dades de referència ja estan ordenades, de manera que la cerca funciona de manera molt eficient i triga poc temps en temps d'execució. Totes les taules estan fetes amb llistes i arbres intrusius per a estructures de dades dinàmiques de manera que no requereixin assignació de memòria en temps d'execució.
Repassem breument la història del desenvolupament del nostre sistema de negociació i compensació.
La primera versió de l'arquitectura del sistema de negociació i compensació es va construir a partir de l'anomenada interacció Unix: es va utilitzar memòria compartida, semàfors i cues, i cada procés constava d'un sol fil. Aquest enfocament va estar molt estès a principis dels anys noranta.
La primera versió del sistema contenia dos nivells de passarel·la i un servidor central del sistema comercial. El flux de treball va ser així:
- El client envia una sol·licitud, que arriba a la passarel·la. Comprova la validesa del format (però no les dades en si) i rebutja les transaccions incorrectes.
- Si s'ha enviat una sol·licitud d'informació, s'executa localment; si estem parlant d'una transacció, llavors es redirigeix al servidor central.
- A continuació, el motor de negociació processa la transacció, modifica la memòria local i envia una resposta a la transacció i a la transacció mateixa per a la seva replicació mitjançant un motor de rèplica independent.
- La passarel·la rep la resposta del node central i l'envia al client.
- Al cap d'un temps, la passarel·la rep la transacció a través del mecanisme de replicació, i aquesta vegada l'executa localment, canviant les seves estructures de dades perquè les següents sol·licituds d'informació mostrin les dades més recents.
De fet, descriu un model de replicació en què la passarel·la replicava completament les accions realitzades al sistema de comerç. Un canal de replicació independent garanteix que les transaccions s'executaven en el mateix ordre a través de diversos nodes d'accés.
Com que el codi era d'un sol fil, es va utilitzar un esquema clàssic amb forquilles de procés per atendre molts clients. Tanmateix, era molt costós bifurcar tota la base de dades, de manera que es van utilitzar processos de servei lleugers que recopilaven paquets de les sessions TCP i els transferien a una cua (SystemV Message Queue). Gateway i Trade Engine només funcionaven amb aquesta cua, agafant les transaccions d'allà per a l'execució. Ja no era possible enviar-hi una resposta, perquè no estava clar quin procés de servei l'havia de llegir. Així que vam recórrer a un truc: cada procés bifurcat creava una cua de respostes per si mateix i, quan una sol·licitud entrava a la cua entrant, s'hi va afegir immediatament una etiqueta per a la cua de respostes.
La còpia constant de grans quantitats de dades de cua a cua creava problemes, especialment típics per a les sol·licituds d'informació. Per tant, vam utilitzar un altre truc: a més de la cua de respostes, cada procés també creava memòria compartida (SystemV Shared Memory). Els mateixos paquets s'hi van col·locar i només es va emmagatzemar una etiqueta a la cua, que permetia trobar el paquet original. Això va ajudar a emmagatzemar dades a la memòria cau del processador.
SystemV IPC inclou utilitats per visualitzar l'estat de la cua, la memòria i els objectes semàfors. Ho vam fer servir activament per entendre què passava al sistema en un moment concret, on s'acumulen els paquets, què estava bloquejat, etc.
Primeres modernitzacions
En primer lloc, ens vam desfer de la passarel·la d'un sol procés. El seu inconvenient important era que podia gestionar una transacció de replicació o una sol·licitud d'informació d'un client. I a mesura que augmenta la càrrega, Gateway tardarà més a processar les sol·licituds i no podrà processar el flux de rèplica. A més, si el client va enviar una transacció, només cal comprovar-ne la validesa i reenviar-la més endavant. Per tant, vam substituir el procés de passarel·la únic per diversos components que es poden executar en paral·lel: informació multifils i processos de transacció que s'executen independentment els uns dels altres en una àrea de memòria compartida mitjançant el bloqueig RW. I al mateix temps vam introduir processos d'enviament i replicació.
Impacte del comerç d'alta freqüència
La versió anterior de l'arquitectura va existir fins al 2010. Mentrestant, ja no estàvem satisfets amb el rendiment dels servidors HP Superdome. A més, l'arquitectura PA-RISC estava pràcticament morta; el venedor no va oferir cap actualització significativa. Com a resultat, vam començar a passar d'HP UX/PA RISC a Linux/x86. La transició va començar amb l'adaptació dels servidors d'accés.
Per què hem hagut de tornar a canviar l'arquitectura? El fet és que el comerç d'alta freqüència ha canviat significativament el perfil de càrrega al nucli del sistema.
Suposem que tenim una petita transacció que va provocar un canvi de preu important: algú va comprar mig milió de dòlars. Després d'un parell de mil·lisegons, tots els participants del mercat ho noten i comencen a fer una correcció. Naturalment, les sol·licituds s'alineen en una cua enorme, que el sistema trigarà molt a esborrar-se.
En aquest interval de 50 ms, la velocitat mitjana és d'unes 16 mil transaccions per segon. Si reduïm la finestra a 20 ms, obtenim una velocitat mitjana de 90 mil transaccions per segon, amb 200 mil transaccions al màxim. És a dir, la càrrega no és constant, amb esclats sobtats. I la cua de peticions sempre s'ha de processar ràpidament.
Però, per què hi ha una cua? Així, en el nostre exemple, molts usuaris van notar el canvi de preu i van enviar transaccions en conseqüència. Arriben a Gateway, els serialitza, estableix un ordre determinat i els envia a la xarxa. Els encaminadors barregen els paquets i els reenvien. El paquet de qui va arribar primer, aquella transacció "guanyada". Com a resultat, els clients d'intercanvi van començar a notar que si s'enviava la mateixa transacció des de diverses passarel·les, augmentaven les possibilitats d'un processament ràpid. Aviat, els robots d'intercanvi van començar a bombardejar Gateway amb peticions, i va sorgir una allau de transaccions.
Una nova ronda d'evolució
Després de proves i investigacions exhaustives, vam canviar al nucli del sistema operatiu en temps real. Per això vam triar RedHat Enterprise MRG Linux, on MRG significa quadrícula de missatgeria en temps real. L'avantatge dels pedaços en temps real és que optimitzen el sistema per a l'execució més ràpida possible: tots els processos estan alineats en una cua FIFO, els nuclis es poden aïllar, no hi ha expulsions, totes les transaccions es processen en una seqüència estricta.
Vermell: treballant amb una cua en un nucli normal, verd: treballant en un nucli en temps real.
Però aconseguir una latència baixa en servidors normals no és tan fàcil:
- El mode SMI, que a l'arquitectura x86 és la base per treballar amb perifèrics importants, interfereix molt. El processament de tot tipus d'esdeveniments de maquinari i la gestió de components i dispositius es realitza pel microprogramari en l'anomenat mode SMI transparent, en què el sistema operatiu no veu el que fa el microprogramari. Com a regla general, tots els principals venedors ofereixen extensions especials per als servidors de microprogramari que permeten reduir la quantitat de processament SMI.
- No hi hauria d'haver un control dinàmic de la freqüència del processador, això comporta un temps d'inactivitat addicional.
- Quan es buida el registre del sistema de fitxers, es produeixen certs processos al nucli que causen retards impredictibles.
- Heu de parar atenció a coses com ara CPU Affinity, Interrupt afinity, NUMA.
He de dir que el tema de la configuració del maquinari i el nucli de Linux per al processament en temps real mereix un article a part. Hem passat molt de temps experimentant i investigant abans d'aconseguir un bon resultat.
Quan vam passar dels servidors PA-RISC a x86, pràcticament no vam haver de canviar gaire el codi del sistema, només l'hem adaptat i reconfigurat. Al mateix temps, hem corregit diversos errors. Per exemple, les conseqüències del fet que PA RISC era un sistema Big endian i x86 era un sistema Little endian van sorgir ràpidament: per exemple, les dades es van llegir incorrectament. L'error més complicat va ser que utilitza PA RISC () accés a la memòria, mentre que x86 pot reordenar les operacions de lectura, de manera que el codi que era absolutament vàlid en una plataforma es va trencar en una altra.
Després de canviar a x86, el rendiment es va multiplicar gairebé per tres, el temps mitjà de processament de la transacció es va reduir a 60 μs.
Mirem ara amb més detall quins canvis clau s'han fet a l'arquitectura del sistema.
Èpica de reserva calenta
Quan vam canviar als servidors de productes bàsics, érem conscients que eren menys fiables. Per tant, a l'hora de crear una nova arquitectura, a priori assumíem la possibilitat de fallada d'un o més nodes. Per tant, es necessitava un sistema d'espera en calent que pogués canviar molt ràpidament a màquines de còpia de seguretat.
A més, hi havia altres requisits:
- En cap cas hauríeu de perdre les transaccions processades.
- El sistema ha de ser absolutament transparent a la nostra infraestructura.
- Els clients no haurien de veure les connexions caigudes.
- Les reserves no haurien d'introduir un retard important perquè aquest és un factor crític per a l'intercanvi.
Quan vam crear un sistema d'espera en calent, no vam considerar aquests escenaris com a fallades dobles (per exemple, la xarxa d'un servidor va deixar de funcionar i el servidor principal es va congelar); no va considerar la possibilitat d'errors al programari perquè s'identifiquen durant les proves; i no va tenir en compte el funcionament incorrecte del maquinari.
Com a resultat, vam arribar al següent esquema:
- El servidor principal va interactuar directament amb els servidors Gateway.
- Totes les transaccions rebudes al servidor principal es van replicar instantàniament al servidor de còpia de seguretat mitjançant un canal independent. L'àrbitre (governador) va coordinar el canvi si sorgia algun problema.
- El servidor principal va processar cada transacció i va esperar la confirmació del servidor de còpia de seguretat. Per reduir la latència al mínim, vam evitar esperar que es completi la transacció al servidor de còpia de seguretat. Com que el temps que va trigar una transacció a viatjar per la xarxa era comparable al temps d'execució, no es va afegir cap latència addicional.
- Només hem pogut comprovar l'estat de processament dels servidors principal i de seguretat de la transacció anterior i l'estat de processament de la transacció actual era desconegut. Com que encara estàvem utilitzant processos d'un sol fil, esperar una resposta de Backup hauria alentit tot el flux de processament, així que vam fer un compromís raonable: vam comprovar el resultat de la transacció anterior.
L'esquema funcionava de la següent manera.
Suposem que el servidor principal deixa de respondre, però les passarel·les continuen comunicant-se. Es produeix un temps d'espera al servidor de còpia de seguretat, es posa en contacte amb el governador, que li assigna la funció del servidor principal i totes les passarel·les canvien al nou servidor principal.
Si el servidor principal torna a estar en línia, també activa un temps d'espera intern, perquè no hi ha hagut cap trucada al servidor des de la passarel·la durant un temps determinat. Llavors també es dirigeix al Governador, i aquest l'exclou del pla. Com a resultat, l'intercanvi funciona amb un servidor fins al final del període de negociació. Com que la probabilitat d'un error del servidor és bastant baixa, aquest esquema es va considerar bastant acceptable; no contenia una lògica complexa i era fàcil de provar.
Continuar.
Font: www.habr.com