您的位置:首页 > 数据库

直播问答丨31问工行分布式数据库选型及设计 - 分布式

2022-06-02 04:01 3155 查看

 

Q1:为什么不考虑MGR架构?

 

A:17年MGR刚出来极不成熟,只是测试了下,Bug很多,不想当实验品。

 

Q2:为什么会选择DBLE呢?

 

A:分布式访问层实际上很麻烦,并不是好的建设规划,当时比较了网易DDB、淘宝TDDL、MySQL Proxy、 MySQL Router、DBLE,也就DBLE还可用,而且相较于MyCat优化了很多,所以最后也选择DBLE去做简单的分布式访问层,但是其配置比较繁琐,对开发人员不友好,所以我们进行深度开发和改造,同时建立了统一配置中心(类似于diamond center)才开始使用。

 

Q3:请问底层存储是什么样的,分布式主要体现在哪个环节?

 

A:底层基于IAAS,采用SSD去做持久化。分布式体现在2方面:

  • 伴随着分布式服务,带来的轻量级分布式数据库,可以弹性扩展;

  • 数据的分片存储以及分布式数据访问层。

 

Q4:使用double中间件,原始表还在吗?

 

A:没有所谓的原始表,分片表名字都是一样的。

 

Q5:分布式事务在double上支持吗?如何解决事务问题呢?

 

A:不支持,应该通过应用的扩展(基于我行的分布式事务框架)去做分布式事务处理,如果对事务有强一致性要求,可以通过XA(2pc或3pc)处理;除此以外,还可以将事务拆分为主辅事务,辅事务通过分布式消息队列进行消费处理。

 

Q6:通过Hash分128片,每个片使用一主三从,是这样的架构吗?

 

A:印象中每4片集中部署的,可以根据实际方式调整分片的集中部署和拆分策略。目前最新是1主4备,3个半同步,1个异步(异地)。

 

Q7:128个分片,分片规则考虑了哪些因素呢?

 

A:这个要根据业务规则去考量选择具体的分片算法,脱离实际场景的分片实际上没有意义的。比如有些表可以用身份证号、卡号、地区号等取模或一致性Hash,没有统一的要求。

 

Q8:有没有应用会一次访问128个分片的?

 

A:没有,规范不允许这么访问。

 

Q9:工行在MySQL上容器这方面,遇到过哪些问题呢?性能能扛得住吗?感觉会有很多坑。

 

A:主要就是容器IP的漂移、IO瓶颈,同时要注意分库。

  • IP漂移的问题,工行是通过扩展K8s实现,业界是通过operator去处理(推荐你用这个);

  •  IO瓶颈是通过使用SSD。

 

Q10:MySQL容器化数据持久化是如何做的呢?

 

A:底层基于IAAS,采用SSD去做持久化。

 

Q11:请问IAAS上的网络和存储是使用的什么方案?

 

A:FC-SAN和SSD。

 

Q12:请问10ms的低延迟是怎么做到的呢?

 

A:高配设备、高配网络、事务拆小。

 

Q13:对于TCC最终一致,银行一般是要求强一致吧?哪些典型场景要用到TCC?

 

A:这个不见得,要看具体业务,本质上每个业务可以拆分成主辅交易,然后主交易成功即可,这点阿里和腾讯都是这么玩的;对于并发要求不高和强一致性要求的,基于2PC实现,所以说,工行针对不同的场景有不同的方式。

 

Q14:MySQL都是用operator创建出来的吗?

 

A:工行基于K8s、SDN、IAAS建设持久性的状态容器运行集群,通过SDN实现容器网络资源的自动化申请,通过底层扩展K8s实现容器的固定IP,业界一般会采用K8s Operator实现容器的有状态资源绑定,也包含了固定IP绑定。

 

Q15:半同步退化是怎么解决的呀?

 

A:1)降低事务大小,原则要求1万条提交一次,如果是大SQL,10万条以内。2)每张表都有递增主键。

 

Q16:半同步怎么保证rpo-0呢?

 

A:1)降低事务大小,原则要求1万条提交一次。2)数据库有主备数据一致性的监测,同时应用层需要将数据放置到分布式缓存中,当主备切换时,如果出现数据问题,进行事务补偿。

 

Q17:数据库跨节点关联查询对吗?性能是怎么暴涨的?

 

A:不建议跨节点查询,原则上应指定到具体节点,如果跨界点查询,说明设计不合理,或者可以通过Spark或Flink进行处理。

 

Q18:能否介绍一下分库分表分区键选的情况呢?是按客户还是按机构?全行同一策略,还是应用分别定义?

 

A:由应用分别定义,其实不同的应用,分区键不一样的,比如信用卡,那就是用卡BIN;人员,那就是身份证的后几位、区号等等,设计师。

 

