本月7日去了一趟鏈家網面試，雖然沒有面上，但仍有不少收穫，在此做個簡單的分享，當然了主要是分享給自己，讓大家見笑了。因為這次是第一次面試JAVA網站架構師相關的職位，還是有些心虛的，畢竟之前大部分時間都是在做.NET相關的技術工作，並且自己所負責過的專案規模都是比較小，並且差異也較大。在高併發性，高伸縮性的網際網路網站的架構方面沒有太多的經驗，只是在之前空閒時閱讀李智慧老師的《大型網站技術架構》一書給了我不少的啟發。面試過程比較簡單，首先是筆試，架構師職位主要是一些知識的理解，也有一些資料庫查詢方面的基礎試題。知識點方面比較偏重於NoSQL、快取伺服器叢集、Session伺服器等內容。大體做的還湊合，因此面試官也比較客氣，和我更加深入的聊了相關方面的知識，也包括該公司主要的組織架構和盈利來源。

    由於鏈家網到目前為止仍然不算特別出名，但在各大網站上已經能經常看到該公司基於房地產行業的研究報告。剛開始我最大的疑問就是這個公司和搜房網、安居客等有什麼區別？這些網站都已經存在多年，那麼該公司有什麼特別的地方可以存活至今，並在這兩年內發展迅速？在回答這些疑問之前，我稍微跑個題，介紹一下面試官老宋，這是我給他起的外號，那次見面應該是第一次也是最後一次見他了，但他給我留下了極深的印象。技術水平很高，很注意自己的外在氣質，溝通時十分和善，影響最深的是在面試時他全程用鋼筆記錄相關的資訊，非常的專業和尊重面試者。之所以提這個，主要是想說個人認為程式設計師在找一份工作時除了收入，公司的未來發展外，最重要的就是直屬領導的性格契合度了，適合的才是最好的。只有這樣，你才能無論遇到多大的困難，都堅信團隊、專案能順利發展，自己多奉獻一些也是值得的，當然最終受益的也是自己了。

    接下來，回答之前的問題，鏈家網是非常大型與房地產經紀相關的公司，組織架構比較複雜和特殊，因為他並不是一家企業慢慢發展起來的，而又由鏈家網牽頭，和各地不同的房產經紀公司聯合組建起來的。由於房地產政策的地區差異，各地客戶群體需求差異，很難有一個非常統一的運營模式來進行管理。各地公司單獨運營，總部主要是一個網際網路的使用者入口，資料資訊服務系統也是各自獨立，感覺比較像原來特許加盟的形式，也算是一種網際網路+的實踐了。該公司與搜房網、安居客的差異來源於它的資料完全來之於本公司，基本是真實有效的，而搜房網等公司的資料來源於各個房產經紀公司或者經紀人，資訊非常的不可靠。簡單舉個例子，比如一套房子房東報價500萬，但一般來說這裡面都有一定的砍價空間，那麼房產經紀人在網上掛售這套房產時就會進行一定的減價，比如說495萬，於此同時，房東一般會和多家經紀公司聯絡，那麼其他經紀人看到這個報價，為了做成生意，很自然的把價格報的更低，最後，甚至爆出400萬這種不可能成交的價格，只是為了接到潛在購買者的電話。這樣就形成了"劣幣驅逐良幣"的情況，使得網站資訊不再可信，同時由於一套房屋可以由多家經紀公司掛售，因而網站上的房源數量往往遠多於實際的數量，給潛在購買者產生了很大的困擾。此外，由於鏈家公司所轄房產經紀公司，比如說上海的德佑公司，已有一定的體量，為了更進一步的保證房產的真實性，經過房產局對在售房屋進行了全面的核查。借用老宋的話說就是，"搜房他們是淘寶，鏈家是京東"。以上是對該公司經營模式的介紹，對房產經紀類企業深入互聯化有很大的借鑑作用。

    然後開始技術部分的介紹，剛開始我也有很打困惑，為什麼這家公司需要一個OA方面的架構師，經過溝通我才知道，該公司目前有大約3萬名的房產經紀，所以該公司的企業資訊系統，每天有將近1000萬得PV，抵得上一個中型網站，每天的早上打卡（採用網上打卡）、爭搶客戶資源等活動會產生大量的併發，類似於電商網站的秒殺，因而需要有高併發相關經驗的工程師。

    最後，是幾個主要的技術點，包括許可權系統的設計，快取伺服器叢集的架設，訊息佇列系統的構建等。在此主要介紹前兩個，其他的會在之後補充。許可權系統基本參考資深博主天空行馬的方案，如下圖所示。

    主體結構比較簡單，職位和專案組的設定可以同時滿足職能型和專案型的企業組織架構，角色則對之前兩者進行了有限的補充，比如系統管理員等不能通過職位和專案組描述的情況。一般來說，系統中包含兩種型別的許可權：模組的許可權；行為的許可權。許可權組通常用於表示某一模組中所有行為許可權的集合。這個思路簡單清晰，便於實現和未來的擴充套件。在實現中，可以通過相關的許可權程式碼組合規則

