本地缓存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作的消息通知以为挺经典的。可是我熟悉了这套系统以后就发现整个系统过于复杂。针对于目前使用的场景彻底能够再进行一些精简。

若是有感兴趣或者有疑问的地方，敬请交流