g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Dinghai Shenzhen Yatırım Bankacılığı Ticaret Sistemi İğnesi - Finansal Piyasa Veri Platformunun Mimari Tasarımı

Yazar Hao Xingyu

Düzenle Xiaozhi

Son yıllarda Fintech adlı bir terim sessizce ortaya çıktı. İnternet teknolojisi ve geleneksel finans endüstrisinin birleşimi gittikçe derinleşiyor Yatırım bankacılığı ticaret sistemi Dinghai Shenzhen'in piyasa veri platformu olarak, ne tür bir teknik geçmişe sahip? Mimari tasarımı nedir?

Yatırım bankasının Global Piyasalar veya Satış Ticareti departmanı temel olarak finansal kurumlar, işletmeler, hükümetler ve piyasa yapıcılar, döviz (FX) dahil olmak üzere çeşitli yatırım fonları (özel sermaye fonları, hedge fonlar vb.) Dahil olmak üzere büyük kurumsal müşterilere hizmet vermektedir. Kurumsal müşteriler ve yatırım bankası özel ticareti gibi çeşitli finansal ihtiyaçları karşılamak için sabit gelirli işlemler (Para Birimleri, Faiz Oranları ve Kredi), hisse senedi işlemleri (Hisse Senedi Senetleri), türev işlemleri (Türevler) ve yapılandırılmış ürünler (Yapılandırılmış Ürünler) vb.

Arka plan tanıtımı

Finansal arka plan

2008 mali krizinden veya Dodd-Frank Yasasından önce, yatırım bankaları iyi finansman kanallarına ve düşük maliyetli avantajlara güveniyordu. Niceliksel ticaret, riskten korunma, çapraz pazar arbitrajı ve kumarla uğraşan çeşitli yüksek kaldıraçlı özel mülk işletmeler (riskten korunma fonlarına benzer) vardı. Ve meşhur Goldman Sachs Global Alpha ve Morgan Stanleyin PDT'si (Proess Driven Trading) gibi diğer işlemler. Bu tür yüksek hacimli vurgunculuk işlemi sadece yatırım bankasının kendisini değil, aynı zamanda Citigroup ve Morgan Stanley gibi Trading Floor'dan yükselen birçok büyük adamı da yaptı. Eski CEO'su.

2008'den sonra, ABD hükümeti yatırım bankalarının özel ticareti durdurmasını açıkça istedi ve çeşitli büyük ölçekli kimya departmanları sert bir şekilde vuruldu. Ya çok küçük bir kendi işleyiş ölçeğini korumak için mücadele ettiler ya da ortadan kayboldular. Aynı zamanda, B2B (Broker'dan Broker'a) piyasalar ve B2C (Broker'dan Broker'a) piyasalar dahil olmak üzere, özellikle endeksler, opsiyonlar, döviz ve ulusal borç gibi yatırım bankalarının münhasır piyasa yapıcısı (Belirlenmiş Piyasa Yapıcı) otomatik işlemlerini kümelemiş, geliştirmiş ve zenginleştirmiştir. -to-Client) pazar.

teknik arka plan

Tanıtacağımız sistem platformu, tescilli ticari işlemleri desteklemekten piyasa yapıcıların otomatik işlemlerini desteklemeye kadar uzanıyor.

Wall Street büyük bankasının finansal iş gücüne ek olarak büyük banka olarak adlandırılmasının nedeni, teknik becerileri küçümsenemez, gücü Silikon Vadisi İnternet şirketlerinden daha az değildir. New York Borsası'nda, Nasdaq piyasasındaki işlemlerin% 70'i, yüksek frekanslı ticaret sisteminin büyük şirketler için vazgeçilmez bir sofistike üst düzey silah olduğu makine otomasyonlu işlemlerdir. Belirli bir tüccarın belirli bir gün, ay ve yılın belirli bir satırındaki Şişman Parmağını hatırlarsanız, Dow Jones Endeksi'nin her dakika 1.000 puandan fazla (yaklaşık% 10) düşmesine neden olursanız, bunun nedeni pozisyonunun yeterince büyük olması değil, açıkçasıdır. Makine sistemi algoritmasının zincirleme reaksiyonunun neden olduğu çığ etkisi. Wall Street'in tamamının bilişim sistemi üzerinde çalıştığını söylemek abartı olmaz, bilişim ticaret sistemi bir hata ile hapşırırsa küresel pazar sarsılır.

Başlıca endüstriler arasında, IT sistemi Morgan Stanley ve Lehman Brothers'ın altyapısı ile ünlüdür, Goldman Sachs ise kendi yolunda.Geliştirme dilinden veri tabanına kadar, kendi kendine yaratılmıştır.Mimari baştan bütünleşiktir. Tüm işlemler Veriler, temel veri tabanındadır ve sonraki tüm risk kontrolü, tasfiye, riskten korunma, finans, denetim ve raporlamaların tümü sorunsuzdur. Diğer hatlar düzinelerce sistemden yüzlerce sisteme kadar değişir ve çeşitli işlem verileri ileri geri iletilir, karmaşık ve anormal. Dahang'ın en iyi tasarımcıları dünyanın en iyi okullarının seçkin yetenekleridir. Çeşitli matematik, fizik ve bilgisayarlardan ve hatta Morgan Stanley gibi endüstri ustalarını Java'nın babasını işe almaya davet eden birçok doktora vardır. Manyetik çekiciliğini oynayın.

Platform işi

Bu makale, büyük bir bankanın Global Piyasa Verilerini (piyasa veri platformu), dahili ticaret sisteminin temel taşı olan piyasa verileri platformunu tartışmak için kullanır. Dinghai Shenzhen olarak adlandırılmasının nedeni, tüm işlemlerin piyasa verilerine, kotasyona ve döviz (FX), Kurlar, Kredi gibi diğer desteğe ihtiyaç duymasıdır, tabii ki bu sistem esas olarak sabit gelir ve döviz işlemlerini desteklemektedir (borsa verileri genellikle her bankada bağımsızdır. Sistem Desteği). Sabit gelir ticareti ve döviz, büyük ticaret hacminde açıkça görülen küresel ticaret hacminin 2 / 3'ünü oluşturuyordu. Üretilen günlük küresel piyasa verileri, gerçek zamanlı Ticker (teklif) verileri dahil on milyonları aşıyor.

