同一个服务器上两个数据库表怎么同步

如果是同一个mysql服务端的两个数据库同步可考虑下触发器，如果是不同端口的两个mysql服务端跟在两台服务器同步配置上没有区别。

数据库最好不要做主从，不然性能会降低很多的。

可以采取其他的方法撒，比如分布式存储。可以考虑下memcachedb，实现持久存储。

表结构一致的话，可以考虑映射表去实现来的（shell脚本定时同步，触发器），不过shell脚本会将环境搞的复杂一点，维护也会相对麻烦映射表具体实现（在要同步的数据库下创建相同的表结构）：

1

2

3

4

5

6

7

8

CREATE TABLE table_name

(

column_name column_type

key

)

ENGINE=MYISAM DEFAULT CHARSET=utf8

CONNECTION="mysql://user:pwd@ip_address/db_name/table_name";

纵向扩展指的是增加单个数据库服务器的性能，这包括增加内存、磁盘空间、CPU 等资源。这种扩展方式会遇到瓶颈，是因为单台数据库服务器的性能有限，总有一天会达到极限。

横向扩展指的是增加多台数据库服务器，将数据分布在多台服务器上。这种扩展方式需要解决如何在多台服务器之间进行数据同步、如何确保数据的一致性、如何处理负载均衡等问题。横向扩展能够提高数据库的性能和可扩展性，但也带来了更多的复杂性。

本文基于对redis、zookpeer、rocketmq、elasticsearch学习总结，对于分布式系统学习，一定绕不开一个点，那就是CAP定理。什么是CAP定理，我这里简单的复制摘抄一下百度上的文案。

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

说明一下上面的三个要素各代表的含义：

CAP定理说明上述的三个要素不能兼顾，最多只能满足其中的两个要素，在分布式系统中，一般都是保证分区容错性，而在一致性和可用性之间做取舍。因此存在CP、AP两种分布式集群的实现。

CP集群，即满足一致性和分区容错性，如zookpeer

AP集群，即满足可用性和分区容错性，如redis-cluster

下面，针对与上述的CP和AP问题，我们展开话题。

对于分布式系统，学习了解多了之后，发现其内在的解决方案基本上都是一样的，所谓万变不离其中。总结一下大体在于以下几步：

数据分片，很多分布式系统尤其是中间件服务，一般都会涉及高并发，数据量大的问题，如redis-cluster、recketmq，以及被大家熟知的Elasticsearch。针对于大数据量高并发的问题，若不做处理，服务器的性能将会成为服务的瓶颈，解决的方案之一便是数据分片，将大数据量在集群中按照一定的规则分片，使数据按照一定的规则分布集群的不同服务器上，以减轻单个服务器的压力，保证服务集群的可用性。

redis-cluster的数据分片是通过redis-cluster的哈希槽来实现的，redis-cluster有16384个哈希槽，这个数量是固定的，根据集群中服务器的数量可以手动的调配每个服务上存放的hash槽的数量，哈希槽之间是相互独立的，因此对集群的扩展提供了便利。

rocketmq的分片和topic紧密相关，在使用rocketmq中，无论是消息的生产者还是消费者都需要注册订阅一个topic。在rocketmq集群中，集群中的broker保存这个topic下数据的一部分，也就是topic的其中一个数据分片。当然，rocketmq不仅将一个topic下的数据分片到多个broker上，而且，一个broker上的topic数据还可以被分为多个queue，这是因为rocketmq中，一个queue只能被一个consumer消费，若是consumer的数量多于queue的数量，没有绑定queue的consumer将不能消费数据。

elasticsearch的数据分片在我看来和mysql的分库分表原理是一样的，elasticsearch中，每一个索引都相当于mysql的一个表，将一个索引分成多个shard放在不同的节点上，每个shard存储一部分数据。elasticsearch将数据进行分片，这样可以支持集群的横向扩展，同时，多个节点提供服务可以提高系统的效率和吞吐量。

综上所述，数据分片的一般都有两个好处，一个是支持集群的横向扩展，而是提升服务的吞吐量和性能。数据分片解决了以上两个问题，但是若是集群中一个节点发生宕机，或者因为网络原因和集群断开链接，那么这部分的数据分片甚至整个集群都会不可用，如何解决这个问题，就需要用到数据备份和主备切换。

数据分片的策略 了解了数据分片之后，需要了解以下数据分片的策略，根据集群提供服务的性质不同，可以采用的数据分片策略也各有不同，下面是我学习后的总结：

说到这里，会发现其实这种分片策略和负载均衡的策略还是挺相似的。

数据备份，举个例子来说，我有两台电脑A、电脑B，A用于工作，B用于游戏，我写了一篇文章，保存在电脑上电脑上，若是某一天我的电脑A磁盘坏了，那我这篇文章就找不到了，即便我现在还有电脑B，我也没有办法在对文章进行编辑。但是若是我在之前，就将文章拷贝了一份放在电脑B上，那么现在，我用电脑B就可以对文件进行编辑修改。

举这个例子，我的目的就是为了说明数据备份对于集群可用性的意义，例子中，我的两台电脑可以认为是集群中两台服务器，两台服务器一开始提供的服务可能不相同，A电脑提供的就是编辑文章的服务，数据备份的意义就在于，当原本提供服务的服务器宕机损坏，集群中另外的服务器仍然可以根据已经备份的数据提供相同的服务，而不会影响到用户的工作。

数据备份的目的就是不发生单点问题的措施之一，但是若是数据备份的策略不合适，备份的时机不对，那么备份的数据时效性也是问题。还是从例子出发，这里的文章每次都是我手动从A电脑拷贝到B电脑，这是我的备份策略，若是我选择每天晚上才拷贝一次，那么若是A电脑在我拷贝之前坏了，当天的文章编辑数据就丢失了，采用手动的方式备份，这种备份方式耗时耗力且不可控，而在分布式集群中，不同的系统采用了不同的备份策略，下面一一来说明。

首先明确一点，在分布式集群中，不可能采用人工手动备份，一定是系统程序按照一定的规则自动备份，就好像我将AB连在一起，写个程序，让A电脑自动把文章同步到B电脑。数据备份的方式分为两种：

这里以redis-cluster和zookeeper举例。

在redis-cluster中，当一台新的slave节点加入时，会出发数据同步，需要将主节点的数据同步到从节点。这时根据从节点的状态有两种同步方案：完整重同步 和 部分重同步

