深度解析 12306 技术演进：从传统框架到云化内存数据平台的跨越

注：本文首发于 CSDN，转载请标明出处。

【导读】在年前的「技术揭秘 12306 改造」系列专题中，负责该项目的技术架构师刘云程从专业视角出发，运用科学论证剖析了 12306 应对高流量与高并发的关键技术点，并深入讲解了其两地三中心混合云架构。本期，他继续分享第三篇内容：如何将传统框架迁移至云化的内存数据平台。

以下为正文》》

摘要

12306 混合云的成功实践带来的核心启示在于构建一个自底向上均具备弹性伸缩能力的“云应用”体系。企业客户能够将关键业务的“子系统”部署在资源充裕的云计算数据中心，“云化”后的子系统能够“按需”获取所需的服务器虚拟机资源及动态调整网络带宽，从而利用这些资源克服在高流量和高负载下，因系统无法快速弹性扩展而引发的性能瓶颈。

本文列举了不同类型系统迁移至云平台的改造方案，涵盖从改造思路探讨、系统框架设计到项目实施的完整迁移流程，供读者参考交流。此处以 Pivotal Gemfire 云平台为例，因其已拥有大规模部署的成功案例。客户 IT 环境各异，对系统改造的思路和目标也不尽相同，Gemfire 是一个不错的选择，但并非唯一选项。

前言

在过去的 20 年间，系统架构师最普遍采用的系统框架是三层架构设计，包含 Web 层、应用业务逻辑层和数据库层；Web 层和应用逻辑层可随业务变化进行快速弹性扩展，然而绝大部分关系型数据库层难以实现此功能。在云计算、大数据和移动互联网时代，由于业务成长迅速、服务多样化、数据量急剧增加，用户对系统响应时间的要求愈发严格；在高负载情况下，无法横向扩展的数据库层往往成为制约系统性能的绊脚石。

在此篇文章中，讨论重点是从软件中间件平台（PaaS）和应用系统（SaaS）层面出发，利用“分布式内存数据网格 (In Memory Data Grid)”技术，将传统架构改造迁移至云平台。系统改造存在多种不同方式，主要取决于改造目的和所受限制；为了具体说明，我们提供以下三个案例供读者参考和交流。

1. 12306 项目：整个售票环节的一系列核心子系统均经过高度“云化”。旨在将云化后的子系统“按需”灵活部署在不同的数据中心（公有云或私有云），提供优质服务。云化手段是将子系统业务逻辑和数据置于 Gemfire 集群执行，利用 Map Reduce 技术，建立可弹性扩展平台，提供“高性能 CPU 计算能力”。
2. 某市社保项目：采取短平快的局部“子系统云化”，针对有高并发需求会导致瓶颈的子系统进行改造。手段是将子系统业务逻辑和数据放在 Gemfire 节点执行，建立可弹性扩展平台，利用 Gemfire 分布式并行查询技术来应对“高并发查询”的要求。
3. 金融单位 POC 测试项目：问题在于系统查询业务量大，关联表格多，在高并发情况下，查询反应时间长。POC 目的是验证在不更改子系统业务逻辑限制下，以最小代价修改“数据访问层（DAO）”，建立可扩展的“内存数据缓存层”，解决“高并发查询”的方案；此外，还涉及数据库与 Gemfire 集群之间“失效转移 fail over”的设计。以此为基础，未来再将业务逻辑逐渐移至 Gemfire 平台，进行改造升级。

一、12306 混合云的启示

在前两篇文章中提到，2012 年春运后，12306 承办单位——铁科院引入了“分布式内存数据网格”技术，将余票计算/查询子系统改造迁移至 Gemfire 云平台，局部解决了 12306 的主要瓶颈；改造后的子系统在 2013 年春运时上线，效果显著，虽然整个系统运行仍存在“卡、顿”等不足，但铁科院对此技术深具信心并坚持改革，才催生了后续一连串的子系统改造。在 2015 年春运，建立了两地三中心混合云服务模式，将大部分余票查询流量引导至阿里云提供查询服务；此举旨在借助云计算数据中心的资源，“临时性”解决春运期间因互联网购票和刷票软件所引发的难预测、高流量和高并发请求，降低系统不稳定的风险。