Ticari kat

Yatırım bankacılığının önemli temel dayanaklarından biri olarak, önemli kullanılabilirliği ve başarı faktörleri aşağıdakileri içerir:

İş ihtiyaçları

Yüksek eşzamanlılık, yüksek verim, hızlı erişim, sorgulama pazarı verilerini destekler ve veriler kalıcı olarak depolanabilir
Dünya çapında birden çok veri merkezini, yakın erişimi, veri merkezleri arasında veri tutarlılığını destekleyin
Birden çok veri merkezi arasında yüksek kullanılabilirlikli HA 7 * 24 desteği, otomatik Yük Devretme
Düşük gecikmeli gerçek zamanlı piyasa veri kotasyon erişimini destekleyin
Geçmiş verilere erişim sorgusunu destekleyin
RPC, REST, Web, .Net, Excel vb. Gibi çoklu istemci protokol erişimini destekleyin.
Gerçek zamanlı sistem durumu izleme, otomatik çalıştırma ve bakım / dağıtım platformunu destekleyin

Veri gereksinimleri

Ana veri kaynakları Reuters (Thomson Reuters), Bloomberg (Bloomberg) ve CBOT (Chicago Vadeli İşlem Borsası) gibi büyük vadeli işlem borsalarından güncellenmiştir.
Günlük yeni piyasa verileri yaklaşık 20 g'dır;
Her gün yaklaşık 20-40 g Anlık Görüntü / EOD eklenir;
Sistemin önbellekte 1-2 aylık EOD Sanpshot'ı yaklaşık 100-150 g tutması gerekir;
Günlük küresel piyasa kotasyonu veri akışı 20-100 g'dır, tabii ki bunların çoğu, yüksek frekans bandı dakikada 100000 kez güncellenen veya zirve saniyede 1500-10000 kez güncellenen Ticker'dır (Kayan yazı verileri çoğunlukla makine stratejisi işlemleri için hizmetler sağlar, Kalıcılık) Genel olarak, önbelleğin yaklaşık 200g desteklemesi gerekir.Veri güvenliği ve artıklık göz önüne alındığında, toplamda yaklaşık 500g gereklidir.

Her gereksinim mantıklı geliyor, ancak bir mimarsanız, nasıl başlayacaksınız? Yazar bu sistemin asıl mimarı değil ve platform yıllar içinde doğal olarak gelişti, bugün problemi ters sırayla çözmeye ve gerçeğe adım adım yaklaşmaya çalışıyoruz. Ek olarak, hassas bilgiler nedeniyle bazı adlar / mimariler duyarsızlaştırılır, ancak genel tasarım fikirleri korunur.

Mimari tasarım

ürün modeli

Yukarıdaki gereksinimlere göre, aslında, genel olarak dağıtılması gereken yönü düşünebiliriz + önbellek + veritabanı / dosya + veri ambarı / büyük veri analizi vb.

Şu anda endüstri nispeten olgunlaşmıştır. Popüler büyük ölçekli dağıtılmış önbellekler arasında Oracle Coherence, GemFire, Redis, Memcached ve Apache Ignite bulunmaktadır. Ana özelliklerini karşılaştırmak ve analiz etmek için bir tablo kullanıyoruz.

Dağıtılmış önbellek karşılaştırması

Aslında, yukarıdaki iş ve veri gereksinimleri analizine göre, Ignite önce hariç tutulmuştur. Sadece 2014'te doğdu ve artık çok geçti. Ignite, zamandan bağımsız olarak büyük veri çağında doğdu, Hadoop ve Spark ile iyi bir entegrasyonla doğdu ve yükselen bir yıldız haline geliyor.

"İsviçre Çakısı" Redis için, istediğimiz ihtiyaçların çoğu karşılanabilir. Ne yazık ki, sunucu kümeleri ve küresel çok siteli dağıtım 3.0'dan önce iyi desteklenemez ve Memcached'in keskinliği İnternet önbelleği için daha uygundur;

Kralların en iyileri olan kalan Coherence ve Gemfire nasıl seçilir? Aslında, Gemfire ilk yıllarda çoktan Wall Street'e agresif bir şekilde girdi ve paralel hesaplamadan MapReduce omnipotence'a kadar zamana ayak uydururken küresel çok alanlı dağıtım gibi yatırım bankacılığı ihtiyaçlarına odaklandı. 2008 finansal krizinden sonra, daha da çalkantılıydı. Yongjin, büyük banka önbellek platformunu tekeline alıyor.İstatistiklere göre, küresel Gemfire hizmetinin 2 / 3'ünden fazlası Wall Street'te çalışıyor.

Gemfire elbette bir meseledir ve büyük şirketlerde, bazen birçok ürün stratejisi halihazırda belirlenmiştir (ürün olgunluğuna, kullanılabilirliğine ve sürdürülebilirliğe dayalı olarak). İyi bir ürün, başarının temel taşıdır. "Dünyanın en büyük online ticaret sistemi" olan "12306" daki üstün performansına gelince, yine kanıtlanmıştır.Ancak, iyi bir ürün, tüm senaryolara uyum sağlayabilen her derde deva değildir.

Verilere yüksek eşzamanlılık, hızlı erişim ve kalıcılığı destekleyin

Yüksek eşzamanlılık ve hızlı erişim, önbelleğe almanın ana amaçlarından biridir. Bunu yapmak için, uygulamalarımızın ihtiyaçlarını anlamalıyız ve verilerimizi doğru bir şekilde yönetmeliyiz. Söylendiği gibi, kendinizi ve düşmanı tanımak bir savaş olabilir.

Veri yönetimi

