在對于讀寫鎖的認識當中，我們都認為讀時加讀鎖许帐，寫時加寫鎖來保證讀寫和寫寫互斥劳坑，從而達到讀寫安全的目的。但是就在我翻Eureka源碼的時候成畦，發(fā)現(xiàn)Eureka在使用讀寫鎖時竟然是在讀時加寫鎖距芬，寫時加讀鎖，這波操作屬實震驚到了我循帐，Eureka到底是故意為之還是一個bug框仔？于是我就花了點時間研究了一下Eureka的這波操作。

Eureka服務注冊實現(xiàn)類

眾所周知拄养，Eureka作為一個服務注冊中心离斩，肯定會涉及到服務實例的注冊和發(fā)現(xiàn)，從而肯定會有服務實例寫操作和讀操作衷旅，這是每個注冊中心最基本也是最核心的功能捐腿。

image.png

AbstractInstanceRegistry

如上圖纵朋，AbstractInstanceRegistry是注冊中心的服務注冊核心實現(xiàn)類柿顶，這里面保存了服務實例的數(shù)據(jù)，封裝了對于服務實例注冊操软、下線嘁锯、讀取等核心方法。

這里講解一下這個類比較重要的成員變量

服務注冊表

private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry= new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();

注冊表就是存儲的服務實例的信息聂薪。Eureka是使用ConcurrentHashMap來進行保存的家乘。鍵值是服務的名稱，值為服務的每個具體的實例id和實例數(shù)據(jù)的映射藏澳，所以也是一個Map數(shù)據(jù)結構仁锯。InstanceInfo就是每個服務實例的數(shù)據(jù)的封裝對象。
服務的上線翔悠、下線业崖、讀取其實就是從注冊表中讀寫數(shù)據(jù)。
最近變動的實例隊列

private ConcurrentLinkedQueue<RecentlyChangedItem> recentlyChangedQueue = new ConcurrentLinkedQueue<>();

recentlyChangedQueue保存了最近變動的服務實例的信息蓄愁。如果有服務實例的變動發(fā)生双炕，就會將這個服務實例封裝到RecentlyChangedItem中，存到recentlyChangedQueue中撮抓。

什么叫服務實例發(fā)生了變動妇斤。舉個例子，比如說，有個服務實例來注冊了站超，這個新添加的實例就是變動的實例荸恕。

所以服務注冊這個操作就會有兩步操作，首先會往注冊表中添加這個實例的信息死相，其次會給這個實例標記為新添加的戚炫，然后封裝到RecentlyChangedItem中，存到recentlyChangedQueue中媳纬。

image.png

新增

同樣的双肤，服務實例狀態(tài)的修改、刪除（服務實例下線）不僅會操作注冊表钮惠，同樣也會進行標記茅糜，封裝成一個RecentlyChangedItem并添加到recentlyChangedQueue中。

image.png

修改

image.png

下線

所以從這分析也可以看出素挽，注冊表的寫操作同時也會往recentlyChangedQueue中寫一條數(shù)據(jù)蔑赘，這句話很重要。

后面本文提到的注冊表的寫操作都包含對recentlyChangedQueue的寫操作预明。

讀寫鎖

下線

所以從這分析也可以看出缩赛，注冊表的寫操作同時也會往recentlyChangedQueue中寫一條數(shù)據(jù)，這句話很重要撰糠。

后面本文提到的注冊表的寫操作都包含對recentlyChangedQueue的寫操作酥馍。

讀寫鎖

private final ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
private final Lock read = readWriteLock.readLock();
private final Lock write = readWriteLock.writeLock();

讀寫鎖就不用說了，JDK提供的實現(xiàn)阅酪。

讀寫鎖的加鎖場景

上面說完了AbstractInstanceRegistry比較重要的成員變量旨袒，其中就有一個讀寫鎖，也是本文的主題术辐，所以接下來看看哪些操作加讀鎖砚尽，哪些操作加寫鎖。

加讀鎖的場景

1辉词、服務注冊

image.png

register

服務注冊就是在注冊表中添加一個服務實例的信息必孤，加讀鎖。

2瑞躺、服務下線

image.png

cancel和internalCancel

服務下線就是在注冊表刪除這個服務實例的信息敷搪，服務下線的方法最后是調(diào)用internalCancel實現(xiàn)的，而internalCancel是加的讀鎖隘蝎，所以服務實例下線的時候加了讀鎖购啄。

3、服務驅逐

什么叫服務驅逐嘱么，很簡單狮含，就是服務端會定時檢查每個服務實例是否有向服務端發(fā)送心跳顽悼，如果服務端超過一定時間沒有接收到服務實例的心跳信息，那么就會認為這個服務實例不可用几迄，就會自動將這個服務實例從注冊表刪除蔚龙，這就是叫服務驅逐。

服務驅逐是通過evict方法實現(xiàn)的映胁，這個方法最終也是調(diào)用服務下線internalCancel方法來實現(xiàn)驅逐的木羹。

image.png

所以服務驅逐，其實也是加讀鎖的解孙，因為最后是調(diào)用internalCancel方法來實現(xiàn)的坑填，而internalCancel方法就是加的讀鎖。

4弛姜、更新服務狀態(tài)

image.png

服務實例的狀態(tài)變動了脐瑰，進行更新操作，也是加的讀鎖

5廷臼、刪除服務狀態(tài)

image.png

將服務的狀態(tài)刪了记劈，也是加的讀鎖彼棍。

這里都是對于注冊表的寫操作迄汛，所以進行這些操作的同時也會往recentlyChangedQueue中寫一條數(shù)據(jù)扣墩，只不過方法太長，代碼太多莱没，這里就沒有截出來初肉。

加寫鎖的場景

獲取增量的服務實例的信息。

image.png

getApplicationDeltasFromMultipleRegions

所謂的增量信息郊愧，就是返回最近有變動的服務實例朴译，而recentlyChangedQueue剛剛好保存了最近的服務實例的信息井佑，所以這個方法的實現(xiàn)就是遍歷recentlyChangedQueue属铁，取出最近有變動的實例，返回躬翁。所以保存最近變動的實例焦蘑，其實是為了增量拉取做準備的。

加鎖總結

這里我總結一下讀鎖和寫鎖的加鎖場景：

• 加讀鎖： 服務注冊盒发、服務下線例嘱、服務驅逐、服務狀態(tài)的更新和刪除
• 加寫鎖：獲取增量的服務實例的信息

讀寫鎖的加鎖疑問

上一節(jié)講了Eureka中加讀鎖和寫鎖的場景宁舰，有細心的小伙伴可能會有疑問拼卵，加讀鎖的場景主要涉及到服務注冊表的增刪操作，也就是寫操作蛮艰；而加寫鎖的場景是一個讀的操作腋腮。

這不是很奇怪么，不按套路出牌啊即寡，別人都是寫時加寫鎖徊哑，讀時加讀鎖，Eureka剛好反過來聪富，屬實是真的會玩葡粒。

image.png

寫的時候加的讀鎖，那么就說明可以同時寫膜钓，那會不會有線程安全問題呢嗽交？

答案是不會有安全問題。

我們以一個服務注冊為例颂斜。一個服務注冊夫壁，涉及到注冊表的寫操作和recentlyChangedQueue的寫操作。

注冊表本身就是一個ConcurrentHashMap沃疮，線程安全的map盒让，注冊表的值的Map數(shù)據(jù)結構，其實也是一個ConcurrentHashMap司蔬，如圖邑茄。

image.png

通過源碼可以發(fā)現(xiàn)，其實也是放入的值也是一個ConcurrentHashMap俊啼，所以注冊表本身就是線程安全的肺缕，所以對于注冊表的寫操作，本身就是安全的授帕。

再來看一下對于recentlyChangedQueue同木，它本身就是一個ConcurrentLinkedQueue，并發(fā)安全的隊列跛十，也是線程安全的彤路。

所以單獨對注冊表和recentlyChangedQueue的操作，其實是線程安全的芥映。

到這里更加迷糊了洲尊，本身就是線程安全的缝裤，為什么要加鎖呢，而且對于寫操作颊郎，還加的是讀鎖憋飞，這就導致可以有很多線程同時去寫，對于寫來說姆吭，相當加鎖加了個寂寞榛做。

帶著疑惑，接著往下看内狸。

Eureka服務實例的拉取方式和hash對比機制

拉取方式