完整重同步既是将主节点的全部数据都复制给新的slave节点。大致流程为，当一个新的节点加入进来时，发送PSYNC命令给主节点并携带slave节点自身的信息（重点是复制偏移量），主节点会根据slave传过来的信息判断是完整重同步还是部分重同步，如何判断与数据同步时的复制缓冲区有关，更细节不展开介绍。

相对于redis-cluster，zookeeper中的数据同步有四种方式，和redis-cluster完整重同步和部分重同步相似的SNAP（全量同步）和DIFF（增量同步），以及zk事务处理相关的TRUNC（仅回滚同步）、TRUNC+DIFF（回滚+增量同步）

当节点已经加入集群，成为集群中的从节点，只要不断开连接，一般都只需要进行增量同步，不过系统同步的范围和方式有所差异，大致分为下面六种：

下面还是以具体服务来举例： redis-cluster中，主从复制采用的是异步复制的方式，master节点在做数据变更之后，会由一个异步线程将数据变更同步给slave节点，这是通过push的方式。当redis28之后，slave会周期的获取最新的数据，加入了pull方式。无论是master还是slave，在进行数据同步时，不会阻塞正常的应用请求。所以redis-cluster的主从复制，是异步备份+最终一致性的备份。

elasticsearch的主从复制可以手动设置同步备份或者异步备份，数据备份时不要求强一致性，而是主分片（primary shard）会维护一份需要同步的（replica shard）分片列表，这个分片列表同步完成，则认为数据备份完成，需要注意的是，这里的主从复制不是节点的更新数据，而是分片的更新数据。

rocketmq的主从复制和elasticsearch类似，也可以分为同步备份和异步备份，不同的是rocketetmq的数据备份采用的是pull的方式，从节点会通过HAConnection链接主动向主节点发送待拉取数据偏移量，待主节点返回节点更新数据信息，更新从节点数据偏移量，如此重复。

zookeeper的数据备份则是通过ZAB协议，通过消息广播的方式同步数据到从节点。

当数据备份后，主从节点上就有了相同的数据，为了提升服务的性能，那么可以采用读写分离的方式。主节点提供数据写服务，从节点提供读服务，可以有效的分担主节点的服务器压力。可以进行数据分片的系统，如：redis、rocketmq、elasticsearch，一般都可以配置一主多从、多主多从的集群架构。

读写分离之后，主节点提供写服务，从节点只提供读服务，因此若是主节点发生宕机，从节点依然可以提供读服务，但是服务无法更新数据，这时候就要进行主从切换。早起，主从切换可以由人工手动完成，不过随着技术发展，主从切换已经成为集群的必备功能。想要实现主从切换，必须要解决两个问题：

解决这个问题，需要额外再引入一个角色，相当于是一个监视者的角色，能够长期的对主节点进行监视，若是只有一个监视者，可能会发生误判，所以还需要一套机制去保证当监视者说主节点宕机，那么主节点是真的宕机，否则集群会出现脑裂问题。

以redis为例，在redis的哨兵模式中，这个监视者的角色是一个个哨兵实例，而在redis-cluster架构中，这个监视者的角色是redis实例自己。

在redis哨兵模式中，哨兵集群中的哨兵实例会定期和redis实例进行通信（ping），监视redis实例的在线情况，若是其中一台哨兵发现redis实例master故障，那么该哨兵会将该master状态改为主观下线，并通知其他哨兵，当哨兵集群中达到配置数量的哨兵实例认为该master都为主观下线状态，这时会将master修改为客观下线状态，并开始触发后续的故障转移。

在redis-cluster模式中，集群中的每一个节点都可以和其他节点通讯（ping），当某一个节点A发现主节点B下线了，A会将该主节点B设为疑似下线状态。集群中的节点会通过互发消息维护信息，当另一个节点C收到A的消息时，会将A对B节点的判断记录在C节点的维护信息下，这个信息可以理解为A说C疑似下线了。若是有其他节点发送C的状态信息，A同样也会记录。当某一个节点如C发现记录的B节点信息中，超过半数的主节点都认为B下线了，那么C就会将B节点状态修改为已下线状态，并广播消息给集群的其他节点，开始后续的故障转移。

上面就是redis的两种分布式模式故障检测的方案。大致可以归结为，监视节点会和被监视节点进行通讯，感知被监视节点的状态；监视节点之间也会进行通讯，同步信息。为了防止集群出现脑裂，对于某个主节点的故障判断会十分的谨慎，需要达到一定数量的监视节点都认为主节点故障时，才会认为主节点真的故障，从而触发故障转移。

在rocketmq集群模式中，nameserver扮演着监视者的角色（不同于其他系统，nameserver并不负责集群的主从切换，rocketmq 45之前不支持自动主从切换，45之后，通过dledger实现自动的故障转移）。在elasticsearch集群中，elasticsearch实例本身在扮演监视者角色。zookeeper也是实例本身扮演监视者的角色。

故障转移就是当集群发现集群中的主节点/从节点发生故障之后的处理，从节点比较简单，直接将从节点下线即可，主节点的故障转移流程比较复杂，各个系统根据系统的功能和架构有不同的实现方式，共同点是选举出的主节点一定是集群中数据最新的最完善的节点。

选举过程大致如下：

首先选举成功的条件时集群中具有投票权限的超过半数的节点投票一致，通过某一个节点成为主节点。

开始一轮选举时，定义为一个纪元，用一个自增的id表示。

候选节点将带着纪元id，以及自身信息作为投票申请广播给集群给可投票的节点。

具有投票权限的节点投票只要满足两个条件：1自身在最新纪元没有给投过票 2节点发送过来的投票申请时最新纪元的（如何判断时最新纪元，则是判断一下节点之前通过申请的纪元id是否小于当前申请的纪元id）。

半数以上的投票节点通过某一个候选节点成为leader节点，则leader产生。

若是一个纪元没有产生主节点，则候选节点进入随机的休眠，并且开启下一个纪元，知道产生leader节点。

在zk集群经过崩溃恢复模式之后，需要保证：1已经提交的事务不能丢失 2未被提交的事务不能出现。如何保证以上两点，zk服务集群中维护了zxid，zxid也可以看作是一个自增的id，集群中每产生一个新事物，zxid就会增加。zxid有64位，前32位维护了集群主节点变更情况，每重新选举出一个新的主节点则增加，后32位维护在新的主节点集群下事务的id，产生一个新事物则增加。

ZAB的选举模式有很多种，我主要了解了默认，也是推荐的FastLeaderElection模式，在这个模式下，我会以集群中一台参与选举的服务器的视角来模拟选主的过程；

我是一台zk服务器，我现在很慌，因为我的leader服务器不见了，作为一个有梦想的follower，我也要参加leader的选举，为了这次选举我要准备：myid(在集群中标识是这台服务器的id)，zxid(本台服务器保存的最新事务id)，logicClock(本台服务器发起的第几轮投票)

首先我会自己选自己，这得自信。于是我将自身的选举信息[myid, zxid]放到自己的收票箱，然后将我的选举信息还有我的选举轮次logicClock广播给其他服务器进行PK

作为一个有原则的服务器，我们的选举也是有原则的，当我收到别人的选举信息时，我也会将他和我自己的选举信息进行PK，PK的原则如下：

经过这一系列的PK，终于选出了我心中的leader服务器，要广播给其他服务器。

超过半数的服务器都同意某一台服务器成为leader，选举结束了。

sschrodinger

2019/07/17

一个分布式系统 不可能同时满足 一致性（ C:Consistency )，可用性（ A: Availability ）和分区容错性（ P：Partition tolerance ）这三个基本需求， 最多只能同时满足其中的 2 个 。

如下：

BASE 是 Basically Available (基本可用) ，Soft state （软状态）,和 Eventually consistent （最终一致性）三个短语的缩写。

既是无法做到 强一致性 （ Strong consistency ），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到 最终一致性 （ Eventual consistency ）

基本可用

允许出现响应时间损失或者功能损失。

软状态

允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即 允许系统在多个不同节点的数据副本存在数据延时 。

最终一致性

系统能够保证 在没有其他新的更新操作 的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问 最终都能够获取到最新的值 。

在分布式系统中，会有多个机器节点，因此需要一个 “ 协调者 ” ，而各个节点就是 “ 参与者 ”，协调者统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点就是 “参与者”。

阶段一

阶段一主要是询问参与者是否可以进行提交。

阶段二

阶段二会根据阶段一的投票结果执行两种操作： 执行事务提交 ， 回滚事务 。

执行事务提交步骤如下：

中断事务步骤如下：

优点

原理简单，实现方便

缺点

同步阻塞，单点问题，数据不一致，过于保守

2PC （两阶段提交协议）

三阶段提交协议在协调者和参与者中都引入 超时机制 ，并且把两阶段提交协议的第一个阶段拆分成了两步：询问，然后再锁资源，最后真正提交。

协调流程如下：

阶段一： CanCommit

阶段二：preCommit

协调者在得到所有参与者的响应之后，会根据结果执行2种操作：执行 事务预提交 ，或者 中断事务 。

执行事务预提交分为 3 个步骤：

中断事务也分为2个步骤：

阶段三：doCommit

该阶段做真正的提交，同样也会出现两种情况：

执行提交

中断事务

假设有任何参与者反馈了 no 响应，或者超时了，就中断事务。

优点

缺点

如果参与者收到了 preCommit 消息后，出现了网络分区，那么参与者等待超时后，都会进行事务的提交，这必然会出现事务不一致的问题

3PC（三阶段提交协议）

paxos 算法保证了一致性 。

在一个分布式系统中，有一组的 process，每个 process 都可以提出一个 value，consensus 算法就是用来从这些 values 里选定一个最终 value。如果没有 value 被提出来，那么就没有 value 被选中；如果有1个 value 被选中，那么所有的 process 都应该被通知到。

在 2PC 或者 3PC 中，如果协调者宕机了，整个系统就宕机了，这个时候就需要引用多个协调者，paxos 就是用来协调协调者的协议。

首先将议员的角色分为 proposers ， acceptors ，和 learners （允许身兼数职）。 proposers 提出提案，提案信息包括提案编号和提议的 value ； acceptor 收到提案后可以接受（ accept ）提案，若提案获得多数派（ majority ）的 acceptors 的接受，则称该提案被批准（ chosen ）； learners 只能“学习”被批准的提案。划分角色后，就可以更精确的定义问题：

通过不断加强上述3个约束（主要是第二个）获得了 Paxos 算法。

批准 value 的过程中，首先 proposers 将 value 发送给 acceptors ，之后 acceptors 对 value 进行接受（ accept ）。为了满足只批准一个 value 的约束，要求经“多数派（ majority ）”接受的 value 成为正式的决议（称为“批准”决议）。这是因为无论是按照人数还是按照权重划分，两组“多数派”至少有一个公共的 acceptor ，如果每个 acceptor 只能接受一个 value ，约束 2 就能保证。

于是产生了一个显而易见的新约束：

注意 P1 是不完备的。 如果恰好一半 acceptor 接受的提案具有 value A ，另一半接受的提案具有 value B ，那么就无法形成多数派 ，无法批准任何一个 value 。

约束 2 并不要求只批准一个提案 ，暗示可能存在多个提案。 只要提案的 value 是一样的，批准多个提案不违背约束 2 。于是可以产生约束 P2：

如果 P1 和 P2 都能够保证，那么约束 2 就能够保证。

批准一个 value 意味着多个 acceptor 接受（ accept ）了该 value 。因此，可以对 P2 进行加强：

由于通信是异步的，P2a 和 P1 会发生冲突。如果一个 value 被批准后，一个 proposer 和一个 acceptor 从休眠中苏醒，前者提出一个具有新的 value 的提案。根据 P1，后者应当接受，根据 P2a，则不应当接受，这种场景下 P2a 和 P1 有矛盾。于是需要换个思路，转而对 proposer 的行为进行约束：

由于 acceptor 能接受的提案都必须由 proposer 提出，所以 P2b 蕴涵了 P2a，是一个更强的约束。

但是根据 P2b 难以提出实现手段。因此需要进一步加强 P2b。

假设一个编号为 m 的 value v 已经获得批准（ chosen ），来看看在什么情况下对任何编号为 n （ n > m ）的提案都含有 value v 。因为 m 已经获得批准（ chosen ），显然存在一个 acceptors 的多数派 C ，他们都接受（ accept ）了 v 。考虑到任何多数派都和 C 具有至少一个公共成员，可以找到一个蕴涵 P2b 的约束 P2c：

