mysql数据库主从同步的3种一致性方案实现，及优劣比较
在线网址：
https://www.syncnavigator.cn/chm/index.htm
官网下载：https://www.syncnavigator.cn
创建第一个同步项目
使用 HKROnline SyncNavigator 创建一个数据库同步项目。只需要通过简单的配置，创建完成后您可以随时执行数据库同步任务。
1. 点击 "SyncNavigator(Client)" 图标进入系统。
2. 在登录界面中输入连接到的服务器地址，点击 "确定" 按钮开始连接。
- 注意：这里不是登陆您的数据库，而是登陆到本软件的管理端。
- 默认情况下直接点击 "连接" 按钮即可（本机默认已经安装）。
- 默认服务器登录用户名为 "admin" 密码为空。
- 本机服务器地址 = 127.0.0.1 。
- 您可以使用域名或者IP地址作为服务器地址。如果指定了端口号可以使用 IP:Port 方式填写。
3. 切换到 "同步管理" 面板中点击 "新建" 按钮开始创建同步项目。
4. 首先切换到 "来源数据库" 选项卡。填写同步的来源数据库信息。
-
一般情况下只需要输入数据库地址，数据库名称，登录用户名，登录密码。
- 数据库地址: 连接到的数据库地址。可以是域名或者IP地址。如果指定了端口号可以使用 IP:Port 方式填写。
- 数据库名称: 使用的数据库名称。如果已经指定了默认的登录数据库可以为空。
- 登录用户名: 登录数据库服务器使用的用户名。如果需要使用Windows账户登录请变更 "登录方式"
- 连接测试: 测试输入的信息是否正确。如果连接失败则会返回具体错误信息。
5. 切换到 "目标数据库" 选项卡。以相同的方式填写同步的目标数据库。
-
您只需要创建一个新的目标数据库，软件会自动创建最大兼容的表结构。
- 如果您希望目标数据库与来源数据库表结构完全一致，您只需要在目标数据库创建一个空表结构即可。
- 当您使用 MySQL 作为来源数据库时，同步的表至少需要一个主键。
- 目标数据库不应包含外键约束，因为它可能导致部分数据无法同步。
- 如果您的目标数据库与来源数据库结构（如字段类型，约束）不兼容，这可能导致部分数据无法同步。
- 假设您设置来源库为 192.168.1.2 ，设置目标数据库为 192.168.1.3, 那么数据将从192.168.1.2 同步到 192.168.1.3。如果您的方向设置错误，可能会导致数据被覆盖。
6. 切换到 "同步内容设置" 选项卡。选择需要同步的数据库表。
-
如果需要设置每个表的具体内容可以点击 "详细设置" 按钮进行调整。
- 您可以设置条件过滤。比如只查询评分大于90的表记录，或者隐藏不需要同步的字段。
- 如果在这一个步骤未勾选任何表则不会同步任何内容。
数据主从同步的由来
互联网的很多业务，特别是在高并发的场景下，基本都是读远远大于写，如果数据库读和写的压力都同在一台主机上，这显然不太合理。
于是，把一台数据库主机分为单独的一台写主库（主要负责写操作），而把读的数据库压力分配给读的从库，而且读从库可以变为多台，这就是读写分离的典型场景如下：
为了进一步的降低数据库端的压力(高并发的瓶颈)，这个时候也会在业务层部署分布式缓存集群(redis、memcached)等，把读的压力转移给应用服务器端，其实与数据主从的设计是遵循同一个原则，降低后端数据库的压力。
问题：
读写分离提高了资源的利用效率的同时也引出了一个问题，就是由于延时（网络传输，操作）而引起的数据库主从不一致的问题，以下会详细谈相关的数据一致性解决方案。
数据同步一致性解决方案
1.半同步复制
办法就是等主从同步完成之后，等主库上的写请求再返回，这就是常说的“半同步复制”。
实现方案
mysql的半同步复制方案，下面我以mysql为例介绍。
MySQL半同步复制
MySQL的Replication默认是一个异步复制的过程，从MySQL5.5开始，MySQL以插件的形式支持半同步复制，我先谈下异步复制，这样可以更好的理解半同步复制。
1）异步复制
MySQL默认的复制是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从库上。
2）半同步复制
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay
log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。
半同步复制原理：
事务在主库写完binlog后需要从库返回一个已接受，才放回给客户端
mysql5.5版本以后，以插件的形式存在，需要单独安装
确保事务提交后binlog至少传输到一个从库
不保证从库应用完成这个事务的binlog
性能有一定的降低
网络异常或从库宕机，卡主库，直到超时或从库恢复
该方案优点：
利用数据库原生功能，比较简单
该方案缺点：
主库的写请求时延会增长，吞吐量会降低
2.数据库中间件
流程：
1）所有的读写都走数据库中间件，通常情况下，写请求路由到主库，读请求路由到从库
2）记录所有路由到写库的key，在主从同步时间窗口内（假设是500ms），如果有读请求访问中间件，此时有可能从库还是旧数据，就把这个key上的读请求路由到主库。
3）在主从同步时间过完后，对应key的读请求继续路由到从库。
相关的中间件有：
1）canal:是阿里巴巴旗下的一款开源项目，纯Java开发,基于数据库增量日志解析，提供增量数据订阅&消费，目前主要支持了MySQL。
2）otter：也是阿里开源的一个分布式数据库同步系统，尤其是在跨机房数据库同步方面，有很强大的功能。它是基于数据库增量日志解析，实时将数据同步到本机房或跨机房的mysql/oracle数据库。
两者的区别在于：
otter目前嵌入式依赖canal，部署为同一个jvm，目前设计为不产生Relay Log。
otter目前允许自定义同步逻辑，解决各类需求。
该方案优点
能保证绝对一致
该方案缺点：
数据库中间件的成本较高
缓存记录写key法
写流程：
1）如果key要发生写操作，记录在cache里，并设置“经验主从同步时间”的cache超时时间，例如500ms
2）然后修改主数据库
读流程：
1）先到缓存里查看，对应key有没有相关数据
2）有相关数据，说明缓存命中，这个key刚发生过写操作，此时需要将请求路由到主库读最新的数据。
3）如果缓存没有命中，说明这个key上近期没有发生过写操作，此时将请求路由到从库，继续读写分离。
该方案优点：
相对数据库中间件，成本较低
该方案缺点：
为了保证“一致性”，引入了一个cache组件，并且读写数据库时都多了缓存操作。
————————————————