Q19:三表以上的关联复杂查询要怎么解决?

 

A:说明设计不合理,检查下设计是否满足3NF或BCNF,如果不可避免,建议通过时间换空间的方式进行冗余存储。

 

Q20:工行的四类分布式事务处理使用场景可以再详细地描述一下吗?

 

A:涉及账务处理且交易量并发度极低的用XA(2PC或3PC),交易并发量大的应用使用分布式事务框架(TCC或SAGA)处理,但是TCC要求说实话有点高,所以现在应该SAGA会更有优势,特别是阿里和华为就是SAGA。

 

Q21:工行目前整个的数据模型管理是怎么做的呢?

 

A:工行有自己的系统去管理相应的数据模型,同时该系统已与流水线整合,版本时会自动串联之前生成的脚本。

 

Q22:请教一个问题,批处理和联机交易都访问同一MySQL,如何避免批处理异常时,把数据库连接占满而导致的联机交易失败呢?

 

A:不允许,规范要求批量和联机要分开处理,避免影响联机交易。

 

Q23:多中心多活部署时,是否存在交易路径上多个应用间的跨广域网访问问题?如果存在,是如何解决的呢?

 

A:不存在,否则网络延时不可控。

 

Q24:工行的MySQL高可用架构是怎样的?应用异地多活的话,数据库同步的方式能不能讲讲?

 

A:分享时说了,1主4备,3个半同步,1个异步(异地),最早使用磁盘复制实现灾备,一方面成本比较高,另一方面是冷备,无法热切换,RTO至少半个小时以上。

 

Q25:请问双活的应用,连的是同一个库还是异地的库?

 

A:MySQL群组(1主4备)应配置唯一域名,实现应用配置与具体数据库节点的配置的解耦,这样DNS可以自动调整域名指向主库的VIP,同时也会确保只有主库的VIP处于绑定状态。

 

Q26:请问从Oracle迁移到MySQL,要注意哪些坑?

 

A:简单说下,多表关联、分库分表(必须)、设备运维(为什么要上云)、存储过程转换为JAVA处理的内存和事务控制、SQL调优等等,说多了都是泪。

 

Q27:从Oracle到MySQL,sequence是怎么转换的?

 

A:我行是自己实现的sequence处理,所以无所谓Oracle还是MySQL,同时你可以使用雪花算法自己生成,很多玩法。

 

Q28:MySQL的版本是不是太低了?

 

A:16年底开始5.7是当时最好的版本了,8.0当时极其不成熟,问题很多。

 

Q29:老师对MarialDB有了解吗?和MySQL有什么差异呢?

 

A:MariaDB和MySQL的版本不一致,且不兼容问题很多,这个在网上能搜出来很多资料,看自己选择。

 

Q30:工行Redis的应用情况是怎样的呢?分布式缓存用的Redis,大致是什么架构呢?

 

A:工行的分布式缓存用Redis实现的,最早是SSDB,后来被Redis给PK掉了。

 

Q31:老师您是开发还是DBA?您的成长路线是怎样的?

 

A:我是技术管理和安全管理以及生产问题支持人员,最早是开发人员,然后考了Oracle和MySQL的OCP,可以解决从JAVA、数据库、安全等各项问题,一定要开阔自己的视野,不要被工作所局限,你会发现本质都是一样的。

 

获取本期PPT请添加右侧二维码微信  

时代给予传统金融业的危机感从未停止过,不论是互联网的冲击,还是疫情引发的新一轮挑战。为此Gdevops全球敏捷运维峰会北京站精选出近10家银行的金融科技探索,分享其在中台建设、数据库迁移、运维转型上的实战经验,助力Fintech战略落地。部分主题:

 
  • 中邮消费金融:《建设敏捷型消费金融中台及云原生下的DevOps实践》

  • 建信金科:《银行数字化转型战略分析、关键技术及未来架构趋势》

  • 平安银行:《平安银行“传统+互联网”混合CMDB及运营中台实践》

  • 中国银行:《银行日志监控系统优化手记》

  • 工商银行:《ICBC的MySQL转型探索之路》

  • 农业银行:《中国农业银行信贷中台及数据中台建设实践》

  • 民生银行:《民生银行智能运维平台实践之路》《民生银行在SQL审核方面的探索和实践》

  • 蚂蚁金服:《OceanBase分布式数据库在西安银行的落地和实践》

 ​2020年,金融科技会走向何方?让我们9月11日北京一起复盘前十年,定义新十年!

 

 

回看本期直播:https://v.zmengzhu.com/play/10127294?i=7907844&ticket_id=10127294&mod=play

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: