数据同步

3 月，跳不动了？>>> 分布式开发的一些问题 总结 我是用了两个xp(一个主的，一个从的)的系统测试成功的，linux系统我也做测试了，没有成功，不过我想我所遇到的问题是同一个问题，xp下的可以成功，linux下的应该也可以成功，稍候会测试，然后更新结果！ PS:刚测试了下linux 可以同步成功，主服务器是xp，从服务器是centos，可以成功。 例： A机器 192.168.0.2 B机器 192.168.0.3 两个机器可以ping通，互相访问 先配置主服务端 首先配置一个同步帐号 Sql代码 GRANT FILE ON *.* TO ‘backup’@'192.168.0.3' IDENTIFIED BY ‘1234’; GRANT REPLICATION SLAVE ON *.* TO ‘backup’@'193.168.0.3' IDENTIFIED BY ‘1234’; 帐号名是backup,密码1234，ip为从服务器的ip 这时候我们在服务端增加一个同步数据库 Sql代码 create database test use test create table mytest (username varchar(20),password varchar(20)) 打开my.ini 在[mysqld]输入下面的内容 log-bin=c:\master.log/

主从复制简介： 　　互联网“三高”架构： 　　　　高并发 　　　　高性能 　　　　高可用 　　单机redis的风险与问题： 　　　　问题1.机器故障 　　　　　　现象：硬盘故障、系统崩溃 　　　　　　本质：数据丢失，很可能对业务造成灾难性打击 　　　　　　结论：基本上会放弃使用redis. 　　　　问题2.容量瓶颈 　　　　　　现象：内存不足，从16G升级到64G，从64G升级到128G，无限升级内存 　　　　　　本质：穷，硬件条件跟不上 　　　　　　结论：放弃使用redis 　　　　结论： 　　　　　　为了避免单点Redis服务器故障，准备多台服务器，互相连通。将数据复制多个副本保存在不同的服务器上，连接在一起，并保证数据是同步的。 　　　　　　即使有其中一台服务器宕机，其他服务器依然可以继续提供服务，实现Redis的高可用，同时实现数据冗余备份。 　　多台服务器连接方案： 　　　　 　　主从复制： 　　　　主从复制即将master中的数据即时、有效的复制到slave中 　　　　特征：一个master可以拥有多个slave，一个slave只对应一个master 　　　　职责： 　　　　　　master: 　　　　　　　　写数据 　　　　　　　　执行写操作时，将出现变化的数据自动同步到slave 　　　　　　　　读数据（可忽略） 　　　　　　slave: 　　　　　　　　读数据 　

1. 前言 本编主要记录Zookeeper写请求处理的一些流程，涉及到过半机制，数据同步。 2. 处理流程 这里假设4台服务器，server1(Follower),server2(Leader),server3(Follower),server4(Observer)。 由于我们Zookeeper客户端对于服务端的任何一台服务都是可以进行连接的，有可能是连接的是Leader，或Follower，甚至是Observer。 这里若有一个客户端Client连接的是Observer，并写入数据。但是由于只有写请求只能交与Leader处理，所以若是连接到的是Follower，Observer，就会发生请求的转发到Leader。 接下来，Leader会想所有的Follower发送提议请求，不对Observer发送。Follower收到来自Leader的提议后，会返回ack响应。 Leader收到ack请求后，会采用过半机制，即发送出去的提议有一半以上的ack响应，则就会发送commit提交数据，同时也会向Observer提交commit。 整个写流程就是如此，这样就保证了每个写入请求都会成功的写入到集群中，若有新的服务器加入进来，也会对Leader进行数据同步，来达到集群中数据的一致性。 3. 为何不向Observer发送提议？ 这个问题在Zookeeper单机和集群环境搭建中有提到过