如果一个没有 chose 过任何 proposer 提案的 acceptor 在 prepare 过程中接受了一个 proposer 针对提案 n 的问题，但是在开始对 n 进行投票前，又接受（ accept ）了编号小于n的另一个提案（例如 n-1 ），如果 n-1 和 n 具有不同的 value ，这个投票就会违背 P2c。因此在 prepare 过程中， acceptor 进行的回答同时也应包含承诺：不会再接受（ accept ）编号小于 n 的提案。这是对 P1 的加强：

通过一个决议分为两个阶段：

prepare 阶段

proposer 选择一个提案编号 n 并将 prepare 请求发送给 acceptors 中的一个多数派；

acceptor 收到 prepare 消息后，如果提案的编号大于它已经回复的所有 prepare 消息(回复消息表示接受 accept )，则 acceptor 将自己上次接受的提案回复给 proposer ，并承诺不再回复小于 n 的提案；

批准阶段

当一个 proposer 收到了多数 acceptors 对 prepare 的回复后，就进入批准阶段。 它要向回复 prepare 请求的 acceptors 发送 accept 请求，包括编号 n 和根据 P2c 决定的 value （如果根据 P2c 没有已经接受的 value ，那么它可以自由决定 value ） 。

在不违背自己向其他 proposer 的承诺的前提下， acceptor 收到 accept 请求后即批准这个请求。

这个过程在任何时候中断都可以保证正确性。例如如果一个 proposer 发现已经有其他 proposers 提出了编号更高的提案，则有必要中断这个过程。因此为了优化，在上述 prepare 过程中，如果一个 acceptor 发现存在一个更高编号的提案，则需要通知 proposer ，提醒其中断这次提案。

一个实例如下：

在这之后，提议者还需要做一件事，就是告知D,E，被决定的决议已经是什么了。即可。

这个过程叫 Learn 。 D ， E 被称为 Learner

Paxos VS Zab

wiki 百科

维基百科-paxos

对于 paxos 来说，每一个议案都要经过不同节点的提出，并且讨论，在提出一个议案的阶段，另外的提议会被否决，导致了性能的低下。

ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持 崩溃恢复 和 原子广播 协议。

基于该协议， Zookeeper 实现了一种 主备模式 的系统架构来保持集群中各个副本之间数据一致性。具体如下图所示：

即只有一个 proposal 可以提出提议，其他的进程都只能复制决议。

所有客户端写入数据都是写入到 主进程（称为 Leader ）中，然后，由 Leader 复制到备份进程（称为 Follower ）中。从而保证数据一致性。

ZAB 协议的消息广播过程使用的是一个原子广播协议，类似一个 二阶段提交过程 。但是只需要 Follower 有一半以上返回 Ack 信息就可以执行提交，大大减小了同步阻塞。也提高了可用性。

对于客户端发送的写请求，全部由 Leader 接收， Leader 将请求封装成一个事务 Proposal ，将其发送给所有 Follwer ，然后，根据所有 Follwer 的反馈，如果超过半数成功响应，则执行 commit 操作（先提交自己，再发送 commit 给所有 Follwer ）。

流程如下：

Leader 挂了之后， ZAB 协议就自动进入崩溃恢复模式，选举出新的 Leader ，并完成数据同步，然后退出崩溃恢复模式进入消息广播模式。

可能 Leader 遇到如下异常情况：

第一种情况 主要是当 leader 收到合法数量 follower 的 ACKs 后，就向各个 follower 广播 COMMIT 命令，同时也会在本地执行 COMMIT 并向连接的客户端返回「成功」。 但是如果在各个 follower 在收到 COMMIT 命令前 leader 就挂了，导致剩下的服务器并没有执行都这条消息。

为了实现已经被处理的消息不能丢这个目的，Zab 的恢复模式使用了以下的策略：

第二种情况 主要是当 leader 接收到消息请求生成 proposal 后就挂了，其他 follower 并没有收到此 proposal ，因此经过恢复模式重新选了 leader 后，这条消息是被跳过的( 其他机器日志中没有这一条记录，但是他的日志中有这一条记录 )。 此时，之前挂了的 leader 重新启动并注册成了 follower ，他保留了被跳过消息的 proposal 状态，与整个系统的状态是不一致的， 需要将其删除 。

Zab 通过巧妙的设计 zxid 来实现这一目的。一个 zxid 是 64 位，高 32 是纪元（ epoch ）编号，每经过一次 leader 选举产生一个新的 leader ，新 leader 会将 epoch + 1 。低 32 位是消息计数器，每接到一个消息，则 $lo^{32} + 1$ ，新 leader 选举后这个值重置为 0。这样设计的好处是旧的 leader 挂了后重启，它不会被选举为 leader ，因为此时它的 zxid 肯定小于当前的新 leader 。当旧的 leader 作为 follower 接入新的 leader 后，新的 leader 会让它将所有的拥有旧的 epoch 未被 COMMIT 的 proposal 清除。

Zookeeper系列（5）--ZAB协议，消息广播，崩溃恢复，数据同步

Raft是用于管理复制日志的一致性算法，raft 协议也是一个 主备模型 ，有一个唯一的 leader 控制任务的提交。

如下是一个 raft 协议中每一个节点可能存在的状态，主要分为 领袖 、 群众 和 候选人 。

raft 最关键的一个概念是任期，每一个 leader 都有自己的任期，必须在任期内发送心跳信息给 follower 来延长自己的任期。

Raft 协议强依赖 Leader 节点的可用性来确保集群数据的一致性 。 数据的流向只能从 Leader 节点向 Follower 节点转移 。当 Client 向集群 Leader 节点提交数据后， Leader 节点接收到的数据处于 未提交状态（ Uncommitted ） ，接着 Leader 节点会 并发向所有 Follower 节点复制数据 并等待接收响应，确保 至少集群中超过半数节点 已接收到数据后再向 Client 确认数据已接收。一旦向 Client 发出数据接收 Ack 响应后，表明此时数据状态进入已提交（ Committed ）， Leader 节点再向 Follower 节点发通知告知该数据状态已提交。

在数据同步阶段，可能出现七种情况：

动画演示 raft 算法

动画演示 raft 算法 - 2

