淺談微服務註冊中心與分佈式鎖

問題的引出：

前幾天面試了一個童鞋，他說熟練掌握分佈式開發，微服務設計實現，而後我就簡單問了幾個問題，感受聊得還挺愉快的，這裏記錄一下相關的知識點

1.簡單對比了註冊中心ZooKeeper與MySQL

>dubbo框架註冊中心使用ZooKeeper能夠替換爲MySQL嗎？

不能夠，MySQL是數據庫<

>註冊中心註冊的是什麼東東？

微服務啓動時生產者向註冊中心節點寫入信息，消費者去註冊中心取對應數據。<

>寫入的信息是什麼東東，消費者取到的又是什麼東東？

 額，不太清楚。<

>咱的微服務不就是個RPC調用嗎，寫入的是服務的URL地址啊，這和咱請求一個URL不是同樣的嗎，知道了地址不就能夠訪問了嗎？

對對對，剛纔有點短路，是URL地址，RPC調用。<

>那居然是數據，MySQL也能夠保存啊，註冊中心換成MySQL沒問題吧？

額，可是微服務都是分佈式的，都是不一樣的數據庫  <

>那個人分佈式服務就共用一個MySQL，這沒問題了吧，我建個表，把URL地址寫到數據庫表裏，從表裏查數據？

恩，您這麼一說確實沒問題，可是感受怪怪的，您幫我捋一捋吧<

>咱就舉一個最簡單的例子，zkClient斷開時會自動刪除臨時節點信息，這樣某個生產者掛掉時，URL地址就移除了，MySQL能夠自動刪除廢棄的URL嗎？

哦，明白了，多謝了。<

2.簡答談了一下爲何要用Redis

>爲何要使用redis呢？

緩存，加快訪問速度<

>緩存放到本地不是更快嗎，redis還得請求一次

恩，本地內存資源寶貴，

咱們的圖片都是另外啓的圖片服務器<

>若是本地內存無限大，那就不須要redis了吧

    額，無限大的內存，好像是不須要redis，直接本地緩存<

>那你以爲用redis還帶來哪些好處？

恩，redis做爲中間件，固然還起着解耦的用，多個系統能夠經過redis交換數據；同時redis還能夠用來集中式管理，好比session會話管理。<

>恩，說的不錯，看來此次沒有短路。

3.簡單設計一個分佈式鎖。

>如今個人分佈式系統中有一個公共資源，各個系統訪問公共資源數據時，我須要上一把鎖，你如何design？

這個我只須要保證在分佈式訪問中，每次僅有一個服務操做公共資源便可，能夠利用中間件技術嗎<

>固然能夠，給出你的思路就好。

mq就能夠，我把一個個請求順序放到一個隊列裏，而後一個消費者一次取一條慢慢處理<

>恩，能夠的，既然說到mq，那mq還帶來哪些好處

mq一樣做爲中間件，能夠解耦合，提供了異步處  理機制，可以起到緩衝的做用<

>如何起到異步處理機制，有用到的案例嗎？

有的，咱們的微信公衆號後臺開發，有的消息處理須要調用各個系統拉取帳單數據，而5秒內沒有響應微信就會斷開鏈接，因此咱們收到用戶消息後，當即返回，而後消息  入隊列，再調用微信客服接口，將消息推送給用戶<

>恩，不錯，假如讓你使用ZooKeeper實現下分佈式鎖，如何設計？仍是思路便可

zk的話藉助臨時節點，遞增的序號，watch監聽事件， 應該也能夠，讓我整理一下思路<

>恩，我能get到你的點，你整理下

仍是以保持順序性爲前提，而後分佈式服務鏈接zk，獲取同一個父節點下的全部節點序列號，而後每一個節點監聽它以前的節點，只要以前的節點處理完刪除節點後，就輪到  本身處理了，不然等待前一個節點，大概這樣吧<

>恩，思路有了，實現起來把握住幾個點就OK。