开源内存数据库容器化探索与研究

当前，以Redis为代表的开源内存数据库被金融机构广泛应用于高并发、低延迟业务场景，旨在为客户提供快速响应、高质量的金融服务。

以邮储银行为例，邮储银行在云平台中普遍采用了“虚拟机+Redis”的方式支撑业务发展，并配套制定了相关数据库配置规范。

但是，在云平台部署Redis通常意味着要交付更多的节点，并将导致数据库安装、变更、升级、故障处置等运维成本迅速上升;同时，固化的虚拟机在应对节点扩缩容时步骤繁琐，也难以实现对宿主机资源的充分合理利用。

为解决上述难点，笔者团队深入研究
Kubernetes(K8S)管理下的Redis容器化标准，并针对性开展了验证测试，以使其能更好地适配微服务应用架构，应对业务规模弹性伸缩需求。

一、开源内存数据库容器化存储研究
在容器化存储方面，Redis主要支持RDB和AOF两种持久化机制，属于写大于读的操作，而在K8S中要使用持久化存储方式，Ceph和Glusterfs是业界较为常用的两种分布式解决方案，两者不仅支持通用底层硬件，可实现纵向升级和横向扩展，同时还具备高可用、去中心化等特点。

为观察不同存储组件对Redis功能和性能的影响，笔者团队分别选取本地硬盘Local PV、Ceph和Glusterfs作为Redis持久化底层存储介质，并使用Dbench作为测试工具，测试了包括4k随机读Iops、4k随机写Iops、128k随机读带宽、128k随机写带宽、4k随机读延时、4k随机写延时、1M顺序读带宽、1M顺序写带宽、4k混合读写IOPS等在内的九项指标。

测试过程中，物理机使用X86架构，主要用于存储测试和搭建虚拟机环境，虚拟机环境主要用于后续测试网络、高可用、扩缩
容等内容。

物理机环境配置见表1。

虚拟机环境配置见表2。

测试结果对比见表3。

表1 物理机环境配置
表2 虚拟机环境配置
表3 测试结果对比
测试结果显示，Ceph可能是比较适合实现Redis容器化存储的组件。

具体而言，在性能方面，Local PV的性能在大多数情况下都是最优，但Local PV与Node节点绑定，当Node节点发生故障时，Pod无法被调度到此节点，将影响集群健康度。

在读写性能方面，Ceph写性能明显优于Glusterfs，4k随机写的延
时甚至优于Local PV，十分契合Redis持久化这一写多于读的场景，而Glusterfs的读性能表现则要优于Ceph。

在稳定性方面，Ceph在多种场景下测试表现均衡，底层服务器性能差距对Ceph影响不明显，但Glusterfs受服务器性能影响较大，若服务器配置不同，当Pod被调度到不同服务器时，可能导致业务性能差别巨大。

在易用性方面，Ceph安装维护复杂、组件较多，对运维团队提出了更高的技术要求，而Glusterfs安装简单、数据可见，相对更容易入手。

此外，从Redis各命令延迟和QPS看，三种存储性能表现类似，均足以支撑Redis持久化需求。

经综合考量，笔者团队认为，Ceph更适合作为Redis的容器化存储组件。

二、开源内存数据库容器化网络研究
在同一个K8S集群内部，应用节点访问Redis集群一般可通过Clusterip或Headless Service等方式实现，但是当属于K8S集群A的应用节点访问属于
K8S集群B的Redis集群时，将会遇到一个问题，即A集群的应用节点如何发现B集群内部的Redis节点的IP信息和拓扑关系。

一般情况下，从K8S集群外部访问主要有Hostnetwork、Nodeport、Ingress、Cloud Loadbalancer与F5四种方案。

其中，Ingress方案只支持七层服务，Cloud Loadbalancer与F5方案依赖外部厂商支持，均不适用于本文场景。

在针对Nodeport方案的测试过程中，笔者团队通过选择映射端口，随机连接了Redis集群中的一个节点，但是当执行Redis命令时，由于重定向到另一个
Redis节点，而集群外到集群内Pod IP的网络不通，出现访问超时，因此该方案也不合适。

最后是Hostnetwork方案，该方案在网络访问上基本与原有“虚拟机+Redis”的部署方式一致，但缺点也极为明显，即受限于Node，无法实现快速扩容，且在Node出现故障或需要维修时，无法把Pod疏散到其他Node，易导致Node数量和Pod数量快速增长，进而增加维护成本。

除此之外，传统的Redis集群访问过程也曾经出现过很多代理软件，其通过屏蔽Redis集群细节，可使得访问集群如同访问单节点一样。

对此，笔者团队综合对比K8S集群下的开源Redis代理软件，最终选取了Predixy进行相关功能和性能测试。

在功能方面，Predixy支持Redis主从切换发现、扩缩容发现、Predixy节点自愈、代理多个Redis集群、单节点Redis相关操控命令、Predixy节点根据资源使用率自动扩缩容等。