Raft Vs zab

NWR 是一种在分布式存储系统中用于控制一致性级别的一种策略。在 Amazon 的 Dynamo 云存储系统中，就应用 NWR 来控制一致性。

让我们先来看看这三个字母的含义：

在分布式系统中， 数据的单点是不允许存在的 。即线上正常存在的 Replica 数量是 1 的情况是非常危险的，因为一旦这个 Replica 再次错误，就 可能发生数据的永久性错误。假如我们把 N 设置成为 2，那么，只要有一个存储节点发生损坏，就会有单点的存在。所以 N 必须大于 2。N约高，系统的维护和整体 成本就越高。工业界通常把 N 设置为3。

当 W 是 2、R 是 2 的时候， W+R>N ，这种情况对于客户端就是强一致性的。

在具体实现系统时，仅仅依靠 NWR 协议还不能完成一致性保证，因为在上述过程中，当读取到多个备份数据时，需要判断哪些数据是最新的，如何判断数据的新旧？这需要向量时钟来配合，所以对于 Dynamo 来说，是通过NWR协议结合向量时钟来共同完成一致性保证的。

1，Zookeeper -- paxos

2，kafka -- zookeeper上创建节点

3，redis -- 哨兵模式

4，Eureka -- 相互复制

我们探讨这几个集群的选举机制，其实就是探讨它们的高可用性。如果集群中的某些节点挂了，如何保证可用性？这个问题是分布式系统面临的三大问题之一。

Zookeeper的leader选举机制，是这四种集群中最复杂的选举机制，同时也是这四种集群中最接近paxos算法的实现。相比于Zookeeper的选举机制，kafka集群、redis集群、Eureka集群的选举机制简单了许多。

Zookeeper的leader选举是Zookeeper实现数据一致性的关键，同时也存在一些问题。认清Zookeeper的优点与缺陷，对于我们使用好它还是很有必要的。

Zookeeper的选举机制有2个触发条件：集群启动阶段和集群运行阶段leader挂机。这2种场景下选举的流程基本一致，我们以集群运行阶段leader挂机为例来进行说明。leader挂机以后，重新选举leader，选举的流程如下：

1，Zookeeper集群中的follower检测到leader挂机，然后把自己的状态置为LOOKING，开始进行leader选举。

2，每台服务器选举自己为leader，然后把自己的选票通过广播通知其他服务器。

3，每台服务器接收来自其他服务器的选票，并进行合法性校验，主要有两点校验，选举轮次校验和服务器的状态的校验。

4，处理选票。每台服务器都会将自己的选票与其他服务器的选票进行PK，PK的规则如下：

第一个规则：首先进行ZXID的PK，大者获胜。

第二条规则：如果ZXID相等，则进行myid的PK，大者获胜。

经过PK以后，如果当前服务器PK失败，则会把自己的选票重新投给胜者，然后把更新后的选票通过广播通知其他服务器。

5，统计选票。根据超过半数的原则，每台服务器都会统计leader的选票，如果超过半数，则结束选举。

6，更新服务器状态。follower把自己的状态更新为FOLLOWING，leader把自己的状态更新为LEADING。

OK，这就是Zookeeper的leader选举机制。经过若干轮选举以后，Zookeeper集群继续对外提供服务。由于选票PK首先比较的是ZXID，所以Zookeeper能够保证leader的数据是最新的。

kafka集群是如何保证高可用性的呢？

kafka通过Zookeeper管理集群配置、选举leader、consumer group发生变化时进行rebalance。

那么我要问了，kafka是如何选举leader的呢？

概括来说，Kafka选举leader的过程是这样的：kafka的所有broker，在Zookeeper的/controller路径下创建临时节点，成功创建的那个broker就会成为leader，其他的broker就会成为follower。

当leader挂机时，临时节点会被删除，这是其他节点通过Zookeeper的watch机制，会监听到leader的变化，然后所有的follower会再次进行leader选举。

kafka的选举其实就是创建临时节点，这和Zookeeper分布式锁的实现原理基本相同。

redis主从切换和redis集群的理解。

要注意，主从切换默认只有一个master，但是对于多个master的集群，没有主从切换的说法。

redis没有类似Zookeeper的选举机制。redis的master挂掉以后，redis集群是通过主从切换来保证高可用性的。

redis主从切换有2种方式：手动切换和自动切换。

这里我们讨论自动切换，redis主从自动切换需要哨兵模式的支持，哨兵模式简单来说就是：监控master和slave，在master出现故障的时候，自动将slave切换成master，master恢复以后，作为新master的slave对外提供服务。

准确的来说，Eureka集群中的各节点之间不存在主从关系。Eureka集群中的节点的关系是对等的，其他3种集群则都存在主从关系，这是Eureka集群的一个特色。

Eureka集群的各个server之间通过相互注册的方式来实现集群的高可用性。数据同步的方式是增量备份，这样可以保证每个server都是最新最全的数据。从而保证集群的高可用性。这样即使某个server挂了，集群还可以对外提供服务。

Eureka有一个配置项：eurekaclientfetch-register，是否从Eureka server获取注册信息。如果我们是Eureka集群，那么该项配置为true。这样Eureka server直接就可以相互注册。

OK，这篇文章只是对4种集群的选举机制进行了一个概括性的介绍，具体细节还是很复杂的。之前有文章重点分析过Zookeeper的leader选举，后续还会另起文章分析其他几种集群的选举机制，到时候我们再进行更深入的讲解。

大数据的由来

对于“大数据”（Big data）研究机构Gartner给出了这样的定义。“大数据”是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力来适应海量、高增长率和多样化的信息资产。

1

麦肯锡全球研究所给出的定义是：一种规模大到在获取、存储、管理、分析方面大大超出了传统数据库软件工具能力范围的数据集合，具有海量的数据规模、快速的数据流转、多样的数据类型和价值密度低四大特征。

大数据技术的战略意义不在于掌握庞大的数据信息，而在于对这些含有意义的数据进行专业化处理。换而言之，如果把大数据比作一种产业，那么这种产业实现盈利的关键，在于提高对数据的“加工能力”，通过“加工”实现数据的“增值”。

从技术上看，大数据与云计算的关系就像一枚硬币的正反面一样密不可分。大数据必然无法用单台的计算机进行处理，必须采用分布式架构。它的特色在于对海量数据进行分布式数据挖掘。但它必须依托云计算的分布式处理、分布式数据库和云存储、虚拟化技术。