数据传输服务DTS（Data Transmission Service）提供的数据同步功能简单易用，您只需在控制台上进行简单操作，即可完成整个数据同步作业的配置。 注意事项 本文仅简单介绍数据同步作业的通用配置流程，不同的数据源在配置数据同步作业时略有不同。关于各类数据源的详细配置案例请参见 DTS数据同步方案概览 。 准备工作 数据同步的源数据库为PolarDB MySQL或自建MySQL时，须开启其binlog功能。详情请参见开启 PolarDB MySQL的binlog 和 为自建MySQL创建账号并设置binlog 。 操作步骤 1.根据待同步的源实例、目标实例的数据库类型和地域信息购买数据同步作业，详情请参见 购买流程 。 2.登录 数据传输控制台 。 3.在左侧导航栏，单击 数据同步 。 4.在 同步作业列表 页面顶部，选择数据同步实例所属地域。 5.定位至已购买的数据同步实例，单击该实例的 配置同步链路 。 6.配置同步通道的源实例及目标实例信息。 7.上述配置完成后，单击 授权白名单并进入下一步 。 说明 当源实例或者目标实例为阿里云实例时，此步骤会将DTS服务器的IP地址自动添加到源实例或者目标实例的白名单中，用于保障DTS服务器能够正常连接实例。 8.配置同步策略及对象信息，配置完成后单击页面右下角的 下一步 。 9.配置同步初始化的高级配置信息。 10

概要 基于在当前很多不同行业的不同系统如：嘉宝华， 喜茶，碧优选，美团，饿了么，三十加等等不同的系统对接，我们在对接系统是存在一定的问题： 每次开发都需要嵌入到系统中，迭代开发速度慢 内部大量重复建设 大多时候都是通 if else 来区分，代码耦合性太高 服务部署问题，但面临大量数据同步时， 会影响业务系统其它功能（如 碧优选 商品同步为全国的商品信息进行同步，此同步在wshop中进行，会影响wshop当前业务使用） 业务不确定性， 创新困难，无法支撑市场高速变化。如渠道扁平化管理，统一会员营销，全渠道等（每个项目都可能存在一些个性化的表） 后续项目维护成本高，因为业务个性化的原因，久而久之后续系统维护困难 为解决上述问题，采用 系统集成中台 + 应用小前台 的数据同步方式，统一同步标准，以便开发人员快速，便捷的应对企业的开发需求，部署结构调整，不在直接嵌入到内部基础服务，因部署问题而影响 公司核心业务点。架构图如下 现状 增量定时拉取数据同步 场景1 初始化数据 场景2 当数据变更时，定时同步变更的数据 项目案例： 碧优选商品同步 接口回调数据同步 场景 当第三方平台的数据有变动时通过回调接口，进行同步修改 项目案例： 饿了么，订单状态同步（在饿了么下订单，同步到惟客服务） 数据反向同步 场景 当维客服务修改数据，同步至第三方平台 项目案例： 碧优选 会员信息更新

针对大型解决方案的架构设计有了一些进展，继续来做一下总结。 根据项目组中同事提供北京格瑞趋势的资料，我和他们进行了联系，根据他们提供的解决方案，发现能完全满足我们的业务要求。这个产品的简介如下： 1 、Moebius采用无共享磁盘架构的设计，结构灵活简单，方便用户将多个中小型服务器组成集群替代大型服务器，实现更高的综合性能；采用和SQL Server高度集成的设计方式，将Moebius 集群的管理工具集成到SQL Server Management Studio中，方便用户操作，轻松部署、维护、管理集群。 2 、传统的数据库集群都是保证业务持续可用的，有一个主节点，一个备用节点，如MSCS或者第三方的HA集群，这类集群的共同特点是始终只有一个节点在运行，在性能上得不到提升，系统也就不具备扩展的能力，当现有的机器不能满足应用的负载时只能更换更高配置的机器。这样的系统既不利于扩展，同时硬件资源浪费严重。 在Moebius for SQL Server 数据库负载均衡集群中，打破了以往主节点和备用节点的概念，集群中的每个节点都具有同等地位，Moebius可以在多个节点之间实现动态均衡连接请求，实现各节点压力的均衡，进而显著提升数据库系统的性能。 3 、Moebius集群为用户提供了多种选择模式，可以根据对可用性要求程度的不同，采取合适的设置