Eureka作為一個注冊中心检眯，客戶端肯定需要知道服務端道理存了哪些服務實例吧，所以就涉及到了服務的發(fā)現(xiàn)昆淡，從而涉及到了客戶端跟服務端數(shù)據(jù)的交互方式锰瘸，pull還是push。如果有不清楚pull和push的機制昂灵，可以看一下RocketMQ的push消費方式實現(xiàn)的太聰明了這篇文章避凝，里面有交代什么是pull還是push。

那么Eureka到底是pull還是push模式呢眨补？這里我就不再賣關子了管削，其實是一種pull模式，也就是說客戶端會定期從服務端拉取服務實例的數(shù)據(jù)撑螺。并且Eureka提供了兩種拉取方式含思，全量和增量。

1甘晤、全量

全量其實很好理解含潘，就是拉取注冊表所有的數(shù)據(jù)。

全量一般發(fā)生在客戶端啟動之后第一次獲取注冊表的信息的時候线婚，就會全量拉取注冊表遏弱。還有一種場景也會全量拉取，后面會說酌伊。

2腾窝、增量

增量，前面在說加寫鎖的時候提到了居砖，就是獲取最近發(fā)生變化的實例的信息，也就是recentlyChangedQueue里面的數(shù)據(jù)驴娃。

增量相比于全量拉取的好處就是可以減少資源的浪費奏候，假如全量拉取的時候數(shù)據(jù)壓根就沒有變動，那么白白浪費網(wǎng)絡資源唇敞；但是如果是增量的話蔗草，數(shù)據(jù)沒有變動咒彤，那么就沒有增量信息，就不會有資源的浪費咒精。

在客戶端第一次啟動的全量拉取之后镶柱，定時任務每次拉取的就是增量數(shù)據(jù)。

增量拉取的hash對比機制

如果是增量拉取模叙，客戶端在拉取到增量數(shù)據(jù)之后會多干兩件事：

• 會將增量信息跟本地緩存的服務實例進行合并
• 判斷合并后的服務的數(shù)據(jù)跟服務端的數(shù)據(jù)是不是一樣

那么如何去判定客戶端的數(shù)據(jù)跟服務端的數(shù)據(jù)是不是一樣呢歇拆？

Eureka是通過一種hash對比的機制來實現(xiàn)的。

當服務端生成增量信息的時候范咨，同時會生成一個代表這一刻全部服務實例的hash值故觅，設置到返回值中，代碼如下

image.png

所以增量信息返回的數(shù)據(jù)有兩部分渠啊，一部分是變動的實例的信息输吏，還有就是這一刻服務端所有的實例信息生成的hash值。

當客戶端拉取到增量信息并跟本地原有的老的服務實例合并完增量信息之后替蛉，客戶端會用相同的方式計算出合并后服務實例的hash值贯溅，然后會跟服務端返回的hash值進行對比，如果一樣躲查，說明本次增量拉取之后盗迟，客戶端緩存的服務實例跟服務端一樣，如果不一樣熙含，說明兩邊的服務實例的數(shù)據(jù)不一樣罚缕。

這就是hash對比機制，通過這個機制來判斷增量拉取的時候兩邊的服務實例數(shù)據(jù)是不是一樣怎静。

image.png

hash對比

但是邮弹，如果發(fā)現(xiàn)了不一樣，那么此時客戶端就會重新從服務端全量拉取一次服務數(shù)據(jù)蚓聘，然后將該次全量拉取的數(shù)據(jù)設置到本地的緩存中腌乡，所以前面說的還有一種全量拉取的場景就在這里，源碼如下

image.png

重新全量拉取

讀寫鎖的使用揭秘

前面說了增量拉取和hash對比機制夜牡，此時我們再回過頭仔細分析一下增量信息封裝的兩步操作：

• 第一步遍歷recentlyChangedQueue与纽，封裝增量的實例信息
• 第二步生成所有服務實例數(shù)據(jù)對應的hash值，設置到增量信息返回值中

為什么要加鎖

假設不加鎖塘装，那么對于注冊表和recentlyChangedQueue讀寫都可以同時進行急迂，那么會出現(xiàn)這么一種情況

當獲取增量信息的時候，在第一步遍歷recentlyChangedQueue時有2個變動的實例蹦肴，注冊表總共有5個實例

