Java NIO內存映射文件：提高文件讀寫效率的優秀實踐！
Java的NIO庫提供了內存映射文件的支持，它可以將文件映射到內存中，從而可以更快地讀取和寫入文件數據。本文將對Java內存映射文件進行詳細的介紹和演示。內存映射文件概述內存
在微服務架構下，我們最容易遇到的一個問題就是分布式事務處理問題，當你微服務模塊拆分越細，那么遇到分布式事務處理的場景就越多。即使是同一個微服務模塊，對應一個業務數據庫，但是你某個業務邏輯的實現是調用兩個Service接口服務來完成的，同樣也是分布式事務問題。
因此有必要對分布式事務整體解決思路進行下總結。
圖片
分布式事務就是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位于不同的分布式系統的不同節點之上。簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的服務器上，且屬于不同的應用，分布式事務需要保證這些小操作要么全部成功，要么全部失敗。本質上來說，分布式事務就是為了保證不同數據庫的數據一致性。
一個分布式事務包含一組操作序列，由兩個或兩個以上的網絡主機參與。通常主機提供事務性資源，而事務管理器負責創建和管理全局事務，由事務管理器協調事務參與的資源。分布式事務和本地事務并無太大不同，也需保證事務的四個屬性（原子性、一致性、隔離性、持久性）。
對于分布式事務的潛在場景，可以簡單的分為三類：
一個完整業務需要操作兩個獨立數據庫，比如需要在A數據庫插入一條訂單記錄，同時更新B數據庫中的庫存狀態，兩個操作跨數據庫，但是需要控制在一個完整事務里面。
在和工作流集成場景中出現，業務用戶在提交單據的時候需要后臺執行兩個操作，首先是調用本地API將單據數據保存到本地數據庫，其次是調用啟動流程WebService服務。
由于Web Service服務本身無狀態，即使是同一個數據庫提供給處理的兩個WebService服務，在進行調用和組合的時候也屬于分布式事務控制。
對于分布式事務的主流解決方法，主要包括了XA兩階段提交，事務補償和基于BASE的最終一致性（可靠消息傳輸），首先再對這三種方法做下簡單描述。
圖片
兩階段提交，因為它是實現XA分布式事務的關鍵（確切地說：兩階段提交主要保證了分布式事務的原子性：即所有節點要么全做要么全不做）。所謂的兩個階段是指：第一階段：準備階段和第二階段：提交階段。具體過程如下：
此時，事務涉及到的資源還有最后一次機會來結束事務。如果任意一個資源決定異常結束事務，則整個事務取消，不會進行資源的更新。否則，事務將正常執行，除非發生災難性的失敗。為了防止會發生災難性的失敗，所有資源的更新都會寫入到日志中。這些日志是永久性的，因此，這些日志會幸免于難并且在失敗之后可以重新對所有資源進行更新。
此時，所有能被定位和單獨控制的資源管理器都將開始執行真正的數據更新。事務管理器將基于第一個階段的投票結果進行決策：提交或取消。當所有的參與者同意提交事務協調者才通知所有的參與者提交事務，否則協調者將通知所有的參與者取消事務。
從以上工作過程可以看出，兩階段提交協議正確工作的前提假設是每個節點都會記錄來寫前日志（write-ahead log）并持久性存儲，即使節點發生故障日志也不會丟失。同時假設節點不會發生永久性故障而且任意兩個節點都可以互相通信。
兩階段提交協議最大的劣勢是其通過阻塞完成的協議，在事務參與者等待消息的時候處于阻塞狀態，事務參與者中其他進程則需要等待阻塞進程釋放資源才能使用。如果事務管理器發生了故障，那么事務參與者將無法完成事務則一直等待下去。同時兩階段提交協議沒有容錯機制，一個節點發生故障整個事務都要回滾，代價比較大。
兩階段提交協議僅在一種情況下可能導致數據不一致，所有或部分參與者都響應了Prepare階段，在任何參與者收到事務管理器提交或回滾決定之前事務管理器宕機死亡，此時所有參與者都必須等待事務管理器恢復。而可能事務管理器此時已經丟失了事務上下文，這時需人工介入參與數據恢復。
兩階段提交協議僅僅是提供了分布式事務中的原子性屬性，保證一個事務在全局要么全部提交，要么全部回滾，但是在并發控制上(隔離性)，仍然需要封鎖協議，為了達到分布式環境下全局串行和避免一個事務的失敗可能引起一連串事務的回滾，通常使用強兩階段封鎖協議（SS2PL）。
兩階段封鎖協議并不保證不會發生死鎖，數據庫系統必須采取其他的措施，預防和解決死鎖問題。但常見的數據庫系統通常都實現了隔離級別，不同的隔離級別對于不同的鎖機制，下表列出他們的對應關系。值得一提的是，兩階段封鎖協議并不保證不會發生死鎖，數據庫系統必須采取其他的措施，預防和解決死鎖問題。所以說，如果兩階段提交協議中事務時間越長，那么鎖等待的時間和死鎖的概率也會變大。
圖片
事務補償機制是指在事務鏈中的任何一個正向事務操作，都必須存在一個完全符合回滾規則的可逆事務。例如存款操作通過取款操作來補償、買入通過賣出來補償。
這里的“補償”與數據庫事務中的“回滾”是有區別的，“回滾”是指操作的取消，“回滾”前后對外界來講，數據是一致的。而“補償”則是獨立的逆向操作，如果事務執行了“補償操作”，外界可能會看到數據的兩種狀態。從這個角度講，“回滾”需要鎖定資源。從數據庫操作上來“補償操作”其實也是一次短事務。而“回滾”是一個事務內的操作。
事務補償通常在實現時采取嵌套事務的方式，即把一個主事務拆分成多個從業務操作，事務的發起和結束由主事務完成。從業務服務提供的業務操作提供補償操作，補償操作可以抵銷（或部分抵銷）正向業務操作的業務結果。業務活動管理器控制業務活動的一致性，它登記業務活動中的操作，并在業務活動取消時調用補償操作。具體回滾整個事務還是回退到某個事務點，可以依據具體業務來處理。
在上面方式中可以看到需要手工編寫大量的代碼來處理以保證事務的完整性，我們可以考慮實現一個通用的事務管理器，實現事務鏈和事務上下文的管理。對于事務鏈上的任何一個服務正向和逆向操作均在事務管理和協同器上注冊，由事務管理器接管所有的事務補償和回滾操作。
補償機制能正確工作是基于事務是可以補償這一前提，如果這一前提無法滿足，那么就無法使用這一機制。現實業務場景中，確實存在這樣的業務，例如證券交易，因為對時效性特別敏感，不能簡單地使用賣出（買入）來補償買入（賣出），因為不同時間交易的價格可能差距很大。
另外，補償操作也是一次事務操作，考慮到補償操作也是有可能失敗的，所以，補償操作應該支持重試，這就要求補償操作滿足冪等性。即重復調用多次產生的業務結果與調用一次產生的業務結果相同。
在前面已經強調了，對于事務補償必須滿足冪等性要求，而且不能對時效性太敏感。
場景：采購訂單在提交時候調用預算檢查和扣減，但是如果單據保存失敗需要再次調用預算檢查和調整，將扣減預算退回。
那么基于以上場景事務補償的核心實現邏輯如下：
圖片
即調用和扣減預算完全對等的一個逆向操作，將扣減服務造成的影響全部回退
以上即是對事務補償機制的關鍵說明。
圖片
由于對系統或者數據進行了拆分，我們的系統不再是單機系統，而是分布式系統，針對分布式系統的CAP原理包含如下三個元素。
CAP原理指的是，這三個要素最多只能同時實現兩點，不可能三者兼顧。因此在進行分布式架構設計時，必須做出取舍。而對于分布式數據系統，分區容忍性是基本要求，否則就失去了價值。因此設計分布式數據系統，就是在一致性和可用性之間取一個平衡。
當然，犧牲一致性，并不是完全不管數據的一致性，否則數據是混亂的，那么系統可用性再高分布式再好也沒有價值。犧牲一致性，只是不再要求關系型數據庫中的強一致性，而是只要系統能達到最終一致性即可。
從CAP理論到BASE理論
BASE 是 Basically Available（基本可用）、Soft state（軟狀態）和 Eventually consistent（最終一致性）三個短語的簡寫，由 eBay 架構師 Dan Pritchett 于 2008 年在《BASE: An Acid Alternative》論文中首次提出。
BASE 思想與 ACID 原理截然不同，它滿足 CAP 原理，通過犧牲強一致性獲得可用性， 一般應用于服務化系統的應用層或者大數據處理系統中，通過達到最終一致性來盡量滿足業務的絕大多數需求。BASE 模型包含如下三個元素：
BASE理論是基于CAP定理演化而來，是對CAP中一致性和可用性權衡的結果。核心思想：即使無法做到強一致性，但每個業務根據自身的特點，采用適當的方式來使系統達到最終一致性。
1、基本可用：指分布式系統在出現故障的時候，允許損失部分可用性，保證核心可用。但不等價于不可用。比如：搜索引擎0.5秒返回查詢結果，但由于故障，2秒響應查詢結果；網頁訪問過大時，部分用戶提供降級服務，等。
2、軟狀態：軟狀態是指允許系統存在中間狀態，并且該中間狀態不會影響系統整體可用性。即允許系統在不同節點間副本同步的時候存在延時。
3、最終一致性：系統中的所有數據副本經過一定時間后，最終能夠達到一致的狀態，不需要實時保證系統數據的強一致性。最終一致性是弱一致性的一種特殊情況。
BASE理論面向的是大型高可用可擴展的分布式系統，通過犧牲強一致性來獲得可用性。ACID是傳統數據庫常用的概念設計，追求強一致性模型。
基于可靠消息隊列實現最終一致性
圖片
基于消息的最終一致性是消除了分布式事務，是一種在BASE思想指導下比較好的方案。這種方案實現了兩個服務之間的解耦，解耦的關鍵就是異步消息和消息持久化機制。在兩個服務調用之間，會存在一個真空期，這段時間相關數據不一致，而只是在一個事務的中間狀態。
事務主動方的業務服務事務提交和消息發送之間必須通過事務同步，可以通過事務管理器進行管理，如兩階段提交。事務主動方在完成事務提交和消息發送之后，它的最終處理結果不再受到事務被動方的影響。即發送到事務被動方的事務要么成功，要么重試。
所以，消息同樣需要滿足冪等性。實際情況下，消息很難具有冪等性，解決這一問題的方法是使用另一個表記錄已經被成功應用的消息，這樣就可以通過避免消息多次被應用，從而達到冪等性。
在實際應用中，如果消息接收端的服務出現失敗，可能需要人工干預。
場景舉例說明
場景：在采購系統中擬制采購訂單，在提交單據申請的時候既需要將單據成功保存到本地，同時又需要啟動遠程流程平臺提供的流程啟動服務。在該場景中，第二個步驟屬于必須要最終完成的操作，同時業務上也允許最終一致（不要因為流程平臺本身問題導致單據提交不成功，啟動流程失敗如何重試是系統內部的事情）
對于該場景，基于消息實現最終一致性邏輯如下：
圖片
三種事務處理方案的比較和選擇
對于上面談到的三種事務處理方案，我們列個表格比較如下：
圖片
當前主流的方法仍然是事務補償和BASE最終一致性，同時可以看到，基于消息中間件實現的事務最終一致性由于本身具備高可靠，高性能，并滿足大并發的高吞吐量，因此在互聯網應用往往采用的更加多。在企業內部的基于SOA服務的分布式事務控制，
圖片
場景：業務操作需要同時調用 ServiceA-》ServiceB 兩個服務，并控制到一個分布式事務里面。
兩種方法選擇思路為：
If ( 服務A是否可以完整設計出 –A補償服務){ //-A補償服務能夠保證A服務影響完整回退 //在調用-A前，A服務調用影響不會波及到后續操作 if(服務A成功 則 服務B調用必須成功 and B只要最終成功即可) { //在服務A成功的情況下服務B不存在因業務邏輯處理和校驗導致的不成功。 Choose 最終一致性方案；(優選方案） } Else { Choose 事務補償方案； }}Else{ Choose 最終一致性方案；}整體思路也就是說能夠采用最終一致性的地方盡量采用最終一致性來解決問題。
對于不能采用BASE事務最終一致性的地方，特別是在ServiceB在調用的時候存在較多的業務邏輯校驗，因此ServiceA即使調用成功也會經常出現由于邏輯校驗導致ServiceB調用不成功，那么這種情況下就很難用BASE方案，否則就會導致大量的人工補償操作和處理。
對于ServiceB的調用如果需求都是最終一致，同時ServiceB的調用不存在由于業務原因導致的調用失敗，那么都建議采用BASE事務最終一致性方案。由于BASE方案基于消息中間件來實現，通過消息中間件既可以實現大并發下的吞吐量，同時也可以實現兩個服務調用間的徹底解耦。
本文鏈接：http://www.www897cc.com/showinfo-26-55303-0.html微服務架構下分布式事務處理方案選擇和對比
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 漲知識！Spring AOP還能這么玩，看看你的項目能否用上
下一篇： 微服務架構下分布式事務處理方案選擇和對比
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號