摘要 为了提升传统的缓存刷新的性能，本文提出了一种基于“企业内外网强隔离装置、数据库中间件、及应用程序模拟器”的复合技术为背景的实时缓存数据刷新实现技术，它与传统的应用缓存刷新架构的设计方式不同，它最主要的优势是实时性强、易扩展、数据一致性更准确、稳定性更高，有效支撑了大中型企业IT运行环境的服务能力。通过实验证明，使用这种实时缓存数据刷新方案解决了解决级运维复杂、数据一致性、系统稳定性等问题。
关键词 企业级 内外网穿透 实时缓存 刷新服务
An implementation of real time cache data refresh based on Enterprise Intranet application scenarios
[Abstract]
In order to improve the performance of traditional cache refresh, the invention provides a method based on "enterprise internal and external network isolation device, database middleware, and application Simulator" composite technology as the background of the real-time data cache refresh technology, its design and application of the traditional brush cache architecture is different, its main advantage is real-time, easy expansion, the consistency of the data is more accurate and more stable and effective support of the large and medium-sized enterprises operating environment of IT service capability.The experimental results show that the real-time cache data refresh scheme is used to solve the problems of complex operation, data consistency, system stability and so on.
[Key words] Enterprise Internal and External Network Realtime cache Refresh Service
1 引言
在信息化高速发展的今天，尤其是互联网应用的普及，大多数应用为了应付高并发、高可用、高体验等，系统架构设计中通常都会考虑使用缓存模块来提升QPS和系统稳定性。例如，通常会使用中央缓存系统Memcached和Redis等、以及本地缓存HashMap等的方式进行系统架构设计，但是，所有采用缓存设计的系统架构设计都必须考虑一个场景，那就是缓存的刷新和实时性要求。
然而，大多数的解决方案都是采用定时器或者是监听查询删除新增等方式来进行缓存的更新，这种方式在实时性要求不高的场景下适用的，但是在实时性要求非常高、并且业务复杂度高的场景下，这样的设计就有点形同虚设，没有起到实质性的作用。
一个使用缓存Cache的站点会监听客户端向服务器端发出的请求，并保存服务器端的回应——比如HTML页面、图片等文件。接着，如果有另外一个使用相同URL发送请求，他能够使用之前已经保存下来的反馈文件，而不是再次向服务器发出请求。一般传统的缓存刷新方法是通过数据库触发器、或者定时任务配合消息通知等方式进行缓存数据更新，一般要经过QUERY、DELETE、ADD等一系列操作才能完成一次缓存更新事务，缓存的实时性不高，IT资源的占用较多，效率低下。因此，本文提出了一种基于“企业内外网强隔离装置、数据库中间件、及应用程序模拟器”的复合技术为背景，一种基于企业级内外网应用场景的实时缓存数据刷新实现技术（英文名称：“ASD-Low Delayed Cache Refresh ”，简称：“ASD-LDCR”），它与传统的应用缓存刷新架构的设计方式不同，它最主要的优势是实时性强、易扩展、数据一致性更准确、稳定性更高，有效支撑了大中型企业IT运行环境的服务能力。
2 传统的缓存同步技术分析
传统的缓存同步和实时刷新技术一般都是根据具体的业务进行个性化定制，这种做法往往会导致业务复杂度会增加，系统运维成本等也会增大；然而，这种方式在需要进行大数据量同步和刷新的场景下，就会显得力不从心。一般传统的解决方案是通过非实时或者准实时的的Task的方式对缓存数据进行批量更新。然而在现实场景中，这两种方案能够单独使用的情况少之又少，往往需要通过两种方案结合共同使用，才能解决缓存同步和刷新的业务问题。综上所述，传统解决方案的问题如下：
2.1定制缓存
往往需要局部做更大的改造，运维复杂；在需要进行大数据量同步和刷新的场景下显得力不从心。
2.2批量缓存
一把是非实时或者准实时的，达不到实时性高的要求；运行不稳定，容易出现数据一致性问题。
3实时缓存技术刷新技术分析
本文研究的是一种基于企业级内外网应用场景的实时缓存数据刷新实现技术（英文名称：“ASD-Low Delayed Cache Refresh ”，简称：“ASD-LDCR”），它与传统的应用缓存刷新架构的设计方式不同，它最主要的优势是实时性强、易扩展、数据一致性更准确、稳定性更高，有效支撑了大中型企业IT运行环境的服务能力。
ASD-LDCR的目标是实现企业级内网数据库的高安全统一存储，实现企业信息内网与信息外网同时提供IT服务能力的整体解决方案，具有以下优点：
1. 增量订阅和消费
2. 数据实时性高；
3. 批量处理能力强；
4. 跨平台集成整合；
5. 企业级内外网轻量穿透；
6．简易化实施运维。
下面将结合“定制缓存”和“批量缓存”两种传统缓存技术存在的问题，提出本文ASD-LDCR的方案优点，也就是我们改进后的解决方案。
在我们的设计中，通过借助数据库中间件（如：MySQL）集群架构的数据复制原理，实现本文ASD-LDCR的核心模块（增量订阅和消费模块）设计，主要包括log日志抓取与解析（EventParser），事件分发与过滤（EventSink），事件存储（EventStore）等主要子模块过程。HA采用Zookeeper保存各个子模块的状态，让整个增量订阅和消费模块实现无状态化，Consumer(客户端)的状态也可以保存在ZK之中，整体上通过一个Manager System进行集中资源管理和分配。
ASD-LDCR模拟Slave的交互协议，向Master发送Dump协议，Master收到Dump请求后开始推送Binary log给Slave(ASD-LDCR)，ASD-LDCR解析Binary log对象Byte流，实现了数据的实时性要求，通过Slave的特性，完成了大业务下实时增量缓存数据的更新。
ASD-LDCR模块部署简单，一般与平台其他模块一起实现一键式部署，有专门的管理界面进行监控管理，运维简易。
4实时缓存技术刷新实现原理
从原理来看，本文借助数据库集群主从节点数据复制协议，主要分成三个步骤，说明如下：
实时缓存技术刷新实现原理
（1）master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events，可以通过show binlog events进行查看）；
（2）slave将master的binary log events拷贝到它的中继日志(relay log)；
（3）slave重做中继日志中的事件，将改变反映它自己的数据。
5实时缓存技术刷新解决方案
此方案中，Server代表一个ASD-LDCR运行实例，对应于一个JVM，Instance对应于一个数据队列 （1个server对应1..n个Instance)。Instance包括以下组件：EventParser (数据源接入，模拟slave协议和master进行交互，协议解析)；EventSink (Parser和Store链接器，进行数据过滤，加工与分发的工作)；EventStore (数据存储)；MetaManager (增量订阅&消费信息管理器)。
5.1 EventParser方案说明
通过Connection获取上一次解析成功的位置，如果第一次启动，则获取初始制定的位置或者是当前数据库的binlog位点，Connection建立连接，发生BINLOG_DUMP命令，DB开始推送Binary Log，接收到的Binary Log通过Binlog parser进行协议解析，补充一些特定信息，传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储成功，存储成功后，定时记录Binary Log位置。如下图所示：
数据过滤：支持通配符的过滤模式，表名，字段内容等；
数据路由/分发：解决1:n (1个parser对应多个store的模式)；
数据归并：解决n:1 (多个parser对应1个store)；
数据加工：在进入store之前进行额外的处理，比如join。
（1）1:n业务：
为了合理的利用数据库资源， 一般常见的业务都是按照schema进行隔离，然后在DB上层或者dao这一层面上，进行一个数据源路由，屏蔽数据库物理位置对开发的影响，主要是通过分库分表路由来解决数据源问题。 所以，一般一个数据库实例上，会部署多个schema，每个schema会有由1个或者多个业务方关注。
（2）n:1业务：
同样，当一个业务的数据规模达到一定的量级后，必然会涉及到水平拆分和垂直拆分的问题，针对这些拆分的数据需要处理时，就需要链接多个store进行处理，消费的位点就会变成多份，而且数据消费的进度无法得到尽可能有序的保证。 所以，在一定业务场景下，需要将拆分后的增量数据进行归并处理，比如按照时间戳/全局id进行排序归并。下图所示：
目前实现了Memory内存、本地file存储以及持久化到zookeeper以保障数据集群共享。Memory内存的RingBuffer设计。如下图所示：
Memory内存的RingBuffer设计
定义了3个Cursor：
Put : Sink模块进行数据存储的最后一次写入位置；
Get : 数据订阅获取的最后一次提取位置；
Ack : 数据消费成功的最后一次消费位置；
借鉴Disruptor的RingBuffer的实现，将RingBuffer拉直来看。
拉直RingBuffer模型
实现说明：
Put/Get/Ack cursor用于递增，采用long型存储；buffer的get操作，通过取余或者与操作。(与操作： cusor & (size - 1) , size需要为2的指数，效率比较高)。
Instance代表了一个实际运行的数据队列，包括了EventPaser,EventSink,EventStore等组件。抽象了CanalInstanceGenerator，主要是考虑配置的管理方式：
Manager方式：和你自己的内部web console/manager系统进行对接。
Spring方式：基于spring xml + properties进行定义，构建spring配置spring/ memory -instance.xml。所有的组件(parser , sink , store)都选择了内存版模式，记录位点的都选择了memory模式，重启后又会回到初始位点进行解析。
特点：速度最快，依赖最少spring /file-instance.xml。所有的组件(Parser , Sink , Store)都选择了基于file持久化模式，支持单机持久化spring/default-instance.xml，目前持久化的方式主要是写入zookeeper，保证数据集群共享， 支持HA，spring/group-instance.xml 主要针对需要进行多库合并时，可以将多个物理instance合并为一个逻辑instance，提供客户端访问。
场景：分库业务，比如产品数据拆分了4个库，每个库会有一个instance，如果不用group，业务上要消费数据时，需要启动4个客户端，分别链接4个instance实例。使用group后，可以在canal server上合并为一个逻辑instance，只需要启动1个客户端，链接这个逻辑instance即可。
Instance设计方案
5.5 Server设计方案说明
代表了一个运行实例，为了方便组件化使用，特意抽象了Embeded(嵌入式) / Netty(网络访问)的两种实现：
Embeded : 对latency和可用性、分布式的相关技术(比如failover)有比较高的要求；
Netty : 基于netty封装了一层网络协议，由server保证其可用性，采用的pull模型，当然latency会稍微打点折扣，不过这个也视情况而定。
5.6 HA设计方案
ASD-LDCR的HA分为两部分，LDCR-server和LDCR-client分别有对应的HA实现：
LDCR-server: 为了减少对dump的请求，不同server上的instance要求同一时间只能有一个处于running，其他的处于standby状态。
LDCR-client: 为了保证有序性，一份instance同一时间只能由一个client进行get/ack/rollback操作，否则客户端接收无法保证有序。
整个HA机制的控制主要是依赖了zookeeper的几个特性，watcher和EPHEMERAL节点(和session生命周期绑定)。
大致步骤：
（1）LDCR-server要启动某个instance时都先向zookeeper进行一次尝试启动判断 (实现：创建EPHEMERAL节点，谁创建成功就允许谁启动)，创建zookeeper节点成功后，对应的LDCR-server就启动对应的instance，没有创建成功的instance就会处于standby状态，一旦zookeeper发现LDCR -server A创建的节点消失后，立即通知其他的LDCR-server再次进行步骤1的操作，重新选出一个LDCR-server启动instance。
（2）LDCR-Client每次进行connect时，会首先向zookeeper询问当前是谁启动instance，然后和其建立链接，一旦链接不可用，会重新尝试connect。
（3）LDCR-Client的方式和LDCR-Server方式类似，也是利用zookeeper的抢占EPHEMERAL节点的方式进行控制。
6 实时缓存技术刷新的关键点
（1）ASD-LDCR Parser (数据源接入，协议交互，协议解析)：
ASD-LDCR Parser在整个缓存刷新组件中起到核心作用，通过建立与数据库中间件的Connection获取上一次解析成功的位置(如果第一次启动，则获取初始指定的位置或者是当前数据库的Binlog位点)后，发送BINLOG_DUMP指令。开始推送Binaly Log
接收到的Binaly Log的通过Binlog parser进行协议解析，补充一些特定信息传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储成功，存储成功后，定时记录Binaly Log位置。
BINLOG_DUMP指令如下：
// 0. write command number
// 1. write 4 bytes bin-log position to start
// 2. write 2 bytes bin-log flags
// 3. write 4 bytes server id of the slave
// 4. write bin-log file name
（2）ASD-LDCR Sink (链接器，数据过滤，加工与分发)：
ASD-LDCR Sink也是模块核心数据加工厂，通过数据过滤，完成通配符的过滤模式，表名，字段内容等。进行数据路由分发：解决1:n (1个Parser对应多个Store的模式)；完成数据归并，解决n:1 (多个Parser对应1个Store)；完成数据加工，在进入Store之前进行额外的处理。
（3）ASD-LDCR Store (数据存储)：
ASD-LDCR Store类似RingBuffer的实现思路，实现了Memory内存模式以及本地File存储、Mixed混合模式的存储。
（4）ASD-LDCR Manager (增量订阅&消费信息管理器)：
ASD-LDCR Manager包含一个运维的Console，在分布式环境中Manager管理尤为重要。一个总体的Manager System对应于n个Server（物理上来说是一台服务器）, 那么一个Server对应于n个Instance (Destina tions)，大体上是三层结构，第二层也需要Manager统筹运维管理。
7测试结果分析
本节将通过实验，主要针对配置数据库来完成数据实时缓存刷新，下面将详细阐述实验过程。
（1）配置监听的数据库地址账号
（2）开始监听数据库变化信息
（3）数据库变化时，监听服务发生变化
（4）客户端会拿到变化数据，如下图所示
（5）再来将进行数据实时缓存刷新前和数据实时缓存刷新后的数据库进行对比，同步前：
同步后：
实验结果与分析：
可以看到进行数据实时缓存刷新前的数据库里，原本为“ssotest131xd”的字段变成了“test”字段，说明数据库配置成功，数据实时缓存刷新完成。
8总结
传统的缓存刷新方法要经过QUERY、DELETE、ADD等一系列操作才能完成一次缓存更新事务，缓存的实时性不高，IT资源的占用较多，效率低下。本文这种基于“企业内外网强隔离装置、数据库中间件、及应用程序模拟器”的复合技术具有以下特点：
1. 基于Java平台构建，本文实现跨主机操作系统平台；
2. 应用程序被封装成节点模拟器，使用集群心跳机制进行消息更新提醒，数据包基于日志增量进行订阅和消费；
3. 减少了传统方式中间环节（数据检索、数据复制、定时器执行等）的传输过程，大大提高了缓存刷新的性能；
4. 集群心跳监听与底层日志解析技术相结合，提高了资源使用的效率。
参 考 文 献
[1] http://www.cnblogs.com/YuArtian/p/5086791.html关于网站缓存的几种解决方案
[2] 陈杰. 本地文件系统数据更新模式研究[D]. 华科技大学 2014
[3] 刘洋. 层次混合存储系统中缓存和预取技术研究[D]. 华中科技大学 2013
[4] 陆承涛. 存储系统性能管理问题的研究[D]. 华中科技大学 2010