目录 主从复制概述 如何使用主从复制 开启主从复制 断开主从复制 主从复制的实现原理 连接建立阶段 数据同步阶段 命令传播阶段 【数据同步阶段】全量复制和部分复制 全量复制 部分复制 psync命令的执行 【命令传播阶段】心跳机制 主->从：PING 从->主：REPLCONF ACK 应用中的问题 读写分离及其中的问题 复制超时问题 各场景下复制的选择及优化技巧 复制相关的配置 单机内存大小限制 回到顶部 主从复制概述 在Redis客户端通过 info replication 可以查看与复制相关的状态，对于了解主从节点的当前状态，以及解决出现的问题都会有帮助。 主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower)；数据的复制是单向的，只能由主节点到从节点。 默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。 主从复制的作用主要包括： 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务

写在前面 DataX 是阿里巴巴集团内被广泛使用的异构数据源离线同步工具，致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、MaxCompute(原ODPS)、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。 DataX本身作为离线数据同步框架，采用Framework + plugin架构构建。将数据源读取和写入抽象成为Reader/Writer插件，纳入到整个同步框架中。目前已经有了比较全面的插件体系，主流的RDBMS数据库、NOSQL、大数据计算系统都已经接入。 设计理念 为了解决异构数据源同步问题，DataX将复杂的网状的同步链路变成了星型数据链路，DataX作为中间传输载体负责连接各种数据源。当需要接入一个新的数据源的时候，只需要将此数据源对接到DataX，便能跟已有的数据源做到无缝数据同步。 图1…： 框架设计 DataX本身作为离线数据同步框架，采用Framework + plugin架构构建。将数据源读取和写入抽象成为 Reader/Writer插件，纳入到整个同步框架中。 Reader：Reader为数据采集模块，负责采集数据源的数据，将数据发送给Framework。 Writer： Writer为数据写入模块，负责不断向Framework取数据，并将数据写入到目的端。 Framework

Redis详解（五）——主从复制 面临问题 机器故障。我们部署到一台 Redis 服务器，当发生机器故障时，需要迁移到另外一台服务器并且要保证数据是同步的。而数据是最重要的，如果你不在乎，基本上也就不会使用 Redis 了。 容量瓶颈。当我们有需求需要扩容 Redis 内存时，从 16G 的内存升到 64G，单机肯定是满足不了。当然，你可以重新买个 128G 的新机器。 解决办法 要实现分布式数据库的更大的存储容量和承受高并发访问量，我们会将原来集中式数据库的数据分别存储到其他多个网络节点上。 Redis 为了解决这个单一节点的问题，也会把数据复制多个副本部署到其他节点上进行复制，实现 Redis的高可用，实现对数据的冗余备份，从而保证数据和服务的高可用。 主从复制 什么是主从复制 主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave),数据的复制是单向的，只能由主节点到从节点。 默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。 主从复制的作用 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。 负载均衡

接着上篇 选举流程 。当zk选举成功后，zk会进行(Leader-Follower)数据同步，数据同步成功后，整个集群才开始正常运作。这篇我们就来分析下数据同步流程。 首先我们还是回到org.apache.zookeeper.server.quorum.QuorumPeer的run方法为主入口 @Override public void run ( ) { // ....省略一些无关紧要的代码 try { /* * 主循环 */ while ( running ) { switch ( getPeerState ( ) ) { // 根据zk的状态，执行对应的逻辑 case LOOKING : // LOOKING，会触发选举逻辑，这个我们上篇已经说过了。 LOG . info ( "LOOKING" ) ; // ... 省略一些无关紧要的代码 /* * 当选举结束后。 * 会然后break跳出switch，然后会继续循环，根据选举后的状态 * 执行对应角色的逻辑 */ break ; case OBSERVING : // OBSERVING，Observer需要执行的逻辑。我们主要说Leader、Follower // ... 省略一些无关紧要的代码 break ; case FOLLOWING : // FOLLOWING，Follower需要执行的逻辑 try { LOG