工行“去O”数据库选型与分布式架构设计( 六 ) _分布式架构

6、典型实施案例：信息辅助服务
介绍一下我行的典型案例：信息辅助系统：

文章插图

从应用场景分析其需求，需要支持高并发、低延时，日均交易量为2亿，交易响应延时要求10ms以内，业务数据量大概20T左右，要求7×24小时的联机服务，这就对应用的高可用提出了新的要求。
为此，通过统一运维管理平台，吸纳所有节点，实现一键式的安装、版本的升级、参数的配置。
1）设计层面通过分布式数据中间件DBLE ，进行分库分表，规划了128个分片，并对分片进行了合并部署，虽然相较于阿里的1024分片来说较少，但是我们使用了一致性hash算法，在资源使用上收益很大。
2）DBLE中间件在日间进行联机服务，夜间进行批量变更，把主机上的一些数据同步下来，减少批量作业对联机作业的影响。
3）目前我们的高可用架构采用一主三从（1主库、1本地半同步库、2同城半同步库）架构，基于MySQL的半同步复制，实现园区级的RPO=0 ，通过DBLE中间件和管理平台联动完成实现了本地和同城的自动化切换， RPO=0 ， RTO<60S ，完全满足工行的业务要求。最后补充说明下，为了实现数据库层面的高可用， DBLE到数据库的访问同一配置为实IP 。
4）这里我补充下我们高可用的发展史，其实我们对高可用方案进行了持续的优化，同时学习和借鉴互联网包括分布式数据库的一些方案，从1主2备，本地1备和同城1备，扩展成1主3备，通过半同步的机制，做到真正的在系统级去保证RPO=0 。
5）在异地灾备方面。最开始采用磁盘复制实现灾备，一方面成本比较高，另一方面是冷备，无法热切换， RTO至少半个小时以上。所以我们后期用了MySQL异步复制。
在存储方面采用集中存储，一套集中存储上面需要同时支撑上百个MySQL实例， IO性能直接成为瓶颈，为了应对高并发场景时的IO瓶颈，我们直接引入SSD盘，基本上把MySQL的IO瓶颈给解决了。
三、转型中遇到的各种心酸坑
最后我们说下我行转型过程中遇到的心酸坑。
其实如果使用过MySQL 5.7的企业，肯定都遇到过相似的问题，比如超过MySQL的默认闲置时间导致的连接超时、dependent subquery导致的语句效率差、字符集乱码等等，以及MySQL的自身bug ，比如Intel PAUSE指令周期的迭代引发MySQL的性能瓶颈。毕竟免费的午餐并不是那么完美，总是会有或多或少的问题需要规避。

文章插图

我这里说下让我痛心疾首的几个心酸坑吧：
坑一：慢SQL数量爆发式增长，应用隐患逐步暴露，在阿里等互联网公司和我行都是一个痛点，值得大家警醒和重视。我行OLTP之前为Oracle数据库，借助于Oracle良好的优化器，大家习惯于5张表左右的连接，但是迁移至MySQL后，习惯没有及时转换过来，一个慢SQL可能就导致服务不可用，降低用户幸福指数。为此我们规划了3个方面的改善措施：
1）设计层面制定了规范，强调数据设计的合理性，组织DBA进行内部复核，提前规避设计问题，比如3NF、BCNF的设计遵循、可控性冗余处理（空间换时间或时间环空）等等，通过辅助工具的自动化手段，从源头扼杀风险。
2）开发层面我们基于Sonar开发了自动化检查工具，支持分析mapper文件，既然开发人员没空看规范，那我们工具辅助，增加质量门禁，强制将规范融合至开发过程中，进一步降低风险。但是对新人可能不友好，以前看到一个新人的朋友圈的哭诉，被质量门禁卡的无法提交代码，一直苦逼的加班整改。
3)运维层面我们建立了SRE平台，监测慢SQL语句，并分批次要求整改，将结果都摆在台面上，真的不是我们不给力，而是应用开发不给力啊。