MyBatisPlus聯表查詢短板有工具補齊了，微服務架構也可以優化了
一、讀寫鎖的介紹
上一篇文章：《??年底了我裁完兄弟自己也離職了，復習了Java鎖的底層準備面試...??》，聊了一下java并發包的公平鎖和非公平鎖。
這篇文章來聊一下讀寫鎖。所謂的讀寫鎖，就是將一個鎖拆分為讀鎖和寫鎖兩個鎖，然后你加鎖的時候，可以加寫鎖，也可以加讀鎖。如下面代碼所示：
如果有一個線程加了寫鎖，那么其他線程就不能加寫鎖了，同一時間只能允許一個線程加寫鎖。因為加了寫鎖就意味著有人要寫一個共享數據，那同時就不能讓其他人來寫這個數據了。
同時如果有線程加了寫鎖，其他線程就不能加讀鎖了，因為既然都有人在寫數據了，你其他人當然不能來讀數據了！
如果有一個線程加了讀鎖，別的線程是可以隨意同時加讀鎖的，因為只是有線程在讀數據而已，此時別的線程也是可以來讀數據的！
同理，如果一個線程加了讀鎖，此時其他線程是不可以加寫鎖的，因為既然有人在讀數據，那就不能讓你隨意來寫數據了！
好了！這個就是初步介紹一下讀寫鎖的使用方法，相信很多同學應該之前都知道了，因為這個是java開發中非常基礎的一塊知識。
二、微服務注冊中心的讀寫鎖優化
現在進入主題，我們主要聊一下微服務注冊中心里面的讀寫鎖優化。
為什么要聊一下這個問題呢？
因為如果你出去面試，很可能被問到讀寫鎖的問題，此時你可以自然而然的帶出來，你之前了解過Spring Cloud微服務技術架構，同時對里面的微服務注冊中心的注冊表讀寫鎖優化有一些自己的感悟和看法。
這樣的話，相比于你簡單的給面試官聊聊讀寫鎖的基本概念和使用方法，要增色不少！
好，了解了這些前置知識之后，我們正式開始。
先來看看下面的圖，現在我們知道一個微服務注冊中心（可以是Eureka或者Consul或者你自己寫的一個微服務注冊中心），他肯定會在內存中有一個服務注冊表的概念。
這個服務注冊表中就是存放了各個微服務注冊時發送過來的自己的地址信息，里面保存了每個服務有多少個服務實例，每個服務實例部署在哪臺機器上監聽哪個端口號，主要是這樣的一些信息。
OK，那現在問題來了，這個服務注冊表的數據，其實是有人讀也有人寫的。
舉個例子，比如有的服務啟動的時候會來注冊，此時就會修改服務注冊表的數據，這個就是寫的過程。
接著，別的服務也會來讀這個服務注冊表的數據，因為每個服務都需要感知到其他服務在哪些機器上部署。
所以，這個內存里的服務注冊表數據，天然就是有讀寫并發問題的！可能會有多個線程來寫，也可能會有多個線程來讀！
如果你對同一份內存中的注冊表數據不加任何保護措施，那么可能會有多線程并發修改共享數據的問題，可能導致數據錯亂，對吧？
上述過程，大家看看下面的圖，就明白了。
此時，如果對服務注冊表的服務注冊和讀取服務注冊表的方法，都加一個synchronized關鍵字，是不是就可以了呢？
或許你會想，加上synchronized，直接讓所有線程對服務注冊表的讀寫操作，全部串行化。那不就可以保證內存中的服務注冊表數據安全了嗎？
下面是一段偽代碼，大家來感受一下：
在上面的代碼中直接給寫（服務注冊）和讀（讀取服務注冊表）兩個方法，都暴力的加上了synchronized關鍵字，確實是可以保證服務注冊表的數據不錯亂，但是這樣肯定是不太合適的。
因為這么搞的話，相當于是所有的線程讀寫服務注冊表數據，全部串行化了。
大家思考一下，我們想要的效果是什么？其實不就是在有人往服務注冊表里寫數據的時候，就不讓其他人寫了，同時也不讓其他人讀！
然后，有人在讀服務注冊表的數據的時候，其他人都可以隨便同時讀，但是此時不允許別人寫服務注冊表數據了！
對吧，我們想要的，其實不就是這個效果嗎？
想清楚了這點，我們就不應該暴力的加一個synchronized，讓所有讀寫線程全部串行化，那樣會導致并發性非常的低。
大家看看下面的圖，我們想要的第一個效果：一旦有人在寫服務注冊表數據，我們加個寫鎖，此時別人不能寫，也不能讀。
那么如果有人在讀數據呢？此時就可以讓別人都可以讀，但是不允許任何人寫。大家看下面的圖。
關鍵點來了，這樣做有什么好處呢？其實大部分時候都是讀操作，所以使用讀鎖可以讓大量的線程同時來讀數據，不需要阻塞不需要排隊，保證高并發讀的性能是比較高的。
然后?少量的時候是有服務上線要注冊數據，寫數據的場景是比較少的，此時寫數據的時候，只能一個一個的加寫鎖然后寫數據，同時寫數據的時候就不允許別人來讀數據了。
所以讀寫鎖是非常適合這種讀多寫少的場景的。
另外，我們能不能盡量在寫數據的期間還保證可以繼續讀數據呢？大量加讀鎖的時候，會阻塞人家寫數據加寫鎖過長時間，這種情況能否避免呢？
最后看下上面那段偽代碼如果用讀寫鎖來優化是怎么樣的？?
