金融行业的云数据库实践

金融行业的云数据库实践金融行业应用架构的变迁——互联网分布式应用对数据库挑战Spring/Struts/SOAJ2EE/.NETWebLogic/WAS/MQOracle/DB2集中数据库小机，X86，存储微服务架构容器Swarm/K8S/MesosMySQL/Redis/HBase公有云/私有云/混合云可控发布，保守运维传统金融架构DevOps/持续集成互联网+分布式应用资源数据中间件发布封装应用框架开发运维分布式敏捷性微分服布务式容低器成化本金融互联网创新需要什么样的数据库？●自主可控：基于开放架构，基于开源的优化●高可用：跨机房容灾，满足金融级业务系统全天候对外提供稳定可靠的客户服务●高性能：互联网+金融的创新业务所需的流量弹性●支持云：私有云和公有云互通一致的体感，降低使用和运维难度●易运维：大体量自动化、运维体系合规化要求（基线、环境适配、管理体系等）●数据安全：审计&数据强一致性&多中心容灾部署●成本优化：IT总体拥有成本必须下降阿里云数据库——开放，多机房容灾，强一致性，助力金融科技创新如今，阿里云数据库产品已聚木成林MySQLSQLServerPostgreSQLPPAS(高度兼容Oracle)POLARDBRedisMongoDBHBaseMemcacheHybridDBforMySQLHybridDBforPostgreSQLOpenSearchElasticsearchHiTSDBDTS智能顾问DMS关系型数据库RelationalDatabaseServiceNoSQL数据库NoSQLDatabaseService混合分析数据库HTAPDatabase搜索与时序数据库Searchandtime-seriesDatabase数据库服务与工具DataBackupandMigrationApsaraDBProductCatalog基础版与云服务器一样的成本IaaS的价格，PaaS的服务高可用版多项企业级功能，包括读写分离实时升降配置数据加密金融版SQL审计秒级高频监控版本不同，普惠相同从初创企业到金融巨擘的共同认可MySQL金融版内置读写分离主节点备节点备节点Raft读写分离读(Read)写(Write)Client读/写4/7层代理slaveslavemaster只读只读只读完全兼容MySQL*表*数据类型*函数/存储过程*sql_mode*……无成本迁移*免费热迁移（DTS）数据强一致*节点故障*机房故障MySQL金融版——产品特征规格与性能…60核470G3T4核16GMySQL金融版——产品规格MySQL金融版——同城多机房容灾代理Client代理Client备节点机房A主节点机房B备节点机房CFailover机房间的延迟带来的性能损耗不到5%➢分布式高频探测➢网络/硬件/OS/数据库多重监控➢智能决策系统➢数据一致性保护切换过程，对上层无感知：➢新连接直接到备节点➢空闲的老连接，自动切换到备节点；➢事务中或运行中的老连接，等待10s后切换到备节点，超时Kill。三机房部署灾备切换新主库机房A主节点机房B备节点机房C网关/代理（四层/七层）主：上海（三机房）灾备：北京（单机房）Raft协议，日志同步备节点机房A主节点机房B备节点机房C网关/代理（四层/七层）主节点备节点机房AMySQL金融版——两地多中心用户流量mydb.mysql.rds.aliyuncs.comBinlog同步DTSDRCMQ金融级可靠性原理揭秘•数据复制的演进——双通道binlog复制•拜占庭将军问题与Raft一致性算法•RaftinMySQL负责选主、控制复制关系•Flashback确保数据强一致•………..1.数据复制技术的演进MySQL的日志复制是异步的，也就是说主备库客观上存在延迟。虽然IO_Thread传输日志的延迟（大部分所说的延迟都是指SQL_ThreadApply的延迟）小到几乎可以忽略不计，但对数据安全性要求极高的场景下却存在天然缺陷。除了延迟导致的日志丢失，当Master意外故障时，没有来得及复制到备库的日志是不会在新Master执行。但老Master恢复后，会对PendingBinlog执行EngineCommit。导致新老Master数据不一致。MySQL原生异步复制的问题永远不知道备库的数据是不是最新异步复制(一主一备/一主多备)MySQL原生半同步复制的问题网络故障时，半同步会降级成异步（可以设降级的延迟时间）网络恢复后，从节点异步复制追数据，直到追平后，提升成半同步复制因此，当主节点宕机时，无法判断从库当前是异步状态，还是半同步状态，不知道从库数据是否追平。即：半同步状态下，也不能确定备库的数据是不是最新的。AliSQL改进：双通道数据复制主备间有两条数据复制通道：1.半同步复制通道——只接收最新的binlog，不回放。网络故障就放弃接收，恢复后不追数据，接收最新的binlog2.异步复制通道——正常按异步复制逻辑拖取和回放binlog，保持备库数据再现当主库宕机时，双通道模式可以确定性得知，备库的数据是否跟主库一致双通道复制——数据一致性判断备库数据一致，放心切换备库数据不一致，根据不同SLA做出动作，即RTO优先时，可以切换；RPO优先时，需人工做数据恢复当主库宕机时，备库具有确定性状态即：异步通道半同步通道网络故障区，放弃同步主库宕机点时间备库数据一致1异步通道半同步通道网络故障区，放弃同步主库宕机点时间备库数据不一致可补偿到一致2异步通道半同步通道网络故障区，放弃同步主库宕机点时间备库数据不一致无法补偿32.拜占庭将军问题与分布式一致性算法SlaveSlaveRaftRoleDatabaseRoleStateTermExpiredLeaderMasterread-write100117052616:20:09FollowerSlaveread-only100117052616:20:09FollowerSlaveread-only100117052616:20:09这是节点的状态，包含他们的角色，数据库状态，选举的Term值，以及租约过期时间。角色决定了他们的读写状态，以及日志复制流向。Raft分布式一致性协议MySQL金融版实现方式——内核引入Raft分布式一致性算法Master底层维护了三个数据库节点，一主两备的复制拓扑结构意味着每个节点都是全量的数据，数据库事务日志（Log）从主库同步复制到所有的备库，当集群中超过半数的节点都写入成功后，事务才能完成提交。虽然是同步复制，但由于是三个点，因此单个节点的故障不会影响到实例整体的可用性。这种设计的好处显而易见，即在不损失可用性的情况下，通过较高的数据冗余度来换取更好的可靠性，同时支持跨机房的部署方式，具备机房容灾能力。分布式一致性复制——三节点强同步复制数据安全——安全是根植于阿里云内核的原生功能事前•VPC专有网络•IP白名单•防暴力破解•灵活账号权限管理事中•SSL加密•TDE加密•拦截SQL注入攻击事后•SQL审计•克隆实例全生命周期的安全体系，根植在阿里云飞天内核最底层。安全功能安全，是根植于内核的原生功能未来，已来——划时代数据库POLARDBPOLARDB兼容并包，大有风度100%向下兼容MySQL5.664核，512G强大的计算节点性能6倍超越100TB极大存储容量POLARDB——划时代的数据库产品架构CloudNative产品设计1.计算与存储分离2.RDMA远程直接数据存取3.一写多读DBServer4.分布式共享存储架构（Raft控制的共享存储）放弃了基于binlog的逻辑复制，而是基于innodb的redolog实现了物理复制