【視點】混合型事務處理

線上事務處理一般可分為線上交易事務處理（OLTP）和線上分析事務處理（OLAP），也有叫聯機交易處理和聯機分析處理。而混合型事務處理（HTAP）則融合了上述兩種事務類型，即一個系統同時很好的滿足OLTP和OLAP的需求。 
   早在2014年Gartner的報告就明确指出了：“混合型交易/分析事務處理（HTAP）将幫助應用提升場景識别能力，增強業務靈活性。這将引發由記憶體計算技術催生的現有架構和IT科技的劇變”。
    電子商務領域就有很多混合型事務處理的例子，比如信用卡消費，既要計算目前消費，又要按T+1統計剩餘額度；個性化引擎，既要應對當下行為，又要根據偏差調整推薦算法；物聯網事件處理器等等。                  

當然作為這樣一套系統，首先它需要滿足一些非功能的需求，包括每秒10萬次以上的并發處理能力；可以與應用同步線性擴充；零網絡延時、零資料丢失。在功能性上，它需要支援純Java技術棧的業務邏輯以及可以接受來自流處理架構（[【觀察】常用的流式架構（一）-- Storm與Samza](https://yq.aliyun.com/articles/750868?spm=a2c4e.11155435.0.0.409a33129XlKTs)；[【觀察】常用的流式架構（二）-- Spark與Flink](https://yq.aliyun.com/articles/750869?spm=a2c4e.11155435.0.0.409a33129XlKTs)）的消息，并能對其中的狀态資訊進行快速識别。           

上圖的模型是最早的OLTP與OLAP并存模型，沒有任何的分離處理，直接面臨的問題就是中間關系型資料庫在承載多分析子產品讀取資料的同時，源應用程式的寫操作會處理不過來。于是企業的資料架構又會在應用與結構化資料庫之間加入一層操作性資料庫（ODS）。           

ODS确實很好的分解了OLTP與OLAP的資源配置設定，但是首先會帶來資料備援，其次由于ETL轉置需要時間，是以資料倉庫中的資料距離實時性一定會有不小的差距，進而就導緻報表資料的不及時。并且ETL任意環節的故障都會導緻資料倉庫的失真。
    随着記憶體計算技術的發展，并且借助多版本并發控制（MVCC）能力，HTAP已經可以将OLTP和OLAP事務放在一個資料庫上處理了。           

這類資料庫市面上的選擇還不少，尤以VoltDB，NuoDB和MemSQL為首，程式内置MVCC功能可以對頻繁更新的資料記錄版本号，以建立緩存序列供OLAP差異化調取。           

随着微服務在企業中的普及，不同的微服務可以挂接不同的HTAP資料庫以滿足多并發更新與讀取的需求。當然如果目标微服務沒有很大的并發更新量的情況下，多個微服務共享一個HTAP，根據Schema分庫分表也不失為企業混合事務處理的有效解決辦法。