12306 混合云成功案例最大的启发是给企业客户和政府部门带来新思路，即将关键业务的“子系统”改造迁移至云平台架构，根据实际情况，将“云化”后的子系统部署在资源丰富的云计算数据中心（私有云或公有云）。例如，12306 核心系统经过全面改造和优化后，每个云化后的子系统都具有特定独立性，因为相关数据都放在 Gemfire 内存数据网格节点；这意味着这些子系统类似“云”一样，可以随着业务需求变大或变小，一分为多，自由地漂移到多个不同数据中心协同合作，避免在 IT 设备方面的重复投资，并提高资源利用率。

云化后的子系统部署在多数据中心，需特别注意下列两点建议：

1. 如果将子系统部署在公有云提供服务时，数据隐私保护和安全性应为首要考虑。
2. 如果规划将子系统部署在多数据中心时，在系统框架上必需考虑上下游子系统之间的数据传输或同步/异步设计。

以 12306 为例，两地多中心混合云的架构示意图如下；在春运售票高峰期间可以将余票查询功能部署在多个公有云数据中心提供快速服务（例如阿里云和电信天翼云）。

两地多中心混合云架构

二、系统改造迁移的思路和需求

随着企业成长，对于一个复杂的大系统而言，其业务功能不断增加，服务方式多样化，数据存储量越来越大，但系统性能却越来越慢，而用户对响应时间的要求越来越严格；尤其是在过去 5 年里，每年都有新技术的演进（大数据和分布式内存数据平台）和新业务的衍生（物联网应用，社交应用平台和移动应用）。

当传统架构系统已逐渐无法满足日趋成长的业务需求时，有两种方案可供选择，一是从硬件着手，scale up 的选项，即更换性能更强大的服务器；二是 scale out 的选项，从软件平台着手，进行应用系统改造，采取弹性可扩展的框架设计。

更换硬件服务器是最简单的做法，但以后更换成本会越来越高，系统性能提升空间越来越有限。软件应用系统的改造，是一劳永逸从根本做起，改造成本与系统的复杂度有关，是需要全面改造？还是选择性的局部改造？这需要根据实际使用情况来决定。

针对系统的 scale out 设计，如果要推翻以前的架构重建系统，那是个大工程，除非有下列三种情况：

1. 系统已经千疮百孔，无法再打补丁也无人后续维护
2. 原有的框架设计已优化到极致，无论如何优化，都已经无法满足日益增加的业务需求。例如，12306 就是典型例子。
3. 业务流程和组织管理方式有巨大的变动，需要重建系统

否则，最省钱和最有效的方法就是针对系统瓶颈做“局部改造”来提高性能，保护过去的投资。例如，社保项目就是典型例子。

在此篇文章中，讨论的重点是如何将系统改造迁移到云应用平台，由于每个系统都有其特殊性和复杂性的开发背景，其设计的系统框架、所采用的软件平台和开发技术也都随着时间演进而不一样。因此改造的方式需要依据实际的环境来进行。

1. 12306 系统改造思路和需求 – 按阶段逐步云化核心子系统

• 原来系统是使用 Stored Procedure 开发，系统已经优化到极致，很难再进一步提升性能。
• 如果采用 scale up 的硬件升级，投资过于庞大；随着铁路基础建设不断扩大，业务量也会随之增加，无法保证硬件升级后的系统性能会满足未来业务成长的需求。另外，春运高峰期过后该如何处置过剩的 Unix 小型机也必须列为考虑。
• 承办单位——铁科院经过仔细评估后，认为高流量和高并发问题必需采用云计算可弹性扩展的平台和技术来解决。
• 以分布式内存数据网格” - Gemfire 技术为切入点，以余票计算/查询子系统为试点项目。采取稳妥的改造策略，逐年逐步改造和优化其子系统，解决一系列环节上的瓶颈，保证在改造期间整个 12306 系统的稳定运行。
• 在改造初期，新旧两套系统必须同时并行运行。利用 CDN（Content Delivery Network）的流量管理功能，逐渐将流量加压到 Gemfire 集群，测试集群在高负载下是否能平稳过渡高峰售票期。
• 采用“多重 Gemfire 集群”相互备份的设计，同时并行运行，为未来“多数据中心”的部署当试点和铺路。

2. 社保系统改造思路和需求 – 短平快的局部子系统云化