大数据需要特殊的技术，以有效地处理大量的容忍经过时间内的数据。适用于大数据的技术，包括大规模并行处理（MPP）数据库、数据挖掘、分布式文件系统、分布式数据库、云计算平台、互联网和可扩展的存储系统。

最小的基本单位是bit，按顺序给出所有单位：bit、Byte、KB、MB、GB、TB、PB、EB、ZB、YB、BB、NB、DB。

大数据的应用领域

大数据无处不在，大数据应用于各个行业，包括金融、 汽车 、餐饮、电信、能源、体能和 娱乐 等在内的 社会 各行各业都已经融入了大数据的印迹。

制造业，利用工业大数据提升制造业水平，包括产品故障诊断与预测、分析工艺流程、改进生产工艺，优化生产过程能耗、工业供应链分析与优化、生产计划与排程。

金融行业，大数据在高频交易、社交情绪分析和信贷风险分析三大金融创新领域发挥重大作用。

汽车 行业，利用大数据和物联网技术的无人驾驶 汽车 ，在不远的未来将走入我们的日常生活。

互联网行业，借助于大数据技术，可以分析客户行为，进行商品推荐和针对性广告投放。

电信行业，利用大数据技术实现客户离网分析，及时掌握客户离网倾向，出台客户挽留措施。

能源行业，随着智能电网的发展，电力公司可以掌握海量的用户用电信息，利用大数据技术分析用户用电模式，可以改进电网运行，合理设计电力需求响应系统，确保电网运行安全。

物流行业，利用大数据优化物流网络，提高物流效率，降低物流成本。

城市管理，可以利用大数据实现智能交通、环保监测、城市规划和智能安防。

体育 娱乐 ，大数据可以帮助我们训练球队，决定投拍哪种 题财的 影视作品，以及预测比赛结果。

安全领域，政府可以利用大数据技术构建起强大的国家安全保障体系，企业可以利用大数据抵御网络攻击，警察可以借助大数据来预防犯罪。

个人生活， 大数据还可以应用于个人生活，利用与每个人相关联的“个人大数据”，分析个人生活行为习惯，为其提供更加周到的个性化服务。

大数据的价值，远远不止于此，大数据对各行各业的渗透，大大推动了 社会 生产和生活，未来必将产生重大而深远的影响。

大数据方面核心技术有哪些？

大数据技术的体系庞大且复杂，基础的技术包含数据的采集、数据预处理、分布式存储、NoSQL数据库、数据仓库、机器学习、并行计算、可视化等各种技术范畴和不同的技术层面。首先给出一个通用化的大数据处理框架，主要分为下面几个方面：数据采集与预处理、数据存储、数据清洗、数据查询分析和数据可视化。

数据采集与预处理

对于各种来源的数据，包括移动互联网数据、社交网络的数据等，这些结构化和非结构化的海量数据是零散的，也就是所谓的数据孤岛，此时的这些数据并没有什么意义，数据采集就是将这些数据写入数据仓库中，把零散的数据整合在一起，对这些数据综合起来进行分析。数据采集包括文件日志的采集、数据库日志的采集、关系型数据库的接入和应用程序的接入等。在数据量比较小的时候，可以写个定时的脚本将日志写入存储系统，但随着数据量的增长，这些方法无法提供数据安全保障，并且运维困难，需要更强壮的解决方案。

Flume NG

Flume NG作为实时日志收集系统，支持在日志系统中定制各类数据发送方，用于收集数据，同时，对数据进行简单处理，并写到各种数据接收方(比如文本，HDFS，Hbase等)。Flume NG采用的是三层架构：Agent层，Collector层和Store层，每一层均可水平拓展。其中Agent包含Source，Channel和 Sink，source用来消费(收集)数据源到channel组件中，channel作为中间临时存储，保存所有source的组件信息，sink从channel中读取数据，读取成功之后会删除channel中的信息。

NDC

Logstash

Logstash是开源的服务器端数据处理管道，能够同时从多个来源采集数据、转换数据，然后将数据发送到您最喜欢的 “存储库” 中。一般常用的存储库是Elasticsearch。Logstash 支持各种输入选择，可以在同一时间从众多常用的数据来源捕捉事件，能够以连续的流式传输方式，轻松地从您的日志、指标、Web 应用、数据存储以及各种 AWS 服务采集数据。

Sqoop

Sqoop，用来将关系型数据库和Hadoop中的数据进行相互转移的工具，可以将一个关系型数据库(例如Mysql、Oracle)中的数据导入到Hadoop(例如HDFS、Hive、Hbase)中，也可以将Hadoop(例如HDFS、Hive、Hbase)中的数据导入到关系型数据库(例如Mysql、Oracle)中。Sqoop 启用了一个 MapReduce 作业(极其容错的分布式并行计算)来执行任务。Sqoop 的另一大优势是其传输大量结构化或半结构化数据的过程是完全自动化的。

流式计算

流式计算是行业研究的一个热点，流式计算对多个高吞吐量的数据源进行实时的清洗、聚合和分析，可以对存在于社交网站、新闻等的数据信息流进行快速的处理并反馈，目前大数据流分析工具有很多，比如开源的strom，spark streaming等。

Strom集群结构是有一个主节点(nimbus)和多个工作节点(supervisor)组成的主从结构，主节点通过配置静态指定或者在运行时动态选举，nimbus与supervisor都是Storm提供的后台守护进程，之间的通信是结合Zookeeper的状态变更通知和监控通知来处理。nimbus进程的主要职责是管理、协调和监控集群上运行的topology(包括topology的发布、任务指派、事件处理时重新指派任务等)。supervisor进程等待nimbus分配任务后生成并监控worker(jvm进程)执行任务。supervisor与worker运行在不同的jvm上，如果由supervisor启动的某个worker因为错误异常退出(或被kill掉)，supervisor会尝试重新生成新的worker进程。

Zookeeper

Zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，提供数据同步服务。它的作用主要有配置管理、名字服务、分布式锁和集群管理。配置管理指的是在一个地方修改了配置，那么对这个地方的配置感兴趣的所有的都可以获得变更，省去了手动拷贝配置的繁琐，还很好的保证了数据的可靠和一致性，同时它可以通过名字来获取资源或者服务的地址等信息，可以监控集群中机器的变化，实现了类似于心跳机制的功能。