Veri yönetiminin temel konuları arasında uygulamanın yönetmesi gereken veri miktarı, örneğin 100g; metin gibi verilerin türü ve boyutu ve 500k dosya boyutu; veriler arasında herhangi bir bağımlılık var mı? Kalıcılık gerektirip gerektirmediği vb. Gibi verilerin yaşam döngüsü. Öte yandan, kaç eşzamanlı müşteri, sürekli sorgu veya olay aboneliği gibi kullanıcı erişim veri modu gibi bu verilerin nasıl kullanılacağını da anlamamız gerekiyor.

Sıralamak için bir grafiğe bakalım:

Önbelleğe alınmış veri analizi

Veri kapasitesi

Pazar verilerini önbelleğe almamızın ihtiyaçları için, yukarıdaki analiz muhtemelen yaklaşık 200 g gerektirir Veri güvenliği ve artıklık dikkate alındığında, toplamda yaklaşık 500 g gereklidir.

Disklerin ve veritabanlarının kalıcı kapasitesine gelince, diskler büyük bir sorun olmamalıdır.Veritabanları için her veri merkezi gerçek zamanlı veritabanı 500g ila 1T veya daha fazlasına ihtiyaç duyar ve geçmiş veritabanları yaklaşık 5T-10T'dir.Gerçek zamanlı veritabanlarının düzenli olarak arşivlenmesi gerekir.

Sunucu planlaması

64 bitlik bir platform (Linux) için, mevcut işletim sistemi tarafından desteklenen gerçek belleğin yaklaşık 192G (teorik üst sınır 16.8TB) olduğunu ve JVM GC'nin (1.6 / 1.7) yönetim belleği boyutunu önerdiğini göz önünde bulundurarak, bir Veri belirledik. / Anlık görüntü düğüm belleği 10-16 g'dır, tek bir veri merkezi toplam 30-50 düğüm gerektirir ve veri sunucusu olarak 3 fiziksel sunucu kullanılır;

Yukarıda bahsedilen sunucunun tahsisli bir veri sunucusu olarak kullanılması tavsiye edilir.Veriler diğer uygulamalardan ayrılır, bu da genişletme için uygundur ve karşılıklı etkiyi önler.Özellikle, dağıtılmış sistemdeki hizmetlerin birbirleriyle iletişim kurması gerekir.

Veri yedekleme

Veri yedeklemesi açısından, veriler için sıkı hata toleransı gereksinimleri varsa, 3 yedek kullanılması önerilir (temel sayı), 3 sihirli bir sayıdır, yani verilerin tam yedeklemesi güvenilirdir ve kaynaklar dikkate alınır. Veriler yanlış gittiğinde, bir kopya verileri geri yüklemek için kullanılabilir ve diğeri gerçek zamanlı olarak hizmet vermeye devam edebilir. Pazar verilerimizin esas olarak fiyat teklifi ve EOD'ye dayandığını göz önünde bulundurarak, tek bir veri yedekliliği kullanabiliriz (para tasarrufu) Tabii öyle olsa bile, daha sonra çok zor performans ve kararlılık problemleriyle karşılaştık, bu yüzden ilk önce zemini hazırladık.

Veri bölümü

Veri kümeleri ile depolama, endişesizdir. Bununla birlikte, yüksek eşzamanlılığı ve düşük gecikmeli erişimi desteklemek istiyorsanız, veri düzeninin dahili işlevi vazgeçilmezdir. Dağıtılmış önbellekte daha yaygın olarak kullanılan veri bölümleri, Partioned ve Replicated'dır. Çoğaltılmış bölüm, nispeten küçük veri hacmi için uygundur, ancak yüksek frekanslı okunan veriler ve verileri otomatik olarak tüm küme üyelerine yansıtılacaktır; Partioned, genellikle büyük veri hacmi, nispeten yüksek yazma gereksinimleri için uygundur ve dahili olarak ConcurrentHashMap'e benzer şekilde Bucket veya Redis'e bölünmüştür Depodaki Hash Yuvası.

Bu fikre göre, yaygın olarak kullanılan bazı yapılandırma bilgilerini Replicated olarak depoluyoruz ve gerçek pazar verileri Partioned kullanılarak depolama için her düğüme dağıtılıyor.

Veri kalıcılığı

Disk kalıcılığı

Veri kalıcılığı için, önbelleğe alınmış Diske Taşma ve veritabanı kalıcılığını desteklememiz gerekir. Disk kalıcılığı. Dağıtılmış önbelleklerin çoğu zaten LRU algoritmasını destekliyor ve disk alma / koyma işlemlerini destekliyor. Bazı Tahliye tetikleme eşiklerinin yapılandırılması gerekiyor. Eşik tetiklendikten sonra, en son kullanılan veriler LRU algoritmasına göre bellek önbelleğinden kaldırılacaktır. Diske.

Veritabanı kalıcılığı

Önbellek veritabanının kalıcılığına gelince, klasik algoritmalar kabaca Yazma ve Arkaya Yazma olarak ikiye ayrılır.

Önbelleğe Yazma, esas olarak önbelleğe alınan verilerin güncellendiği anlamına gelir; sistem, tümü tamamlanana kadar veritabanını eşzamanlı olarak günceller.

Önbelleğe Yazma

Yazma işleminin veri tutarlılığını doğru bir şekilde sağlayabildiği görülebilir, ancak elbette dezavantajları performansı etkileyecektir.

Önbelleğe Yazma, önbelleğe alınan veriler güncellendiğinde, sistemin güncellemeyi veritabanına son güncellemeyi beklemeden ileti ara yazılımına veya kuyruğa yazması ve ardından geri dönmesi ve ardından ileti ara yazılımının, güncelleştirmeyi veritabanına geciktirmesi anlamına gelir.

Arkaya Yazma Önbelleği

Write-Behind tarafından benimsenen veri stratejisi Nihai Tutarlılıktır.Performans iyileştirmeleri getirirken, kesinlikle veri kaybı ve gecikmenin maliyetini karşılaması gerekir.

