下载网站:www.SyncNavigator.CN
客服QQ1793040
----------------------------------------------------------
关于HKROnline SyncNavigator 注册机价格的问题
HKROnline SyncNavigator 8.4.1 非破解版 注册机 授权激活教程
最近一直在研究数据库同步的问题，在网上查了很多资料，也请教了很多人，找到了一种通过快照复制的方法。研究了一番后发现之前就是用的这个方法，效果不是很好，果断放弃。经过了一番寻觅和他人指点，最后从一位热心网友那里得知一款很好用的软件—— SyncNavigator。
好东西就要拿出来跟大家分享，所以今天向大家介绍一下这款软件，及其一些使用方法。下面先看看它有什么强大的功能吧！
SyncNavigator的基本功能：
自动同步数据/定时同步数据
无论是实时同步/24小时不间断同步，还是根据计划任务(每小时/每日/每周/等)定时自动同步都能完全胜任。
完整支持 Microsoft SQL Server
完整支持 Microsoft SQL Server 2000 2005 2008 数据库类型。并能在不同数据库版本之间相互同步数据。
支持 MySQL 4.1 以上版本
支持 MySQL 4.1 5.0 5.1 5.4 5.5。并能在不同数据库版本之间相互同步数据。
无人值守和故障自动恢复
当数据库故障或网络故障以后，无需人工干预(或操作)自动恢复同步并确保数据完全准确，可靠。
同构数据库同步/异构数据库同步
SQL Server to SQL Server, MySQL to MySQL, SQL Server to MySQL 等都能轻松实现。
断点续传和增量同步
当同步完成(或中断)后，再次同步时能继续上一次的位置增量同步，避免每次都需要从头开始的问题。
分布式异构系统的实际应用场景
在现代的系统设计里面，由于科技的不断更新，分布式算法和移动计算模型，分布式计算模型的成熟，
会产生很多系统迁移的案例, 主要是系统集成以及数据的迁移和整合。
随着基于应用域的设计和开发(DDD)的成熟，让微服务(Mirco-Service)架构的应运而生。
就产生了各个基于domain的细粒度的分布式系统的设计。每一个系统基于不同的应用域需求，运用了不同的架构设计实现，
和分布式存储模型。
举个例子，最简单的一个购买推广的云平台，提供Saas的商城购买服务。
那么，在基于这种DDD的微服务(Micro-Service)架构的设计理念，
把整个Saas的架构基于不同的domain, 划分成不同的微服务系统，
比如, 财务模块(Accounting), 社交模块(Social), 搜索模块(Searching), 数字安全模块(Security),
统计报表模块(Reporting), BI模块(Business Intelligence)
在每一个这种模块里面，都会基于实际的需求采用不同的分布式架构设计和分布式数据存储。
在Social模块，主要记录的是用户的关系和Profile, 这一类用GraphDB 比较合适
在搜索模块，会使用Solr或者Elastic Search作为Indexing引擎
在财务模块，会使用结构化存储，以及强调数据一致性
在数字安全模块，使用OAuth，和结构化存储
在统计报表模块，使用的是结构化存储，和数据分析功能
在BI模块，使用的是HDFS和Hadoop以及使用数据平台架构
那么，其实在这种细粒度的微服务架构里面, 在某些子系统存在着需要数据强一致或者最终一致性的要求。
那么，在分布式异构系统里面是如何做到保证数据完整性又不去损失对于高并发的支持。
首先，说几个案例，
1. 一个对于外部智能家具系统的数据采集和分析系统里面，在对方Utilty公司用push的模式对于系统平台，定时推送数据
的情况下，在每一秒钟有上万次数据采集甚至10w次数据采集频率的级别下面, n * 100000 /second , 当时，系统
采用Hibernate的乐观锁，或者行级锁，是没有办法Scale的
解决方案，把这个系统的存储从Mysql改为了Cassandra
评论: 在这种系统里面是不需要强调数据的完整性，所以不需要事务支持
2. 交易系统，在每秒钟要求实时的高并发达到每秒上十万甚至百万级别的交易量, 要求是实时(Real-Time), 数据完整，
以及支持高吞吐(High Thought-put)和高并发(high Concurrent), 低延迟(Low Latency)
解决方案: 结合使用non-blocking和blocking算法，在JVM层面达到系统设计要求
评论: 这种系统里面需要同时支持高并发和数据完整性, 需要根据实际的应用需求设计系统
其实在CAP理论里面，论述了Consistency, Availability 以及 Partition 不可兼得
举个例子说明，还是以A, B, C 3个人的转账来称述
初始状态 A($100) B($100) C($0)
在时间点T1 A 向 B转账 $100 那么系统状态变化 ($0, $200, $0) 事件1: From A to B $100 状态变化:[[A, -$100],[B, +$100]]
在时间点T2 B 向 C转账 $200 那么系统状态变化 ($0, $0, $200) 事件2: From B to C $200 状态变化:[[B, -$100],[C, +$100]]
在一般的并发的事务处理里面，系统一般是使用 Permisic Lock: 对于整个表，或者行级别加锁，保证数据的一致性和完整性，
其实就是保证了这个事件序列的正确性。也就是事件1一定是发生在事件2之前的，是使用排他锁(Mutual Lock)去完成的。
在这一个并发处理级别，是不太可能达到Scalable的。
那么，如果是基于多个数据源的，一般是采用了基于2阶段提交协议(2 phase commit)的处理方式，等多方表决一致的情况下
才一致提交，这种也是基于sync的处理方式，也是不能Scale性能的。
其实，在使用了Optimize Lock的之后，牺牲了一定程度的对于事件序列的一致性要求，来提高了整个系统的并发量，和可以一定程度的Scale
这个是一种无锁并发算法，也就是Lock-Free，在JDK里面是使用了一些并发库API，比如putIfAbsent的API等等，比如readAndUpdate的API
来实现一样的Lock-Free算法。
那么，在接下来，我们说，这个系统是要支持高度并发的系统设计要求。
那么，必须做到通过扩容服务器的数量，就可以简单有效地无限扩容计算性能，那么，这个就是分布式算法。
我们再次重述一下问题，
在时间点T1 A 向 B转账 $100 那么系统状态变化 ($0, $200, $0) 事件1: From A to B $100 状态变化:[[A, -$100],[B, +$100]]
在时间点T2 B 向 C转账 $200 那么系统状态变化 ($0, $0, $200) 事件2: From B to C $200 状态变化:[[B, -$100],[C, +$100]]
那么，在分布式系统里面，缺乏全局状态，没有全局时钟，
如果，事件1 发生在一个在美国的服务器，T1是当地时间 8:00 am, 随后 事件2 发生在一个中国的服务器，T2: 当地时间 5:01pm
其实统一到UTC时间，他们只是相隔1分钟发生的，但是在服务器上面缺乏一致的时间。所以，也无法对于事件排序，说T1 是发生在T2之前，
那么，作为用户小A，看到的是在T1时刻，他发起转账，在T1.1时刻，他看到账号里面少了100刀，
用户小B在T1时刻是$0,但是在T1.1时刻，他可能什么都没有看到，或者看到了100刀，取决于他的手机app读取的是哪个分布式数据库，
是在西雅图的，还是在上海的，在T1时刻，数据先到了西雅图的AWS上面，但是在上海的数据库还没有同步数据，因为partition的问题，
因为地域分布的问题。如果，他在美国，看到的是转账成功，多了$200,但是如果他在上海，是看不到这个转账。
下面一个问题出现了，
如果小B看不到转账，他是无法向小C转账$200， 在UI上面做了限制
如果小B看到了转账，他是可以向小C转账$200, 那么，还是partition的问题，他的转账对于，小C来说，或者是看到了，或者没有看到，
就是，读写不一致的问题。在这种情况下，要强调数据强一致性，会损失系统的性能。那么其实，只要做到session级别的数据一致就可以了。
这个是一种最终一致的强级别。
在系统设计上面，在分布式系统，使用happened before来定义事件发生序列，
还是以这个例子，
在时间点T1 A 向 B转账 $100 那么系统状态变化 ($0, $200, $0) 事件1: From A to B $100 状态变化:[[A, -$100],[B, +$100]]
那么，A的第一个状态V1 是$100, 第二个状态V2 是$0 B的第一个状态V1 是$100 第二个状态V2 是$200
对于分布式系统的状态保存是使用客户端(Session at Client)保存和分布式状态(Distributed Session)保存2种.
那么不管哪一种状态，在session层，始终是能根据不同数据的版本去同步数据，保证了数据在Session层面的一致性。
那么，其实是数据库保证了partition和availibity，但是在session层去保证了consistence，最终数据库也会得到正确的数据版本更新。
这个就是在3年前大家一直使用的分布式异构系统的数据一致性实现方案。