當recentlyChangedQueue遍歷完之后僚碎，還沒有進行第二步計算hash值時，此時有服務實例來注冊了阴幌，由于不加鎖勺阐，那么可以同時操作注冊表和recentlyChangedQueue卷中，于是注冊成功之后注冊表數(shù)據(jù)就變成了6個實例，recentlyChangedQueue也會添加一條數(shù)據(jù)

但是因為recentlyChangedQueue已經(jīng)遍歷完了渊抽，此時不會在遍歷了蟆豫，那么剛注冊的這個實例在此次獲取增量數(shù)據(jù)時就獲取不到了，但是由于計算hash值是通過這一時刻所有的實例數(shù)據(jù)來計算懒闷，那么就會把這個新的實例計算進去了十减。

這不完犢子了么，增量信息沒有毛雇，但是全部實例數(shù)據(jù)的hash值有嫉称，那么就會導致客戶端在合并增量信息之后計算的hash值跟返回的hash值不一樣，就會導致再次全量拉取灵疮，白白浪費了本次增量拉取操作织阅。

所以一定要加鎖，保證在獲取增量數(shù)據(jù)時震捣，不能對注冊表進行改動荔棉。

為什么加讀寫鎖而不是synchronized鎖

這個其實跟Eureka沒多大關系，主要是讀寫鎖和synchronized鎖特性決定的蒿赢。synchronized會使得所有的操作都是串行化润樱，雖然也能解決問題，但是也會導致并發(fā)性能降低羡棵。

為什么寫時加讀鎖壹若，讀時加寫鎖

現(xiàn)在我們轉過來，按照正常的操作皂冰，服務注冊等寫操作加寫鎖店展，獲取增量的時候加讀鎖，那么可以不可呢秃流？

其實也是可以的赂蕴，因為這樣注冊表寫操作和獲取的增量信息讀操作還是互斥的，那么獲取的增量信息還是對的舶胀。

那么為什么Eureka要反過來概说？

寫（鎖）寫（鎖）是互斥的。如果注冊表寫操作加了寫鎖嚣伐，那么所有的服務注冊糖赔、下線、狀態(tài)更新都會串行執(zhí)行纤控，并發(fā)性能就會降低挂捻，所以對于注冊表寫操作加了讀鎖，可以提高寫的性能船万。

但是刻撒，如果獲取的增量讀的操作加了寫鎖，那豈不是讀操作都串行化了耿导，那么讀的性能不是會變低么声怔？而且注冊中心其實是一個讀多寫少的場景，為了提升寫的性能舱呻，浪費讀的性能不是得不償失么醋火？

哈哈，其實對于這個讀操作性能低的問題箱吕，Eureka也進行了優(yōu)化芥驳，那就是通過緩存來優(yōu)化了這個讀的性能問題，讀的時候先讀緩存茬高，緩存沒有才會真正調(diào)用獲取增量的方法來讀取增量的信息兆旬，所以最后真正走到獲取增量信息的方法，請求量很低怎栽。

image.png

ResponseCacheImpl

ResponseCacheImpl內(nèi)部封裝了緩存的操作丽猬，因為不是本文的重點，這里就不討論了熏瞄。

總結

所以脚祟，通過上面的一步一步分析，終于知道了Eureka讀寫鎖的加鎖場景强饮、為什么要加讀寫鎖以及為什么寫時加讀鎖由桌，讀時加寫鎖。這里我再總結一下：

為什么加讀寫鎖

是為了保證獲取增量信息的讀操作和注冊表的寫操作互斥邮丰，避免由于并發(fā)問題導致獲取到的增量信息和實際注冊表的數(shù)據(jù)對不上行您，從而引發(fā)客戶端的多余的一次全量拉取的操作。

為什么寫時加讀鎖柠座，讀時加寫鎖

其實是為了提升寫的性能邑雅，而讀由于有緩存的原因，真正走到獲取增量信息的請求很少妈经，所以讀的時候就算加寫鎖淮野，對于讀的性能也沒有多大的影響。

從Eureka對于讀寫鎖的使用也可以看出吹泡，一個技術什么時候用骤星，如何使用都是根據(jù)具體的場景來判斷的，不能要一概而論爆哑。