Dağıtılmış önbellek sistemlerinin çoğu, veri güncelleme bildirimlerinin özelleştirilmesini ve Arkada Yazma gibi diğer güncelleme stratejilerini kolaylaştırmak için verileri önbelleğe almak için bir dinleyici sağlar. Aşağıdaki resim, olaylardan önce / sonra sağlayan Gemfire / Geode önbellek dinleyicisini göstermektedir. Write-Through stratejisini uygulamak için genellikle Cache Writer'ı ve Write-Behind stratejisini uygulamak için Cache Listeners'ı kullanabilirsiniz.

Önbellek Dinleyici

Pazar verilerinin hassasiyeti ve güncelliği ve sürekliliğin esas olarak raporlama, analiz ve arşivlemeye dayandığını göz önünde bulundurarak, Arkada Yazma önbellek güncelleme stratejisini uygulamak için EMS mesaj ara yazılımını kullanıyoruz.

Dünya çapında birden çok veri merkezini, yakın erişimi, veri merkezleri arasında veri tutarlılığını destekleyin

Dört merkez

Bu gereksinim, büyük bir bankanın giriş seviyesidir. Şubeler dünya çapında dağıtılır. Genellikle, New York, Londra, Tokyo, Hong Kong / Singapur gibi 4 konumun veri merkezleri olarak oluşturulması gerekir, böylece 4 konumun tümü yerel uygulamalara erişebilir ve veri merkezleri arasındaki verilerin karşılıklı olarak olması gerekir Yedekleyin, bir veri merkezi yanlış giderse, dünya çapında 24 saat kesintisiz işlemlere ulaşmak için otomatik olarak diğer birkaç veri merkezine geçecektir. Aslında, tıpkı küresel pazar gibi, Avustralya ve Tokyo ilk açılanlar, ardından Asya kapandığında Hong Kong / Singapur Londra açıldıktan sonra ertesi güne kadar New York başladı.

Küresel çoklu veri merkezleri (WAN)

Yukarıdaki resim, dünyadaki birden çok veri merkezine bir örnektir. Sistemimizin 4 veri merkezini (Londra, New York, Tokyo, Hong Kong) desteklemesi gerekir.

Dağıtılmış önbellek ürünlerinin çoğu, küresel çoklu veri merkezi (WAN) yapısını ve veri merkezindeki birden çok site arasındaki iletişim ve koordinasyon yapılandırmasını destekler Gemfire / Geode'un çoklu veri merkezi, aşağıdaki şekilde gösterilen yapılandırmadır.

WAN Sitesi XML yapılandırma bilgileri

Her veri merkezi kendi dağıtılmış kümesini oluşturur ve veri merkezleri, yukarıdaki temel yapılandırma yoluyla bağlanır ve paylaşılır.

veri iletişimi

Her veri merkezi, TCP / IP keşfi, eşzamansız iletişim, Çoğaltma, vb. Gerçekleştirmek için Konumlandırıcı, Gönderici, Alıcı kullanır. Her veri merkezi veya kümede gönderen ve alıcı olarak Alıcı bulunur.

Gönderen, Konum Belirleyici aracılığıyla uzak kümenin Konum Belirleyicisini bulur ve uzak Alıcı, isteği kabul eder ve uzak ana bilgisayar / bağlantı noktası bilgilerini gönderir. Birden çok paralel Göndericiyi (Parallel Gateway Sender) da yapılandırabilirsiniz.

WAN Gönderen / Alıcı

Ve dahili olarak, Queue, bir önbellek eşzamansız iletişim kanalı olarak kullanılır.Ack mekanizması sayesinde, iki veri merkezi, verilerin bütünlüğünü sağlar.Aynı zamanda, Sıra, senkronizasyonu eşzamansız olarak değiştirir, verimliliği ve eşlemeyi aynı anda artırır. Bir veri merkezindeki bir sorun diğer verileri etkilemez. merkez. Birden çok veri merkezi, döngü veya tam ağ topolojisi ile bağlanabilir.

Genellikle birden fazla veri merkezi çöktüğü için daha zor sorunlar, eşzamanlılık altında veri tutarlılığının nasıl sağlanacağı ve WAN'ın çökmesinin neden olduğu veri gecikmesidir.

Veri tutarlılığı

Birden çok veri merkezi, birden çok veri merkezinde verilerin birleştirilmesini sağlamak için nihai tutarlılık stratejisini benimser.Varsayılan olarak, birden çok veri merkezi bir Girişi eşzamanlı olarak güncellediğinde, sistem, olayın zaman damgasına göre son veri olarak daha yeni güncellemeyi seçer; Ekstrem durumlarda, zaman damgaları tamamen aynıysa, uzaktan güncelleme varsayılan olarak seçilir (veri tutarsızlığına neden olabilir). Sistem ayrıca güncellemeleri seçmek için kendi stratejilerini tanımlayabilir.

Pazar verilerinin doğruluk gereksinimleri göz önünde bulundurulduğunda, belirli bir tür verinin esas olarak işletmeden belirli bir veri merkezinde, yani çözülecek özelleştirilmiş çatışma önceliği stratejilerinde kullanılmasını şart koşuyoruz.

Veri gecikmesi

Küresel veri merkezlerinde veri iletimi için, çoğaltma genellikle ağ, trafik ve milisaniyeden birkaç saniyeye kadar değişen kendi iletim boyutu gibi çeşitli faktörlerle sınırlıdır ve veri gecikmesi büyük zorluklarla karşı karşıya ve kontrol edilemez.

Bununla birlikte, iş dünyasındaki veri merkezlerinin çoğunun yalnızca özerkliğe ihtiyaç duyması biraz sevindiricidir.Örneğin, Tokyo veri merkezi, açılış saatleri sırasında piyasa verilerini almak için çoğunlukla Tokyo veri merkezini ziyaret eder; her veri merkezinin yalnızca piyasa kapandıktan sonraki günün EOD verilerini kaydetmesi gerekir. Çoğaltılan, dünyadaki diğer veri merkezleriyle senkronize edilebilir ve gecikme iyidir.

Bununla birlikte, küresel döviz piyasasına Londra'nın (döviz merkezi) hakim olduğu düşünüldüğünde, Tokyo ve Singapur'daki birçok FX sistemi gerçek zamanlı piyasa kotasyonları gerektirir. Şu anda iki çözüm vardır:

