本地緩存ViewCache的實現原理及優化

三個月前加入到類目和共享打通的項目中。其中個人一個任務就是完成對viewCache進行優化，使得ViewCache能夠訂閱指定的數據包。在這過程當中對ViewCache這個本地緩存的實現有了比較深刻的瞭解，在這裏分享出來。

1、ViewCache的介紹
1.使用場景
因爲類目，類目屬性，屬性表，省市地區等等一些信息不是常變更，使用頻率可能比較高，這種場景就不適合RPC的方式來調用了。因而就有本地緩存的ViewCache這種的東東，1688這邊的類目相關以及地區銀行等等數據很大一部分都是經過ViewCache來使用的。

2.使用過程

<bean id="viewCacheFactory" class="com.alibaba.china.biz.viewcache.DefaultViewCacheFactory" >
</bean>

viewCacheFactory.getViewCache().getPostCategoryTree().getNode(int categoryId)便可取出Category對象

應用裏面只要配置一個bean。應用第一次使用的時候就會加載文件到內存中去。之後每次使用這個文件的時候都會直接從內存裏面取出。目前ViewCache有27個子文件，每一個子文件都是獨立的數據。譬如後臺類目，前臺類目，類目屬性，省市地區，分別是一個獨立的文件。每週會有人負責打包文件，並推送文件到各個訂閱的ViewCache的機器上。


2、ViewCache的實現
1.角色劃分
ViewCache中分爲三種角色：Master,Server,Client
Master:VC文件的生成者
Server:VC文件的分發者
Client: 使用VC文件的應用
其中全部角色能夠混合使用，譬如一臺應用既能夠是Master,也能夠是Client。

2.Zookeeper上6種節點

2.1  1688vc   持久化節點。1688根節點，下面的master、server、client 、clientNotify、queue所有是該節點的子節點，這裏記錄最新的文件版本信息，由Master角色每次生成VC文件分發成功以後寫入當前最新的VC子文件信息。

2.2  master   下面掛臨時子節點。Master角色會在這個節點下建立子節點，寫入本身地址和當前使用的子文件版本
2.3  server    下面掛臨時子節點。Server角色會在這個節點下建立子節點，寫入本身地址和當前使用的子文件版本
2.4  client     下面掛臨時子節點。Client角色會在這個節點下建立子節點,寫入本身地址和當前使用的子文件版本
2.5  clientNotify  下面掛臨時子節點。由Client角色在這個節點下建立子節點，子節點名稱爲Client名稱,子節點數據由Server寫入本身的ip和port
2.6  queue     下面掛持久化順序節點。由Master角色或者Client角色建立子節點，子節點的名稱爲順序id，子節點數據爲Client角色名稱。Server角色會監聽這個節點下全部子文件的變更。 


上圖就是Master,Server,Client等角色建立的的子節點。



上圖是clientNotify子節點中寫入的Server地址

3.文件推送流程
ViewCache經過zookeeper完成各角色之間的消息傳遞，而文件推送使用Netty。

3.1.Master角色

3.2.Server角色



3.3Client角色




3.4.消息總流轉圖



4.多級緩存
在應用啓動的時候，全部子文件會先被加載到SoftReference的Map中，做爲內存中的緩存，當子文件第一次被使用的時候纔會變成常駐內存中。當內存不足，進行GC或者新文件推送的時候SoftReference就會被的Map就會被清空。減小了應用讀取文件的時間消耗。其實我的以爲這個做用並非很大。


3、ViewCache的改造
當前VC含有27個子文件，可是不支持推送指定文件到本地，加載指定文件到本地。爲了實現這種狀況，就須要對ViewCache進行改造。因爲對ViewCache相關代碼已經看得很是詳細，那麼須要修改的地方就很清晰了。

修改點：
1.Client啓動的時候在配置bean的地方配置須要加載的文件
2.在Client角色建立1688vc/client下子節點的信息的時候把指定加載的文件名稱寫入節點中。
3.在Client角色自我檢測是否更新的時候判斷指定加載的文件。
4.在Client角色啓動把全部文件讀取到SoftReference的Map的時候要進行判斷指定加載文件。
5.在Master角色檢測Client角色是否須要拉取新文件的地方只判斷指定加載的文件。

固然了，在考慮到老的二方庫兼容的問題，若是不附帶指定加載文件配置信息的，默認加載所有VC子文件。

4、ViewCache其餘能夠優化的地方
以前作的是對ViewCache文件定製化推送和加載的優化。這裏補充幾個ViewCache其餘優化點。
1.目前的ViewCache的各個角色之間是按照節點順序去處理的，包括各個子文件也是沒有優先級的。咱們能夠在各個角色以及子文件加上優先級。具體作起來也比較簡單，各角色註冊到各自節點client、master、server的時候把本身的優先級寫入到節點中，這樣master在檢測client須要更新以及爲server推送最新文件的時候能夠加上優先級。client在拉去文件的時候根據配置的文件優先級來順序拉去文件。

2.目前的ViewCache中Master節點只有一臺機器沒法保證高可用性。爲Master角色作好主從控制，主Master機器負責master全部功能，這個主從控制經過zookeeper上建立臨時順序節點，判斷本身是否是最小的節點來作控制。不是主的只要被動接受主的推送文件便可。從會監聽master節點變更，當主掛了的時候，會有且只有一個從頂替成爲主。



5、感悟
不得不認可原先設計ViewCache的人挺牛逼的，據說是一個高P的架構師設計的。總體抽象的很是好，不管是擴展性、可用性都作的很好。特別是基於zookeeper作的消息通知以爲挺經典的。可是我熟悉了這套系統以後就發現整個系統過於複雜。針對於目前使用的場景徹底能夠再進行一些精簡。

若是有感興趣或者有疑問的地方，敬請交流