• 社保制度逐年改革，新编制组织架构不断扩大，新业务不断增加，省市社保人数从数百万级别到某些人口大省超过亿的级别；这些社保缴费资料需要保存达数十年以上，永随一生，每年都有数百 T 甚至 P 量级的数据存储单位。社保单位必须考虑如何存储这些资料？如何在大数据量情况下提供快速查询服务？如何建设一个 IT 平台能随着未来业务成长而不断的弹性扩容，此为主要的改造思路。
• 社保系统是对外的公共服务平台于 2008 年上线，此平台是以互联网为载体，开通企业单位和个人网上申报业务的服务。在面对日益增加的网络业务办理需求，平台硬件系统（多部高端 Unix 小型机）所承载压力逐渐加大。系统硬件已逐渐出现瓶颈。在 2012 年 1 月集中申报期间，系统的 CPU（包含应用服务器和数据库服务器）高达 90% 以上，导致系统不稳定，无法正常访问，影响重大。
• 经过社保相关单位仔细评估，确立系统改造的策略应由两方面着手，一是建立虚拟化的云环境，二是针对子系统瓶颈进行局部改造，改造后的子系统平台需要支持“弹性扩展”，满足未来日益增加的网上业务。
• 采用 VMware 技术搭建虚拟化云平台来提升基础架构的扩展能力，采用 Pivotal Gemfire 可弹性扩展的高速缓存功能，支持高并发“热点数据”查询服务，降低原有数据库的 I/O 瓶颈，提高整个系统性能和稳定性。

3. 金融单位 POC 测试改造思路和需求 – 建立可扩展的“分布式内存缓存数据层”

金融单位系统庞大复杂，所有的子系统从设计到开发都需要严格遵循统一开发流程。

核心子系统业务逻辑不轻易更改。对系统而言，查询业务量多，数据量大，关联表格多，在高并发情况下，查询反应时间长。

POC 测试目的：

• 在不改系统业务逻辑情况下，对“数据访问层 DAO – Data Access Object”进行改造，建立可扩展的“分布式内存缓存数据层”；目的是提高业务查询性能，快速反应查询结果，降低原有数据库的 I/O 瓶颈，提高整个系统性能。
• 考虑系统稳定性和安全性，还需要验证“分布式内存缓存数据层”与关系型数据库之间“失效转移 fail over”的设计。

三、12306 系统改造迁移到 Gemfire 平台

在最初的框架设计已考虑系统性能问题，所以使用 Stored Procedure 开发来提升系统执行速度。此设计思路是参考德国和英国互联网售票经验——即总售票量 20% 的比率是透过互联网售票，也就是说当初 12306 系统规划是要满足每天售票量 100 万张的需求来设计。

在 2012 年春运 12306 对外开放时，涌入将近 2 千万人次登录，远远超过当初的预设目标，但又受限于系统架构无法弹性扩展，导致整个 12306 系统里里外外都不稳定，无法正常访问。在采用 Pivotal-Gemfire 云化后的 12306 系统有了“质与量”的大跃进，在 2015 年春运售票高峰日已达 560 万张，占了整体售票量的 60%；避免了过去日夜排队购票的痛苦，也节省了大量社会成本。

由于 12306 业务逻辑复杂，系统庞大，在此只以余票计算/查询为案例。有关整个系统的业务逻辑设计不在此讨论。下列的描述如果有误，也请各位先进指正。

2012 年 改造前的余票计算/查询子系统架构描述

1. 路局“实时”提供售票记录

火车票的席位销售是由每个路局规划和调控（铁路总公司共有 18 个路局），而 12306 与每个路局是共享同一个“票库”。换句话说，“线上”的 12306 是与“线下”的火车站点售票窗口，电话售票，和各地的售票点抢票。每个路局将每张票的销售记录都“实时“传送到 12306 在铁总数据中心“主数据库服务器”做汇总。

在铁总的数据中心 - 余票计算服务器集群是由“主数据库服务器”和 72 部 Unix 小型机组成；主数据库服务器汇总各个路局传输过来的数据后，利用数据库复制的机制，实时将数据“复制“到 72 部 Unix 小型机。

3. 并行处理余票计算：其中 8 部小型机做售票预处理，再将预处理结果送到 64 部小型机，64 部小型机“同时并行”处理余票计算。

4. 应用缓存服务器：64 部小型机将余票计算后的结果汇总产生余票表，将余票表放置在前端的应用缓存服务器集群；此举是要解决在高并发的情况下，缓存服务器提供更快速的余票查询服务。

5. CDN(Content Delivery Network) 服务器：12306 最外围部署 CDN 网络，其目的是使用户可就近取得所需信息，将用户的请求重新导向离用户最近的服务节点解决 Internet 网络拥挤的状况，还有调整负载均衡的功能，提高用户访问的响应速度。