在性能方面，通过将直接压测和代理压测下的Redis集群进行对比，发现随客户端数量增加，直连Redis集群的QPS逐渐下降，而代理方式则在压测下基本保持稳定，此外在5000客户端连接情况下，代理性能相对要好于直连集群方式。

三、开源内存数据库容器化高可用与
扩缩容研究
Redis集群原生具有“哨兵”和“集群”两种高可用模式，而在业务量和数据量迅速增长的背景下，集群模式用途越来越广泛。

本研究中，笔者团队重点分析了通过K8S中的Operator实现Redis集群高可用和扩缩容的可行性。

目前，
UCloud(简称“UC”)与Ot-Container-Kit(简称“Ot”)是开源Operator方案中两个比较有代表性的项目，其中UC为每组Redis主从分片均建立了一个Statefulset控制器，主从之间可通过Pod反亲和落到不同节点；Ot则是具备两组Statefulset，一组名为Leader，包含所有主节点，另一组名为Follower，包含所有从节点，同一组的Pod通过反亲和落到不同节点。

从功能角度来看，UC的特点是应用较广泛、功能较齐全、运行较稳定，但由于开发者已不再维护，因此其对新版本K8S集群的支持度有待验证，同时高可用设计也存在一定缺陷;与之相比，Ot的开发者则仍在持续更新，Statefulset控制器分组方式较新颖，但是其更新版本和修复Bug的速度较慢，功能上目前仍有缺失，扩容和缩容尚未实现，且切换逻辑存在缺陷，并非每次切换都能成功。

综合考虑，笔者团队最终选取了UC作为高可用和扩缩容的组件。

但是，Redis 集群中如果半数Master宕机，将导致整个集群无法使用，而UC使用中可能会出现多个Master调度到同一个Node的情况，该Node宕机会造成集群崩溃，难以满足高可用需求。

对此，笔者团队结合UC和Ot的设计理念，对UC的Operator进行了改造，改造后的Operator实现了Node亲和与Pod反亲和(如图1所示)。

图1 结合UC和Ot理念的高可用设计
具体而言，笔者团队将6个Node节点分成三组，每组设置标签Redis-
Class(固定名称)值，分别为0、1、2，取每一组Statefulset的尾号数字，如Psbc-Rediscluster-0，取其最后一位0并对3取模，即当Statefulset的结尾是0、3、6、9时，创建的Pod要去亲和标签Redis-Class=0的组，且只能调度到这组节点上，以此类推，所有的Pod都会按照上述规则去亲和对应的主机组。

然后，Statefulset内的两个Pod会遵循Pod的反亲和，根据主机名调度到不同的主机上，以保证节点能实现均衡分布，并且变得可预测，从而提前规划出Pod会调度到哪，以及确定哪个主机组上会有哪些Pod等。

在扩缩容方面，笔者团队针对Redis集群在无数据和有数据(单分片约180M)两种情况下的集群规模变化(3节点和5节点之间)展开了扩缩容耗时测试。

测试结果显示，当进行扩容时，无数据耗时7.5分钟，有数据耗时9.5分钟;当进行缩容时，无数据耗时1.5分钟，有数据耗时8分钟。

总体而言，数据量越大则耗时越明显，后续仍存在较大的优化空间。

四、后续研究方向
综上所述，本文通过对Redis容器化部署最关键的存储、网络、高可用、扩缩容等开展测试分析，实践验证了Redis不同于关系型数据库，其实施容器化部署对存储要求不高，分布式存储即可满足，且改进后的Operator也能有效规避Redis集群高可用失效的风险。

但是，由于Operator在线扩缩容Redis节点的效率较低，无法发挥K8S自动管理的特点，因此目前还很难满足实际生产要求。

围绕上述难点，笔者团队尝试探讨了两套可行方案：方案一是牺牲Redis节点在K8S集群上的灵活部署和弹性扩缩容需求，采取Hostnetwork的网络访问方式;方案二是对网络代理组件和Operator进行深入自研开发，使其满足生产环境的网络访问和高效扩缩容需求。

相较而言，方案一可看作是云端Redis虚拟机部署架构向K8S集群转变的过渡方案，兼顾了现有的系统开发能力和运维能力，相对容易实现快速部署和实施，适用于对系统稳定性要求较高的生产场景；方案二则是相对理想的Redis容器化方案，也是一个远期方案，对团队技术能力提出了更高要求，且需要持续不断地实践和优化，当前阶段该方案更适合在特定研究和小规模测试中使用。

基于上述研究成果，邮储银行目前已在项目建设中大力推广微服务架构和应用服务容器化，并在数据库容器化方面基于“重点突出，稳步推进”的原则，选
择渠道管理平台作为Redis容器化的试点系统，采用方案一作为试点方案，同步发布了全行Redis容器化部署指引。

后续，邮储银行将根据试点情况，不断提升技术能力、总结实践经验、迭代技术方案，以更好适应未来系统的技术架构演进方向。