Zeromq Trading System

AVISO: Este texto está obsoleto e se refere a uma versão antiga do MQ. Continua aqui por interesse histórico. NÃO UTILIZE ESTE PARA APRENDER MQ. Introdução Como a MQ destina-se principalmente a impulsionar negócios de negociação de ações, criamos um aplicativo de exemplo que simula o funcionamento interno de uma bolsa de valores. O principal foco deste exemplo é mostrar como o MQ perfroms em cenário de mundo real. O diagrama a seguir mostra a arquitetura do aplicativo: o componente Gateway deve obter pedidos de comerciantes na rede (usando o protocolo FIX ou um protocolo proprietário específico) e enviar respostas de volta aos comerciantes. No entanto, como o exemplo de aplicação destina-se a mostrar quais são as possiveis características de transmissão de tal sistema, o gateway gera ordens aleatórias em vez de recebê-las dos comerciantes. Ao iniciar o gateway, você pode especificar o número de pedidos por segundo a serem gerados. A unidade correspondente contém o núcleo da lógica comercial da bolsa de valores. Ele corresponde a ordens um ao outro e produz trades e citações. Nossa implementação é minimalista, com base no algoritmo de correspondência timeprice (a implementação do algoritmo pro rata é deixada como um exercício para o leitor). Ainda assim, o algoritmo tem complexidade de O (1) e é fortemente otimizado. Nós vimos isso processar cerca de 18 milhões de pedidos por segundo. O componente de estatísticas recebe informações de desempenho geradas pelo mecanismo de gateway e correspondência e exibe-as de forma legível por humanos. Para tornar a leitura das estatísticas ainda mais conveniente, a ferramenta gráfica simples está incluída no exemplo. Desempenho A captura de tela seguinte mostra o desempenho de exemplos em duas caixas high-end de 8 núcleos (3GHz) cada uma com 2 NIC dedicadas 1GbE. Tenha em mente que, se você executá-lo no hardware não especificado ou não ligado, pode ser ainda muito rápido, no entanto, você experimentará menores débitos de mensagens e mais picos de latência. Se você definir a taxa de mensagem muito alta, você pode até mesmo ter uma falha de segurança, pois o componente ticker usado para enviar ordens na taxa estável não conseguirá manter o ritmo. A linha amarela mostra latência de ida e volta, ou seja, quanto tempo demorou para passar da ordem do gateway para o mecanismo correspondente, processá-lo e enviar a confirmação do pedido de volta ao gateway. Na nossa latência de teste, oscilou em torno da média de 200 microssegundos. A linha de transferência mais baixa (900,000 messagessecond) é a taxa de pedidos passados ​​do gateway para o mecanismo correspondente. A linha de transferência superior (2.300.000 mensagens) é a taxa de confirmações de pedidos, trocas e cotações de ações passadas do motor correspondente para o gateway. No total, vimos aproximadamente 3.200.000 mensagens por segundo passando pela rede. Construindo-o Para construir o exemplo, use a opção - with-exchange com configure: Para poder executar a ferramenta gráfica, você precisa ter o Perl-Tk instalado (embalado como perl-tk no Debian), bem como Tk :: Graph from CPAN . Executando-o Por exemplo, temos a seguinte topologia de rede para executar o exemplo. As caixas representam máquinas individuais, as setas representam cabos físicos entre as interfaces de rede individuais (marcadas pelos respectivos endereços IP): existem 3 caixas (test01, test02 e test03) conectadas à rede comutada com respectivos endereços IP de 192.168.0.1, 192.168.0.2 E 192.168.0.3. Além disso, existem duas conexões diretas entre test02 e test03. Uma conexão conecta a interface de rede 10.0.0.1 no test02 com a interface de rede 10.0.0.2 no teste03. Outro conecta interface de rede 10.1.0.1 em test02 com interface de rede 10.1.0.2 em test03. Bem, execute o zmqserver e o componente estatístico no test01, combinando o motor no test02 e o gateway no test03. Bem, use uma das conexões diretas entre test02 e test03 para passar ordens de gatway para motor correspondente e a outra para passar confirmações, trocas e citações de correspondência de mecanismo para gateway. Primeiro, comece o zmqserver no test01: depois, comece o componente estatístico no teste01. Os parâmetros são a caixa onde zmqserver está sendo executado e interface de rede para receber informações estatísticas: Alternativamente, você pode canalizar os dados estatísticos para a ferramenta gráfica: agora comece o mecanismo correspondente. Forneça o nome do host do zmqserver, interface para receber mensagens e interface para enviar mensagens como parâmetros: Finalmente, execute o gateway. Forneça o local do zmqserver e o número de pedidos a serem enviados por segundo como parâmetros: Conclusão O exemplo de troca permite que você teste o desempenho do MQ em cenário real. No entanto, obter uma latência estável em altos débitos é uma questão complicada dependente da sintonia geral do seu hardware, sistema operacional, ambiente de execução, etc. Se você é sério sobre testes de desempenho, entre em contato conosco para ajudá-lo na tarefa. Escrito: 1218019882Y. m.e Revisado: 1286694428.j. Se você encontrou esta página útil, avalie-a para que outros a encontrem. Introdução O setor financeiro vive com tecnologia de mensagens. Em quotWall Streetquot (o negócio global de negociação de ações), capacidade e latência são tudo. A infra-estrutura atual, altamente sintonizada para obter milhões de mensagens por segundo, e latências sub-milissegundos, ainda falha quando o comércio fica frenético. Enormes quantidades de dinheiro dependem de ser o primeiro a obter dados e o primeiro a negociar. O negócio de negociação de ações está evoluindo dramaticamente. O preço Penny gera mais dados. Novos regulamentos dos EUA e da UE aumentam o número de partes envolvidas nos mercados financeiros. As novas tecnologias de negociação algorítmica aumentam a demanda por dados de estoque atualizados e números de ordens iguais. Embora a infra-estrutura existente possa duplicar em capacidade ou velocidade por 18 meses, espera-se que o tráfego cresça em 20 vezes nos próximos três anos 1. Ao mesmo tempo, os preços da tecnologia de mensagens estão aumentando constantemente. O middleware de mensagens - software que conecta aplicativos ou peças de aplicativos em uma forma de plug-and-play generalizada - é um dos últimos itens de grande bilhete ainda não transformados em uma commodity pela era da Internet de software barato. Os mainframes obtiveram grande parte do seu poder de mensagens inteligentes, sistemas de processamento de transações como o IBM CICS. Mas, hoje mesmo, os middleware padrão dos anos 1980 - ao contrário de bancos de dados, sistemas operacionais, compiladores, editores, GUIs e assim por diante - ainda não estão amplamente disponíveis para desenvolvedores comuns. A indústria de software está produzindo várias aplicações de negócios e peças de aplicativos, e as ferramentas para fazer isso, em quantidades cada vez maiores, e preços cada vez mais baixos, mas o bit de mensagens ainda está faltando. A falta de uma maneira de conectar essas aplicações tornou-se não apenas um terreno não conquistado, mas também um sério obstáculo para o crescimento, especialmente para novas empresas que, em teoria, poderiam competir de forma agressiva com empresas maiores e mais antigas, se pudessem combinar barato Blocos existentes de software. Essa frustração é visível em muitos mercados e levou ao crescimento de mensagens-sobre-HTTP (SOAP) e outros compromissos. Arquiteturas como o SOAP funcionam, mas não resolvem os dois principais problemas de mensagens de nível corporativo, nomeadamente roteamento e filas. Assim, as empresas que usam essas tecnologias não podem escalar e não podem competir em mercados realmente grandes, a menos que escrevam seu próprio software de mensagens ou compram um produto comercial. Várias outras tentativas de padronização foram feitas para comercializar o mercado: CORBA, JMS e ultimamente AMQP, o CORBA não teve êxito devido à metáfora RPC que não se adequa às necessidades dos mercados financeiros, a JMS é bem sucedida no mundo de Java, mas não pode expandir-se e o AMQP ainda está sendo implementado. Um grande desconhecido. A crescente demanda e a falta de concorrência real mostram nas demonstrações financeiras de fornecedores de mensagens de ponta como o Tibco Software Inc: a receita total no primeiro trimestre do ano fiscal de 2007 comparado ao mesmo trimestre do ano passado aumentou 11,0 milhões ou 10. A O aumento foi composto por um aumento de 7.0 milhões ou 11 na receita de serviços e manutenção e por um aumento de 4,0 milhões ou 8 na receita de licenças. Dois clientes da Tibco informam que as taxas de licença estão aumentando, ano a ano. O mercado O mercado global de negociação de ações é foco primário do MQ porque isso é onde a maior ênfase é colocada na mensagem, a maioria dos recursos são acumulados e a maioria das tecnologias de corte de ponta são usadas. A principal característica do mercado é a fome de entrega rápida. Em cada milissegundo, a cotação de ações ou a ordem comercial é mais rápida do que a concorrente se traduz em lucro financeiro direto, então as empresas envolvidas estão naturalmente ansiosas por qualquer vantagem que possam obter. Atualmente, no estoque de negociação, a carga de tráfego é tão alta e a latência tão crítica, que o middleware precisa ser altamente otimizado. As latências são dadas em microssegundos e throughput em milhões de mensagens por segundo8230. Apesar disso, o comércio geralmente experimenta problemas quando a carga da mensagem atinge o pico. A latência pode de repente cair para segundos (ou mesmo dezenas de segundos) e grandes quantidades de dinheiro podem ser perdidas à medida que os negócios são atrasados ​​ou falham. 3 A situação está piorando por várias razões: em 2001, a NYSE e a NASDAQ passaram do preço de suas ações em unidades de 116 dólares para unidades de centavo único. Este chamado quotpenny pricingquot significa que os mercados de ações produzem mais dados e esses dados devem ser deslocados em todas as redes. Tanto nos EUA como na UE, os reguladores estão obrigando os mercados financeiros a competir de forma mais aberta e agressiva, no interesse dos consumidores. Por exemplo, as mudanças regulatórias da SEC dos EUA permitem que novas empresas atuem como intermediários no setor de estoque de ações, enquanto a Directiva de Mercados de Instrumentos Financeiros da UE (MiFID) 4 deverá aumentar as taxas de tráfego de ações na UE para corresponder aos volumes vistos nos EUA após Reg NMS 5. Muitas empresas novas e agressivas estão entrando no mercado, especialmente construindo ou usando plataformas de negociação algorítmicas. A negociação algorítmica executa grande quantidade de ordens de baixo volume em oposição a uma pequena quantidade de ordens de alto volume executadas por comerciantes humanos tradicionais. Portanto, aumentamos os fluxos de dados, para mais participantes, que estão empurrando para desenvolver novos modelos de negócios que dependem de obter esses dados rapidamente, detectar anomalias temporárias do mercado e responder a ele (com trades) antes de seus concorrentes. Um ambiente regulatório mais flexível está abrindo mercados previamente protegidos para uma nova competição. No geral, vemos uma corrida de armamentos para largura de banda e latência em que melhor tecnologia se traduz diretamente em mais lucros. 6 O tráfego de mensagens deverá crescer significativamente no curto prazo - ouvimos números diferentes de até 30 vezes nos próximos três anos - e os sistemas existentes só podem duplicar a capacidade a cada 18 meses. Há muitas tentativas para resolver esse problema emergente. As melhorias mais dramáticas no desempenho vêm de substituir o intermediário central clássico por uma arquitetura peer-to-peer em que as mensagens podem fluir diretamente na rede sem saltos extras. Nem todos os sistemas de mensagens podem adaptar sua arquitetura desta maneira. Além da arquitetura, o lugar óbvio para otimizar mensagens é no quotstackquot, ou seja, as camadas que separam o programa aplicativo da rede física. O software em si já é fortemente otimizado na maioria dos casos, então os fornecedores estão mudando para outras opções, como: Otimizando a arquitetura de rede por provedores de conectividade para obter latências melhores, incluindo a mudança de clientes de mensagens perto (em termos de rede) para os produtores de mensagens 7. 8 . Clientes que se deslocam de alimentações consolidadas de cotações de estoque para conectividade direta com as trocas 9 Otimizando formatos em que os dados são passados ​​(FIXFAST 10) Fornecer soluções de hardware completas (Tervela, Exegy, etc.) Substituindo a camada de transporte físico (Infiniband 11. Ethernet de 10GB ) Otimizando hardware de rede existente. TCP offload engines, Intel IOAT technology 12. etc. Modificando o sistema operacional para lidar com as mensagens em tempo real. Vários sistemas operacionais em tempo real, como o Novells SLERT 13 Modificando o sistema operacional para usar uma pilha de mensagens mais eficiente: IO assíncrono, SDP, várias técnicas de cópia zero, etc. Usando multicast para distribuir cotações de estoque na LAN dos clientes, além dessas otimizações, foco Em aspectos individuais da pilha ou arquitetura de mensagens, também vemos tentativas que analisam o problema como um todo: Intels Low Latency Lab 14 Centro de Análise de Tecnologia de Valores (STAC) 15 Várias soluções de monitoramento de amplificação de medição (Endace, etc.) Produtos altamente otimizados com Suporte de hardware extensivo torna-se muito caro. Somente as maiores empresas comerciais podem pagar toda a gama de produtos e mesmo para essas empresas, os custos continuam sendo uma preocupação persistente. Para as pequenas empresas, muitas das soluções simplesmente não são uma opção. Oportunidades Nesta seção, analisamos as oportunidades para novos produtos de mensagens de alto desempenho, como os que estamos construindo. Saída de alto desempenho O primeiro e mais óbvio alvo é qualquer empresa que use middleware comercial high-end para negociação de ações, onde podemos fornecer um equivalente mais barato. Este mercado é sensível aos custos e, na nossa experiência, está disposto a absorver mudanças e riscos, a fim de obter um preço atraente e uma vantagem de desempenho em relação aos seus concorrentes. Além disso, existem muitas empresas que não podem pagar esses produtos, mas os usariam se o custo fosse menor. O direito de Zipfs (geralmente usado para linguagem, mas também aplicável aos tamanhos de negócios) sugere que o número de empresas e seu tamanho seguem um índice inverso de energia, então, oferecendo um produto a 20, o preço dos líderes de mercado de alto custo deve abrir um mercado cinco vezes Tão grande. (Na verdade, provavelmente não é tão grande, porque as pequenas empresas vão comprar ou alugar plataformas de negociação ao invés de tentar construir as suas próprias.) Plataformas de negociação As plataformas de negociação são aplicativos de software que as empresas comerciais podem comprar pronto, em vez de construir usando o middleware de mensagens . Dada a demanda por negócios mais baratos e mais rápidos, existe um grande mercado para essas plataformas. Obviamente, uma empresa que constrói uma plataforma de negociação é sensível ao custo da mensagem que ela usa e essas empresas fornecem um mercado para nossos produtos planejados. Bancos de investimento Os bancos de investimento criam seus próprios sistemas de negociação e (da nossa experiência limitada) gostam de ter controle sobre a tecnologia que utilizam. Os sistemas baseados em padrões são altamente atraentes aqui. O cálculo é que uma tecnologia padrão é mais fácil de controlar e é servida por um mercado maior de especialistas mais baratos. Qualquer solução AMQP tem atração imediata. O custo também é sempre um motorista, mas para as empresas que fazem um desenvolvimento significativo em torno da mensagem, a redução dos custos secundários (como o número e o custo dos consultores internos) é um aspecto importante. Torna-se claro por que a JPMorganChase foi motivada a empurrar e investir no processo AMQP, mesmo tendo riscos consideráveis ​​na época: o AMQP permite economias muito grandes em despesas de TI, para licenças de mensagens, desenvolvimento personalizado, controle operacional e assim por diante. Podemos oferecer uma proposta de risco muito menor para outros bancos de investimento, mas com os mesmos tipos de benefícios. Consolidadores de dados O mundo das ações comercialmente conecta muitas bolsas (NASDAQ, NYSE, etc.) a muitos clientes. Os grandes clientes fazem conexões separadas para cada troca, mas a maioria trabalha através de consolidadores de dados, empresas como a Reuters que fornecem fluxos unificados de várias fontes. Os consolidadores de hoje executam software de mensagens personalizadas altamente personalizadas, não é baseado em padrões e tem pouca margem para se tornar mais barato e mais rápido. Pode ser mais rápido, mas apenas a um custo elevado, que punha as empresas que ficam com mensagens personalizadas e oferece vantagens para as empresas que utilizam mensagens baseadas em padrões, o que dissemina os custos e aproveita muito mais o desempenho. Há uma oportunidade definitiva para abrir esse mercado e permitir que novas empresas compitam como consolidadores de dados, usando nossos produtos de alto desempenho para levar cotações aos clientes. Novas regulamentações dos EUA estão abrindo esse mercado para uma concorrência real. As trocas (bolsas de valores, câmbios, commodities, etc.) são fortemente impactadas pelo crescimento da demanda por seus serviços. Parece inevitável que os padrões nas bordas irão forçar seu caminho para o centro e devemos ser capazes de acompanhar as ofertas de produtos. Além disso, estão surgindo novos tipos de mercados de negociação (ATSs, MTFs e pools escuros 16) que gradualmente adquirem ainda maior participação do mercado nas trocas tradicionais. Dado que essa tendência é bastante nova e ainda ganha impulso, esperamos ver crescente demanda por sistemas de mensagens de ponta neste mercado. Movendo o valor para diferentes mercados Um dos objetivos do MQ é usar o dinheiro, os recursos e a experiência acumulados durante a corrida de armamentos de baixa latência no negócio de negociação de ações para oferecer soluções de mensagens de uso geral de ponta de alta qualidade para o resto do setor de TI. Algumas das áreas onde MQ pode ser útil seguem. Mensagens empresariais e institucionais O envio de pagamentos, a comunicação entre empresas, a transmissão de documentos dentro de organizações governamentais, etc., é o principal mercado a se concentrar, além da negociação de ações. A razão é que este é o campo onde a mensagem é usada tradicionalmente, com muitos especialistas em TI experientes conscientes de mensagens e usá-lo por um longo período de tempo. Também deve ser levado em consideração que mesmo as aplicações que não usam mensagens adequadas podem ainda estar enviando mensagens por diferentes meios. Considere um aplicativo localizado no local A, escrevendo um registro para o servidor de banco de dados remoto e outro no lugar B, lendo o registro. Na verdade, houve uma mensagem enviada de A para B, mesmo que o programador possa não estar ciente disso. Mesmo a comunicação inter-processo e inter-thread pode ser considerada mensagem. Sincronizar diferentes aplicativos, copiando arquivos para destinos remotos, uma vez por dia pode ser considerado mensagem também (embora seja um caso de baixa latência espetacular). Basicamente, qualquer aplicação feita para setor financeiro ou institucional precisa de algum tipo de mensagem e o custo da implementação varia entre 10 e 30% do custo total do projeto, de modo que usar a implementação de middleware baseada em padrões atualmente parece ser um investimento bastante bom. Embora a baixa latência não seja um requisito fundamental nesta esfera, esperamos que as taxas de transação crescentes (considere regulamentos como EU SEPA 17 e esforços de padronização como o TWIST 18) forçará lentamente as instituições financeiras a adotar soluções de mensagens de alto desempenho, causando a atual pequena A fatia do mercado de mensagens abordado por soluções de alto desempenho crescerá de forma constante até chegar em 100. Sistemas embutidos Os sistemas embutidos geralmente possuem requisitos em tempo real semelhantes aos observados no negócio de negociação de ações. Considere, por exemplo, um equipamento que mede algum valor crítico em um processo tecnológico. Os dados devem ser entregues à unidade que controla o processo dentro de 1160ms, caso contrário, todo o processo será prejudicado. Os sistemas incorporados geralmente não precisam da taxa de transferência fornecida por pilhas de estoque, no entanto, se a latência, a confiabilidade e os tempos de entrega deterministas forem garantidos, eles podem aproveitar isso, mesmo que ele não use toda a capacidade de banda disponível. Multimídia A mesma observação sobre os requisitos em tempo real aplica-se a multimídia (transmissão de áudio e vídeo, teleconferência, etc.). Ao contrário dos sistemas incorporados, a latência não é tão crítica, sendo o primordial o tempo de entrega determinista e o alto rendimento. No futuro, podemos descobrir que o modelo de pequenas e pequenas mensagens de aplicativos de estoque comercial é incompatível com a abordagem multimídia baseada em fluxo. No entanto, não acreditamos que este seja o caso. Para testar a hipótese, nós construímos um aplicativo de teleconferência de prova de conceito em relação ao AMQP e consideramos que ele funciona sem problemas. Computação em grade Tendo quase os mesmos requisitos que a negociação de estoque, os sistemas de grade são áreas naturais para empregar pilha do MQ. As grelhas são icreasingly usadas nas finanças 19 e - não surpreendentemente - na negociação de ações em si, fornecendo uma solução para problemas computacionalmente caros, como gerenciamento de risco e negociação algorítmica 20. A bolha de baixa latência O mercado para soluções de baixa latência é muito animado e está expandindo estes dias. No entanto, alguns têm a sensação de que o valor do mercado é superestimado e que as corridas de armas de baixa latência continuam resultando na explosão da bolha, semelhante ao crash ponto-com do início dos anos 2000. Vamos examinar as possíveis causas da quebra do mercado: existem leis da física que colocam o limite inferior na latência. Especificamente, a velocidade da luz não pode ser excedida e, uma vez que a mensagem atinge esse limite, não haverá muito espaço para competição e a corrida de armas de baixa latência chegará ao fim. Os custos de mensagens rápidas estão crescendo constantemente. Uma vez que atingimos o ponto em que melhorar a latência exigirá investimentos que excedam os lucros que possivelmente possam render, o fluxo de dinheiro no mercado acabará. Os gastos não razoáveis ​​em soluções de baixa latência podem resultar em histeria, uma vez que o crescente mercado de baixa latência começa a encolher. A histeria pode fazer o mercado cair mesmo abaixo do seu valor real. Nossa visão dos problemas acima é a seguinte: a velocidade da luz é certamente uma barreira final, no entanto, como pode ser visto com os microprocessadores, as barreiras vistas como definitivas são bastante propensas a serem cruzadas uma e outra vez. No negócio de mensagens, por exemplo, vemos soluções emergentes de proximidade (velocidade de processamento do problema da luz, colocando as aplicações interdependentes fisicamente fechadas uma à outra) ou a tendência de otimizar a parte do software da pilha de mensagens, removendo a latência do ponto final em vez da latência no fio . Na verdade, não acreditamos que existam barreiras reais e não-penetraveis para impedir a corrida de armas de baixa latência pelo menos nos próximos anos. Embora o custo da mensagem de baixa latência cresça de forma constante, deve ser levado em consideração que o preço da tecnologia - hardware e software - está diminuindo constantemente ao mesmo tempo. O que custa 100 no ano passado, custa 50 hoje. Assim, mesmo em um mercado estável e não expansível, onde os gastos com TI se mantêm constantes, haverá uma demanda por novas soluções para acompanhar as novas tecnologias. A histeria pode acontecer a qualquer momento e não há como evitar isso completamente. No entanto, como as mensagens de troca de estoque são, de certa forma, um mundo para si, esperamos que a histeria seja restrita a este pequeno mercado turbulento, deixando o restante do mercado de mensagens intacto. Assim, as principais vítimas serão as empresas que fornecem soluções especializadas de negociação de ações em vez de mensagens de propósito geral. Especificamente, o projeto do MQ, aproveitando os recursos acumulados no mercado de TI focado na comercialização de estoque para desenvolver uma solução de mensagens de propósito geral, pode sobreviver à quebra do mercado, dependendo de sua presença em diferentes setores do mercado de mensagens. Conclusão O foco principal do MQ começa com a negociação de ações, porque esse mercado possui uma demanda bem definida e crescente de soluções high-end, e as opções para colaborações e retorno sobre o investimento são abundantes. No entanto, a construção de um sistema de mensagens de baixo custo com base em padrões que pode competir de frente com o melhor do mundo abre portas para muitos outros domínios também. Comentários: 0Distributed Messaging com ZeroMQ Um sistema distribuído é aquele em que a falha de um computador que você didn8217t mesmo sabia que existiam pode tornar seu próprio computador inutilizável. - Leslie Lamport Com o aumento da prevalência e acessibilidade da computação em nuvem, a arquitetura de sistemas distribuídos substituiu em grande parte as construções monolíticas. A implicação de usar uma arquitetura orientada a serviços, é claro, é que você agora tem que lidar com uma infinidade de dificuldades que anteriormente nunca existiram, como tolerância a falhas, disponibilidade e escalonamento horizontal. Outra camada interessante de complexidade é proporcionar consistência entre nós, o que em si é um problema cercado de pesquisas infinitas. Algoritmos como Paxos e Raft tentam fornecer soluções para gerenciar dados replicados, enquanto outras soluções oferecem consistência. Construir sistemas escaláveis ​​e distribuídos não é uma façanha trivial, mas pales em comparação com a construção de sistemas em tempo real de natureza similar. A arquitetura distribuída é um problema bem compreendido e o fato é que a maioria dos aplicativos tem uma alta tolerância à latência. Poucos sistemas têm uma necessidade demonstrável de comunicação em tempo real, mas os poucos que apresentam um desafio interessante para os desenvolvedores. Neste artigo, exploro o uso do ZeroMQ para abordar o problema da distribuição de mensagens em tempo real de forma escalável, considerando também a noção de consistência eventual. O Intelligent Transport Layer ZeroMQ é uma biblioteca de mensagens assíncrona de alto desempenho, escrita em C. It8217s não é um corretor de mensagens dedicado, mas sim uma estrutura de concorrência simultânea incorporada, com suporte para conexões de ponto final direto e desativado em uma variedade de transportes. O ZeroMQ implementa vários padrões de comunicação diferentes como request-reply, pub-sub e push-pull através de canais TCP, PGM (multicast), em processo e interprocesso. A falta flagrante de suporte UDP é, mais ou menos, por design porque o ZeroMQ foi concebido para fornecer entrega garantida de mensagens atômicas. A biblioteca não oferece nenhuma garantia real de entrega, mas faz o melhor esforço. O que o ZeroMQ garante, no entanto, é que você nunca receberá uma mensagem parcial, e as mensagens serão recebidas em ordem. Isso é importante porque os ganhos de desempenho do UDP8217s realmente só se manifestam em ambientes com perda ou congestionamento. A lista abrangente de padrões de mensagens e transportes por si só faz do ZeroMQ uma escolha atraente para a construção de aplicativos distribuídos, mas particularmente se destaca por sua confiabilidade, escalabilidade e alto rendimento. O ZeroMQ e as tecnologias relacionadas são populares dentro do comércio de alta freqüência, onde a perda de pacotes de dados financeiros geralmente é inaceitável. Em 2011, o CERN realizou um estudo comparando CORBA, Ice, Thrift, ZeroMQ e vários outros protocolos para uso em seus aceleradores de partículas E classificou o ZeroMQ o mais alto. O ZeroMQ usa alguns truques que permitem superar de fato os soquetes TCP em termos de throughput, como lote de mensagens inteligentes, minimizando os percursos da pilha de rede e desabilitando o algoritmo Nagle8217s. Por padrão (e quando possível), as mensagens são enfileiradas no assinante, o que tenta evitar o problema dos assinantes lentos. No entanto, quando isso não é suficiente, o ZeroMQ emprega um padrão chamado 8220Suicidal Snail.8221. Quando um assinante está funcionando devagar e não consegue acompanhar as mensagens recebidas, o ZeroMQ convence o assinante a se matar. 8220Slow8221 é determinado por uma marca de alta água configurável. A idéia aqui é que it8217s melhor falhar rapidamente e permitir que o problema seja resolvido rapidamente do que potencialmente permitir que os dados obsoletos fluam a jusante. Novamente, pense no caso de uso comercial de alta freqüência. Uma arquitetura distribuída, escalável e de mensagens rápidas O ZeroMQ é um caso convincente para uso como camada de transporte. Let8217s exploram um pouco mais para ver como ele poderia ser usado para criar uma estrutura de mensagens para uso em um sistema em tempo real. O ZeroMQ é bastante intuitivo para usar e oferece uma infinidade de ligações para vários idiomas, portanto, concentremo-nos mais nos paradigmas de arquitetura e mensagens do que o código atual. Cerca de um ano atrás, enquanto comecei a investigar o ZeroMQ, criei uma estrutura para executar sincronização de mensagens e documentos em tempo real chamado Zinc. Um documento 8220, 8221 neste sentido, é qualquer peça bem estruturada e mutable do documento de texto, folha de cálculo, tela, etc. Embora seja puramente acadêmico, o objetivo era fornecer aos desenvolvedores uma estrutura para a construção de experiências ricas e colaborativas de forma distribuída . A estrutura realmente tinha duas implementações, uma apoiada pelo ZeroMQ nativo, e uma apoiada pela implementação pura de Java, o JeroMQ 2. Ele foi realmente projetado para permitir que qualquer camada de transporte fosse usada. O zinco é estruturado em torno de apenas alguns conceitos básicos: pontos de extremidade, ChannelListeners, MessageHandlers e mensagens. Um ponto final representa um único nó em um cluster de aplicativos e fornece funcionalidades para enviar e receber mensagens de e para outros pontos finais. Possui canais de saída e de entrada para transmitir mensagens para pares e recebê-los, respectivamente. ChannelListeners essencialmente atuam como daemons ouvindo mensagens recebidas quando o canal de entrada está aberto em um Endpoint. Quando uma mensagem é recebida, ela é passada para um pool de threads para ser processada por um MessageHandler. Portanto, as Mensagens são processadas de forma assíncrona na ordem em que são recebidas, e como mencionado anteriormente, o ZeroMQ garante a entrega de mensagens em ordem. Como um lado, isso é antes de eu começar a aprender Go. O que faria para um substituto ideal para Java aqui como it8217s bastante adequado para o problema :) As mensagens são simplesmente os dados que estão sendo trocados entre os pontos finais, dos quais podemos construir com documentos e documentFragmentos. Um documento é o dado estruturado definido por um aplicativo, enquanto DocumentFragment representa um documento parcial, ou delta, que pode ser tão fino ou grosseiro quanto necessário. O zinco é construído em torno dos padrões de mensagens de publicação e de push-pull. Um ponto final atuará como o host de um cluster, enquanto os outros atuam como clientes. Com essa arquitetura, o host atua como editor e clientes como assinantes. Assim, quando um host dispara uma Mensagem, it8217s são entregues a cada assinante de um cliente de forma multicast. Por outro lado, os clientes também atuam como 8220push8221 Endpoints, sendo o host um 8220pull8221 Endpoint. Os clientes podem então empurrar Mensagens para a fila de mensagens dos hosts a partir das quais o host está puxando de uma maneira inicialmente inicial. Essa arquitetura permite que mensagens sejam propagadas em todo o cliente Clustera faz uma alteração que é enviada para o host, que propaga esse delta para todos os clientes. Isso significa que o cliente que iniciou a alteração receberá um delta 8220echo8221, mas será descartado ao verificar a origem da Mensagem, um UUID que identifica de forma exclusiva um Endpoint. Os clientes são então responsáveis ​​por preservar a consistência dos dados, se necessário, talvez por meio de transformação operacional ou mantendo uma única fonte de verdade a partir da qual os clientes possam conciliar. Uma das vantagens desta arquitetura é que ele escala razoavelmente bem devido à sua composabilidade. Especificamente, podemos construir nosso cluster como uma árvore de clientes com amplitude e profundidade arbitrárias. Obviamente, quanto mais escalamos horizontalmente ou verticalmente, mais latência introduzimos entre nós de borda. Juntamente com a eventual consistência, isso pode causar problemas para algumas aplicações, mas pode ser aceitável para outras pessoas. A desvantagem é que, inerentemente, introduz um único ponto de falha caracterizado pelo modelo cliente-servidor. Uma solução pode ser promover outro nó quando o host falhar e equilibrar a árvore. Mais uma vez, esse quadro era principalmente acadêmico e atuava como uma maneira para eu testar o controle do ZeroMQ, embora existam outras aplicações interessantes. Since the framework supports multicast message delivery via push-pull or publish-subscribe mechanisms, one such use case is autonomous load balancing. Paired with something like ZooKeeper. etcd. or some other service-discovery protocol, clients would be capable of discovering hosts, who act as load balancers. Once a client has discovered a host, it can request to become a part of that hosts cluster. If the host accepts the request, the client can begin to send messages to the host (and, as a result, to the rest of the cluster) and, likewise, receive messages from the host (and the rest of the cluster). This enables clients and hosts to submit work to the cluster such that its processed in an evenly distributed way, and workers can determine whether to pass work on further down the tree or process it themselves. Clients can choose to participate in load-balancing clusters at their own will and when they become available, making them mostly autonomous. Clients could then be quickly spun-up and spun-down using, for example, Docker containers. ZeroMQ is great for achieving reliable, fast, and scalable distributed messaging, but it8217s equally useful for performing parallel computation on a single machine or several locally networked ones by facilitating in - and inter - process communication using the same patterns. It also scales in the sense that it can effortlessly leverage multiple cores on each machine. ZeroMQ is not a replacement for a message broker, but it can work in unison with traditional message-oriented middleware. Combined with Protocol Buffers and other serialization methods, ZeroMQ makes it easy to build extremely high-throughput messaging frameworks. ZeroMQ8217s founder, iMatix, was responsible for moving JPMorgan Chase and the Dow Jones Industrial Average trading platforms to OpenAMQ 8617 In systems where near real-time is sufficient, JeroMQ is adequate and benefits by not requiring any native linking. 8617 Share this: