本月7日去了一趟鏈家網面試，雖然沒有面上，但仍有不少收獲，在此做個簡單的分享，當然了主要是分享給自己，讓大家見笑了。因為這次是第一次面試JAVA網站架構師相關的職位，還是有些心虛的，畢竟之前大部分時間都是在做.NET相關的技術工作，並且自己所負責過的項目規模都是比較小，並且差異也較大。在高並發性，高伸縮性的互聯網網站的架構方面沒有太多的經驗，只是在之前空閑時閱讀李智慧老師的《大型網站技術架構》一書給了我不少的啟發。面試過程比較簡單，首先是筆試，架構師職位主要是一些知識的理解，也有一些數據庫查詢方面的基礎試題。知識點方面比較偏重於NoSQL、緩存服務器集群、Session服務器等內容。大體做的還湊合，因此面試官也比較客氣，和我更加深入的聊了相關方面的知識，也包括該公司主要的組織架構和盈利來源。
由於鏈家網到目前為止仍然不算特別出名，但在各大網站上已經能經常看到該公司基於房地產行業的研究報告。剛開始我最大的疑問就是這個公司和搜房網、安居客等有什么區別？這些網站都已經存在多年，那么該公司有什么特別的地方可以存活至今，並在這兩年內發展迅速？在回答這些疑問之前，我稍微跑個題，介紹一下面試官老宋，這是我給他起的外號，那次見面應該是第一次也是最后一次見他了，但他給我留下了極深的印象。技術水平很高，很注意自己的外在氣質，溝通時十分和善，影響最深的是在面試時他全程用鋼筆記錄相關的信息，非常的專業和尊重面試者。之所以提這個，主要是想說個人認為程序員在找一份工作時除了收入，公司的未來發展外，最重要的就是直屬領導的性格契合度了，適合的才是最好的。只有這樣，你才能無論遇到多大的困難，都堅信團隊、項目能順利發展，自己多奉獻一些也是值得的，當然最終受益的也是自己了。
接下來，回答之前的問題，鏈家網是非常大型與房地產經紀相關的公司，組織架構比較復雜和特殊，因為他並不是一家企業慢慢發展起來的，而又由鏈家網牽頭，和各地不同的房產經紀公司聯合組建起來的。由於房地產政策的地區差異，各地客戶群體需求差異，很難有一個非常統一的運營模式來進行管理。各地公司單獨運營，總部主要是一個互聯網的用戶入口，數據信息服務系統也是各自獨立，感覺比較像原來特許加盟的形式，也算是一種互聯網+的實踐了。該公司與搜房網、安居客的差異來源於它的數據完全來之於本公司，基本是真實有效的，而搜房網等公司的數據來源於各個房產經紀公司或者經紀人，信息非常的不可靠。簡單舉個例子，比如一套房子房東報價500萬，但一般來說這里面都有一定的砍價空間，那么房產經紀人在網上掛售這套房產時就會進行一定的減價，比如說495萬，於此同時，房東一般會和多家經紀公司聯系，那么其他經紀人看到這個報價，為了做成生意，很自然的把價格報的更低，最后，甚至爆出400萬這種不可能成交的價格，只是為了接到潛在購買者的電話。這樣就形成了"劣幣驅逐良幣"的情況，使得網站信息不再可信，同時由於一套房屋可以由多家經紀公司掛售，因而網站上的房源數量往往遠多於實際的數量，給潛在購買者產生了很大的困擾。此外，由於鏈家公司所轄房產經紀公司，比如說上海的德佑公司，已有一定的體量，為了更進一步的保證房產的真實性，經過房產局對在售房屋進行了全面的核查。借用老宋的話說就是，"搜房他們是淘寶，鏈家是京東"。以上是對該公司經營模式的介紹，對房產經紀類企業深入互聯化有很大的借鑒作用。
然后開始技術部分的介紹，剛開始我也有很打困惑，為什么這家公司需要一個OA方面的架構師，經過溝通我才知道，該公司目前有大約3萬名的房產經紀，所以該公司的企業信息系統，每天有將近1000萬得PV，抵得上一個中型網站，每天的早上打卡（采用網上打卡）、爭搶客戶資源等活動會產生大量的並發，類似於電商網站的秒殺，因而需要有高並發相關經驗的工程師。
最后，是幾個主要的技術點，包括權限系統的設計，緩存服務器集群的架設，消息隊列系統的構建等。在此主要介紹前兩個，其他的會在之后補充。權限系統基本參考資深博主天空行馬的方案，如下圖所示。
主體結構比較簡單，職位和項目組的設置可以同時滿足職能型和項目型的企業組織架構，角色則對之前兩者進行了有限的補充，比如系統管理員等不能通過職位和項目組描述的情況。一般來說，系統中包含兩種類型的權限：模塊的權限；行為的權限。權限組通常用於表示某一模塊中所有行為權限的集合。這個思路簡單清晰，便於實現和未來的擴展。在實現中，可以通過相關的權限代碼組合規則
來將權限信息保存在數據庫中，例如權限的數字或字母的表示組合。
分布式緩存集群的伸縮性不同於Web服務器集群的伸縮性，對於后者來說，每一台Web服務器上內容相同，伸縮性只需要簡單的負載均衡算法即可達到。但每一台分布式緩存服務器上數據各不相同，緩存訪問請求不可以再集群中任意服務器上完成，需要先找到存儲該數據的服務器后訪問。同時新上線的服務器上沒有緩存數據，下線的緩存服務器上有熱點數據，會對分布式緩存集群的伸縮性設計造成很大的困難。為了更好的闡述相關概念，接下來將以最常見的Memcached為例介紹相關設計與實現，所圖所示。
過程非常簡單，Memcached API將應用程序傳入的key進行哈希運算，然后使用簡單取余算法（例如11/3=2），得到指定的節點Node2，然后存儲數據到指定服務器。但涉及到服務器擴容時，以上見取余算法就會遇到很大的問題，例如將3台緩存服務器增加到4台時(11/4=3)，那么在Node3上找不到該緩存，緩存未命中的概率為75%。並且隨着擴容，未命中的概率會不斷的增大（N/N+1）。這時就需要使用比較流行的一致性hash算法，該算法通過一致性Hash環的數據結構實現KEY到緩存服務器的映射，過程若下圖所示。
算法的具體過程為：首先構造一個232的整數環，根據節點名稱的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