互連網金融代表一種海量資料高事務高速處理

標籤：http   io   使用   java   ar   strong   資料   問題   cti   

 

我們知道分布式系統是一種橫向水平伸縮(Scalable)方案，業務決定架構，

不是所有的業務都能夠採取水平伸縮就能解決效能問題的，問題的關鍵還在於資料之間的關係的強弱。

資料結構是不是表達資料之間的關係的強弱？

請注意結構這個詞語，當你看到建築結構，看到你的房屋結構時，你對結構一詞可能有更深入理解，既然是結構了，預設資料之間已經是一種強關係。

結構化資料和非結構化資料才是完整表達資料之間關係的強弱。

也就是說，水平伸縮方案適合非結構化資料，也就是資料之間是弱關係甚至沒有關係，這是很容易理解的；但如果資料之間是一種強烈的結構關係，我們稱之為彙總，怎麼辦呢？

有一條電腦原理：彙總必然引發爭奪，道理很簡單：僧多粥少，坐地鐵人多就要搶位置。

對於爭奪，傳統軟體的思路就是用鎖，某個時刻只能允許一個使用者操作這個資源，其他使用者線程必須等待其操作完成，於是互連網並排歡樂奔跑的使用者到這裡被迫強行停下來，等待，聽從指揮，如果允許，將被喚醒進入操作。

這種人為強制性的管理措施顯然帶來了很差的使用者體驗，甚至崩潰，同時也是不尊重底層辛苦勞動的CPU。因為線程是CPU私人財產，你不能將之充公後再進行管理分配，活活地折磨CPU。

當前對於爭奪比較優雅的解決方案是Reactive編程，也就是事件驅動編程。

對於有著強烈關係的彙總資料，我們必須將其作為整體對象來處理，當發生多個並發使用者操作這個整體對象時，我們也不能使用鎖來對使用者進行限制。

參考Java的NIO的Reactor原理，以及Node.js的原理，我們為每個彙總對象分配一個專門的守護者，所有有關這個資源的操作都交給這個守護者操作，通過一個無鎖的隊列進行快速排隊與守護者進行交接。

通過Reactive編程，我們還可以避免某個資源的操作佔據CPU線程太久，只要做完有關資源爭奪的那點事情後就趕快另派線程做剩餘的事情。這樣將串列順序操作和並行操作能夠有機細膩度的完美結合在一起。

那麼效能的擴充如何解決呢？不能通過水平擴充，就只能通過垂直擴充，這裡的垂直擴充不一定是向上擴充，比如PC換小型機，而是一種向下擴充，通過增加CPU核心數來提升彙總資料的並發處理能力。

總之，互連網金融代表一種海量資料高事務高速處理，類似高頻交易，與前期12306 或光大事件一樣，對於我們從業務資料分析方法，一直到底層組件代碼編程實現，都會提出新的挑戰，產生顛覆性編程革命。

互連網金融代表一種海量資料高事務高速處理