01 分布式缓存使用现状

众所周知，分布式缓存作为系统性能提升的银弹利器，它在大型分布式系统中的使用频率非常高，对系统的性能提升起到了不可或缺的作用。近些年来，分布式、中心化红遍整个 IT 界，以高内聚、低耦合为原则，CRM 逐步演进成为多中心分布式部署的架构，由此产生的各中心间交互在业务日益复杂的催化下，系统对 PAAS 平台组件提出了更高的要求。不出意外的是，分布式缓存在业务生产中也正面临着诸多挑战。

02 理想与现实的冲突

业务系统引入分布式缓存的初衷是提升系统性能，给使用人员带来快、简、灵的操作体验。为了能够尽快得到分布式缓存带来的好处，加速在系统建设中引入分布式缓存，采用懒汉式（读时触发）的加载模式--当缓存中没有数据时，先从 DB 读取，再加载到分布式缓存中，这种模式普遍存在于很多系统建设的初期。

伴随着时间的推移和业务诉求的不断变化，人们会在使用中发现，要满足复杂业务的要求，光使用分布式缓存还是不够，因此加入了应用服务器作为二级缓存，以期减少应用与远程分布式缓存的交互次数。调整后系统的缓存使用架构就变为两级模式。

在这个架构模式下，发现系统在很多业务场景下性能有了很大的提升，例如产销品查询、产销品关系查询。可随之也带来了一些缓存使用上的问题：

1. 缓存数据不透明：无论是远程的分布式缓存，还是本地的二级缓存，都是一个巨大的黑盒。目前并没有可靠的可视化工具能够清晰查看缓存的内容。尤其是在应用层对缓存的 key/value 值进行加工后，运维人员更没有办法通过简单的一个标识去查看缓存 key 对应的 value 值。

2. 多中心缓存刷新问题：多中心架构下，同一套配置数据，几个中心可能都需要，因此在做刷新的时候，如何保证各中心的缓存都能刷新到？如何确保漏刷情况被及时发现，并且能够灵活处理。

3. 缓存数据一致性问题：远程分布式缓存、本地二级缓存的数据与 DB 的数据一致性如何保证？如何及时发现不一致的情况并且能够提示预警。

在分布式缓存给业务系统带来的性能提升的理想前面，依然存在使用过程中技术与业务结合的痛点和运维过程中面临的一些比较实际的问题。解决理想与现实的冲突也是一个较大的挑战，怎么办？

03 直面挑战，给出答案

生活中我们常常遇到因时间推移、个人需求、人口数量等变化导致房屋设施老化、格局不合时宜的情况，需要不定期整理或是翻新。有趣的是，实际的 CRM 缓存优化过程跟旧房翻新的工序原本异曲同工。

围绕“一个愿景、两个目标、四个提升、七大举措”，CRM 各中心的缓存模块重构和优化分为两部分：一部分是主体改造部分，另一部分则是精修打磨部分。

04 主体改造——缓存刷新重构

改造前期--对现有功能的拆解

改造前期对原有功能逻辑的梳理过程，需要对现有的业务支撑力度有一定的了解。把原页面的所有元件，包括按钮、表单等都进行拆解，记录每个按钮的功能。拆解是一个机械的过程，不需要多加任何判断。所有需要优化的部分，放在后面的步骤中决定。便于后期区分哪些业务功能进行保留，哪些逻辑进行重整。

设计阶段--确定整体风格、进行整体设计

对现有的功能进行拆解与梳理之后，我们已经知道了系统中的存量功能，发现原有的旧版页面功能比较混乱，部分逻辑冗余、部分功能存在缺陷等。梳理之后按照业务维度，进行整理和归纳，确定总体优化方案。建立了统一刷新的总体事项和计划：

1. 构建 CRM 几大中心的缓存统一管理功能，让运维人员易懂，功能清晰，支持单值刷新、支持批量刷新，支持缓存值查看；

2. CRM 一点刷新能力，涉及关联关系的缓存数据，根据业务要求做到同步刷新，包括关联的规格、实例模板等。实现一点刷新，不再需要人为去判断逻辑顺序，可以按照销售品维度、产品维度等进行全量刷新；

3. CRM 缓存刷新操作有迹可循，分布式应用多节点缓存信息可巡检、对比，刷新操作日志保留，方便运维和开发人员对问题进行定位与跟踪；

4. 提供 CRM 可视化界面，经过加工的 KV 值按结构进行展示，可直观、清晰地查看到分布式缓存、本地缓存、数据库三者的缓存对象具体值。

重新设计后的统一刷新架构如图

优化重构改造

第一步：拆除工作--剔除不必要冗余的逻辑

