金融场景下的NoSQL实践！看WeRedis在微众银行的应用落地

导语 |  随着数字化转型的深入、移动互联网的蓬勃发展，产生了大量以语音、图像、视频为代表的非结构化数据，这些数据越来越得到人们的利用，使得越来越多的 NoSQL 产品不断涌现，助力企业创新业务落地，赋能业务快速发展。今天，我们特邀微众银行数据库平台负责人、腾讯云 TVP 胡盼盼老师为我们带来《金融场景下的 NoSQL 实践：微众银行 Redis 应用实践》的主题演讲，他将带我们了解微众银行在 Redis 上的开发和运维实践。

作者简介

胡盼盼，硕士毕业于华中科技大学，毕业后加入腾讯，任高级工程师，从事分布式存储与云数据库相关的研发与运营工作；2014 年在微众银行筹办之时，就加入了微众银行基础架构团队，亲历和见证了微众银行分布式核心架构从无到有的建设与发展，也参与了微众银行基础架构 1.0 到基础架构 2.0 的重大演进。目前全面负责微众银行数据库平台的建设和运营，包括关系数据库平台和 KV 数据库平台。

引言

本文将分为五个部分来分享，第一部分是社区版 Redis 的使用痛点，第二部分是基于这一痛点我们对 Redis 做的一些封装化改造，微众银行内部将它称为 WeRedis。第三部分将介绍微众银行WeRedis的应用场景，第四部分是介绍 WeRedis 的运维开发规范，最后再和大家聊聊我们未来的规划。

一、社区版Redis的使用痛点

微众银行在使用社区版的 Redis 后，发现它存在以下四个问题：首先，虽然 Redis 从 3.0 版本开始就有一个分片架构，它可以实现 Redis 的高可用和水平拓展，但是这个分片架构，在主节点异常切换的时候，对集群还是会有抖动的影响。其次，社区版的 Redis 权限管理功能有限。在金融场景里对安全的权限管理要求是比较高的，但是社区版的 Redis 对权限管理这块是非常弱的。此外，Redis 对于资源统计和资源控制的功能非常有限，比如无法实现多租户的功能。最后是在运维层面缺少统一的运维与管理平台。因此，社区版 Redis 整体而言不能满足微众银行的需求。

二、WeRedis的特性与架构

由于社区版 Redis 无法满足需求，微众银行自研了基于 Redis 的分布式缓存平台 WeRedis，除了拥有开源 Redis 的特性外，还有如下特性：

• 多租户与细粒度的鉴权；
• 负载控制与隔离；
• 高危操作隔离；
• 高扩展性；
• 高可用性；
• 智能分析与管控。

上图是 WeRedis 的架构图，除了中间Redis Cluster模块，其他的外延模块都是我们增加的模块，比如 proxy 接入模块，除了实现 Redis 协议的兼容和转化外，还可以实现资源控制、多租户的功能以及高危命令隔离，包括一些负载的限流、负载的调度都在 proxy 这个模块实现。左上角是 OB 模块，这是一个类似于元数据管理模块，它主要的功能是会定期更新集群的 proxy 列表信息，因为 proxy 节点会被替换、更新，这个模块就是负责 proxy 列表的更新，及时通知到客户端这边，客户端这边就维护最新的 proxy 列表，保证路由的正确性。最下面是 WeRedis Admin 管控平台，这是一个可视化的系统，集成了监控系统和运维操作功能。上方还有一个 WeRedis 统计模块，所有模块运行的信息，比如 proxy 集群的信息和 RedisCluster 集群的信息都会及时上报到这个统计模块，这个统计模块再对这些数据做一些处理。

另外介绍一下我们针对Redis Cluster的二次分片功能。这里我们补充一个概念——Redis Partition，它主要是用来对Redis Cluster 做二次分片，每一个Redis Partition 都是一个独立的Redis Cluster，然后多个Partition 再组成WeRedis 集群。所以，Redis Partition 是第一级别的分片，Partition 内部的 Redis Cluster是第二级的分片。通过Redis Partition 概念的引入，我们可以更加灵活地做 Redis 的扩展。这边还有一个我们新开发的迁移集群，这个集群就是负责 Partition 之间数据的扩容，比如我现在要新增一个Redis Partition 分片，要重新做数据均衡，就需要通过这个模块来做， Redis Partition 之间的数据迁移也是通过这个模块来操作。

以上就是我们整个 WeRedis 的架构图，我们在外围做了许多工作来适配银行内的生产需求，其中运维层面的需求是非常重要的。

