随着互联网普及,5G、云计算、大数据等新型技术不断发展,普通用户能够接触到的资讯、服务越来越广泛,使得原本只需要服务特定区域的信息系统需要服务的客户群体越来越大,需要处理的数据量也越来越多。与此同时,数字化时代也使得数据变成了企业核心资产,数据成为新的生产要素。
一、异地多活是摆在企业面前的迫切问题
对于数据资产安全、持续访问、灾备等方面的刚性需求,也使得中小企业将目光从传统单节点应用模型上移开,寻找分布式的可替代方案。
本文主要讨论两个问题:
1、如何保证数据量不断增大的情况下,信息系统的响应速度不变
2、如何更好的对数据进行容灾
信息系统中的软件部分,主要分为应用程序和数据库。
应用程序本身可以是无状态的,其可用性和横向扩展都很好实现,只需要部署多套应用程序,使用负载均衡的软件或者硬件将请求进行转发,就能实现性能的线性提升。针对单节点故障,也只需要在转发层屏蔽掉故障节点。
二、常见数据库架构
分布式中的最大难点还是在于数据库,无论是针对性能的线性扩展,还是单点故障的容灾,都比较复杂。针对数据量增大,性能需求的问题,业界比较常见的数据库架构主要分为下述几类,以下逐个优劣进行分析:
- 共享存储集群
- 读写分离机群
- MPP数据库
- 分库分表
- 共享存储集群
共享存储集群的典型代表为 Oracle RAC。使用共享的存储硬件,多个数据库实例一般部署在同一个机房内,可以横向扩展数据库的并发性能,由于受制于共享存储的性能,一般最大可以扩展到4 - 6节点。其灾备能力仅限于单节点故障,如果不同节点部署在不同的机架,还可以抵抗机架故障。但由于本身数据仅有一套,为了保证数据可靠性,一般要配备硬件或者软件的数据同步组件进行数据的实时灾备。
2、读写分离机群
此种方案以金仓Kingbase ES V8读写分离机群为代表,主库负责读和写操作,备库仅负责针对读操作的负载分离。其优点是在同一时刻,数据有多个副本,发生故障时,只需要将其中一个备库升级到主库,不用担心数据丢失的风险。
当应用于读多写少的应用场景时,会有很大的性能提升;受制于主库写能力的限制,当应用中写多读少时,性能则会受到一定限制。此类数据库集群一般部署在单机房内,可以抵抗单点故障和机架故障。
3、MPP集群
MPP数据库集群以金仓KADB为代表,在大规模数据分析(OLAP)领域优势明显,但在OLTP场景中表现不如读写分离机群和共享存储集群。横向扩展能力强,可以支撑规模更大的应用查询场景、支持单机房内的单点故障转移。
4、异地多活
异地多活方案常见于大型互联网企业,不同的用户访问被定向到不同的数据中心。比如针对用户表的访问,阿里会根据user ID做hash,将主数据存储在不同机房;饿了么会将同一区域的user存储在距离较近机房。
应用访问数据时,路由层会根据访问的数据分片信息,将请求路由到主数据所在的机房,针对横向扩展,只要尽可能多的对应用逻辑进行分解,将不同的应用逻辑分片到不同的数据节点甚至数据中心。
采用数据同步的方式让每个数据节点或者数据中心都存储全量数据,当某个节点或者数据中心发生故障失效时,其灾备节点或者中心即可接管。同时,对于每份数据的灾备数据,还可以承担查询的负载,进一步增加系统的整体吞吐量。此方案无论从大规模应用的并发访问,还是数据异地容灾,都有比较明显的优势。
三、异地多活面的难点和金仓解决方案
异地多活场景中,数据库主要面临以下问题:
- 数据同步的时效性保证
- 数据同步正确性保证
- 数据回环的处理技术
- 数据重复和数据冲突的解决
下面,以金仓异构数据同步软件 Kingbase FlySync(以下或称KFS) 为例,逐一攻克异地多活中的重重障碍,助力企业实现数据访问的性能提升和数据容灾。
1、高性能同步方案解决数据延迟困扰
金仓数据库同步软件KFS基于数据库日志硬解析,使用流水线技术最大限度释放多核服务器的CPU性能。同时,Kingbase FS 还支持并行多通道数据解析。实际测试场景中,数据同步速度可以到亚秒级,每日分析增量数据库日志最大3.5 TB。
2、增量数据落盘,保证同步内容可追溯
针对数据同步正确性保证,Kingbase FlySync会将增量数据存储到中间文件,以中间文件的记录为单位进行数据传输,保证性能的同时,让同步内容可追溯,免去用户面对黑盒的焦虑感。