这是汽车之家的基本系统架构，最底层是MYSQL、SQL Server，现在在跟进分布式数据库的评估，后续会有一些相关场景的落地。之上是基础组件、信息采集层。基础组件主要包括运维的基础设施。信息采集层包括元信息、性能数据以及查询日志等。然后在这些信息的上层做了很多运维、数据相关的组件系统，完成我们的运维工作。 整体架构的上层是一些服务的Portal，主要是面向开发同学和DBA同学的服务单元。灰色部分是在做的以及未来的考量，蓝色部分和绿色部分是已经实现的功能。 服务的自动化构建，是开发同学提出资源申请, 一直到服务交付的完整流程。我们主要实现了数据库服务的自动化部署，包括MySQL集群建设、SQL Server部署 以及Slave自动构建。 整个实验方案是基于Salt来实现的部署模块，部署采用Celery分布式异步任务框架来做任务的异步化。整个流程会结合系统平台部的资源申请和装机的流程，协调交互。 服务化自动化架构 整个公司多个机房之间部署了内部DNS解析服务，所有的业务和DB之间的交互全部都通过DNS来做。整个基本的架构就是MHA加半同步。MHA提供原有功能对DNS做支持。运营解析会有对应接口，我们切完之后可以实时更新DNS Cache，让它生效，这样可以保证切换时间对业务影响比较小。对于SQL Server，我们引入了Always ON来实现秒级HA方案。 未来我们主要考虑基于MySQL集群的一些技术，以及分布式数据库技术来实现真正的高可用方案的升级换代。 SQL实时分析 现在我们的系统分了全量、增量，增量里面又分为分钟级和小时级的调度，因为每个组的调度频率是单独可控的，所以只要调度正常，每个分组里的任务状态正常，并且不断的有Worker来执行各种任务的小时调度单元，就可以实现整个数据的迁移。 Worker在执行一个任务片的时候，任务片可能会因为意外情况导致失败。于是有了任务片故障自愈功能。任务片出现了问题之后，它的状态会自动归为可调度状态。调度完成之后会更新任务的元信息来表示数据迁移到了哪个时间点。 结构感知是一个逻辑抽取，不适合做结构感知。所以，我们基于这套框架做了结构对比度的功能，它会定期的校验任务的主库和配置的信息是否对等，如果不对等会触发一个结构同步动作，然后进行更新。 所有的任务在调度的过程中都是互相独立的，每一个任务都可能会延迟，这个延迟时间在做计算的时候是有要求的。我们会根据它所在组的调度区间对它做延迟校验，如果它延迟了，我们会把相关的信息反馈到系统层面，让相关同学去处理。 整个系统有几个核心的组件，第一个是日志解析，也就是把自己伪装成一个Slave，然后不断的获取Binlog的Stream里面的Event来做相关的处理，它会把Event的数据换成Json格式，序列化后投递到Kafka。 在整个解析中，我们加入了一个幂等消息分发。在异常的时候，Kafka因为一些异常的情况会导致消息重发，因此我们为每个消息生成了一个MD5值，消息端可以基于这个值做消息的幂等性校验。 还有一个是解析端高可用，就是我们在做日志解析的时候，如果我的主库或者解析源挂掉，可以换到下一个节点去做解析。 做数据接入的时候，会需要一个历史数据，于是我们引入了快照处理的模块。这个模块利用了一个MYSQL特性，因为我们使用的版本是Percona，Percona把Consistent Snapshot从MariaDB取过来，在此基础上实现了一个session克隆。当开多个线程的时候，可以用同一个Snapshot去抽取，实现真正的并发。 快照的创建，首先连接数据库要开启RR模式，然后通过START TRANSACTION WITH CONSISTENT SNAPSHOT命令开启快照，这个快照可以拿到Binlog的位点，然后通过函数可以拿到当前连接的session id。 当Snapshot、Binlog都存在的情况下， Apply端消费对应任务的topic，处理数据的Snapshot，然后做Apply增量。因为已经有位点了，每一个Json消息里面都会包含消息对应的Binlog的位置和它的file，这样就可以做增量的消费，在消费过程中，如果对数据准确要求很高，可以对每一个消息做校验。 这是当前系统的架构，有Dumper解析模块，还有Snapshot，主要做集备做并发执行，把消息以同样的格式提供到消息缓冲Kafka系统，消费端就可以基于Snapshot加解析端增量来实现实时化的消费。 目前的消息端可以支持这几个方面：

广播电视节目制作经营许可证(京) 字第1234号 中国互联网协会会员