三、WeRedis的应用场景与部署架构

WeRedis 目前已经应用在全行绝大部分的业务场景，有 300+ 系统接入、87 套集群、4000+ 实例数。其中典型的应用场景包括：

• 全行客户信息缓存：低时延、高并发、读多写少；
• 全行客户单元化路由信息缓存；
• 安全规则计算： 低时延、高并发、读多写少；
• 短信平台队列： 队列、低时延；
• 客服系统的会话缓存和客服分配：缓存、队列、低时延；
• 账户交易侦测系统：缓存、高并发计算、低时延；
• 需要用到分布式锁的各种场景：高并发、低时延。

在了解完 WeRedis 的应用场景后，我们再来看看 WeRedis 的跨 IDC 部署架构。这个部署架构是基于微众银行同城多个生产数据中心的架构来实现。我们会把 WeRedis 不同的数据副本部署在不同的  IDC，默认采用 3 副本配置，3 个副本分布在同城的三个不同的 IDC，以便实现同城跨 IDC 数据的高可用。我们在一个WeRedis集群里面有若干个 Partition，不同的 Partition 数据副本也可以做到不同数据中心的分布。比如第一个 Partition 在前三个 IDC 里面，第二个 Partition 可以在后三个 IDC 里面。Proxy 这一层则是根据业务的应用流量分布，来决定部署在哪个 IDC。

这种架构整体而言较为灵活，而且可以实现整个 IDC 层面的高可用。我们会进行常规的 IDC 断网演练，把其中一个 IDC 进行隔离，在 IDC 失联状态下，验证同应用到中间件到底层数据库切换的功能是否能达到预期。

四、WeRedis的运维与规范

微众银行从 2015 年系统上线开始就使用 Redis，但在运维过程中，我们在性能、高可用、容量等问题上也踩过不少坑，基于这些坑，我们持续不断完善我们的运维开发规范。下面分享一些从复盘中不断优化来的 WeRedis 应用开发规范。

例1：生产的 Key 必须要打标，微众银行内部是以子系统来区分各个业务系统，每个子系统就会有一个子系统 ID——systemid，我们要求所有的 Key 必须有一个 systemid 为前缀，这样快速区分某个 K 是属于哪个子系统的，排查问题非常方便。

例2：对 member 大于 1000 的 Key 或 memory大于 10M 的 Key，我们会定期巡检出报表，建议业务整改。另外对于生产的操作我们也会避免大 Key 和大 value 操作，一旦操作可能会把整个集群堵塞。

例3：为了避免垃圾数据堆积，我们会要求业务一定要设置 TTL 或者获悉时间。

另外为了更好的保证生产集群的稳定性，我们也通过proxy，限制了一些 Redis 原生高危命令。上述只是运维开发规范的一小部分，我们的规范也在不断完善。

五、WeRedis的未来展望

首先是容器化，我们优先做的是应用 APP 层面的容器化，因为应用层面是属于无状态的组件，它的容器化相对容易。但从去年开始我们也开始做数据库层面组件的容器化，结合我们内部容器化平台的团队一起开发，然后自研 Operator 组件，目前还在灰度测试阶段。

其次是针对 Redis6.0 版本的升级和应用。我们现在生产环境已经有少量的集群已经升级到 Redis6.0 版本，它有一些新特性，比如 ACL 用户及权限控制、多现成 IO 能力提升性能、OOM 时优先控制提升集群稳定性。此外，还有 module 定制化开发功能，用于某些特殊功能和需求的实现。

最后是持久化架构，我们正在研发基于WeRedis的持久化架构，计划引入开源的持久 KV 存储组件，进行整合，实现基于 Redis 协议数据的持久化，使得缓存数据实现更持外化存储。目前还在研发阶段，暂时还没有上线。

此外，我们也在公有云的业务场景，使用腾讯云数据库 Redis（TencentDB for Redis）。云数据库 Redis是由腾讯云提供的兼容 Redis 协议的缓存和存储服务。其低延迟、高吞吐、弹性扩缩容特性，可以帮助我们进行自动容灾切换和数据备份，并在数据处理过程中进行故障迁移和实例监控。其提供的全套关于数据缓存和计算相关问题的解决方案，很好地满足了我们业务在缓存、存储、计算等不同场景中的应用需求。

展望未来，伴随微众银行 WeRedis 的实践越来越丰富，它也将为金融领域里 NoSQL 的发展添上浓墨重彩的一笔，助推 NoSQL 数据库持续前进！