数据存储

Hadoop作为一个开源的框架，专为离线和大规模数据分析而设计，HDFS作为其核心的存储引擎，已被广泛用于数据存储。

HBase

HBase，是一个分布式的、面向列的开源数据库，可以认为是hdfs的封装，本质是数据存储、NoSQL数据库。HBase是一种Key/Value系统，部署在hdfs上，克服了hdfs在随机读写这个方面的缺点，与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。

Phoenix

Phoenix，相当于一个Java中间件，帮助开发工程师能够像使用JDBC访问关系型数据库一样访问NoSQL数据库HBase。

Yarn

Yarn是一种Hadoop资源管理器，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。Yarn由下面的几大组件构成：一个全局的资源管理器ResourceManager、ResourceManager的每个节点代理NodeManager、表示每个应用的Application以及每一个ApplicationMaster拥有多个Container在NodeManager上运行。

Mesos

Mesos是一款开源的集群管理软件，支持Hadoop、ElasticSearch、Spark、Storm 和Kafka等应用架构。

Redis

Redis是一种速度非常快的非关系数据库，可以存储键与5种不同类型的值之间的映射，可以将存储在内存的键值对数据持久化到硬盘中，使用复制特性来扩展性能，还可以使用客户端分片来扩展写性能。

Atlas

Atlas是一个位于应用程序与MySQL之间的中间件。在后端DB看来，Atlas相当于连接它的客户端，在前端应用看来，Atlas相当于一个DB。Atlas作为服务端与应用程序通讯，它实现了MySQL的客户端和服务端协议，同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节，同时为了降低MySQL负担，它还维护了连接池。Atlas启动后会创建多个线程，其中一个为主线程，其余为工作线程。主线程负责监听所有的客户端连接请求，工作线程只监听主线程的命令请求。

Kudu

Kudu是围绕Hadoop生态圈建立的存储引擎，Kudu拥有和Hadoop生态圈共同的设计理念，它运行在普通的服务器上、可分布式规模化部署、并且满足工业界的高可用要求。其设计理念为fast analytics on fast data。作为一个开源的存储引擎，可以同时提供低延迟的随机读写和高效的数据分析能力。Kudu不但提供了行级的插入、更新、删除API，同时也提供了接近Parquet性能的批量扫描操作。使用同一份存储，既可以进行随机读写，也可以满足数据分析的要求。Kudu的应用场景很广泛，比如可以进行实时的数据分析，用于数据可能会存在变化的时序数据应用等。

在数据存储过程中，涉及到的数据表都是成千上百列，包含各种复杂的Query，推荐使用列式存储方法，比如parquent,ORC等对数据进行压缩。Parquet 可以支持灵活的压缩选项，显著减少磁盘上的存储。

数据清洗

MapReduce作为Hadoop的查询引擎，用于大规模数据集的并行计算，”Map(映射)”和”Reduce(归约)”，是它的主要思想。它极大的方便了编程人员在不会分布式并行编程的情况下，将自己的程序运行在分布式系统中。

随着业务数据量的增多，需要进行训练和清洗的数据会变得越来越复杂，这个时候就需要任务调度系统，比如oozie或者azkaban，对关键任务进行调度和监控。

Oozie

Oozie是用于Hadoop平台的一种工作流调度引擎，提供了RESTful API接口来接受用户的提交请求(提交工作流作业)，当提交了workflow后，由工作流引擎负责workflow的执行以及状态的转换。用户在HDFS上部署好作业(MR作业)，然后向Oozie提交Workflow，Oozie以异步方式将作业(MR作业)提交给Hadoop。这也是为什么当调用Oozie 的RESTful接口提交作业之后能立即返回一个JobId的原因，用户程序不必等待作业执行完成(因为有些大作业可能会执行很久(几个小时甚至几天))。Oozie在后台以异步方式，再将workflow对应的Action提交给hadoop执行。

Azkaban

Azkaban也是一种工作流的控制引擎，可以用来解决有多个hadoop或者spark等离线计算任务之间的依赖关系问题。azkaban主要是由三部分构成：Relational Database，Azkaban Web Server和Azkaban Executor Server。azkaban将大多数的状态信息都保存在MySQL中，Azkaban Web Server提供了Web UI，是azkaban主要的管理者，包括project的管理、认证、调度以及对工作流执行过程中的监控等;Azkaban Executor Server用来调度工作流和任务，记录工作流或者任务的日志。

流计算任务的处理平台Sloth，是网易首个自研流计算平台，旨在解决公司内各产品日益增长的流计算需求。作为一个计算服务平台，其特点是易用、实时、可靠，为用户节省技术方面(开发、运维)的投入，帮助用户专注于解决产品本身的流计算需求

数据查询分析

Hive

Hive的核心工作就是把SQL语句翻译成MR程序，可以将结构化的数据映射为一张数据库表，并提供 HQL(Hive SQL)查询功能。Hive本身不存储和计算数据，它完全依赖于HDFS和MapReduce。可以将Hive理解为一个客户端工具，将SQL操作转换为相应的MapReduce jobs，然后在hadoop上面运行。Hive支持标准的SQL语法，免去了用户编写MapReduce程序的过程，它的出现可以让那些精通SQL技能、但是不熟悉MapReduce 、编程能力较弱与不擅长Java语言的用户能够在HDFS大规模数据集上很方便地利用SQL 语言查询、汇总、分析数据。

Hive是为大数据批量处理而生的，Hive的出现解决了传统的关系型数据库(MySql、Oracle)在大数据处理上的瓶颈 。Hive 将执行计划分成map->shuffle->reduce->map->shuffle->reduce…的模型。如果一个Query会被编译成多轮MapReduce，则会有更多的写中间结果。由于MapReduce执行框架本身的特点，过多的中间过程会增加整个Query的执行时间。在Hive的运行过程中，用户只需要创建表，导入数据，编写SQL分析语句即可。剩下的过程由Hive框架自动的完成。

Impala

Impala是对Hive的一个补充，可以实现高效的SQL查询。使用Impala来实现SQL on Hadoop，用来进行大数据实时查询分析。通过熟悉的传统关系型数据库的SQL风格来操作大数据，同时数据也是可以存储到HDFS和HBase中的。Impala没有再使用缓慢的Hive+MapReduce批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎(由Query Planner、Query Coordinator和Query Exec Engine三部分组成)，可以直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据，从而大大降低了延迟。Impala将整个查询分成一执行计划树，而不是一连串的MapReduce任务，相比Hive没了MapReduce启动时间。

