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

请添加右侧二维码微信