案例丨缓存数据库在核心系统分布式转型中的实践
文 / 中信银行数据中心 李鑫
《金融科技发展规划（2019~2021年）》明确提出“以重点突破带动全局，规范关键共性技术的选型，能力建设、应用场景和安全管控，探索新兴技术在金融领域安全应用，加快扭转关键核心技术和产品受制于人的局面，全面提升金融科技应用水平，将金融科技打造成为金融高质量发展的新引擎”。中信银行不断探索科技赋能，金融创新的发展方向，联合中兴通讯自主研发GoldenDB金融领域分布式数据库，并在2020年5月完成核心系统的分布式下移转型工作。
优势选型
在我行核心系统的分布式转型过程中，除了采用GoldenDB作为分布式数据库，用于支撑核心重要业务数据，同时在如此高并发、高负载的重要系统中，我们也需要引入其他组件类产品进行配合，例如分布式缓存、分布式消息队列等，用于提高和拓展整体应用系统性能。本文重点介绍分布式缓存的相关技术环节。选型Redis开源产品作为分布式缓存数据库，给我行提供了如下优势。
1.基于开源，自主可控。我行缓存数据库坚决选择拥抱开源的技术路线，一方面可以降低我行的软件投入成本，同时也秉承核心技术自主可控的先进科学理念，深入挖掘源码，结合我行实际使用技术需求进行二次开发，实现降本增效。
2.内存存储，高速响应。采用内存存储数据，处理速度在微秒级别，用于储存分布式核心系统中数据变化频率较低但是访问频繁的数据，从而提高系统整体响应效率，与分布式数据库GoldenDB形成组合拳，非常适合我行核心系统高并发、大数据的交易场景。采用Redis缓存数据库经测试，缓解了后端GoldenDB数据库80%的业务访问压力，效果非常显著，是对关系型数据库的重要补充。
3.接口丰富。Redis提供了丰富的数据类型，便于存储不同类型的用户数据。
4.高可用支持。Redis自身提供稳定可靠的集群高可用架构，通过多实例分片的槽位分配来确保数据分散，提高性能，通过主从复制来保证节点同步，完全可以支持核心下移项目总体的高可用目标。
高可用技术架构
根据整体架构设计方案，数据中心部署了两地三中心的高可用方案，生产机房和同城机房同时对外提供服务。一旦发生故障，需要进行切换，优先本地机房切换，切换对应用全透明，容灾切换数据全局一致，支持孤岛演练。
其中缓存数据库分别部署在生产、同城、灾备机房，规模一致。采用Redis集群作为高可用技术架构，此种架构是Redis 3.0版本之后才开始提供支持的，可以通过Raft算法协议，进行领导节点选取，实现故障自愈，对应用无感知。无中心架构也便于整体架构的延展，实现快速扩容部署方案。同时在此基础上进行了集群优化改造，针对原生集群无中心化投票切换的机制缺陷，创新引入旁备节点功能，在集群功能无法自愈时，通过自动化调度平台进行调用，在秒级内恢复集群状态，避免了生产转同城或者灾备等大规模切换操作，进一步增加架构高可用程度（见图1）。
图1 核心系统缓存数据库高可用架构概括图
技术应用与实践
采用分布式系统架构相比较传统的集中式服务架构而言，在系统扩展性，资源利用率角度都有很大提升，但转型同时也带来了新的技术局限性与难点挑战。
1.数据一致性。数据一致性是任何数据库都不能忽视的问题，如果在交易过程中，客户拿到旧版本的数据或者无法获得数据，最终会影响交易结果，降低服务体验，更有甚者可能会造成不可挽回的经济损失。根据CAP理论，对于无中心化的分布式架构，增加了系统的可用性以及分区容错性，势必会带来分区数据一致性问题，且由于Redis遵循BASE理论，产品本身不支持数据强一致性。因此我们必须通过客户端程序设计开发进行数据二次校验环节，确保数据有效性和完整性，不受网络环境、数据过期失效、节点同步失败等问题干扰。
2.数据设计要求。Redis缓存数据库属于单线程模式，这种设计减小了线程之间的切换与资源争抢的性能损耗，进一步提升了响应时间。但与此同时，由于单线程串行操作机制，在如此高吞吐量的系统压力下，必须确保每一次数据获取时间在微妙内，否则就会造成数据排队现象，从而影响服务质量。因此我们在高仿真以及压力测试环节中，针对缓存数据库设计了大量破坏性测试场景，综合考虑了运行系统当中可能发生的各种异常以及极端场景，重点对于性能毛刺、网络中断、热点数据、大key数据、数据不穿透问题进行跟踪排查，并针对每个场景进行业务交易分析，包括是否异常场景对业务透明、业务性能指标是否受到影响等。
3.缓存架构设计。对于缓存架构设计，采用多级缓存架构，一级缓存为客户端本地缓存，二级缓存为Redis分布式缓存。应用逐级进行缓存访问，优先从本地缓存读取数据，如无法获取，再集中访问Redis，减小了访问Redis数据的频率，从而降低了Redis端的热点数据风险。同时，在架构设计时重点针对缓存穿透、缓存击穿、缓存雪崩的缓存失效极端场景提出相关解决方案，制订开发代码设计要求。
4.安全性防护。《金融科技发展规划（2019~2021年）》明确提出“做好新技术金融应用风险防范”的指示。作为核心系统的分布式缓存，开源产品安全性、用户安全性以及数据安全性是重中之重。通过规范化运维体系、建立系统安全漏洞扫描平台，定期组织安全生产管控排查，确保安全性环节落实到位。
5.监控体系。对于分布式架构易于扩展以及产品功能组件众多带来新的监控挑战，我行建立了一整套监控体系，ITM监控、普罗米修斯（prometheus）监控、交易监控平台、NPM流量监控、云新平台带外监控、智能分析中心等，形成全方位立体化监控体系，7×24小时即时全链路监控覆盖，确保出现异常后迅速产生报警并根据报警模块触发智能巡检。但当出现某些故障场景，也会遇到报警风暴的情况，需要人为通过这些监控系统的告警进行分析、排查，仍需进行不断改进，向着人工智能分析、场景自愈的方向发展。
6.应急预案。出现突发问题，需要快速介入，确认问题原因，并且对故障场景进行隔离、排查，尽快恢复生产。这些都需要在事前具备充分的应急预案方案。对于缓存服务器，总共制订了48个应急预案，针对这些应急预案，在上线前都由运维人员进行了充分验证。出现故障时，遵循总体应急原则为按照故障影响范围，应急处理逐层升级。
7.自动化运维。自动化运维体系的建立使得整个运维流程高效运营，处置有效。通过开发一键式巡检脚本，可以自动生成并通过图形化界面展示缓存数据库的健康状态。通过自动化运维工具CITICTools for Redis，可以实现Redis大部分日常运维以及应急预案线上化、开发运维问题诊断等20余个功能。
8.数据备份。涉及数据备份和恢复是运维工作中非常重要的一个环节。我行分布式核心系统对各产品的数据备份以及恢复一致性有严格的指标要求。目前使用NBU备份恢复软件，采取每天增量备份，定期发起全备的备份策略。
不断探索、未来可期
从目前运行情况看，基于当前的分布式高可用技术架构，我行核心系统技术指标运行情况平稳。在整个核心下移的过程中，我们也不断积累、创新，就分布式缓存数据库方向，形成了一套技术架构标准、开发运维规范标准、运维工具等一整套知识体系，这些知识体系可以形成技术成果，运用到我行后续的其他业务系统当中。同时，针对缓存数据库的标准化输出，已经部署到我行的PAAS云管平台当中，计划实现T+1交付，提升基础软件部署工作的效率和标准化程度，形成服务器资源的自动化、池化快速供给。
在当今提倡金融科技赋能的大环境下，更加灵活、开放的分布式基础架构可以更好地应对未来金融业务高速发展、快速创新的功能需求。分布式缓存+分布式数据库的组合已经成为此基础架构的重要组成部分，我行也会在这个重点科技领域内进行更加积极的探索实践，不断完善，深入研究，最终为银行客户提供更优质、便捷的金融服务。
（点击查看精彩内容）
关于仿冒我刊收费的声明
我刊自创刊以来，从未向投稿人收取过任何费用。任何以刊发文章为名向投稿人收取费用的行为，均属于对投稿人的欺诈行为。
我刊官网地址为 www.fcmag.com.cn。
我刊投稿邮箱为 fcmag@fcmag.com.cn。
对于仿冒我刊网站、网页的违法行为，我社将追究其侵权责任，以维护我社和投稿人的合法权益。仿冒网站、网页举报电话：010-88232443
《金融电子化》新媒体部：主任 / 邝源 编辑 / 潘婧 傅甜甜