İlk olarak, biraz daha düşük gecikme gereksinimleri olan sistemler için, doğrudan Londra veri merkezine bağlanın.

İkincisi, gerçek zamanlı teklifler gibi düşük gecikmeli veriler için TIBCO RV (Rendezvous) Yönlendirme, yüksek gerçek zamanlı gereksinimleri elde etmek için güvenilirliği feda ederek UDP protokolünü kullanır ve Tokyo, Tokyo, Hong Kong ve benzerlerini Londra'dan doğrudan yönlendirir. TIBCOnun iki amiral gemisi ürünü EMS ve RV, mesaj ara yazılımında uzmanlaşırken, RV küçük mesajlar ve yüksek gerçek zamanlı senaryolar için UDP protokolünü kullanır. TIBCO RV Güvenilir modunun kullanılması, şimdiden 1,5 milyon / saniye, 500.000 / saniye kabul haber yayın performansına ulaşabilir.

TIBCO RVRD (Rendezvous Routing Daemon)

Yukarıdaki iki çözüme göre, iş ihtiyaçları şimdilik karşılanabilir.

Yüksek verim, düşük gecikmeli gerçek zamanlı piyasa veri teklifi

Yüksek verim

Çıktı

Sisteme başlangıçta birkaç büyük sistem tarafından erişildi. Birkaç yıl içinde, büyük müşteriler 10-20'den fazla yüksek frekanslı sisteme ve diğer 10-20'den fazla ortak sisteme (raporlar, toplu işleme vb.) Erişime sahip ve muhtemelen birkaç bin Bireysel kullanıcılar özelleştirilmiş bir tarayıcı aracılığıyla erişim sağlar. Yüksek frekanslı sistem, yüksek frekanslı okuma / yazma işlemlerini ve bireysel kullanıcılar çoğunlukla salt okunur sorgular içerir. Başlangıçta, veri güncellemesinin esas olarak yukarıda bahsedilen Reuters, Bloomberg ve küresel vadeli işlem borsalarından geldiğini düşünmüştüm. Daha sonra, dahili sistemin de büyük miktarda veri yayınladığı ve abone olduğu keşfedildi. Yayın içeriği esas olarak dahili analiz ve düzeltmeden sonraki veri sürümüdür, dolayısıyla veri miktarı eşdeğerdir. Birkaç kez arttı.

Olay Odaklı Mimari

Sistem platformunun genel mimarisi açısından, olay odaklı bir mimari benimsedik ve sistem entegrasyonunu ayırırken sistem entegrasyonu sağlayan bir sistemler arası iletişim olarak TIBCO EMS mesaj ara yazılımını kullanıma sunduk.

Olay Odaklı Mimari

MQ, RabbitMQ ve gelecek vadeden Apache Kafka yerine neden EMS'yi seçtiğinizi sorarsanız, bu soru şirketin kendi stratejisinde ve TIBCO'nun kendi ikilisinde yatıyor.

Yüksek verim ve büyük eşzamanlılıkla EMS Kuyruğu da çok şey yapabilir. Sistem, veri sorgulama, veri güncelleme, abonelik, yayınlama, EOD ve hatta veri merkezleri arası veri replikasyonu için düzinelerce Kuyruk ve Geriye Yazma senkronizasyon veritabanı için çeşitli JDB Kuyrukları tasarladı. Sistemin, platform kararlılığını ve iş hacmini sağlamak için daha güçlü ve olgun ara yazılım ürünleri kullandığı görülebilir.

Düşük gecikme süresi

Çoğu zaman, sistemin QPS konsantrasyonunu birkaç yüz ile birkaç bin arasında, hatta on binlerde zirveye çıkarması gerekir.Bunlar In Memory Grid önbelleğinin avantajlarıdır. İstatistiksel bir web sitesi Gemfire 8 gibi verileri 4 düğüm gömülü modda yayınlar, 4G Yığın, 1G bant genişliği, 10 İş Parçacığı, 10 dakikalık ortalama basit okuma işlemi 70.000 / sn'ye ulaşabilir ve ortalama yazma 23.000 / sn'dir.

Piyasa verileri, verilere karşı oldukça hassastır ve özellikle FX gibi piyasa verilerine dayanan otomatik işlem sistemleri için sorgular genellikle milisaniyelerdir. Bir yatırım bankası yöneticisinin, bir komisyoncu veya tüccar rakibinden 5 milisaniye daha yavaş bir otomatik işlem platformu kullanıyorsa, toplam gelirin (Gelir)% 1 veya saniyede milyonlarca dolar (dahil olmak üzere) kaybedebileceğini söylediğine dair bir şaka duymuştum. Kar artı maliyet). Biraz şaşırtıcı bir şekilde abartılıyor, ancak düşük veri gecikmesinin önemini görmek yeterli.Ayrıca, birçok ticaret sistemi pazar veri platformumuza dayandığından, düşük gecikme, pazar platformunun başarısı için çok önemlidir.

Gerçekte, Murphy yasasını da uyguluyoruz ve birkaç dakikadan fazla gecikmeye yol açan sorunlarla karşılaşıyoruz. Neyse ki, bunu zamanında, konumlandırıp yaklaşık 15 dakika içinde hallettik, ancak aynı zamanda büyük ölçekli üretim kazalarına da neden oldu. Vakit nakittir. Geçmiş için Teklif, ticaret sistemi çok hassas olacaktır.

Veri bölümü

Bazı yüksek frekanslı veri sorguları için, sistem veri bölümü düzeyinde uygun bir yapıya sahibiz. Küme verileri Replicated olarak yapılandırılır ve kümedeki herhangi bir veri düğümü önbelleğe alınmış verileri içerir. Küme istemcisi için (terminal dışı istemci / sistem), bir tane de tutar. İstemci önbelleği paylaşılır, bu nedenle genel performans mükemmeldir.

Verim iyileştirmesi

Diğer dağıtılmış önbellek verilerinin çoğu için bölümlenmiş depolamadır. Basit bir get (Anahtar) ise, tüm dünya resmi verilerdir. Gerçek hayattaki sorgular, izin doğrulama, veri doğrulama, temel veri ilişkilendirme, diğer ilgili veri sorguları, veri filtreleme vb. Dahil olmak üzere, KV önbellek işlevi ile sınırlıdır ve bazı yüksek düzeyli önbellekler zaten OQL'yi desteklemektedir. SQL, hatta indeks (İndeks), tabii ki indekse gelince, eğer veri salt okunur veya düşük frekanslı güncelleme ise, güçlü bir araçtır, aksi takdirde ek güncelleme yükünü taşıyacaktır.

Harita indirgeme

Ek olarak, dağıtılmış depolamaya ek olarak, dağıtılmış depolamanın elbette paralel hesaplama ve MapReduce yeteneklerini de kullanması gerekir.

MapReduce Yürütme

Dağıtılmış önbelleklerin çoğu, dağıtılmış hesaplamaları / sorguları destekler.Karmaşık hesaplamalar ve sorgular, hesaplamaları gerçekleştirmek için genellikle işlevler içinde kapsüllenebilir, dağıtılabilir veya kümelere dinamik olarak dağıtılabilir. Verimlilik açısından, dinamik dağıtım daha iyi izolasyon ve ayırma sağlarken, her bir düğüme ayrı ayrı dağıtmak daha verimli olabilir.Elbette, serileştirme ihtiyacı nedeniyle, bir miktar performans feda edilir (çoğu dağıtılmış sistem kendi serileştirme veya kullanımlarını yeniden uygular. Apache Thrfit gibi çerçeveler, Java'nın kendi serileştirme verimliliğini engeller).

Sürekli sorgulama / abonelik

Abonelik sisteminin kullanıcılarına gerçek zamanlı teklif bilgileri göndermek için sorgulamaya veya abone olmaya (Abone) devam etmek, gizlemede sorgu gecikmesini azaltmanın başka bir yoludur.

Yayın / çok noktaya yayın ağı

Veri gecikmesine yönelik bir başka aşırı yaklaşım, yukarıda bahsedilen TIBCO RV gibi verimli bir yayın / çok noktaya yayın ağı sunmaktır.Yayınlama ve abone olma uygulamasının tanıdık MQ / JMS modeli ve yenilikçi bilgi oluşturma ile aynı olmadığını unutmayın. Sanal Paylaşımlı Otobüs (TIB).

RV, geleneksel Sıra tabanlı sunucu tarafı önbelleğe alma tasarımını kullanmaz.IP katmanı yayın / çoklu yayın modunda mesajı doğrudan RV ağına gönderir ve UDP protokol yönlendirme yayını aracılığıyla RV ağındaki tüm düğümlere iletir ve alıcı uç Konu kullanır Alınan mesajı eşleştirmek ve istemci kuyruğunda önbelleğe almak için. Sunucu tarafında mesaj kuyruğunu önbelleğe almak için Topic'in kullanıldığı geleneksel MQ / JMS yöntemiyle karşılaştırıldığında, hız çok daha hızlıdır.Elbette, hızlı hızın tadını çıkarırken, aynı zamanda mesaj kaybı riskini de taşımanız gerekir. Gerçek zamanlı piyasa fiyatları için tolere edilebilir.

Ayrıca RV, özel uygulama yoluyla UDP protokolünü genişleten ve belirli bir derecede iletim güvenilirliği sağlamak için bir mesaj paketi inceleme ve yeniden iletim mekanizması ekleyen RV Güvenilir modunu da sağlar. Ayrıca, bir adım daha ileri giden ve iletim güvenilirliğini sağlamak için bir mesaj onay mekanizması ekleyen RVCM modu da vardır. Elbette, bu iki modun performansı doğal olarak azalır, çünkü sözde balık ve ayının pençesi her ikisine de sahip olamaz.

Yüksek frekanslı yazma

Sistem, yüksek frekanslı yazmanın neden olduğu alışılmadık bir sorunla karşılaştı. TIBCO RV kullanan yukarıda bahsedilen yayın farklı bir yaklaşımdır, ancak aynı zamanda bu yüksek frekanslı verilerin de sonraki kullanım için dağıtılmış önbelleğe yazılması gerekir.

Bununla birlikte, beklenmedik olan şey, çoğu ticaret / serbest bırakma sisteminin aynı anda düzinelerce iş parçacığını açmak ve aynı anda serbest bırakmak için kullanılmasıdır.Daha kötüsü, hemen hemen tüm sistemlerin çoğu, piyasa her hafta veya her gün açılmadan önceki saatte piyasaya sürülmeye ayarlanmıştır. / Sorgu, ani bir artış etkisi ile sonuçlanır. Aşağıdaki şekil, sistemin belirli bir günde 3 dakikalık yazma veri hacminin istatistikleridir.Yüksek frekansın ikinci dakikadan itibaren yazdığı görülebilir.İlk 3, 171.000'e çıkar. Sistem istatistikleri dakikalara dayandığından, saniyedeki yazma işlemlerinin kabaca bir tahmini 2800-17000 + 'e yakın (buradaki yazma işlemimizin basit bir yazma işlemi olmadığını ve çok adımlı iş mantığının içeride örtük olduğunu unutmayın), bir bilgisayar korsanı saldırısından daha az değildir ve bu yüksek frekanslı yazma baskısı, şiddetli olduğunda tüm kümeyi doğrudan etkileyecektir. İstikrar.

Ve bu, güçlü bir sistemin geçmesi gereken acı verici bir süreçtir ve baştan düşünmeye gerek yoktur ve tasarlanamaz.

Yüksek frekanslı yazma TOP-33 dakikada

Bu, hala çözülmekte olan başka bir kanlı gerçek durumdur. Bununla birlikte, İş Parçacığı Dökümü, GC günlüğü ve dağıtılmış önbellek Hata Ayıklama Düzeyi günlüklerini analiz ederek, kabaca yüksek frekanslı yazmalardan kaynaklanacak şekilde konumlandırılır. Aynı zamanda, verilerin diğer düğümlerle iletişim kurmak için senkronize edilmesi ve yedekli olarak yedeklenmesi gerekir. Tüm kümedeki tüm düğümler yüksek frekanslı iletişimde olduğunda Etkileşim sırasında, tüm düğümler son derece meşguldür.Birçok düğüm Ack için beklemektedir ve daha fazla isteği kabul edemez. Sonuç olarak, birçok düğüm yanıt vermiyor gibi görünür ve Hung bile Depature'u kümeden zorlamak için oradadır.

Program

Mevcut geçici çözümde düğüm, ACK zaman aşımının zorla bir istisna atmasını ve kaynakları serbest bırakmasını bekler, bu da tüm küme üzerindeki baskıyı azaltır.

Ek olarak, veri bölümünü yeniden planlamaya hazırız.Yüksek frekanslı yazma / güncelleme verileri için Yedeklilik Kopyası, düğümler arasındaki iletişimi azaltmak için gerekli değildir ve ağda yaygın olarak kullanılan akımı sınırlayan sızdıran kova algoritması (Leaky Bucket) veya dağıtılmış KV güncelleme algoritması için daha uygundur Conflation merge algoritması.

Konflasyon algoritması örneği

Dağıtılmış ortam, büyük depolama ve verimli paralel bilgi işlem performansı elde ederken, aynı zamanda son derece karmaşık hata ayıklama ve dağıtılmış sorunların giderilmesini de beraberinde getirir.

Yüksek kullanılabilirlikli HA, otomatik Yük Devretme

Yüksek kullanılabilirlik (HA High Avaiablity) genellikle sistem hizmetlerinin yüksek kullanılabilirliğini ve yüksek veri kullanılabilirliğini içerir.Genel uygulama, önbelleğe alınmış veriler, hizmetler veya gözlemciler, veritabanları ve hatta veri merkezlerinden bağımsız olarak zaman yedekliliği için yer değişimi yapmaktır.

Yüksek düzeyde kullanılabilir veriler

Dağıtılmış olarak yüksek veri kullanılabilirliğinin yaygın uygulaması, 1-3 veya hatta birden fazla yedekleme olabilen veri yedekliliğidir (Artıklık Kopyası). Deneyimler gösteriyor ki, 1 nokta yedeklilik genellikle yeterli.Veri bütünlüğü için katı gereksinimler varsa, 3 kopya yeterlidir.Aynı zamanda, ana verilerde sorunlar olduğunda, yedekleme 1, veri kurtarmayı sağlamak için eşzamanlı yedekleme 2'yi kullanmak için kullanılabilir. Ancak yedekleme sonuçta sermayeyi ve performansı etkileyecek bir kaynaktır.

Yüksek düzeyde kullanılabilir hizmet

Bir veri merkezi için olağan uygulama, kümenin dahili düğümleri olan yükü ve yüksek kullanılabilirliği elde etmek için ters proxy (Nginx gibi), çift makineli çalışırken bekleme (Kalıcı, DR) veya yük dengeleme (F5, LVS) aracılığıyla birden çok aynı hizmeti açmaktır. Ana seçim algoritması da dahil olmak üzere aynı anda birden fazla Konumlandırıcı açarak tek noktaların önüne geçin.

Yük devretme

Yük Devretme için, küme içinde genellikle zaman uyumlu / asenkron veri yedekleme ve kurtarma, ana bilgisayarın yeniden seçilmesi ve düğüm izolasyonu gibi kendi kurtarma yöntemleri vardır.

Kümeler arasındaki gereksinimler nispeten yüksekse, genellikle etkin bir yedekleme kümesi / veritabanı kurulur ve platformumuz ek olarak her veri merkezi için bir DR (felaket kurtarma) kümesi oluşturur.

Sistem Yük Devretme

Çoğu sistem / küme yük devretme manuel müdahaleye dayanır. Nedeni, otomatik yük devretmenin elde edilememesi değildir, ancak çoğu, hızlı ve sorunsuz anahtarlamayı tanıyacak kadar akıllı değildir.

İkili makine / ikili küme yoluyla felaket kurtarma, çok fazla kaynak tüketir ve çoğu zaman kaynak israfı durumunda harcar, ancak finansal işlemler için bu gerekli ve gerekli bir yatırımdır.

Veri merkezlerinde yük devretme daha akıllıdır ve risklere karşı daha dayanıklıdır ve şu anda gelecekteki hedeflerden biri olarak listelenmiştir.

Mesaj ara yazılımı

Mesaj ara yazılımı da yüksek kullanılabilirlikte önemli bir rol oynar.Belirli hizmetler ve veritabanları kullanılamadığında, mesaj ara yazılımı mesajların, olayların ve verilerin kaybını önlemek için geçici bir taşıyıcı görevi görür.Bu nedenle, mesaj ara yazılımı finans kurumlarında yaygın olarak kullanılmaktadır. Evlat edinme nedenlerinden biri.

Geçmiş verilere erişim sorgusunu destekleyin

Tarihsel piyasa verileri, gerçek zamanlı ticaret sistemleri için çok az önem arz etse de, birçok ticaret stratejisi için analiz sistemi büyük önem taşır ve çoğu zaman birkaç dönem için tarihsel büyük veri bilgilerinin elde edilmesi gerekir.

Büyük tarihsel verilerin yönetimi, sorgusu ve kullanımı, sistemimiz için büyük bir zorluk haline geldi. Geleneksel ilişkisel veritabanları büyük verileri destekleyemez.Veri ambarları veya Küpler bile önceden özelleştirilmelidir, bu da gerçek zamanlı kullanımın elde edilmesi zordur.

Planımız elbette üç büyük veri platformu olan HBase + HDFS / Hadoop + ZooKeeper kardeşlerinden yararlanmaktır.

ZK + HBase + Hadoop / HDFS

Neyse ki, platformumuz heterojen olay güdümlü bir mimari benimsediği için, veri depolama modülüne bir HBase mesaj kuyruğu eklememiz ve mevcut platform işlevlerini ve performansını etkilemeyecek şekilde bir adaptör aracılığıyla doğrudan HBase'e kaydetmemiz yeterli. Sonra geliştireceğiz. Diğer sistemlerin kullanması için yeni API'yi açmanız yeterlidir. Platform hala geliştirme ve test aşamasındadır.

Birden çok protokol ile istemci erişimini destekleyin

Olay odaklı mimari

Platform mimarisinin tamamında, olay odaklı mimarinin kendisi platform heterojendir, ayrıştırılmıştır ve halihazırda çeşitli platformlar, diller ve sistemlerle iletişim kurabilir ve kenetlenebilir.

RPC-X

Yatırım bankasının bilgi altyapısı bölümünde, bu ileriye doğru bir başka büyük adımdır. Tüm departmanların sistemleri arasındaki iletişimi entegre etmek için dahili bir RPC veya SOA platform çerçevesi geliştirdik. Şimdilik buna RPC-X diyelim.

Teknik mimari tasarımı hassas nedenlerden dolayı detaylandırılmamıştır. Genel amaç, Unix, Linx, Windows vb. Çapraz platformların yanı sıra diller arası C / C ++, Java, .NET vb. Dahil olmak üzere şirketin dahili sistemleri arasındaki iletişimi entegre etmektir.

İşlevleri şunları kapsar:

-Sistemler arası RPC iletişimi

Şirketin dahili mesaj ara yazılım platformunun iletişim ayrıntılarını özetleyin
Şirket içindeki her Bölgenin ve veri merkezinin iletişim ayrıntılarını paketleyin
Coğrafi ve saat dilimi bilgilerini kapsülleyin
Her hizmet / istemci yapılandırmasına gerek kalmadan, merkezi yapılandırma hizmeti kataloğu yönetimi sağlayın
Çapraz platform, diller arası iletişim
Sistemler arasında yüksek kullanılabilirlik ve yük devretme
Event Bus hizmeti sağlayın
OSGi ile uyumlu
RPC, EMS, RV, REST, Yayın, Talep Üzerine, İzleme, Konu sağlayın

Gerçek zamanlı sistem durumu izleme, çalıştırma ve bakım / dağıtım

Sistem izleme ve otomatik çalışma ve bakım ise sistem platformunun olgunluğunu değerlendirmeye yönelik göstergelerden biridir.

Sistem izleme

Varsayılan dağıtılmış küme ürünü Gemfire / Geode'un yerleşik küme izleme ve önbellek performansı izleme araçlarına ek olarak, pazar veri platformu ayrıca tüm veri merkezi kümelerindeki düğüm hizmet durumunu, EMS mesaj kuyruğunu ve belleği gerçek zamanlı olarak izlemek için bağımsız olarak bir gösterge tablosu (Gösterge Tablosu) geliştirir. Her bileşenin kullanımı, CPU kullanımı, Sinyal, disk, veritabanı ve diğer sağlık durumları.

Sistem işletimi ve bakımı

Sistemin çalıştırılması ve bakımı halka açık bir platformdur ve altyapı departmanı ayrıca, ortama göre gerçek zamanlı ve dinamik olarak dünyadaki çeşitli veri merkezlerine dinamik olarak dağıtılabilen ve her bileşenin çalışma durumunu izleyen ve hatta her bileşenin çalışma saat dilimini ve Sheduler'ı yapılandırıp yönetebilen kendi otomatik dağıtım platformuna sahiptir.

Buna ek olarak, ilgili platform sistemi düzeyinde, bazı JMX arayüzleri, çevrimiçi olarak dinamik olarak işletim stratejilerini ayarlamaya ve çeşitli acil durumlara yanıt vermeye aktif olarak maruz kalacaktır.

Şu anda O&M, otomatik İşletme ve Bakım ve DevOps'tan hala çok uzak.

Sonuna yaz

Kısa bir giriş, ters sıra analizini simüle etmeye çalışın ve dağıtılmış bir piyasa veri platformu oluşturmaya çalışın.Geleneksel finansal sistem platformlarının ihtiyaçları, İnternet platformlarıyla tamamen karşılaştırılamayan doğal özellikleri ve karmaşıklığına sahiptir, ancak teknoloji okyanusunda birlikte çalışabilir. Finansal denetimin rahatlaması ve sürekli yenilik beklentisiyle, finans ve internetin en üst teknolojisi, büyük veri, bulut bilişim, konteynerler, blok zinciri, yapay zeka, derin öğrenme ve diğer teknolojilerin daha iyi bir şekilde birleştirileceğine inanılıyor.

yazar hakkında

Halen Nomura'da teknik Başkan Yardımcısı olarak çalışan Hao Xingyu (Erix), 2004-2015 yılları arasında Citi'de çalışmış, teknoloji araştırma ve geliştirmeye katılmış ve teknik Başkan Yardımcısı ve diğer pozisyonlarda görev yapmıştır. Finansal sistem teknik mimarisine ve en son teknolojiye odaklanın ve sigorta, operasyonel risk, kredi riski, kredi sistemi, banka stres testi ve sabit gelir dahil olmak üzere ilgili sistem platformlarının tasarımına ve geliştirilmesine katıldı. Kişisel teknik kamu numarası "TechBooster".

Akıllı Nesnelerin İnterneti gelgitini kaçırmak istemeyin, Huawei LiteOS'a yabancı olmak istemeyin, kodlama hayatınızın etkisiz kalmasını istemeyin, iyi fikirlerinizin midenizde çürümesini istemeyin ... Ardından makalenin sonunda kayıt olmak ve 7 Ocak'ta katılmak için "Orijinal metni okuyun" u tıklayın. Huawei LiteOS Hackathon'un ev sahipliği yaptığı ve 8'inde Pekin'de InfoQ tarafından ortaklaşa düzenlenen Huawei LiteOS Hackathon. Arkadaşlarınızı arayın ve 2 gün 1 gece çılgınlığı yaşayın. (Veya doğrudan kaydolmak için aşağıdaki QR kodunu tanıyın.)

Bugünün Tavsiyesi

Okumak için aşağıdaki resme tıklayın