來將許可權資訊儲存在資料庫中，例如許可權的數字或字母的表示組合。

    分散式快取叢集的伸縮性不同於Web伺服器叢集的伸縮性，對於後者來說，每一臺Web伺服器上內容相同，伸縮性只需要簡單的負載均衡演算法即可達到。但每一臺分散式快取伺服器上資料各不相同，快取訪問請求不可以再叢集中任意伺服器上完成，需要先找到儲存該資料的伺服器後訪問。同時新上線的伺服器上沒有快取資料，下線的快取伺服器上有熱點資料，會對分散式快取叢集的伸縮性設計造成很大的困難。為了更好的闡述相關概念，接下來將以最常見的Memcached為例介紹相關設計與實現，所圖所示。

    過程非常簡單，Memcached API將應用程式傳入的key進行雜湊運算，然後使用簡單餘數Hash演算法（例如11/3=2），得到指定的節點Node2，然後儲存指定伺服器。需要注意的一旦涉及到伺服器的擴容，以上見餘數Hash演算法就會遇到很大的問題，例如當要將3臺快取伺服器增加到4臺時(11/4=3),這時再Node3上找不該快取，快取未命中的概率達到75%，並且會著擴容，為命中的概率不斷增大（N/N+1）。這時就會使用到比較流行的一致性hash演算法，該演算法通過一致性Hash環的資料結構實現KEY到快取伺服器的Hash對映，過程若下圖所示。

    演算法的具體過程為：首先構造一個2³²的整數環，根據節點名稱的Hash值（極可能的雜湊）將快取伺服器節點防止在這個Hash環上，然後計算需要快取資料KEY的Hash值，順時針查詢最近的節點，作為目標節點。如上圖中，在叢集擴容時，即在原有Node0-2的基礎上加入Node3，可以看到，唯一受影響的資料為Key3，如此快取的命中率就變為了N/N+1，能滿足實際需要。實際程式碼中，該還一般由二叉查詢樹實現，通過連結最外側的葉子節點形成環。但以上設計仍然存在一個問題，就是再擴容後，Node0和1的負載量是Node2和Node3的兩倍。解決該痛點的方法是將物理快取伺服器節點虛擬化為N個虛擬節點，均勻的分散到環中去，使得負載儘可能的均衡。這樣就做到了新增物理伺服器對原有物理伺服器的影響一致，也就是該演算法名稱的由來。

注：本文主要供自己學習，不妥之處望見諒。

參考資料：

[1]天空行馬. OA系統許可權管理設計方案[EB/OL]. http://www.cnblogs.com/kivenhou/archive/2009/10/19/1586106.html。

[2]李智慧. 大型網站架構技術[M]. 上海:電子工業出版社, 2012. 106-112