分布式事务：两段式提交（最终一致性）
【MySQL如何實現分布式事務?】
http://www.linuxidc.com/Linux/2013-10/91925.htm?
Innodb存儲引擎支持XA事務，通過XA事務可以支持分布式事務的實現。分布式事務指的是允許多個獨立的事務資源（transac tional resources）參與一個全局的事務中。事務資源通常是關系型數據庫系統，也可以是其它類型的資源。
?
全局事務要求在其中所有參與的事務要么全部提交，要么全部回滾，這對于事務原有的ACID要求又有了提高。另外，在使用分布式事務時候，InnoDB存儲引擎的事務隔離級別必須設置成serialiable。
?
XA事務允許不同數據庫之間的分布式事務，如：一臺服務器是mysql數據庫，一臺是Oracle的，又有可能還有一臺是sqlserver的，只要參與全局事務中的每個節點都支持XA事務。
分布式事務可能在銀行系統的轉帳中比較常見，如一個用戶需要從上海轉1000元到北京的一個用戶賬號上面：
#?bank?ofshanghai：Update?user_account?set?money=money?–?10000?where?user=’xiaozhang’;
#?bank?ofBeijing：Update?user_account?set?money=?money?+?10000?where?user=’xiaoli’;
?
分布式事務使用兩段式提交（two-phase commit）的方式。
? ? ? ? 第一個階段，所有參與全局事務的節點都開始準備，告訴事務管理器它們準備好提交了。
? ? ? ? 第二個階段，事務管理器告訴資源管理器執行rollback或者commit，如果任何一個節點顯示不能commit，那么所有的節點就得全部rollback。
?
當前的java的JTA（java transaction API）可以很好的支持mysql的分布式事務，可以仔細參考JTA手冊。
下面的例子顯示了如何使用jta支持調用mysql分布式事務。
?
?
分布式事務處理（? Distributed Transaction Processing? ，? DTP? ）涉及多個分布在不同地方的數據庫，但對數據庫的操作必須全部被提交或者回滾。只要任一數據庫操作時失敗，所有參與事務的數據庫都需要回滾。
Open? 組織定義的分布式事務處理模型X/Open DTP? 模型（1994）包括應用程序（? AP? ）、事務管理器（? TM? ）、資源管理器（? RM ，即數據庫 ）、通信資源管理器（? CRM? ）四部分。而 XA 是 X/Open DTP 定義的事務管理器與數據庫之間的接口規范（即接口函數），事務管理器用它來通知數據庫事務的開始、結束以及提交、回滾等。
?XA? 接口規范?使用兩階段提交協議來完成一個全局事務，保證同一事務中所有數據庫同時成功或者回滾。
兩階段提交協議假設每個數據庫點都存在一個?write-ahead log，每一次的write請求都是?先記log后才真正執行寫入。
第一階段為提交請求階段（Commit-request phase）：?
?? 1. 事務管理器給所有數據庫發query to commit消息請求，然后開始等待回應；?
?? 2. 數據庫如果可以提交屬于自己的事務分支，則將自己在該事務分支中所做的操作固定記錄下來（在undo log和redo log中各記一項）；?
?? 3. 數據庫都回應是否同意提交的應答。
第二階段為提交階段（Commit phase）：?
如果事務管理器收到的所有回應都是agreement，?
?? 1. 事務管理器記日志并給所有數據庫發commit消息請求；?
?? 2. 各個數據庫執行操作，釋放所有該事務相關的鎖和資源；?
?? 3. 各個數據庫給事務管理器回復；?
?? 4.當收到所有回復，事務管理器結束當前事務
如果事務管理器收到的任一回應是abort，?
?? 1. 事務管理器記日志并給所有數據庫發rollback消息請求；?
?? 2. 各個數據庫執行undo操作，釋放所有該事務相關的鎖和資源；?
?? 3. 各個數據庫給事務管理器回復；?
?? 4.當收到所有回復，事務管理器結束當前事務
兩階段提交協議的問題在于數據庫在提交請求階段應答后對很多資源處于鎖定狀態，要等到事務管理器收集齊所有數據庫的應答后，才能發commit或者rollback消息結束這種鎖定。鎖定時間的長度是由最慢的一個數據庫制約，如果數據庫一直沒有應答，所有其他庫也需要無休止的鎖并等待。并且，如果事務管理器出現故障，被鎖定的資源將長時間處于鎖定狀態。無論是任一數據庫或者事務管理器故障，其他數據庫都需要永久鎖定或者至少長時間鎖定。并且，分布式系統中節點越多，存在緩慢網絡或者故障節點的概率也就越大，資源被長時間鎖定的概率指數上升。
兩階段提交協議的另一個問題是只要有任意一個數據庫不可用都會導致事務失敗，這導致事務更傾向于失敗。對于多個副本的備份系統，很多時候我們希望部分副本點失效時系統仍然可用，使用該協議則不能實現。并且，分布式系統中節點越多，存在故障節點的概率也就越大，系統的可用性指數下降。
另外，如果數據庫在第一階段應答后到第二階段正式提交前的某個階段網絡故障或者節點故障，該協議無法提交或回滾，數據不一致不能絕對避免。
?
兩階段提交協議。
階段一：開始向事務涉及到的全部資源發送提交前信息。此時，事務涉及到的資源還有最后一次機會來異常結束事務。如果任意一個資源決定異常結束事務，則整個事務取消，不會進行資源的更新。否則，事務將正常執行，除非發生災難性的失敗。為了防止會發生災難性的失敗，所有資源的更新都會寫入到日志中。這些日志是永久性的，因此，這些日志會幸免遇難并且在失敗之后可以重新對所有資源進行更新。 階段二：只在階段一沒有異常結束的時候才會發生。此時，所有能被定位和單獨控制的資源管理器都將開始執行真正的數據更新。 在分布式事務兩階段提交協議中，有一個?主事務管理器負責充當?分布式事務協調器的角色。 事務協調器負責整個事務并使之與網絡中的其他事務管理器協同工作。 為了實現分布式事務，必須使用一種協議在分布式事務的各個參與者之間傳遞事務上下文信息，IIOP便是這種協議。這就要求不同開發商開發的事務參與者必須支持一種標準協議，才能實現分布式的事務。事務就是一個會話過程中，對上下文的影響是一致的，要么所有的更改都做了，要么所有的更變都撤銷掉。就要么生，要么死。沒有半死不死的中間不可預期狀態。 參考下薛定諤的貓。 事務是為了保障業務數據的完整性和準確性的。 分布式事務，常見的兩個處理辦法就是兩段式提交和補償。 兩段式提交典型的就是XA，有個事務協調器，告訴大家，來都準備好提交，大家回復，都準備好了，然后協調器告訴大家，一起提交，大家都提交了。 補償比較好理解，先處理業務，然后定時或者回調里，檢查狀態是不是一致的，如果不一致采用某個策略，強制狀態到某個結束狀態（一般是失敗狀態），然后就世界太平了。典型的就是沖正操作。 準備好了以后，如果沒有問題，收到提交，所有人都開始提交。 這個時候，比如對數據庫來說，有redo日志的。 如果某個數據庫這時候宕機了，那么它重啟的時候，先執行檢查，也會把上一次的這些操作都提交掉的。所以各個點的數據都是一致的。 問題 1：比如 一個業務要調用很多的服務都是寫操作，如果有其中一個寫的服務失敗了，怎么辦 ？假設 4個寫的吧，有2個寫失敗了 。 kimmking：淘寶之類的網站一般的做法是，如果4個都成功才算成功，那么這次提交時4個寫都設置成一個中間狀態，?先容許不一致。然后4個執行完成了以后，回調或是定時任務里檢查這4個數據是不是一致的，如果一致就全部置為成功狀態，如果不一致就全部置為失敗。 復雜的業務交互過程中，不建議使用強一致性的分布式事務。解決分布式事務的最好辦法就是不考慮分布式事務。就像剛說的問題一樣，?把分布式的事務過程拆解成多個中間狀態，中間狀態的東西不允許用戶直接操作，等狀態都一致成功，或者檢測到不一致的時候全部失敗掉。就解耦了這個強一致性的過程。 一般情況下準實時就成了。涉及到錢，有時候也可以這么搞。 淘寶幾s內完整一個訂單處理，不是什么問題吧。 銀行也不是全部都強一致性。也會扎差，也會沖正。 特別是涉及到多個系統的時候，我們比如買機票，支付完成以后，只支付完成狀態，然后返回給用戶了，我們過幾分鐘再刷新頁面，才會看到變成已出票，訂單完成狀態。 這個時候，如果我們要求所有處理，都是強一致性的，那么就完蛋了。頁面要死在那兒幾分鐘，才把這個事務處理完成，返回給用戶。 這樣就肯定涉及一個問題，支付了，但是最終出票沒出來。那就沒辦法，商量換票或退款。 淘寶的訂單改成出票失敗，給支付發消息通知退款。 慢的時候，有可能是手工出票，這時出一張票半小時都可能，如果要求都必須強一致性的話，所有處理線程都掛在哪兒，系統早就完蛋了。 解決分布式事務的最好辦法就是不考慮分布式事務。 拆分，大的業務流程，轉化成幾個小的業務流程，然后考慮最終一致性。 問題2：分布式事務是你們自己開發的，還是數據庫自帶的？ kimmking： 1、只要一個處理邏輯能保證要么成功，要么跟什么也沒做一樣，都算是事務。數據庫事務，MQ也有事務。 你自己甚至可以寫個程序生成兩個文件，要么都生成了，要么都刪掉不留痕跡，這也算是事務。 2、分布式事務這一塊有個XA規范，實現XA接口的事務，都可以加入到一個分布式事務中，被XA容器管理起來。 3、補償的辦法，需要具體情況具體分析，沒有一個各種場合都適用的框架。
【?http://yale.iteye.com/blog/1397917?】
? ? ? ? 事務是一個很重要的概念，它必須滿足ACID特性，在單機的數據庫中，這很容易實現。但在分布式數據庫中，各個表分散在各臺不同的機器上，如何對這些表實施分布式的事務處理就成為一個比較困難的問題，其中兩段式提交就是解決分布式事務的一種方式。
?
?
兩段式提交設計本身的思路非常的容易理解，步驟如下：
1. 協調員服務器（協調員）發送一條投票請求消息給所有參與這次事務的服務器（參與者）。
2. 當一個參與者收到一條投票請求，它會向協調員發送一條響應請求消息，該響應消息包含了參與者的投票：YES 或者NO。如果參與者的消息的投票是NO，那就意味著由于某些原因，參與者不能參與這次事務，等價于收到了ABORT決定，本次事務的工作到此為止。
3. 協調員收集所有參與者的響應投票，如果所有的響應投票都是YES，那么協調員就會做出決定：COMMIT，并且會把COMMIT消息發送給所有參與者。否則，協調員則會做出決定：ABORT，此時協調員會把ABORT消息發給那些投票為YES的那些參與者（投票為NO的參與者已經單方面ABORT了這次事務，協調員不必再發送消息給這些參與者）。發送完決定后，協調員對于本次事務的工作就此停止了。
4. 投了YES票的參與者等待著來自協調員的決定（COMMIT或者ABORT），然后根據決定做完相應的操作，然后本次事務的工作也就此為止。
?
?
? ? ? ? 步驟1,2屬于兩段式提交的階段1，步驟3,4屬于兩段式提交的階段2。在整個過程中，參與者會存在一段不確定時間段（從它發送YES的票開始，到它收到COMMIT/ABORT的決定結束），在此時間段內，參與者的進程會被block住，它需要等待接下來的決定。而協調員則不存在任何不確定時間段，它可以繼續處理其它的事務請求，發送其它事務的投票請求，在做完COMMIT/ABORT決定之后，它可以馬上去干別的事情，無需任何等待。因為協調員的工作不具有原子性，它可以交叉地做任何事。而參與者完成的是事務，具有原子性，它做出承諾后，他必須保持好事務的現場，避免別的事務的交叉感染，從而違反了ACID中的Isolated。
?
?
? ? ? ? 從描述來看非常簡單，很容易理解，但是請注意，在整個過程中的任何時間點，都有可能發生的各種各樣的故障，有的是鏈路故障，有的是服務器故障。如果詳細考慮這些情況，實現就不是這么簡單了。
? ? ? ? 先考慮第一個問題，在整個執行的過程中，無論是參與者的進程，還是協調者的進程，他們在做下一步的處理前都必須等待消息。但是，消息可能會失敗，并不總是能夠到達。為了避免無休止的等待消息，因此需要加入Timeout?。當消息超過一定的時間還沒到來的時候，我們必須做出處理，這些處理我們稱之為Timeout-Action。當服務器或者服務器的進程（無論是協調員還是參與者）從一次失敗中恢復過來的時候，我們希望服務器的進程能夠嘗試著獲得一個和其他進程一致的決定。這很好理解， ? ?
?
? ? ? ? COMMIT/ABORT的決定已經由協調員發出了，那么恢復的參與者進程也希望能夠得到這個決定從而參與完成該事務。當然，在參與者從失敗中恢復過來的時候，由于其它的一些可能的失敗，可能COMMIT/ABORT的決定還未能做出，此時該參與者也需要做出相應的正確處理。因此，服務器的進程必須保存一些信息，比如是一些Log。有了這些Log，才能使得從失敗中恢復的進程能夠正確恢復事務處理。
?
Timeout-Action
進程需要在3個地方等待消息：在（2），（3），（4）步開始的地方：
在（2）步驟中，參與者進程需要等來來自協調員進程的投票請求。此時如果在等待投票請求時發生了timeout，參與者服務器就可以簡單得停止該事務的工作就可以了。
在（3）步驟中，協調員需要等待接受所有參與者回應的YES或NO的投票，在此時，協調員還未達成任何決定，參與者也沒有提交任何數據，因此協調員在Timeout發生后，只需要發送ABORT決定給所有的參與者就可以了。
在（4）步驟中，參與者p已經投了YES票，正在等待來自協調員的COMMIT或ABORT命令。在這個時間節點上，p處在不確定時間段。因此此時，p不能在timeout的時候簡單得單方面作出決定，他需要向其他服務器做咨詢才能知道該如何處理。最簡單的終止設計可以是這樣的：p依然被block住，一直詢問等待協調員，直到p重新建立起和協調員之間的聯系。接著，協調員就會告訴p已經作出的決定（協調員沒有不確定時間期），然后p就可以接著處理決定。
?
? ? ? ? 簡單終止協議的缺點是參與者p會被不必要得block住一段時間。比如，假如有2個參與者p和q，協調員把COMMIT/ABORT決定成功發送給q了，但是在它給p發送的決定失敗了。的確，p這時是處在不確定時期，但是q已經不在不確定期了，如果p能夠和q通信的話，p可以從q那里得到協調員發出的決定，不必一直block等到協調員恢復。
? ? ? ? 這需要參與者能夠互相知道對方，參與者之間可以直接交換信息，不必總是通過協調員的中介。要實現這種自由的信息交換也并不是十分困難，協調員在發送投票請求的時候可以把所有參與者的ID列表附在投票請求消息后面發送給所有的參與者，這樣參與者p在收到投票請求后就可以直接和其他所有的參與者進行交流了。這么做也不會帶來什么副作用，在收到投票請求之前，參與者之間還是互相不認識，因此在此之前（2），（3）發生的timeout還是可以單方面得中止任務或者停止事務。這個思路就出現另外的一個設計-協同終止設計，設計如下：
當一個參與者p在其不確定時間段內發生了timeout，他會依次向所有其他的進程發送一個詢問請求消息，詢問做出的決定是什么或者是否能單方面得做出一個決定（因為如果有一個被詢問的參與者已經向協調員回復了一個NO的投票，那么詢問者自然就可以單方面得做出決定ABORT這次事務，因為只要有一個參與者回復了NO，那么協調員做出的決定肯定是ABORT，無需再向協調員確認了）。在這種場景下，參與者p就被稱之為發起人，作出詢問回答的服務器進程 q就可以稱之為回應人。那么回應人q可能有3種情況：
1. q已經收到了COMMIT/ABORT決定：q只需要把該決定回應給p，然后p就可以自行處理了。
2. q還沒進行投票：q此時可以單方面做出決定，因為此時協調員已經發生故障，此時q可以回應ABORT給p，p就可以自己做出處理。
3. q已經回復YES投票給協調員，處在不確定期內，也沒有收到來自協調員的決定。此時q也無法給p任何幫助。
根據這個設計，如果p發送詢問請求給q，碰巧q處在情況（1）或者（2）時，p馬上就可以達成（也就是獲得）一個決定而無需任何block。如果p能通訊的其他所有的進程都處在情況（3），那么p也會被block住，直到足夠的故障被修復使得p至少能夠和一個處在情況（1）或（2）的參與者進程q通訊。需要注意的是詢問請求可以發給所有的其他服務器進程，包括協調員進程，這樣至少可以確認協調員在沒有故障的狀態下可以回復投票請求，避免了碰巧所有其他的參與者進程都在不確定期而無法提供幫助回應這樣的窘境。
總之，協同終止設計可以降低block的概率，但不能完全排除它。
?
恢復
一個服務器進程p剛剛從一次故障中恢復，我們希望p能夠獲得一個和其它進程們已經達成的決定一致的決定，如果不能馬上恢復這個決定，那么至少在其它的故障被修復后能夠恢復這個決定。
當一個服務器進程p把系統恢復到了故障發生時現場保存的狀態，我們來進一步考慮一下。如果p是在它發送YES投票到協調員之前就發生故障了，那么該進程就可以單方面的決定取消這次事務，發送NO投票給協調員，不做任何處理。同樣，如果p是在已經收到COMMIT/ABORT決定之后或者自己已經作出ABORT的決定之后發生故障了，那么此時p由于已經做出了決定，p就可以作出相應的處理，比如說取消事務操作，或者繼續把COMMIT決定的操作執行完畢。在這些情況下，p都能夠獨立得進行故障恢復。
但是，如果p發生故障時是處在它的不確定期時，那么它就無法在恢復時獨立得做決定了，這就是問題的復雜之處。因為它投了YES，在p故障時，可能其他的參與者全部投了YES并且協調者做出了COMMIT的決定。又或者p發生故障時，其他參與者并未全部投票YES，因此協調者作出的是ABORT的決定。此時p無法根據本地信息就能獨立得進行恢復，他需要和其他進程進行交流。在這種情況下，p所面臨的情況是和time-action的情況（3）是一樣的。（設想一下，p設置了一個非常長的timeout 時間，整個故障期間都沒有超過timeout的期限）。因此此時p也采用前面提到的終止設計來解決問題。
為了保存故障發生時的狀態，每個進程都必須維護一個DT Log（Database Transaction Log）。每個進程只能訪問他自己服務器上的DT Log。假設我們采用的是協同終止設計，我們來看看如果管理這些DT log.
?
1. 當協調員發送投票請求之前或之后，它寫了一條開始兩階段記錄在DT log中。該記錄大概類似這樣：
Xml代碼????
2. 如果參與者線程發送了YES投票，那么他必須在發送投票之前寫這么YES 投票記錄在DT Log中，大概類似這樣：
Xml代碼???? 如果參與者發送了NO投票，那么它可以在發送投票之前或之后寫一條ABORT ACCEPT記錄在DT log中。
?
3. 在協調員發送COMMIT決定給所有參與者進程之前，他寫入一條COMMIT DECISION記錄。
?
4. 當協調員發送ABORT決定給所有參與者進程之前或之后，它寫入一條ABORT DECISION記錄
?
5. 參與者服務器進程在收到COMMIT/ABORT決定之后，參與者進程寫入一條COMMIT ACCEPT/ABORT ACCPET記錄。
?
對上述Log做一些說明，一旦參與者服務器進程在DT日志中寫入COMMIT ACCEPT或者ABORT ACCEPT記錄后，DM（database manager）就可以執行commit或者abort數據庫操作。具體來講還有很多細節，比如系統中的DT Log可能是DM Log中的一部分，因此DT Log中的COMMIT ACCEPT/ABORT ACCEPT記錄是通過本地DM的Commit/Abort子程序來實現的，在子程序中進行具體的操作之前，DM會寫入COMMIT ACCEPT/ABORT ACCEPT記錄到日志中去。
有了這個日志系統，當服務器S就可以按照下面的方式進行恢復：
1>?如果S檢查DT Log發現了記錄，那么S就知道自己是一臺協調員。如果發現日志還包含了COMMIT DECISION或者ABORT DECISION日志，那就證明在故障發生之前已經產生了決定，他可以選擇重新發送這些決定。如果沒有發現這兩條記錄中的任何一條，那么S就可以單方面得決定Abort，同時向日志中寫入ABORT DECISION記錄，并重發決定。需要注意的是，要先插入COMMIT DECISION日志，再發送COMMIT決定給各個參與者進程，這很關鍵。為什么順序這么關鍵呢？試想一下，如果發送決定消息在前，插入日志在后，那么就會有一種可能，消息COMMIT DECISION發送完了但日志還沒來得及寫入的時候服務器發生故障了，當服務器恢復之后，按照前面的邏輯，它會認為還未做出任何決定，于是又單方面的決定ABORT DECISION，這下就和實際情況沖突了，參與者就會受到兩條完全沖突的決定：ABORT DECISION和COMMIT DECISION，系統會無法處理。如果寫日志在前，發送消息在后，系統也有可能在兩個時間點之間發生故障，協調員恢復時會看見日志，因此不會做任何事或者把決定重新發送一遍，因為決定事先已經達成，即使有可能消息還沒有發送，但至少不會做出自相矛盾的決定令參與者無法是從。
2> 如果S沒有發現任何記錄，S就會認為自己是一臺參與者。那么就會有三種情況：
1. DT log中包含了COMMIT ACCEPT或者ABORT ACCEPT記錄，那參與者已經獲得了決定，那么參與者可以自己來決定，可以根據記錄來查看相應的操作是否完成，如果還未完成可以繼續從而完成相應操作。
2. 如果日志中沒有包含VOTE YES記錄以及任何COMMIT ACCEPT或者ABORT ACCEPT記錄，我們無法得到它當時是選擇YES還是NO。我們寫VOTE YES記錄的時間也要比發送實際消息早，盡可能早得保存決定。此時S可以單方面得決定ABORT ACCEPT。
3. 如果日志中包含VOTE YES記錄但沒有任何COMMIT ACCEPT或者ABORT ACCEPT記錄。那么參與者是在不確定期發生故障的，因此它采用終止協議來獲得決定。
?
對于一個實際的系統而言，系統需要處理的是很多的事務，因此不同事務的日志是交錯得存放在DT Log里。因此每條日志記錄需要包含事務的名字。而且隨著時間的積累，事務越來越多，日志的體積也會越來越龐大。因此需要定期對日志進行垃圾回收。日志垃圾回收有2個準則：
GC1：一臺服務器不能刪除事務T的日志，直到它的RM（Recovery Manager）已經處理完了RM-Commit(T)或者RM-Abort（T）
GC2：一臺服務器不能刪除事務T的日志，直到該服務器收到消息，所有其他服務器的RM-Commit（T）或者Rm-Abort（T）已經處理完畢。
對于GC1，通過本地的信息很容易得到。對于GC2，則需要服務器之間能夠相互通信，你可以讓協調員來執行GC2，或者完全分布式得由各個服務器通過相互交流完成GC2.
由于實際系統同時并發得處理很多事務，因此在某臺服務器恢復的時候，我們還需要考慮一些細節問題。當服務器恢復時，它需要把繼續完成那些還未COMMIT或ABORT的事務，這些事務在完全恢復之前都會被block住從而無法訪問數據庫這部分資源，這會造成浪費。因此解決的方法是不是在整個恢復階段一直hold住這些待恢復并且在故障之前處于不確定期被block住得事務的所有的讀寫鎖，而是把這些鎖暫時全部釋放，然后再通過重新爭取鎖的方式來和新到的事務來競爭鎖，這樣避免了在整個恢復階段所有的block資源都無法訪問。具體的流程是這樣的，服務器恢復后，先處理那些沒有被block住的事務，為這些事務做出決定。然后再處那些故障前被block的事務，這時候恢復程序先釋放這些事務的所有讀寫鎖，然后再與故障之后新的事務一起競爭重新請求這些讀寫鎖。一旦恢復程序先釋放了待恢復的block事務的讀寫鎖，那么這些事務所持有的數據庫資源就可以被訪問了。當然由于有競爭，原來本來可以COMMIT的事務可能由于資源競爭被ABORT掉了，但帶來的好處是吞吐量大大提高。在原來的方案中，事務的鎖可以保存在DT Log里，在競爭的方案中，鎖可以不必保存，因為服務器進程可以根據Log自行決定。
轉載于:https://www.cnblogs.com/lsx1993/p/4628830.html
與50位技術專家面對面20年技術見證，附贈技術全景圖總結
以上是生活随笔為你收集整理的分布式事务：两段式提交（最终一致性）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 亿鼎哈密瓜是哪里的
- 下一篇： nginx——location 优先级