Hive 适合于长时间的批处理查询分析，而Impala适合于实时交互式SQL查询，Impala给数据人员提供了快速实验，验证想法的大数据分析工具，可以先使用Hive进行数据转换处理，之后使用Impala在Hive处理好后的数据集上进行快速的数据分析。总的来说：Impala把执行计划表现为一棵完整的执行计划树，可以更自然地分发执行计划到各个Impalad执行查询，而不用像Hive那样把它组合成管道型的map->reduce模式，以此保证Impala有更好的并发性和避免不必要的中间sort与shuffle。但是Impala不支持UDF，能处理的问题有一定的限制。

Spark

Spark拥有Hadoop MapReduce所具有的特点，它将Job中间输出结果保存在内存中，从而不需要读取HDFS。Spark 启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。Spark 是在 Scala 语言中实现的，它将 Scala 用作其应用程序框架。与 Hadoop 不同，Spark 和 Scala 能够紧密集成，其中的 Scala 可以像操作本地集合对象一样轻松地操作分布式数据集。

Nutch

Nutch 是一个开源Java 实现的搜索引擎。它提供了我们运行自己的搜索引擎所需的全部工具，包括全文搜索和Web爬虫。

Solr

Solr用Java编写、运行在Servlet容器(如Apache Tomcat或Jetty)的一个独立的企业级搜索应用的全文搜索服务器。它对外提供类似于Web-service的API接口，用户可以通过http请求，向搜索引擎服务器提交一定格式的XML文件，生成索引;也可以通过Http Get操作提出查找请求，并得到XML格式的返回结果。

Elasticsearch

Elasticsearch是一个开源的全文搜索引擎，基于Lucene的搜索服务器，可以快速的储存、搜索和分析海量的数据。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。

还涉及到一些机器学习语言，比如，Mahout主要目标是创建一些可伸缩的机器学习算法，供开发人员在Apache的许可下免费使用;深度学习框架Caffe以及使用数据流图进行数值计算的开源软件库TensorFlow等，常用的机器学习算法比如，贝叶斯、逻辑回归、决策树、神经网络、协同过滤等。

数据可视化

对接一些BI平台，将分析得到的数据进行可视化，用于指导决策服务。主流的BI平台比如，国外的敏捷BI Tableau、Qlikview、PowrerBI等，国内的SmallBI和新兴的网易有数等。

在上面的每一个阶段，保障数据的安全是不可忽视的问题。

基于网络身份认证的协议Kerberos，用来在非安全网络中，对个人通信以安全的手段进行身份认证，它允许某实体在非安全网络环境下通信，向另一个实体以一种安全的方式证明自己的身份。

控制权限的ranger是一个Hadoop集群权限框架，提供操作、监控、管理复杂的数据权限，它提供一个集中的管理机制，管理基于yarn的Hadoop生态圈的所有数据权限。可以对Hadoop生态的组件如Hive，Hbase进行细粒度的数据访问控制。通过操作Ranger控制台，管理员可以轻松的通过配置策略来控制用户访问HDFS文件夹、HDFS文件、数据库、表、字段权限。这些策略可以为不同的用户和组来设置，同时权限可与hadoop无缝对接。

简单说有三大核心技术：拿数据，算数据，卖数据。

用数据库快照就能实现啊

Oracle快照原理及实现总结

Oracle数据库的快照是一个表，它包含有对一个本地或远程数据库上一个或多个表或视图的查询的结果。对于中大型数据库，业务数据库里所有的数据同步到另外一个处理服务器上最佳的选择还是使用SnapShot方式，即快照的方式。

由于工作需要，今天需要将业务数据库里所有的数据同步到另外一个处理服务器上。在做方案的时候，想了很多方法，当然最快的办法还是使用物理热备的方式。

但是我个人认为如果对于中大型数据库(我们的数据库有300G左右)最佳的选择还是使用SnapShot方式，即快照的方式。

Oracle数据库的快照是一个表，它包含有对一个本地或远程数据库上一个或多个表或视图的查询的结果。也就是说快照根本的原理就是将本地或远程数据库上的一个查询结果保存在一个表中。

以下是我建立的Snapshot，目的是从业务数据库上将数据Copy到处理数据库上，是不同的两个服务器之间对数据copy。

第一步：在处理服务器上的Oracle终端，建立database link，业务数据库服务器SID为TEST

create database link TEST_DBLINKUSORACLECOM

connect to AMICOS identified by AMICOS

using 'test';

第二步：在业务数据库上对应的表建立快照日志

Create snapshot log on A_Table;

第三步：建立Snapshot 快照名称为：Test_SnapShot

Create snapshot Test_SnapShot

REFRESH COMPLETE START WITH SYSDATE NEXT SYSDATE+1/24

as select from A_Table@TEST_DBLINK

说明：REFRESH是刷新方法

刷新方式有：COMPLETE和FAST两种，而START WITH是说明开始执行的时间。

Next是下次执行的时间

而AS以后是构成快照的查询方法。

相关的方法：

更改快照

ALTER SNAPSHOT Test_SnapShot

REFRESH COMPLETE START WITH SYSDATE NEXT SYSDATE+1/2;

手动刷新快照 在命令界面执行：

EXEC DBMS_SNAPSHOTREFRESH('Test_SnapShot ','C');

第一个参数是要刷新的快照名

第二个参数是刷新的方式，F----FAST, C---COMPLETE

查看快照最后刷新的日期

SELECT NAME,LAST_REFRESH

FROM ALL_SNAPSHOT_REFRESH_TIMES;

最后非常的方案：

1：为需要做Snapshot的表建立Snapshot日志

create snapshot log on t1 with rowid; 这里使用ROWID建立日记的参数

2：采用Fast的方式建立快照，使用rowid做为参考参数

create snapshot fb_test_b refresh fast with rowid start with sysdate next sysdate+1/1440 as select from fb_test_b@my_dblink;

最好能按照rowid来建立快照。要不然就必须要为表建立Primary Key。

http://blogsinacomcn/s/blog_59a515190100ayouhtml