6. 余票信息更新机制：余票信息更新是以“车次”为基准，每隔 10 分钟更新一次。当用户提交“区间站点”的余票查询时，先从 CDN 服务器查询资料，假如 CDN 的资料已超过 10 分钟，会从应用缓存服务器索取最新的数据。同理，当应用缓存服务器的资料超过时效，会触发余票计算流程，重新计算余票产生余票表，提交给应用缓存服务器。每隔 10 分钟更新的参数是可调整的。

12306 改造原则和目标

（1）设定性能指标：

以余票计算子系统为例，Gemfire 集群的余票计算性能指标需要达到 10，000 TPS 以上，并可以随着业务成长做弹性扩展。配合应用缓存服务器集群和最前端的 CDN 负载均衡服务器集群，预估 12306 可以支持每秒达百万次的余票查询。此部分的系统性能是与服务器 CPU 类型、内存大小、Gemfire 节点数和 x86 服务器数量都有关联。

（2）余票计算处理能力可随着虚机的增加而线性增加

余票查询是要反映最新的余票情况，作为购票的依据。在上篇文章已谈到余票计算的复杂度，需要很强大的 CPU 处理能力为后盾来计算每个区间站点的余票量；将计算结果放置到缓存数据服务器和 CDN 服务器。余票计算是利用 Gemfire Data Grid 和 Map Reduce 的技术提供巨大 CPU 处理能力。

（3）在不改变原有的体系框架上增加 Gemfire 集群，新旧两套系统并行运算

为确保 12306 生产环境的稳定性和平稳过渡，新旧两套系统必须同时运行，由最前端的 CDN 服务器控制访问流量，逐渐将需要余票计算的请求加压到 Gemfire 集群，测试 Gemfire 的承载能力，检验可扩展的功能。

（4）系统高可用性（High Availability）

Gemfire 的数据节点都有其它节点的备份数据，也可以将内存数据持久化到硬盘或是同步/异步写到数据库。

（5）x86 服务器

考虑未来多数据中心和混合云的部署，必须使用 x86 服务器为生产机。

根据 12306 改造设计原则在不改变原有的体系框架上增加 Gemfire 集群，在过渡期间，新旧两套系统并行运算，在过渡期后，以 Gemfire 集群为主。所以此步的改造是针对上述”改造前的余票计算/查询子系统架构”的第 2 项和第 3 项进行分析和改造。

12306 改造步骤：

（1）系统架构改造和数据上载

为确保 12306 生产系统的稳定运行和平稳过渡，在不改变原有的体系框架上增加 Gemfire 集群，新旧两套系统并行运算。那就必须考虑如何将数据从数据库实时同步到 Gemfire 集群做余票计算。

A．数据库复制服务器：增加一部数据库服务器，将铁总数据中心“主数据库服务器”汇总的数据实时复制到此部数据库服务器。

B．实时同步机制和 SQL 解析服务器：此步骤是从数据库取出 Log 数据并解析 SQL 语句，因为原来代码是用 Stored Procedure 开发的。

C．Rabbit MQ 服务器：同步机制服务器将解析过的 SQL 语句透过 Rabbit MQ 传输给 Gemfire 集群做余票计算。

D．Gemfire 集群将余票计算结果汇总后，提交给前端的应用缓存服务器提供余票快速查询。

（2）系统数据结构分析

数据结构分析和设计是在改造过程中最关键的一步，影响到后续性能的提升；利用“数据网格 Share Nothing”的特性，将数据切割，把“数据关联性强”的数据放在同一个 Gemfire 数据节点，再配合业务逻辑的设计，降低节点之间数据交换的延迟，提高系统处理能力。

（3）Benchmark（基准点）测试

• 进行 Benchmark 测试，评估每部 Gemfire 服务器的 TPS 和余票计算反应时间
• -验证 Gemfire 集群性能可随着 x86 虚机的增加而线性增加
• 测试“实时同步”机制，量测数据同步到 Gemfire 集群的稳定性，延迟和吞吐量

（4）系统稳定性，安全性和 HA 设计

在 Gemfire 的数据节点都有其它节点的备份数据来达到 HA 的目的，也可以将内存数据持久化到硬盘或是数据库。

使用 Gemfire 改造的实施流程：

1. 需求分析阶段：

• 需求调研，确定改造方案、
• 分析数据表结构、样本数据、数据量及应用访问特性信息

2. 架构设计：

