JAVA架構師面試分享—鏈家網

本月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. 123-182