分布式数据库核心原理 Zookeeper+Mysql

   笔者一直做java开发，由于技术演进做过大型微服务项目，微服务即将一个大的服务拆分成一个一个小的微服务，每个微服务自成生态，而在落地过程中紧紧只是应用层拆分，数据层往往用同一个库。有点形变神不变，当然将微服务与其对应数据库完全按照领域模型拆分永远只是理想状态。但是在应用微服务化后对于数据层带来了分布式事务或者数据一致性问题。这时就需要分布式数据库TDSQL。

    为什么是TDSQL？首先他是个云数据库将资源与数据库隔离，可以根据需要添加资源，在此基础上创建需要的数据库实例数量，其二应用维护成本降低可根据需求使用分布式库，DBA不用将主要精力放在扩容上面。其三其有强大的监控平台。其四 TDSQL有扁鹊平台帮助业务去分析慢查询。我们知道微服务为一个服务调另一个服务形成调用链，其中有一个服务慢则影响整个服务响应时间，在笔者实际项目中一旦调用链中有一个微服务响应时间超过3毫秒那么整个服务响应将不可接受。我们发现服务接口响应慢80%原因在与SQL运行缓慢造成。其五也是对于应用最核心的问题，分布式数据一致问题，对于一个服务会有多个微服务实例如何保证多个实例操作同一个数据一致性问题？ 我们常用的解决方案如：TCC，需要应用做大量改造，乐观锁会出现ABA等问题，而最佳的解决方案是由数据去完成分布式事务，应用只关心业务逻辑实现，所有XA，但是在实际应用中XA方式效率低下，在笔者参与的某大型项目中因为XA方式需要数据库权限非常高而被安全部门否决所以其落地困难。TDSQL天生带有分布式事务其对传统XA方式进行了优化性能优异，并且将分布式事务作为核心功能之一无需高级别权限使用简单。

    言对正传，我们来讨论一下TDSQL核心原理Zookeeper+mysql，MySQL 只提供了一种基于日志的同步模式 ， 但在 MySQL 集群实际应用中 ，还需要解决一系列 的问题 ，主要包括数据一致性监控 、主从切换 、灾难 恢复后加入集群 、状态和资源监控等 ，这些都是集 群管理的基本问题 。 基于 Zookeeper ，实现 MySQL 集群的资源 、配置的统一管理和调度 ，基本思想是 在 MySQL 服务器上部署 agent ，由 agent 实时上报 MySQL实例的可用性 、复制的一致性 、服务器负载等 ，Zookeeper 根据这些动态信息进行资源调度和 协调 。

  Zookeeper 在内存中维护 了一个 Znode 的 hashmap ，key 为 Znode 在 hier‐ achal namespace 上的路径 ，value 为 Znode 对象 ， Znode 在 Zookeeper 源码中由 DataNode 这个类实现。

  该架构主要由 Zookeeper 、DBagent 和 MySQL 等组件组成 ，Zoo‐keeper 作为系统的协调器 ，监控和管理系统资源 ， DBagent 部署在 MySQL 上 ，负责向 Zookeeper 上 报 MySQL 实例的状态 ，包括实例的可用性 、复制 的一 致 性 、服 务 器 负 载 等 ，由 mysqlreport 和 mysqltransfer 两个模块构成 ，mysqltransfer 用于自动扩容 ，mysqlreport 用于上报心跳信息 、资源信息如下图：

  首先主服务器把数据变化记录到主日志，然后从服务器通过I/O线程读取主服务器上的主日志，并且把它写入到从服务器的中继日志中，接着SQL线程读取中继日志，并且在从服务器上重放，从而实现MySQL复制。

  主从数据库的一致性监控通常是在从库上执 行语句 show slave status ＼G 获取 Seconds＿Behind ＿Master 参数的值来判断 ，但这个值通常不能反映 主从数据库一致性的真实情况 。通过比较 sql ＿ thread 执行的 event 的 timestamp 和 io＿thread 复制的 event 的 timestamp 进行比较得到的一个差值。为0则无延迟。