本地缓存ViewCache的实现原理及优化

2019独角兽企业重金招聘Python工程师标准>>>

三个月前加入到类目和共享打通的项目中。其中我的一个任务就是完成对viewCache进行优化，使得ViewCache可以订阅指定的数据包。在这过程中对ViewCache这个本地缓存的实现有了比较深入的了解，在这里分享出来。

一、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的机器上。


二、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就会被清空。减少了应用读取文件的时间消耗。其实个人觉得这个作用并不是很大。


三、ViewCache的改造
当前VC含有27个子文件，但是不支持推送指定文件到本地，加载指定文件到本地。为了实现这种情况，就需要对ViewCache进行改造。由于对ViewCache相关代码已经看得非常详细，那么需要修改的地方就很清晰了。

修改点：
1.Client启动的时候在配置bean的地方配置需要加载的文件
2.在Client角色创建1688vc/client下子节点的信息的时候把指定加载的文件名称写入节点中。
3.在Client角色自我检测是否更新的时候判断指定加载的文件。
4.在Client角色启动把所有文件读取到SoftReference的Map的时候要进行判断指定加载文件。
5.在Master角色检测Client角色是否需要拉取新文件的地方只判断指定加载的文件。

当然了，在考虑到老的二方库兼容的问题，如果不附带指定加载文件配置信息的，默认加载全部VC子文件。

四、ViewCache其他可以优化的地方
之前做的是对ViewCache文件定制化推送和加载的优化。这里补充几个ViewCache其他优化点。
1.目前的ViewCache的各个角色之间是按照节点顺序去处理的，包括各个子文件也是没有优先级的。我们可以在各个角色以及子文件加上优先级。具体做起来也比较简单，各角色注册到各自节点client、master、server的时候把自己的优先级写入到节点中，这样master在检测client需要更新以及为server推送最新文件的时候可以加上优先级。client在拉去文件的时候根据配置的文件优先级来顺序拉去文件。

2.目前的ViewCache中Master节点只有一台机器无法保证高可用性。为Master角色做好主从控制，主Master机器负责master所有功能，这个主从控制通过zookeeper上创建临时顺序节点，判断自己是不是最小的节点来做控制。不是主的只要被动接受主的推送文件即可。从会监听master节点变动，当主挂了的时候，会有且只有一个从顶替成为主。



五、感悟
不得不承认原先设计ViewCache的人挺牛逼的，听说是一个高P的架构师设计的。整体抽象的非常好，无论是扩展性、可用性都做的很好。特别是基于zookeeper做的消息通知觉得挺经典的。但是我熟悉了这套系统之后就发现整个系统过于复杂。针对于目前使用的场景完全可以再进行一些精简。

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

转载于:https://my.oschina.net/u/2250599/blog/1505665