Arquitetura do sistema de negociação

Arquitetura do sistema de negociação
hibernar ou ir para EJBs? Ou Spring JDBC com suporte a transações?
-Sistema tem 60 ações disponíveis da empresa A, com US $ 100 como preço de venda.
-Sistema deve lidar com pedido na primeira base de primeiro a chegar (Spring-JMS é a opção ou Message Driven Beans (MDB)?)
-Primeiro pedido veio com & lt; 100 BUY preço, sistema shold colocar este pedido em pendente (tabela?) Com o seu preço de compra.
-Segundo pedido veio com & gt; = 100 BUY preço para 40 ações. sistema irá vender 40 ações para este cliente. Agora estoques restantes no sistema =: 50-40 = 10.
-O terceiro pedido (cliente) chegou com = 100 BUY preço para 40 ações. O sistema venderá apenas 10 ações remanescentes para esse cliente e colocará a solicitação na tabela pendente com o preço COMPRAR = 100 e a Quantidade = 40-10 = 30.
- Na próxima vez em que alguém vender ações da empresa A, o sistema automaticamente comparará com pedidos abertos pendentes no banco de dados e comprará pedidos pendentes e enviará uma notificação aos clientes sobre a COMPRA.

Tópicos práticos para profissionais de TI e outros.
As perguntas frequentes sobre o protocolo FIX são postadas.
Oficina de Arquitetura do Sistema de Negociação de Renda Fixa em 26 de setembro.
Instrumentos de Renda Fixa Visão Geral de Negociação de Renda Fixa Players de Mercado de Renda Fixa Necessidades de Corretoras (Firmas de Corretagem) Exigências / Características do Sistema de Negociação de Renda Fixa (do Corretor / Negociante) Arquitetura da Plataforma de Negociação de Renda Fixa Vários Componentes e Papéis Tecnologias Populares utilizadas e produtos de fornecedores.
Posts relacionados.
Risco EUA 2016 & # 8211; Desafios dos Dados de Risco & # 038; Solução de plataforma de big data.
My Book & # 8220; Gerenciando Contratos de Derivativos & # 8221; Liberado.
O que é o Factional Notional?
2 comentários.
[& # 8230;] Arquitetura do Sistema de Negociação de Renda Fixa [& # 8230;]
Oi Khader, o seu blog na web é excelente. mantem . é tão.
útil. Vamos continuar voltando aqui. Eu preciso de alguma informação. Qual SQL
função de análise faz uma pessoa construindo um mestre de segurança para um.
firme (por exemplo. Renda fixa) correr ?? Eu preciso de uma tabela de banco de dados com registro.
nomes e nomes de campos nele e nas instruções SQL. Por favor, despacha-te.

Arquitetura do Sistema de Negociação Algorítmica.
Anteriormente neste blog, escrevi sobre a arquitetura conceitual de um sistema inteligente de comércio algorítmico, bem como os requisitos funcionais e não funcionais de um sistema de negociação algorítmica de produção. Desde então, projetei uma arquitetura de sistema que, acredito, poderia satisfazer esses requisitos arquitetônicos. Neste post, descreverei a arquitetura seguindo as diretrizes dos padrões ISO / IEC / IEEE 42010 e o padrão de descrição da arquitetura de engenharia de software. De acordo com este padrão, uma descrição de arquitetura deve:
Contém múltiplas visualizações de arquitetura padronizadas (por exemplo, em UML) e mantém a rastreabilidade entre as decisões de design e os requisitos de arquitetura.
Definição de arquitetura de software.
Ainda não há consenso sobre o que é uma arquitetura de sistema. No contexto deste artigo, ele é definido como a infraestrutura na qual os componentes do aplicativo que satisfazem os requisitos funcionais podem ser especificados, implementados e executados. Requisitos funcionais são as funções esperadas do sistema e seus componentes. Requisitos não funcionais são medidas através das quais a qualidade do sistema pode ser medida.
Um sistema que satisfaz plenamente seus requisitos funcionais ainda pode falhar em atender às expectativas se os requisitos não funcionais forem deixados insatisfeitos. Para ilustrar esse conceito, considere o seguinte cenário: um sistema de negociação algorítmica que você acabou de comprar / construir faz excelentes decisões de negociação, mas é completamente inoperável com os sistemas de contabilidade e gerenciamento de risco da organização. Este sistema atenderia às suas expectativas?
Arquitetura conceitual.
Uma visão conceitual descreve conceitos e mecanismos de alto nível que existem no sistema no mais alto nível de granularidade. Nesse nível, o sistema de negociação algorítmica segue uma arquitetura orientada a eventos (EDA) dividida em quatro camadas e dois aspectos arquitetônicos. Para cada camada e referência, arquiteturas e padrões de referência são usados. Padrões arquitetônicos são estruturas genéricas comprovadas para atingir requisitos específicos. Aspectos arquitetônicos são preocupações transversais que abrangem múltiplos componentes.
Arquitetura orientada a eventos - uma arquitetura que produz, detecta, consome e reage a eventos. Os eventos incluem movimentos do mercado em tempo real, eventos ou tendências complexas e eventos de negociação, por ex. enviando um pedido.
Este diagrama ilustra a arquitetura conceitual do sistema de negociação algorítmica.
Arquiteturas de Referência.
Para usar uma analogia, uma arquitetura de referência é semelhante às plantas de uma parede de suporte de carga. Essa impressão em azul pode ser reutilizada para vários projetos de construção, independentemente do prédio que está sendo construído, uma vez que satisfaz um conjunto de requisitos comuns. Da mesma forma, uma arquitetura de referência define um modelo contendo estruturas e mecanismos genéricos que podem ser usados ​​para construir uma arquitetura de software concreta que atenda a requisitos específicos. A arquitetura para o sistema de negociação algorítmica usa uma arquitetura baseada em espaço (SBA) e um controlador de visão de modelo (MVC) como referências. Boas práticas, como o armazenamento de dados operacionais (ODS), o padrão de transformação e carga de extração (ETL) e um data warehouse (DW) também são usados.
Model view controller - um padrão que separa a representação da informação da interação do usuário com ela. Arquitetura baseada no espaço - especifica uma infraestrutura onde unidades de processamento fracamente acopladas interagem entre si por meio de uma memória associativa compartilhada chamada espaço (mostrada abaixo).
Visão Estrutural.
A visão estrutural de uma arquitetura mostra os componentes e subcomponentes do sistema de negociação algorítmica. Também mostra como esses componentes são implantados na infraestrutura física. Os diagramas UML usados ​​nessa exibição incluem diagramas de componentes e diagramas de implementação. Abaixo está a galeria dos diagramas de implantação do sistema de comércio algorítmico geral e as unidades de processamento na arquitetura de referência SBA, bem como diagramas de componentes relacionados para cada uma das camadas.
Diagrama do componente de comerciante / processamento de eventos automatizado Diagrama do componente da camada de origem de dados e de pré-processamento Diagrama do componente da interface com o usuário baseado no MVC.
Táticas Arquitetônicas.
De acordo com o instituto de engenharia de software, uma tática arquitetônica é um meio de satisfazer um requisito de qualidade, manipulando algum aspecto de um modelo de atributo de qualidade através de decisões de design arquitetônico. Um exemplo simples usado na arquitetura do sistema de negociação algorítmica é 'manipular' um armazenamento de dados operacional (ODS) com um componente contínuo de consulta. Esse componente analisaria continuamente o ODS para identificar e extrair eventos complexos. As seguintes táticas são usadas na arquitetura:
O padrão de disruptor nas filas de eventos e pedidos Memória compartilhada para o evento e filas de pedidos Linguagem de consulta contínua (CQL) no ODS Filtragem de dados com o padrão de design de filtro nos dados de entrada Algoritmos de prevenção de congestionamento em todas as conexões de entrada e saída Gerenciamento de filas ativas (AQM ) e notificação explícita de congestionamento Recursos de computação de commodities com capacidade de atualização (escalonável) Redundância ativa para todos os pontos únicos de falha Estrutura de indexação e otimização otimizada no ODS Agendamento de backup regular de dados e scripts de limpeza para ODS Histórico de transações em todos os bancos de dados ordens para detectar falhas Anotar eventos com registros de tempo para pular eventos 'obsoletos' Regras de validação de pedidos, por exemplo quantidades máximas de negociação Componentes de negociador automatizado usam um banco de dados em memória para análise Autenticação de dois estágios para interfaces de usuário conectando-se aos ATs Criptografia em interfaces de usuário e conexões ao padrão de projeto ATs Observer para o MVC gerenciar visualizações.
A lista acima é apenas algumas decisões de design que identifiquei durante o design da arquitetura. Não é uma lista completa de táticas. À medida que o sistema está sendo desenvolvido, táticas adicionais devem ser empregadas em vários níveis de granularidade para atender aos requisitos funcionais e não funcionais. Abaixo, há três diagramas descrevendo o padrão de design do disruptor, o padrão de design do filtro e o componente de consulta contínua.
Visão Comportamental.
Essa visão de uma arquitetura mostra como os componentes e as camadas devem interagir entre si. Isso é útil ao criar cenários para testar projetos de arquitetura e para entender o sistema de ponta a ponta. Essa visão consiste em diagramas de seqüência e diagramas de atividades. Os diagramas de atividades que mostram o processo interno do sistema de comércio algorítmico e como os comerciantes devem interagir com o sistema de comércio algorítmico são mostrados abaixo.
Tecnologias e frameworks.
A etapa final no projeto de uma arquitetura de software é identificar possíveis tecnologias e estruturas que possam ser usadas para realizar a arquitetura. Como princípio geral, é melhor aproveitar as tecnologias existentes, desde que satisfaçam adequadamente os requisitos funcionais e não funcionais. Uma estrutura é uma arquitetura de referência realizada, por ex. O JBoss é um framework que realiza a arquitetura de referência do JEE. As seguintes tecnologias e estruturas são interessantes e devem ser consideradas ao implementar um sistema de comércio algorítmico:
CUDA - A NVidia possui vários produtos que suportam modelagem de finanças computacionais de alto desempenho. É possível obter até 50x melhorias de desempenho na execução de simulações de Monte Carlo na GPU em vez da CPU. Apache River - River é um kit de ferramentas usado para desenvolver sistemas distribuídos. Ele foi usado como uma estrutura para construir aplicativos baseados no padrão SBA Apache Hadoop - no caso em que o registro generalizado é um requisito, o uso do Hadoop oferece uma solução interessante para o problema de big data. O Hadoop pode ser implementado em um ambiente em cluster que suporta tecnologias CUDA. AlgoTrader - uma plataforma de negociação algorítmica de código aberto. O AlgoTrader poderia ser implantado no lugar dos componentes do negociador automatizado. FIX Engine - um aplicativo independente que suporta os protocolos Financial Information Exchange (FIX), incluindo FIX, FAST e FIXatdl.
Embora não seja uma tecnologia ou uma estrutura, os componentes devem ser construídos com uma interface de programação de aplicativo (API) para melhorar a interoperabilidade do sistema e de seus componentes.
Conclusão.
A arquitetura proposta foi projetada para satisfazer requisitos muito genéricos identificados para sistemas de negociação algorítmica. De um modo geral, os sistemas de negociação algorítmica são complicados por três fatores que variam de acordo com cada implementação:
Dependências da empresa externa e sistemas de troca Desafiando requisitos não funcionais e Evitando restrições arquitetônicas.
A arquitetura de software proposta precisaria, portanto, ser adaptada caso a caso, a fim de satisfazer requisitos organizacionais e regulatórios específicos, bem como superar restrições regionais. A arquitetura do sistema de comércio algorítmico deve ser vista apenas como um ponto de referência para indivíduos e organizações que desejam projetar seus próprios sistemas de negociação algorítmica.
Para uma cópia completa e fontes utilizadas, faça o download de uma cópia do meu relatório. Obrigado.

Começando: Construindo um Sistema de Negociação Totalmente Automatizado.
Nos últimos 6 meses, tenho focado no processo de construção da pilha completa de tecnologia de um sistema de negociação automatizado. Eu me deparei com muitos desafios e aprendi muito sobre os dois métodos diferentes de backtesting (Vectorised e Event driven). Na minha jornada para construir um backtester orientado a eventos, veio a minha surpresa que o que você iria acabar é perto de toda a pilha de tecnologia necessária para construir uma estratégia, fazer backtest e executar a execução ao vivo.
Meu maior problema ao enfrentar o problema foi a falta de conhecimento. Procurei em muitos lugares uma introdução à construção da tecnologia ou um blog que me orientasse. Eu encontrei alguns recursos que vou compartilhar com vocês hoje.
Para iniciantes:
Para os leitores novatos no comércio quantitativo, eu recomendaria o livro de Ernie P. Chan intitulado: Negociação Quantitativa: Como construir seu próprio negócio de comércio algorítmico. Este livro é o básico. Na verdade, é o primeiro livro que li sobre negociação quantitativa e mesmo assim achei muito básico, mas há algumas notas que você deve tomar.
Da página 81-84 Ernie escreve sobre como, no nível de varejo, uma arquitetura de sistema pode ser dividida em estratégias semi-automatizadas e totalmente automatizadas.
Um sistema semi-automatizado é adequado se você quiser fazer algumas transações por semana. Ernie recomenda usar o Matlab, R ou até mesmo o Excel. Eu usei todas as 3 plataformas e este é o meu conselho:
Saltar do Matlab, custou muito dinheiro e só consegui acesso aos laboratórios da universidade. Não há muito material de treinamento como blogs ou livros que ensinem como codificar uma estratégia usando o Matlab. R tem toneladas de recursos que você pode usar para aprender como construir uma estratégia. Meu blog favorito cobrindo o tópico é: QuantStratTradeR é ​​executado por Ilya Kipnis. É mais provável que o Microsoft Excel inicie onde você não tem experiência em programação. Você pode usar o Excel para negociações semi-automáticas, mas isso não vai funcionar quando se trata de construir a pilha completa de tecnologias.
Estrutura semiautomática pg 81.
Sistemas de negociação totalmente automatizados são para quando você deseja colocar automaticamente as negociações com base em um feed de dados ao vivo. Eu codifiquei o meu em C #, o QuantConnect também usa o C #, o QuantStart orienta o leitor através da construção em Python, o Quantopian usa o Python, o HFT provavelmente usará o C ++. Java também é popular.
Estrutura de negociação completamente automatizada página 84.
Passo 1: Conseguir um bom começo.
Faça o Programa Executivo em Algorithmic Trading oferecido pela QuantInsti. Acabei de começar o curso e o primeiro conjunto de palestras foi na arquitetura do sistema. Isso teria me poupado cerca de 3 meses de pesquisa se eu tivesse começado aqui. As palestras me acompanharam através de cada componente que eu precisaria, bem como uma descrição detalhada do que cada componente precisa fazer. Abaixo está uma captura de tela de um de seus slides usados ​​na apresentação:
Você também pode usar essa estrutura geral ao avaliar outros sistemas de negociação automáticos.
No momento em que escrevo, estou apenas na terceira semana de palestras, mas estou confiante de que um praticante será capaz de construir uma estratégia comercial totalmente automatizada que poderia, com um pouco de refinamento, ser transformada no começo de um fundo de hedge quantitativo. .
Nota: o curso não está focado na construção da pilha de tecnologia.
Etapa 2: codifique um backtester baseado em eventos básicos.
Blog de Michael Hallsmore, quantstart & amp; livro “Negociação Algorítmica Bem Sucedida”
Este livro tem seções dedicadas à construção de um robusto backtester orientado a eventos. Ele orienta o leitor através de vários capítulos que explicarão sua escolha de idioma, os diferentes tipos de backtesting, a importância do backtesting orientado a eventos e como codificar o backtester.
Michael introduz o leitor às diferentes classes necessárias em um projeto orientado a objetos. Ele também ensina o leitor a construir um banco de dados mestre de títulos. É aqui que você verá como a arquitetura do sistema da QuantInsti se encaixa.
Nota: Você precisará comprar o livro dele: “Successful Algorithmic Trading”, seu blog deixa de fora muita informação.
Passo 3: Volte para o TuringFinance.
O programa EPAT Reading “Successful Algorithmic Trading” & amp; codificando um backtester em um idioma diferente de sua escolha.
Você deve ir para um blog chamado TuringFinance e ler o artigo intitulado "Algorithmic Trading System Architecture" Por: Stuart Gordon Reid. Em seu post ele descreve a arquitetura seguindo as diretrizes dos padrões ISO / IEC / IEEE 42010 e padrão de descrição de arquitetura de engenharia de software.
Eu achei este post muito técnico e tem algumas ótimas idéias que você deve incorporar em sua própria arquitetura.
Uma captura de tela de seu post.
Etapa 4: Estude os sistemas de negociação de código aberto.
4.1) Quantopian.
Escusado será dizer que Quantopian deve ser adicionado a esta lista e tenho vergonha de dizer que não passei muito tempo usando sua plataforma (devido à minha escolha de idioma). Quantopian tem muitas vantagens, mas as que mais se destacam para mim são as seguintes:
Fácil de aprender Python Acesso gratuito a muitos conjuntos de dados Uma grande comunidade e competições Eu amo como eles hospedam a QuantCon!
Quantopian é os líderes de mercado neste campo e é amado por todos os quants! Seu projeto de código aberto está sob o nome de código Zipline e isso é um pouco sobre isso:
“O Zipline é o nosso mecanismo de código aberto que alimenta o backtester no IDE. Você pode ver o repositório de código no Github e contribuir com solicitações de pull para o projeto. Há um grupo do Google disponível para procurar ajuda e facilitar discussões. ”
Aqui está um link para sua documentação:
4.2) QuantConnect.
Para aqueles que não estão familiarizados com o QuantConnect, eles fornecem um mecanismo completo de negociação algorítmica de código aberto. Aqui está um link.
Você deve dar uma olhada no código deles, estudá-lo, & amp; dê-lhes louvor. Eles são competição de quantopianos.
Eu gostaria de aproveitar esta oportunidade para agradecer à equipe da QuantConnect por me deixar escolher o cérebro deles e pelo serviço brilhante que eles fornecem.
Aqui está um link para sua documentação:
Observações finais:
Espero que este guia ajude os membros da comunidade. Eu gostaria de ter essa percepção 6 meses atrás quando comecei a codificar nosso sistema.
Eu gostaria de falar com a comunidade e perguntar: “Que bons cursos de negociação algorítmica você conhece?” Eu gostaria de escrever um post que analise o tópico e forneça uma classificação. Há alguma recomendação para criar um sistema de negociação totalmente automatizado que você gostaria de adicionar a este post?