• 设计 Region 结构，确定分区方式，和 设计二级索引
• 数据切割（partition）放在 Gemfire 的节点，每个节点数据量大小是根据物理机内存来决定。例如，在阿里云的节点一般是 30G 左右，在铁总数据中心的节点是 60G-120G 左右。从项目经验来说，Gemfire 数据节点以不超过 128G 可得到最佳效果。
• 利用 Data Grid 和 Map Reduce 的分布式技术提供强大的 CPU 处理能力。
• 使用到的 Gemfire 功能参考下列描述

3. 编码和单元测试：

• 12306 是采用 Stored Procedure 开发，必须将 Stored Procedure 解析，采用 Java 开发和编码，并将业务逻辑代码和数据都放在 Gemfire 节点，此举可以达到最高的系统性能
• 单元测试

4. 集成测试/准确度测试/性能调优：

• 在集群环境下进行准确度测试
• 在集群环境下进行性能及压力测试
• 依据测试结果进行性能调优
• 性能调优可能需要调整细部架构的重新设计

5. HA 和热部署测试

6. 线上运维：

• 创建 Release 版本并纳入管理
• 配置部署生产环境并进行持续监控

主要的 Gemfire 功能特性：

在 12306 改造过程中，使用到下列 Gemfire 的功能特性：

• Rich Objects: 以 objects 的形式体现和编码，自己定义数据结构
• Elastic Growth w/o pausing：弹性扩展和热部署
• Partitioned Active Data：根据数据属性，例如：客户，订单，车次，站名，做合理的数据切割，放在不同的数据节点。
• Redundancy for instant FT：HA 的设置
• Colocated Active Data：share nothing 的概念，将关联性强的数据放在同一个 Gemfire 数据节点，例如，车次，站名
• Replicated Master Data：数据量不大的常用数据，例如：站名字典和席位类别等，在每个 Gemfire 节点都有一份拷贝，此举是要减少数据的交换。
• Server-side Event Listeners：当数据在 Server 端产生变化时，会触发相应的操作
• Client-side Durable Subscriptions：当 Server 端满足客户端订阅的某些条件时，会推送信息
• Parallel Map-Reduce Function Execution：车次余票在每个 Gemfire 节点并行运算，再汇总运算结果
• Parallel OQL Queries
• Continuous Queries
• LRU Overflow to disk in native format for fast retrieval
• Parallel, Shared Nothing Persistence to disk w/ online backup
• Asynchronous Write Behind, Write Through or Read Through

四、社保项目子系统改造迁移到 Gemfire 云平台

社保申报子系统改造原则和目标

从访问量和并发量规模来说，社保所遇到的问题远远逊于 12306 所碰到的挑战。子系统改造是基于 VMware 虚拟化云平台基础上提升申报系统的查询性能。

（1）设定性能指标：

性能指标需要达到原有子系统性能 50 倍以上

（2）针对下列两个子系统瓶颈进行局部改造

（3）改造后的子系统性能可随着 Gemfire 节点虚机的增加而线性增加

（4）系统高可用性（HA）

参考 12306 描述。

子系统瓶颈的局部改造步骤：

社保系统是很复杂庞大的系统，由上百个模块构成。此系统采取三层架构设计，使用 Java 开发。主要问题在于高并发申报过程中，频繁的数据库写入和大量查询导致硬件平台高负载，子系统不稳定，无法正常访问。

1. 子系统的改造是针对数据库瓶颈提出改良方案
2. 采取数据库“读/写分离”的方式，将数据“写入”关系型数据库；将“读”的操作由 Gemfire 集群来提供，因为查询的访问量数十倍于数据的写入量。
3. 客户端资料写入时，同时将数据写入 Gemfire 节点和关系型数据库
4. 将“欲改造”的子系统业务逻辑代码改写后移到 Gemfire 节点执行
5. Gemfire 集群提供刚录入“热点数据”的快速查询
6. 不同子系统数据库之间的数据批量同步，将其它子系统“完整”的热点数据上载到 Gemfire 集群提供快速查询

相关的改造步骤和实施流程请参考上述的 12306 章节，改造后的架构如下图所示。

五、某金融单位 POC 项目 - 建立可扩展的“分布式内存缓存数据层”

金融单位系统是由上百个子系统构成，所有的子系统从设计到开发都要遵循标准统一开发流程，子系统采取三层架构设计，应用逻辑层与数据访问层设计层次分明。由于业务查询量大，牵涉到十几张关联表的查询，系统反应时间长。数据库读写频繁，CPU 时常满负载，导致系统性能瓶颈。

POC 子系统改造目标

