客户端缓存让程序越跑越快

众所周知 , 数据缓存是系统调优时常用的并行之有效的手段，无论从操作系统还是应用系统，数据缓存 策略无处不在。就目前应用来看，服务端数据缓存策略和缓存框架是比较成熟和广泛的，但客户端缓存策略和框架则相对薄弱，本文则着重对业务系统的客户端缓存策略和缓存框架进行分析和论述。

在业务系统日常运行过程，大部分基础信息变化频率是非常低的，例如会计科目、凭证类型、物资品种等，而这些基础信息在日常功能被大量频繁使用，如果把这些数据信息缓存在客户端，这不仅能大大提高业务系统性能提高，而且有助于改善用户满意度。

但如何把客户端缓存对于业务组件透明和客户端缓存数据及时更新，是客户端缓存能否成功应用的关键。在B/S 模式下，浏览器对网页信息的缓存策略是应用的比较广泛和成功的，在激活缓存策略的前提下，浏览器访问图片资源时，首先验证图片资源是否在本地存在副本，如果存在，则在访问请求 Header 中使用 If-Modified-Since 和ETag 参数: 如果服务检测到图片文件被变更，则发送整个图片资源；若未发生变更，则服务端响应304(Not Modified) 状态, 而不发送整个图片资源，从而减少网络传输流量，提高响应速度。

 

例如网页浏览器启用缓存策略后，访问静态图片文件时客户端与服务端交互过程如下：

 

 

 

但在一个业务系统中，相关的业务数据是保存在数据库中，客户端通过特定访问协议（如 Soap 协议）访问服务端，如何确定业务数据是否发生变更是一个难点。例如在账务子系统中，“选择会计科目”是“输入会计凭证”等日常功能中频繁操作的一个动作，而根据监控数据得知，“会计科目数据及权限”在一个月度中很少发生变化，那么把“会计科目数据”缓存在客户端对整个账务系统的日常功能带来极大的性能提升，然而当“会计科目数据及权限”被修改后如何及时通知客户端更新缓存呢？

 

如果在账务系统应用中通过硬编码实现缓存数据更新功能（例如在“设置会计科目”功能中保存数据后通知“选择会计科目”功能数据发生变更），显然是不合适的，这不仅增加各个功能点之间的耦合度，还会让整个系统的复杂度呈几何倍数的增加，不利于后续维护和扩展。

 

如何把缓存框架独立于业务系统，并对业务系统透明化是解决问题的关键。通过分析我们可以看出，一般的业务系统是多层架构模式，不同层次之间一般通过服务接口进行调用，那么把缓存框架独立并透明化的奥秘是对代理的处理，如下图：

注：

服务关系列表 ：描述服务端提供的供外部调用的接口服务之间的影响关系，此列表是在业务系统运行时根据监控数据进行配置生成。服务关系列表中的“查询” 类型的“服务”才能应用缓存策略，而“修改” 类型的“服务”则用于控制生成“操作时间戳”的范围 ;

缓存策略主要有“每次调用服务时进行检查”、“定时检查”、“不进行检查”等。

 

操作时间戳 ：记录“服务关系列表”中“修改”类型的“服务”的操作时间，用于通知“缓存框架”是否需要更新本地缓存数据。

 

代理桩 ：即代理类或代理接口，例如客户端的 Soap 服务代理类，通过代理类可以截获和控制相关动作。

 

实现原理 ：客户端调用服务端相关服务时，“代理桩”检查当前服务方法是否在“服务关系列表”进行配置，如果当前服务方法被设置为“修改”类型，则把当前操作时间记录到“操作时间戳”中；如果当前服务方法被设置为“查询”类型，则检查本地是否存在缓存数据，如果存在则根据相关的“缓存策略”及“操作时间戳”判断当前缓存数据是否需要重新刷新，如果不需要则从本地缓存中加载数据。

 

上述缓存框架对于业务系统的应用层是透明的，在业务系统运行时通过调整“服务关系列表”动态设置特定功能服务的“缓存策略”，不同的生产运行环境可以根据自身的业务特点调整配置参数提高“缓存命中率”，从而快速提高特定功能点的响应速度。

 

例如在账务系统在“凭证输入”功能中，若对“选择会计科目”功能应用“缓存策略”，则只需要简单的配置 “服务关系列表” 即可。

 

因为“获取会计科目数据服务”受“设置会计科目”、“设置用户所属角色”和“角色权限分配”功能服务影响，则“服务关系列表”配置如下：