Como funcionam os sistemas de negociação
A negociação automatizada algorítmica ou a Algorithmic Trading estão no centro do mundo comercial há mais de uma década. A porcentagem de volumes atribuídos ao comércio automatizado algorítmico registrou um aumento significativo na última década. Como resultado, tornou-se um mercado altamente competitivo e altamente dependente da tecnologia. Consequentemente, a arquitetura básica dos sistemas de negociação automatizados que executam estratégias algorítmicas sofreu grandes mudanças na última década e continua a fazê-lo. Para as empresas, especialmente aquelas que utilizam sistemas de negociação de alta frequência, tornou-se uma necessidade inovar em tecnologia para competir no mundo do comércio algorítmico, tornando o campo de comércio algorítmico um foco de avanços em tecnologias de computadores e redes.
Neste post, desmistificaremos a arquitetura por trás dos sistemas automatizados de negociação para nossos leitores. Comparamos a nova arquitetura de sistemas de negociação automatizada com a arquitetura de negociação tradicional e entendemos alguns dos principais componentes por trás desses sistemas.
Arquitetura Tradicional.
Qualquer sistema de negociação, conceitualmente, nada mais é do que um bloco computacional que interage com a troca em dois fluxos diferentes.
Recebe dados de mercado Envia solicitações de pedidos e recebe respostas da troca.
Os dados de mercado recebidos normalmente informam o sistema do último pedido. Pode conter algumas informações adicionais, como o volume negociado até agora, o último preço negociado e quantidade para um script. No entanto, para tomar uma decisão sobre os dados, o comerciante pode precisar olhar para valores antigos ou derivar determinados parâmetros do histórico. Para atender a isso, um sistema convencional teria um banco de dados histórico para armazenar os dados de mercado e ferramentas para usar esse banco de dados. A análise também envolveria um estudo das negociações passadas pelo comerciante. Daí outro banco de dados para armazenar as decisões de negociação também. Por último, mas não menos importante, uma interface gráfica para o comerciante para ver todas essas informações na tela.
Todo o sistema de negociação agora pode ser dividido em.
A troca (s) - o mundo externo O servidor Dados de mercado receptor Armazenar dados de mercado Armazenar ordens geradas pelo usuário Aplicação Tomar entradas do usuário, incluindo as decisões de negociação Interface para visualizar as informações, incluindo os dados e ordens Um gerente de pedidos enviando ordens para o troca.
Nova Arquitetura.
A arquitetura tradicional não podia escalar até as necessidades e demandas do comércio automatizado com o DMA. A latência entre a origem do evento e a geração da ordem foi além da dimensão do controle humano e entrou nos domínios de milissegundos e microssegundos. Portanto, as ferramentas para lidar com dados de mercado e sua análise precisavam se adaptar de acordo. O gerenciamento de pedidos também precisa ser mais robusto e capaz de lidar com muito mais pedidos por segundo. Como o período de tempo é muito pequeno comparado ao tempo de reação humano, o gerenciamento de risco também precisa lidar com pedidos em tempo real e de maneira totalmente automatizada.
Por exemplo, mesmo que o tempo de reação de um pedido seja de 1 milissegundo (o que é muito comparado às latências que vemos hoje), o sistema ainda é capaz de tomar 1000 decisões de negociação em um único segundo. Isso significa que cada uma dessas 1000 decisões de negociação precisa passar pelo gerenciamento de riscos dentro do mesmo segundo para alcançar a troca. Este é apenas um problema de complexidade. Como a arquitetura agora envolve lógica automatizada, 100 traders podem agora ser substituídos por um único sistema de negociação automatizado. Isso adiciona escala ao problema. Assim, cada uma das unidades lógicas gera 1000 pedidos e 100 dessas unidades significam 100.000 pedidos por segundo. Isso significa que a parte de tomada de decisão e envio de pedidos precisa ser muito mais rápida que o receptor de dados de mercado para corresponder à taxa de dados.
Portanto, o nível de infraestrutura que este módulo exige precisaria ser muito superior ao de um sistema tradicional (discutido na seção anterior). Portanto, o mecanismo que executa a lógica de tomada de decisão, também conhecido como mecanismo de "Processamento de Eventos Complexos", ou CEP, foi movido de dentro do aplicativo para o servidor. A camada Application, agora, é pouco mais que uma interface de usuário para visualizar e fornecer parâmetros para o CEP.
O problema de escalonamento também leva a uma situação interessante. Digamos que 100 lógicas diferentes estão sendo executadas em um único evento de dados de mercado (conforme discutido no exemplo anterior). No entanto, pode haver partes comuns de cálculos complexos que precisam ser executados para a maioria das 100 unidades lógicas. Por exemplo, cálculo de gregos para opções. Se cada lógica funcionasse independentemente, cada unidade faria o mesmo cálculo grego, o que consumiria desnecessariamente os recursos do processador. Para otimizar a redundância de cálculos, os cálculos redundantes complexos são tipicamente transferidos para um mecanismo de cálculo separado, que fornece os gregos como uma entrada para o CEP.
Embora a camada de aplicação seja basicamente uma visão, algumas das verificações de risco (que agora são operações famintas por recursos devido ao problema de escala) podem ser transferidas para a camada de aplicação, especialmente aquelas relacionadas à integridade das entradas do usuário. erros. As demais verificações de risco são executadas agora por um Sistema de Gerenciamento de Riscos (RMS) separado no Order Manager (OM), imediatamente antes de liberar um pedido. O problema de escala também significa que onde antes havia 100 traders diferentes gerenciando seu risco, agora há apenas um sistema RMS para gerenciar riscos em todas as unidades / estratégias lógicas. No entanto, algumas verificações de risco podem ser específicas de determinadas estratégias e algumas podem precisar ser feitas em todas as estratégias. Portanto, o próprio RMS envolve nível de estratégia RMS (SLRMS) e global RMS (GRMS). Também pode envolver uma interface do usuário para visualizar o SLRMS e o GRMS.
Surgimento de protocolos para sistemas de negociação automatizados.
Com inovações vêm as necessidades. Como a nova arquitetura era capaz de escalonar várias estratégias por servidor, surgiu a necessidade de se conectar a vários destinos a partir de um único servidor. Assim, o gerente de pedidos hospedou vários adaptadores para enviar pedidos para vários destinos e receber dados de várias trocas. Cada adaptador atua como um intérprete entre o protocolo entendido pela troca e o protocolo de comunicação dentro do sistema. Várias trocas significam vários adaptadores.
No entanto, para adicionar uma nova troca ao sistema, um novo adaptador deve ser projetado e conectado à arquitetura, já que cada troca segue seu protocolo apenas que é otimizado para recursos que a troca fornece. Para evitar esse incômodo de adição do adaptador, os protocolos padrão foram projetados. O mais proeminente entre eles é o protocolo FIX (Financial Information Exchange) (veja nosso post sobre introdução ao protocolo FIX). Isso não só torna possível conectar-se a diferentes destinos rapidamente, mas também reduz drasticamente a entrada no mercado quando se trata de conectar-se a um novo destino. Para obter mais informações adicionais: Conectando o FXCM ao FIX, um tutorial detalhado.
A presença de protocolos padrão facilita a integração com fornecedores de terceiros, para análises ou feeds de dados de mercado. Como resultado, o mercado torna-se muito eficiente, pois a integração com um novo destino / fornecedor não é mais uma restrição.
Além disso, a simulação torna-se muito fácil, já que receber dados do mercado real e enviar pedidos a um simulador é apenas uma questão de usar o protocolo FIX para conectar-se a um simulador. O simulador em si pode ser construído internamente ou adquirido de um fornecedor terceirizado. Da mesma forma, os dados gravados podem ser reproduzidos apenas com os adaptadores agnósticos para saber se os dados estão sendo recebidos do mercado ao vivo ou de um conjunto de dados gravados.
Surgimento de arquiteturas de baixa latência.
Com os blocos de construção de um sistema de comércio algorítmico implementado, as estratégias otimizam a capacidade de processar enormes quantidades de dados em tempo real e tomar decisões comerciais rápidas. Mas com o advento dos protocolos de comunicação padrão, como o FIX, a barreira de entrada de tecnologia para configurar uma mesa de operações algorítmicas, tornou-se mais baixa e, portanto, mais competitiva. Como os servidores obtiveram mais memória e freqüências de clock mais altas, o foco mudou para reduzir a latência na tomada de decisões. Com o tempo, reduzir a latência tornou-se uma necessidade por vários motivos, como:
Estratégia só faz sentido em um ambiente de baixa latência Sobrevivência do mais forte - os competidores o escolhem se você não for rápido o suficiente.
O problema, no entanto, é que a latência é realmente um termo abrangente que engloba vários atrasos diferentes. Quantificar todos eles em um termo genérico pode não fazer muito sentido. Embora seja muito fácil de entender, é muito difícil quantificar. Portanto, torna-se cada vez mais importante como o problema de reduzir a latência é abordado.
Se olharmos para o ciclo de vida básico,
Um pacote de dados de mercado é publicado pela troca O pacote viaja pelo fio O pacote chega a um roteador no lado do servidor. O roteador encaminha o pacote pela rede no lado do servidor. O pacote chega na porta Ethernet do servidor. Dependendo se este é o processamento UDP / TCP ocorre e o pacote retirado de seus cabeçalhos e trailers faz o seu caminho para a memória do adaptador. O adaptador então analisa o pacote e o converte em um formato interno para a plataforma de negociação algorítmica. Este pacote agora percorre os vários módulos do sistema - CEP, tick store, etc. O CEP analisa e envia um pedido de pedido. através do reverso do ciclo como o pacote de dados de mercado.
A alta latência em qualquer uma dessas etapas garante uma alta latência para todo o ciclo. Portanto, a otimização da latência geralmente começa com o primeiro passo neste ciclo que está sob nosso controle, ou seja, “o pacote viaja pelo fio”. A coisa mais fácil de fazer aqui seria encurtar a distância até o destino, tanto quanto possível. Colocações são facilidades fornecidas pelas trocas para hospedar o servidor de negociação nas proximidades da troca. O diagrama a seguir ilustra os ganhos que podem ser obtidos cortando a distância.
Para qualquer tipo de estratégia de alta frequência envolvendo um único destino, Colocation tornou-se um imperdível. No entanto, estratégias que envolvem vários destinos precisam de um planejamento cuidadoso. Vários fatores como, o tempo gasto pelo destino para responder aos pedidos de pedidos e sua comparação com o tempo de ping entre os dois destinos devem ser considerados antes de tomar tal decisão. A decisão também pode depender da natureza da estratégia.
A latência de rede é geralmente o primeiro passo para reduzir a latência geral de um sistema de negociação algorítmica. No entanto, existem muitos outros lugares onde a arquitetura pode ser otimizada.
Latência de propagação.
A latência de propagação significa o tempo necessário para enviar os bits ao longo do fio, limitado pela velocidade da luz, é claro.
Diversas otimizações foram introduzidas para reduzir a latência de propagação além de reduzir a distância física. Por exemplo, o tempo de ida e volta estimado para um cabo comum entre Chicago e Nova York é de 13,1 milissegundos. As redes de spread, em outubro de 2012, anunciaram melhorias de latência que trouxeram o tempo estimado de ida e volta para 12,98 milissegundos. A comunicação por microondas foi adotada ainda por firmas como a Tradeworx, trazendo o tempo estimado de ida e volta para 8,5 milissegundos. Observe que o mínimo teórico é de aproximadamente 7,5 milissegundos. Inovações contínuas estão forçando os limites da ciência e atingindo rapidamente o limite teórico da velocidade da luz. Os desenvolvimentos mais recentes em comunicação a laser, adotados anteriormente nas tecnologias de defesa, eliminaram ainda mais uma latência já diminuída em nanossegundos em distâncias curtas.
Latência de processamento de rede.
A latência do processamento de rede significa a latência introduzida pelos roteadores, comutadores etc.
O próximo nível de otimização na arquitetura de um sistema de negociação algorítmico seria o número de saltos que um pacote levaria para viajar do ponto A para o ponto B. Um salto é definido como uma parte do caminho entre a origem eo destino durante o qual um pacote não passa por um dispositivo físico como um roteador ou um switch. Por exemplo, um pacote pode viajar pela mesma distância através de dois caminhos diferentes. Mas pode ter dois saltos no primeiro caminho contra 3 saltos no segundo. Supondo que o atraso de propagação é o mesmo, os roteadores e switches introduzem sua própria latência e geralmente como uma regra geral, e mais o latido é a latência adicionada.
A latência do processamento da rede também pode ser afetada pelo que nos referimos como microbursts. Microbursts são definidos como um aumento repentino na taxa de transferência de dados que pode não necessariamente afetar a taxa média de transferência de dados. Como os sistemas de negociação algorítmica são baseados em regras, todos esses sistemas reagirão ao mesmo evento da mesma maneira. Como resultado, muitos sistemas participantes podem enviar pedidos levando a uma súbita enxurrada de transferência de dados entre os participantes e o destino, levando a uma microburst. O diagrama a seguir representa o que é uma microburst.
A primeira figura mostra uma visualização de 1 segundo da taxa de transferência de dados. Podemos ver que a taxa média está bem abaixo da largura de banda disponível de 1Gbps. No entanto, se mergulhar mais fundo e olhar a imagem dos segundos (a visualização de 5 milissegundos), vemos que a taxa de transferência subiu acima da largura de banda disponível várias vezes por segundo. Como resultado, os buffers de pacote na pilha de rede, tanto nos pontos de extremidade da rede como nos roteadores e switches, podem transbordar. Para evitar isso, normalmente uma largura de banda muito maior do que a taxa média observada é geralmente alocada para um sistema de comércio algorítmico.
Latência de serialização.
A latência de serialização significa o tempo necessário para puxar os bits do fio.
Um tamanho de pacote de 1500 bytes transmitidos em uma linha T1 (1.544.000 bps) produziria um atraso de serialização de cerca de 8 milissegundos. No entanto, o mesmo pacote de 1500 bytes usando um modem de 56K (57344bps) levaria 200 milissegundos. Uma linha Ethernet 1G reduziria essa latência para cerca de 11 microssegundos.
Interromper latência.
Latência de interrupção significa uma latência introduzida por interrupções ao receber os pacotes em um servidor.
A latência de interrupção é definida como o tempo decorrido entre o momento em que uma interrupção é gerada e quando a fonte da interrupção é atendida. Quando uma interrupção é gerada? Interrupções são sinais para o processador emitido pelo hardware ou software, indicando que um evento precisa de atenção imediata. O processador, por sua vez, responde suspendendo sua atividade atual, salvando seu estado e manipulando a interrupção. Sempre que um pacote é recebido na NIC, uma interrupção é enviada para manipular os bits que foram carregados no buffer de recebimento da NIC. O tempo gasto para responder a essa interrupção não afeta apenas o processamento da carga útil recém-chegada, mas também a latência dos processos existentes no processador.
A Solarflare introduziu o onload aberto em 2011, que implementa uma técnica conhecida como bypass do kernel, em que o processamento do pacote não é deixado para o kernel do sistema operacional, mas para o próprio espaço do usuário. O pacote inteiro é mapeado diretamente no espaço do usuário pela NIC e é processado lá. Como resultado, as interrupções são completamente evitadas.
Como resultado, a taxa de processamento de cada pacote é acelerada. O diagrama a seguir demonstra claramente as vantagens do desvio do kernel.
Latência do aplicativo.
A latência do aplicativo significa o tempo gasto pelo aplicativo para processar.
Isso depende dos vários pacotes, do processamento alocado à lógica do aplicativo, da complexidade do cálculo envolvido, da eficiência de programação, etc. Aumentar o número de processadores no sistema reduziria, em geral, a latência do aplicativo. O mesmo acontece com o aumento da freqüência do clock. Muitos sistemas de negociação algorítmica aproveitam a dedicação dos núcleos do processador aos elementos essenciais do aplicativo, como a lógica da estratégia, por exemplo. Isso evita a latência introduzida pelo processo de alternância entre os núcleos.
Da mesma forma, se a programação da estratégia tiver sido feita, tenha em mente os tamanhos de cache e a localidade de acesso à memória, então haveria muitos hits de cache de memória, resultando em uma redução adicional de latência. Para facilitar isso, muitos sistemas usam linguagens de programação de baixo nível para otimizar o código para a arquitetura específica dos processadores. Algumas empresas até chegaram a gravar cálculos complexos em hardware usando matrizes de portas totalmente programáveis ​​(FPGA). Com o aumento da complexidade, vem aumentando o custo e o diagrama a seguir ilustra bem isso.
Níveis de sofisticação.
O mundo da negociação algorítmica de alta frequência entrou em uma era de intensa competição. Com cada participante adotando novos métodos de derrubar a concorrência, a tecnologia progrediu aos trancos e barrancos. Arquiteturas modernas de negociação algorítmica são bastante complexas em comparação com suas contrapartes em estágio inicial. Consequentemente, os sistemas avançados são mais caros de construir em termos de tempo e dinheiro.