改造方式是在不改变子系统业务逻辑情况下，对数据访问层进行修改 DAO 接口，引入“分布式缓存数据层”架构。

（1）设定性能指标：

性能指标需要达到原有子系统性能 20 倍以上

（2）针对两个子系统进行 DAO 接口改造

（3）验证改造后的子系统查询性能可随着 Gemfire 虚机的增加而线性增加

（4）系统高可用性（HA）

除了 Gemfire 集群的 HA 以外，还要考虑系统稳定性和安全性，采用“失效转移 fail over”设计，万一 Gemfire 集群异常时，改由数据库提供查询服务

数据访问层（DAO）改造步骤：

根据客户场景的要求，子系统的改造是针对数据库提出改良方案，对数据访问层进行修改 DAO 接口，嵌入“缓存数据代理层”（Delegator）架构。

缓存数据代理层有如下功能设计：

1. 缓存数据代理层向上封装数据访问接口，向下同时支持 DB 和 Gemfire 缓存数据层
2. 与业务逻辑相关的 API 可以随着业务需求，按需弹性增加 API 接口的支持
3. 根据 Gemfire 的特性，对 SQL 语句进行修改，设计成并行查询功能
4. 考虑数据一致性的要求，客户端数据直接写入关系型数据库，再将数据同步到 Gemfire 集群提供快速查询。
5. 万一 Gemfire 集群有异常，客户端可直接访问数据库，实现缓存数据层和 DB 之间的无缝切换
6. 另外，其他数据库或 Hadoop 集群存储全量业务数据，可将“热点数据”上载到缓存数据层
7. 通过 Gemfire 异步队列也可以将 Gemfire 的“热点数据”持久化到 DB 或 Hadoop 集群
8. 当查询在 Gemfire 缓存数据层未命中时，通过 Cache loader 从 DB 或 Hadoop 集群加载数据到缓存数据层，提供查询服务。

相关的改造步骤和实施流程请参考上述的 12306 章节，改造后的架构示意图如下：

六、结论和启示

由上面几个案例说明，不同的用户有不同的诉求，不同的系统开发环境和不同的限制条件所采用的改造方式也不一样。总结如下：

（1）12306 项目：流量高，并发性强，服务器负载高，反应时间要求严格；为了避免某一个环节的瓶颈，需要理顺整个流程，将一系列的子系统做“云化”的改造。根据实际需求，将云化后的子系统按需部署在公有云提供服务。改造的手段是用“分布式数据网格”的技术，结合业务逻辑特性和数据结构，将业务逻辑和关联性强的数据放在同个 Gemfire 数据节点，利用 Map Reduce 的技术提供强大的 CPU 计算能力来解决问题。

（2）社保项目：社保试点项目的改造重点是针对会发生瓶颈的子系统进行改造，将子系统业务逻辑和关联性强的数据放在同个 Gemfire 数据节点，利用 Gemfire 分布式并行查询技术来解决高并发查询的要求，并为政府行政部门管理透明化，内容更丰富的“Open Data”服务平台铺路。

对于人口大省，例如广东，河南，江苏和四川人口接近上亿的省份，随着社保体制的改革，更要考虑“大数据”的存储和查询，因为这些社保资料达 P 量级，需要存储数十年以上。大数据和快数据的设计可以借鉴 12306 订单分级查询的机制，将“热点数据”放在 Gemfire 缓存集群提供快速查询，将历史数据存放在 Hadoop 集群。当查询在 Gemfire 缓存数据层未命中时，通过 Cache loader 从 DB 或 Hadoop 集群加载数据到缓存数据层，提供查询服务。

（3）金融单位 POC 项目：此 POC 的改造与上述两个项目不一样，在 12306 和社保项目改造都是需要将业务逻辑改写在 Gemfire 集群；此金融单位 POC 的测试目的是在不改写业务逻辑的情况下，对原来系统的数据访问层（DAO）进行改造，提供可扩展的分布式缓存数据层提供快速服务，并提供失效转移的设计。

作者：刘云程（YC），技术总监，任职于资拓宏宇（上海）公司，主要负责提供客户应用系统升级，迁移到高性能和高扩展性的“云应用平台”。刘云程毕业于台湾清华大学，在美国拿计算机博士学位，于 1994 年由 IBM 外派到北京。他在 IT 行业有近 30 年工作经验，曾任职于 IBM 中国研究中心负责电子商务和移动互联网方面的研究。

（责编/仲浩）

系列文章：

揭秘 12306 技术改造（三）：传统框架云化迁移到内存数据平台