经过对功能的拆解和专题设计阶段，梳理出散落在各个中心的缓存刷新口径大概有 10 多个，口径多、页面多，难免给运维人员混淆视听，这就需要从各中心散落的缓存管理功能中取其精华、去其糟粕，剔除掉散落不一的页面和冗余的业务逻辑，将各中心保留的页面功能一并集成到门户的统一管理页面中。

第二步：隐蔽施工工程--缓存刷新机制统一，zk 命令发布监听模式统一

分布式架构中，对于需要更高的性能以及更好的可用性的数据，往往将缓存设计为多级结构，如果有数据更新，需要考虑如何保证各个主机节点进程内缓存数据一致。为保证缓存刷新的一致性，我们使用了新的刷新模式，通过刷新页面发起缓存刷新请求，当应用接收到缓存刷新请求后，生成缓存刷新命令并且把命令写入到 ZK 节点，每个中心后端应用都有一个 zookpper 提供的 api 做实时的监听，当监听到 zk 节点数据发生变化后，每台应用获取节点的命令、解析命令、调用命令缓存刷新的 API，从而刷新本地应用节点的进程内缓存数据。

第三步：基础施工工程--按照使用角色提供刷新界面

参与缓存运营工作角色包括版本发布、故障运维人员和规格数据运营三种角色。角色不同、操作习惯也会存在一定的差异，为了让缓存管理功能更加强大，我们针对不同的角色，提供了个性化的刷新界面和逻辑。

1、针对运维或数据运营角色人员，我们提供了 key 值查看缓存数据并刷新的界面。

2、针对版本发布人员，我们只需要提供表、字段对应的 KV 关系刷新界面即可。

第四步：常规装修--缓存可视化、缓存巡检、缓存操作日志

要解决缓存可视化问题，必须将缓存的内容进行结构化展示。在业务系统中，我们缓存的数据有可能是单一的 KV 映射值，也可能是复杂的业务对象数据。因此要提供给运维人员一个可视化的展示，我们就需要将 key 和 value 值进行内部进行封装再提供出来。以产商品的配置数据缓存结构为例，它的结构是由不同的子表缓存对象组成。

在完成结构化的梳理后，再增加页面缓存数据结构化展示，使得结果能够更清晰直观。

完成了刷新缓存动作后，操作是否成功，缓存的数据情况无法查看。为解决这个问题，还需要提供可视化的巡检功能，操作后可以在页面发起请求，后端根据 key 值循环调用每个应用节点，获取 key 对应的缓存值进行稽核，对比本地缓存与数据库是否一致，标记数据不一致应用节点，同时组装本地缓存对象的数据值。

巡检结果可视化，差异数据对比，效果如下图所示：

巡检

数据差异对比

05 精修打磨——缓存引擎使用提升

旧房翻新经过主体改造之后，基本已经达到入住标准，但是对于改造前房屋主人保留的家具物品等，还需要进行妥善地规整与安置，从而达到拎包入住的水准。俗话说，“三分雕，七分琢”，在完成主体功能优化和重构后，对常用的核心功能也需要进行精修与打磨，从而能够提升缓存的使用效率：

原子能力细化和封装

针对缓存的部分 API 进行原子化封装，对每个 API 给出详细说明，精益求精，规范及方便后续研发人员的使用。

缓存补偿和缓存拦截机制

为防止系统产生脏数据，需要对异常数据进行预防和清洗。对于缓存数据缺失值，需要采取补偿机制；对于异常值，则增加了缓存校验和拦截机制。

打造特色--灰度生产缓存无缝切换

CRM 灰度环境的应用，让部分用户进行版本升级的内测，很大程度地规避了因版本问题产生生产故障的风险。在架构设计时，就将灰度和生产环境的缓存进行了隔离。但这种方式也带来了一些问题，当灰度验证的业务数据没有及时办结，在灰度切换到生产环境后，原来灰度的业务数据无法在生产被读取。因此我们对应用进行读取策略改造，通过生产与灰度共享一套实例数据（用户、订单、费用等）缓存，实现灰度环境的订单也能在生产环境查询与续办。用户在系统切换后，无需重新下单受理，从而实现了灰度和生产环境之间的无缝切换。

06 感言

不同时期业务对系统性能的要求不同，不能性能要求情况下对系统设计的要求也不同，说起来比较拗口，简言之即是系统在持续的支撑演进过程中，都会出现由于前期设计不充分、不到位的情况所引发的问题。解决此类的问题，可以是小心谨慎，哪里不行医哪里；也可以是大刀阔斧，横竖来一刀。对于这种不根治则就会持续缠绵于病榻的问题，修修补补能得一时之爽，但是果断重构方显担当。