?相信長(zhǎng)時(shí)間運(yùn)維HBase集群的童鞋肯定都會(huì)對(duì)RIT（Region-In-Transition揖曾，很多參考資料誤解為Region-In-Transaction渊啰，需要注意）有一種咬牙切齒的痛恨感憾朴，一旦Region處于長(zhǎng)時(shí)間的RIT就會(huì)有些不知所措倒槐，至少以前的我就是這樣過(guò)來(lái)的惕艳。正所謂“恐懼來(lái)源于未知”锈至，不知所措意味著我們對(duì)RIT知之甚少晨缴，然而“凡事都有因果，萬(wàn)事皆有源頭”峡捡，處于RIT狀態(tài)的Region只是肉眼看到的一個(gè)結(jié)果击碗，為什么會(huì)處于RIT狀態(tài)才是問(wèn)題探索的根本筑悴，也是解決問(wèn)題的關(guān)鍵。本文就基于hbase 0.98.9版本對(duì)RIT的工作機(jī)制以及實(shí)現(xiàn)原理進(jìn)行普及性的介紹稍途，同時(shí)在此基礎(chǔ)上通過(guò)真實(shí)案例講解如何正確合理地處理處于RIT狀態(tài)的Region阁吝。一方面希望大家能夠更好的了解RIT機(jī)制，另一方面希望通過(guò)本文的學(xué)習(xí)之后可以不再’懼怕’RIT械拍，正確認(rèn)識(shí)處于RIT狀態(tài)的Region突勇。
Region-In-Trasition機(jī)制
?從字面意思來(lái)看，Region-In-Transition說(shuō)的是Region變遷機(jī)制坷虑，實(shí)際上是指在一次特定操作行為中Region狀態(tài)的變遷甲馋，那這里就涉及這么幾個(gè)問(wèn)題：Region存在多少種狀態(tài)？HBase有哪些操作會(huì)觸發(fā)Region狀態(tài)變遷迄损？一次正常操作過(guò)程中Region狀態(tài)變遷的完整流程是怎么樣的摔刁？如果Region狀態(tài)在變遷的過(guò)程中出現(xiàn)異常又會(huì)怎么樣？
Region存在多少種狀態(tài)海蔽？有哪些操作會(huì)觸發(fā)狀態(tài)變遷？
?HBase在RegionState類(lèi)中定義了Region的主要狀態(tài)绑谣，主要有如下：?上圖中實(shí)際上定義了四種會(huì)觸發(fā)Region狀態(tài)變遷的操作以及操作對(duì)應(yīng)的Region狀態(tài)党窜。其中特定操作行為通常包括assign借宵、unassign幌衣、split以及merge等，而很多其他操作都可以拆成unassign和assign壤玫，比如move操作實(shí)際上是先unassign再assign豁护；
Region狀態(tài)遷移是如何發(fā)生的？
?這個(gè)過(guò)程有點(diǎn)類(lèi)似于狀態(tài)機(jī)欲间，也是通過(guò)事件驅(qū)動(dòng)的楚里。和Region狀態(tài)一樣，HBase還定義了很多事件（具體見(jiàn)EventType類(lèi)）猎贴。此處以u(píng)nassign過(guò)程為例說(shuō)明事件是如何驅(qū)動(dòng)狀態(tài)變遷的班缎，見(jiàn)下圖：
?上圖所示是Region在close時(shí)的狀態(tài)變遷圖，其中紅字部分就是發(fā)生的各種事件她渴〈镏罚可見(jiàn)，如果發(fā)生M_ZK_REGION_CLOSING事件趁耗，Region就會(huì)從OPEN狀態(tài)遷移到PENDING_CLOSE狀態(tài)沉唠，而發(fā)生RS_ZK_REGION_CLOSING事件，Region會(huì)從PENDING_CLOSE狀態(tài)遷移到CLOSING狀態(tài)苛败，以此類(lèi)推满葛，發(fā)生RS_ZK_REGION_CLOSED事件径簿，Region就會(huì)從CLOSING狀態(tài)遷移到CLOSED狀態(tài)。當(dāng)然纱扭，除了這些事件之外牍帚，HBase還定義了很多其他事件，在此就不一一列舉乳蛾。截至到此暗赶，我們知道Region是一個(gè)有限狀態(tài)機(jī)，那這個(gè)狀態(tài)機(jī)是如何正常工作的肃叶，HMaster蹂随、RegionServer、Zookeeper又在狀態(tài)機(jī)工作過(guò)程中扮演了什么角色因惭，那就接著往下看～
一次正常操作過(guò)程中Region狀態(tài)變遷的完整流程是怎么樣的岳锁？
接下來(lái)本節(jié)以u(píng)nassign操作為例對(duì)這個(gè)流程進(jìn)行解析：
整個(gè)unassign操作是一個(gè)比較復(fù)雜的過(guò)程，涉及HMaster蹦魔、RegionServer和Zookeeper三個(gè)組件：
HMaster負(fù)責(zé)維護(hù)Region在整個(gè)操作過(guò)程中的狀態(tài)變化激率，起到一個(gè)樞紐的作用。它有兩個(gè)重要的HashMap數(shù)據(jù)結(jié)構(gòu)勿决，分別為regionStates和regionsInTransition乒躺，前者用來(lái)存儲(chǔ)整個(gè)集群中所有Region及其當(dāng)時(shí)狀態(tài)，而后者主要存儲(chǔ)在變遷過(guò)程中的Region及其狀態(tài)低缩，后者是前者的一個(gè)子集嘉冒，不包含OPEN狀態(tài)的Regions；
RegionServer負(fù)責(zé)接收HMaster的指令執(zhí)行具體unassign操作咆繁，實(shí)際上就是關(guān)閉region操作讳推；
Zookeeper負(fù)責(zé)存儲(chǔ)操作過(guò)程中的事件，它有一個(gè)路徑為/hbase/region-in-transition的節(jié)點(diǎn)玩般。一旦一個(gè)Region發(fā)生unssign操作银觅，就會(huì)在這個(gè)節(jié)點(diǎn)下生成一個(gè)子節(jié)點(diǎn)，子節(jié)點(diǎn)的內(nèi)容是一個(gè)“事件”經(jīng)過(guò)序列化的字符串坏为，并且Master會(huì)監(jiān)聽(tīng)在這個(gè)子節(jié)點(diǎn)上设拟，一旦發(fā)生任何事件，Master就會(huì)監(jiān)聽(tīng)到并更新Region的狀態(tài)久脯。
下圖是整個(gè)流程示意圖：
-
HMaster先執(zhí)行事件M_ZK_REGION_CLOSING并更新RegionStates纳胧，將該Region的狀態(tài)改為PENDING_CLOSE，并在regionsInTransition中插入一條記錄帘撰；
發(fā)送一條RPC命令給擁有該Region的RegionServer跑慕，責(zé)令其關(guān)閉該Region;
RegionServer接收到HMaster發(fā)送過(guò)來(lái)的命令之后，首先生成一個(gè)RS_ZK_REGION_CLOSING事件，更新到Zookeeper核行，Master監(jiān)聽(tīng)到ZK節(jié)點(diǎn)變動(dòng)之后更新regionStates牢硅，將該Region的狀態(tài)改為CLOSING;
RegionServer執(zhí)行真正的Region關(guān)閉操作：如果該Region正在執(zhí)行flush或者compaction，等待操作完成芝雪；否則將該Region下的所有Memstore強(qiáng)制flush;
完成之后生成事件RS_ZK_REGION_CLOSED减余，更新到Zookeeper，Master監(jiān)聽(tīng)到ZK節(jié)點(diǎn)變動(dòng)之后更新regionStates惩系，將該Region的狀態(tài)改為CLOSED;
到這里位岔，基本上將unssign操作過(guò)程中涉及到的Region狀態(tài)變遷解釋清楚了，當(dāng)然堡牡，其他諸如assign操作基本類(lèi)似抒抬，在此不再贅述。這里其實(shí)還有一個(gè)問(wèn)題晤柄，即關(guān)于HMaster上所有Region狀態(tài)是否需要持久化的問(wèn)題擦剑，剛開(kāi)始接觸這個(gè)問(wèn)題的時(shí)候想想并不需要，這些處于RIT的狀態(tài)信息完全可以通過(guò)Zookeeper上/region-in-transition的子節(jié)點(diǎn)信息構(gòu)建出來(lái)芥颈。然而惠勒，在閱讀HBase Book的相關(guān)章節(jié)時(shí)，看到如下信息：
?于是就充滿了疑惑爬坑，一方面Master更新hbase:meta是一個(gè)遠(yuǎn)程操作捉撮，代價(jià)相對(duì)很大；另一方面Region狀態(tài)內(nèi)存更新和遠(yuǎn)程更新保證一致性比較困難妇垢；再者，Zookeeper上已經(jīng)有相應(yīng)RIT信息肉康，再持久化一份并沒(méi)有太大意義闯估。為了對(duì)其進(jìn)行確認(rèn)，就查閱跟蹤了一下源碼吼和，發(fā)現(xiàn)是否持久化取決于一個(gè)參數(shù)：
hbase.assignment.usezk涨薪，默認(rèn)情況下該參數(shù)為true，表示使用zk情況下并不會(huì)對(duì)Region狀態(tài)進(jìn)行持久化（詳見(jiàn)RegionStateStore類(lèi)）炫乓，可見(jiàn)HBase Book的那段說(shuō)明存在問(wèn)題刚夺，在此特別說(shuō)明～
如果Region狀態(tài)在變遷的過(guò)程中出現(xiàn)異常會(huì)怎么樣？
再回顧unassign的整個(gè)過(guò)程就會(huì)發(fā)現(xiàn)一次完整操作涉及太多流程末捣，任何異常都可能會(huì)導(dǎo)致Region處于較長(zhǎng)時(shí)間的RIT狀態(tài)侠姑，好在HBase針對(duì)常見(jiàn)的異常做了最基本的容錯(cuò)處理：
Master宕機(jī)重啟：Master在宕機(jī)之后會(huì)丟失所有內(nèi)存中的信息，也包括RIT信息以及Region狀態(tài)信息箩做，因此在重啟之后會(huì)第一時(shí)間重建這些信息莽红。重啟之后會(huì)遍歷Zookeeper上/hbase/regions-in-transition節(jié)點(diǎn)下的所有子節(jié)點(diǎn)，解析所有子節(jié)點(diǎn)對(duì)應(yīng)的最后一個(gè)‘事件’，解析完成之后一方面借此重建全局的Region狀態(tài)安吁，另一方面根據(jù)狀態(tài)機(jī)轉(zhuǎn)移圖對(duì)處于RIT狀態(tài)的Region進(jìn)行處理醉蚁。比如如果發(fā)現(xiàn)當(dāng)前Region的狀態(tài)是PENDING_CLOSE，Master就會(huì)再次據(jù)此向RegionServer發(fā)送’關(guān)閉Region’的RPC命令鬼店。
其他異常宕機(jī)：HBase會(huì)在后臺(tái)開(kāi)啟一個(gè)線程定期檢查內(nèi)存中處于RIT中的Region网棍，一旦這些Region處于RIT狀態(tài)的時(shí)長(zhǎng)超過(guò)一定的閾值（由參數(shù)hbase.master.assignment.timeoutmonitor.timeout定義，默認(rèn)600000ms）就會(huì)重新執(zhí)行unassign或者assign操作妇智。比如如果當(dāng)前Region的狀態(tài)是PENDING_CLOSE滥玷，而且處于該狀態(tài)的時(shí)間超過(guò)了600000ms，Master就會(huì)重新執(zhí)行unassign操作俘陷，向RegionServer再次發(fā)送’關(guān)閉Region’的RPC命令罗捎。
?可見(jiàn)，HBase提供了基本的重試機(jī)制拉盾，保證在一些短暫異常的情況下能夠通過(guò)不斷重試?yán)鹉切┨幱赗IT狀態(tài)的Region桨菜，進(jìn)而保證操作的完整性和狀態(tài)的一致性。然而不幸的是捉偏，因?yàn)楦鞣N各樣的原因倒得，很多Region還是會(huì)掉入長(zhǎng)時(shí)間的RIT狀態(tài)，甚至是永久的RIT狀態(tài)夭禽，必須人為干預(yù)才能解決霞掺，下面一節(jié)內(nèi)容讓我們看看都有哪些常見(jiàn)的場(chǎng)景會(huì)導(dǎo)致Region會(huì)處于永久RIT狀態(tài)，以及遇到這類(lèi)問(wèn)題應(yīng)該如何解決讹躯。
永久RIT狀態(tài)案例分析
?通過(guò)RIT機(jī)制的了解菩彬，其實(shí)可以發(fā)現(xiàn)處于RIT狀態(tài)Region并不是什么怪物，大部分處于RIT狀態(tài)的Region都是短暫的，即使在大多數(shù)短暫異常的情況下HBase也提供了重試機(jī)制保證Region能夠很快恢復(fù)正常例书。然而在一些特別極端的場(chǎng)景下還是會(huì)發(fā)生一些異常導(dǎo)致部分Region掉入永久的RIT狀態(tài)况褪，進(jìn)而會(huì)引起表讀寫(xiě)阻塞甚至整個(gè)集群的讀寫(xiě)阻塞。下面我們舉兩個(gè)相關(guān)的案例進(jìn)行說(shuō)明：
案例一：Compaction永久阻塞
現(xiàn)象：線上一個(gè)集群因?yàn)槲粗蚝鋈痪涂ㄗ×税业x寫(xiě)完全進(jìn)不來(lái)了；另外還有很多處于PENDING_CLOSE狀態(tài)的Region萝究。
分析：集群卡住常見(jiàn)原因無(wú)非兩個(gè)免都，一是Memstore總消耗內(nèi)存大小超過(guò)了上限進(jìn)而觸發(fā)RegionServer級(jí)別flush，此時(shí)系統(tǒng)會(huì)阻塞集群執(zhí)行長(zhǎng)時(shí)間flush操作帆竹；二是storefile數(shù)量過(guò)多超過(guò)設(shè)定的上限閾值（參見(jiàn)：hbase.hstore.blockingStoreFiles）绕娘，此時(shí)系統(tǒng)會(huì)阻塞所有flush請(qǐng)求而執(zhí)行compaction。
診斷：
（1）首先查看了各個(gè)RegionServer上的Memstore使用大小栽连，并沒(méi)有達(dá)到設(shè)定的upperLimit业舍。
（2）再查看了一下所有RegionServer的storefile數(shù)量，瞬間石化了，store數(shù)為250的RegionServer上storefile數(shù)量竟然達(dá)到了1.5w+舷暮，很多單個(gè)store的storefile都超過(guò)了設(shè)定閾值100
（3）初步懷疑是因?yàn)閟torefile數(shù)量過(guò)多引起的态罪，看到這么多storefile的第一反應(yīng)是手動(dòng)執(zhí)行major_compaction，然而所有的compact命令好像都沒(méi)有起任何作用
（4）無(wú)意中發(fā)現(xiàn)所有RegionServer的Compaction任務(wù)都是同一張表music_actions的下面，而且Compaction時(shí)間都基本持續(xù)了一兩天复颈。到此基本可以確認(rèn)是因?yàn)楸韒usic_actions的Compaction任務(wù)長(zhǎng)時(shí)間阻塞，占用了所有的Compaction線程資源沥割，導(dǎo)致集群中所有其他表都無(wú)法執(zhí)行Compaction任務(wù)耗啦，最后導(dǎo)致StoreFile大量堆積
（5）那為什么會(huì)存在PENDING_CLOSE狀態(tài)的Region呢？經(jīng)查看机杜，這些處于PENDING_CLOSE狀態(tài)的Region全部來(lái)自于表music_actions帜讲，進(jìn)一步診斷確認(rèn)是由于在執(zhí)行g(shù)raceful_stop過(guò)程中unassign時(shí)遇到Compaction長(zhǎng)時(shí)間阻塞導(dǎo)致RegionServer無(wú)法執(zhí)行Region關(guān)閉（參考上文unassign過(guò)程），因而掉入了永久RIT椒拗。
解決方案：
（1）這個(gè)問(wèn)題中RIT和集群卡住原因都在于music_actions這張表的Compaction阻塞似将，因此需要定位Compaction阻塞的具體原因。經(jīng)過(guò)一段時(shí)間的定位初步懷疑是因?yàn)檫@張表的編碼導(dǎo)致蚀苛，anyway在验，具體原因不重要，因?yàn)橐坏〤ompaction阻塞堵未，好像是沒(méi)辦法通過(guò)正常命令解除這種阻塞的腋舌。臨時(shí)有用的辦法是增大集群的Compaction線程，以期望有更多空閑線程可以處理集群中其他Compaction任務(wù)渗蟹，消化大量堆積的StoreFiles
（2）而永久性消滅這種Compaction阻塞只能先將這張表數(shù)據(jù)遷移出來(lái)块饺，然后將這張表暴力刪除。暴力刪除就是先將HDFS對(duì)應(yīng)文件刪除雌芽，再將hbase:meta中該表對(duì)應(yīng)的相關(guān)數(shù)據(jù)清除授艰，最后重啟整個(gè)集群即可。這張表刪除之后使用hbck檢查一致性之后膘怕，集群Compaction阻塞現(xiàn)象就消失了，集群就完全恢復(fù)正常召庞。
案例二：HDFS文件異常
現(xiàn)象：線上集群很多RegionServer短時(shí)間內(nèi)頻頻宕機(jī)岛心，有幾個(gè)Region處于FAILED_OPEN狀態(tài)
?分析診斷：
（1）查看系統(tǒng)監(jiān)控以及RegionServer日志，確認(rèn)RegionServer頻繁宕機(jī)是因?yàn)榇罅緾LOSE_WAIT狀態(tài)的短連接導(dǎo)致篮灼。監(jiān)控顯示短時(shí)間（4h）CLOSE_WAIT的數(shù)量從0增長(zhǎng)到6w+忘古。
（2）再查看RegionServer日志查看到如下日志：
2016-07-27 09:42:14,932 [RS_OPEN_REGION-inspur250.photo.163.
org,60020,1469581282053-0] ERROR org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler - Failed open of region=news_user_actions,|u:cfcd208495d565ef66e7dff9f98764da|1462799167|30671473410714402,1469522128310.3b3ae24c65fc5094bc2acfebaa7a56de., starting to roll
back the global memstore size.java.io.IOException: java.io.IOException:
java.io.FileNotFoundException: File does not exist: /hbase/
news_user_actions/b7b3faab86527b88a92f2a248a54d3dc/meta/
0f47cda55fa44cf9aa2599079894aed6
2016-07-27 09:42:14,934 [RS_OPEN_REGIONinspur250.photo.163.
org,60020,1469581282053-0] INFO org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler - Opening of region {NAME => 'news_user_actions,|u:cfcd208495d565ef66e7dff9f98764da|
1462799167|30671473410714402,
1469522128310.3b3ae24c65fc5094bc2acfebaa7a56de.', STARTKEY => '|u:cfcd208495d565ef66e7dff9f98764da|1462799167|
30671473410714402', ENDKEY => '|u:d0',
ENCODED => 3b3ae24c65fc5094bc2acfebaa7a56de,} failed,
marking as FAILED_OPEN in ZK
?日志顯示，Region ‘3b3ae24c65fc5094bc2acfebaa7a56de’打開(kāi)失敗诅诱，因此狀態(tài)被設(shè)置為FAILED_OPEN髓堪，原因初步認(rèn)為是FileNotFoundException導(dǎo)致，找不到的文件是Region ‘b7b3faab86527b88a92f2a248a54d3dc’ 下的一個(gè)文件，這兩者之間有什么聯(lián)系呢干旁？
（3）使用hbck檢查了一把驶沼，得到如下錯(cuò)誤信息：
ERROR: Found lingering reference file hdfs://mycluster/hbase/
news_user_actions/3b3ae24c65fc5094bc2acfebaa7a56de/meta/
0f47cda55fa44cf9aa2599079894aed6.b7b3faab86527b88a92f2a248a54d3dc
?看到這里就一下恍然大悟，從引用文件可以看出來(lái)争群，Region
‘3b3ae24c65fc5094bc2acfebaa7a56de’
‘ b7b3faab86527b88a92f2a248a54d3dc’的子Region回怜，熟悉Split過(guò)程的童鞋就會(huì)知道，父Region分裂成兩個(gè)子Region其實(shí)并沒(méi)有涉及到數(shù)據(jù)文件的分裂换薄，而是會(huì)在子Region的HDFS目錄下生成一個(gè)指向父Region目錄的引用文件玉雾，直到子Region執(zhí)行Compaction操作才會(huì)將父Region的文件合并過(guò)來(lái)。
?到這里轻要，就可以理解為什么子Region會(huì)長(zhǎng)時(shí)間處于FAILED_OPEN狀態(tài)：因?yàn)樽覴egion引用了父Region的文件复旬，然而父Region的文件因?yàn)槲粗騺G失了，所以子Region在打開(kāi)的時(shí)候因?yàn)檎也坏揭梦募蚨鴷?huì)失敗冲泥。而這種異常并不能通過(guò)簡(jiǎn)單的重試可以解決驹碍，所以會(huì)長(zhǎng)時(shí)間掉入RIT狀態(tài)。
（4）現(xiàn)在基本可以通過(guò)RegionServer日志和hbck日志確定Region處于FAILED_OPEN的原因是因?yàn)樽覴egion所引用的父Region的文件丟失導(dǎo)致柏蘑。那為什么會(huì)出現(xiàn)CLOSE_WAIT數(shù)量暴漲的問(wèn)題呢幸冻？經(jīng)確認(rèn)是因?yàn)镽egion在打開(kāi)的時(shí)候會(huì)讀取Region對(duì)應(yīng)HDFS相關(guān)文件，但因?yàn)橐梦募G失所以讀取失敗咳焚，讀取失敗之后系統(tǒng)會(huì)不斷重試洽损，每次重試都會(huì)同datanode建立短連接，這些短連接因?yàn)閔base的bug一直得不到合理處理就會(huì)引起CLOSEE_WAIT數(shù)量暴漲革半。
解決方案：刪掉HDFS上所有檢查出來(lái)的引用文件即可
（5）有朋友咨詢(xún)?yōu)槭裁磿?huì)出現(xiàn)父文件丟失碑定，在此補(bǔ)充一下。目前有可能有幾個(gè)官方bug觸發(fā)這個(gè)問(wèn)題又官，詳見(jiàn)https://issues.apache.org/jira/browse/HBASE-13331以及https://issues.apache.org/jira/browse/HBASE-16527延刘。
?簡(jiǎn)單來(lái)說(shuō)下在split完成之后父region會(huì)在什么情況下被刪除，實(shí)際上Master會(huì)啟動(dòng)一個(gè)線程定時(shí)檢查完成split之后的父目錄是否可以被有效刪除六敬，系統(tǒng)meta表中會(huì)記錄該父region切分后的子region碘赖，只需要檢查此兩個(gè)子region是否還存在引用文件，如果都不存在引用文件就可以認(rèn)為該父region對(duì)應(yīng)的文件可以被刪除外构。
?HBASE-13331 bug是說(shuō)檢查引用文件時(shí)候（檢查是否存在普泡、檢查是否可以正常打開(kāi)）如果拋出IOException異常，函數(shù)就會(huì)返回沒(méi)有引用文件审编，導(dǎo)致父region被刪掉撼班。正常情況下應(yīng)該保險(xiǎn)起見(jiàn)返回存在引用文件，保留父region垒酬，并打印日志手工介入查看砰嘁。
案例分析
經(jīng)過(guò)上面兩個(gè)案例的講解其實(shí)看出得出這么幾點(diǎn)：
永久性掉入RIT狀態(tài)其實(shí)出現(xiàn)的概率并不高件炉，都是在一些極端情況下才會(huì)出現(xiàn)。絕大部分RIT狀態(tài)都是暫時(shí)的矮湘。
一旦掉入永久性RIT狀態(tài)斟冕，說(shuō)明一定有根本性的問(wèn)題原因，只有定位出這些問(wèn)題才能徹底解決問(wèn)題
如果Region長(zhǎng)時(shí)間處于PENDING_CLOSE或者CLOSING狀態(tài)板祝，一般是因?yàn)镽egionServer在關(guān)閉Region的時(shí)候遇到了長(zhǎng)時(shí)間Compaction任務(wù)或Flush任務(wù)宫静，所以如果Region在做類(lèi)似于Major_Compact的操作時(shí)盡量不要執(zhí)行unassign操作，比如move操作券时、disable操作等孤里；而如果Region長(zhǎng)時(shí)間處于
FAILED_OPEN狀態(tài)，一般是因?yàn)镠DFS文件出現(xiàn)異常所致橘洞，可以通過(guò)RegionServer日志以及hbck定位出來(lái)捌袜。
寫(xiě)在文章最后
?RIT在很多運(yùn)維HBase的人看來(lái)是一個(gè)很神秘的東西，這是因?yàn)镽IT很少出現(xiàn)炸枣，而一旦出現(xiàn)就很致命虏等，運(yùn)維起來(lái)往往不知所措。本文就希望能夠打破這種神秘感适肠，還原它的真實(shí)本性霍衫。文章第一部分通過(guò)層層遞進(jìn)的方式介紹了Region-In-Transition機(jī)制，第二部分通過(guò)生產(chǎn)環(huán)境的真實(shí)案例分析永久性RIT出現(xiàn)的場(chǎng)景以及應(yīng)對(duì)的方案侯养。希望大家能夠更多的了解RIT敦跌，通過(guò)不斷的運(yùn)維實(shí)踐最后再也不用懼怕它～～
