数据库大数据处理---复制（SQLServer)
复制?
复制起初并不是用于作为高可用性功能而设计的，实际上复制的概念就像其名称一样，用于复制数据。比如将某个库中的数据“复制”到另一个库，到另一个实例中，由OLTP复制到OLAP环境中，由某数据中心复制到位于地球另一侧的另外一个数据中心中。因此，由于复制所提供的功能，复制可用被用来剥离负载，用于做数据冗余，直至把复制用于作为高可用性拓扑中的一个环节。（切记，复制的功能可以被用做高可用性，而不是复制是高可用性功能。）
不同于其它SQL Server可以被用作高可用性的特性，复制可以做的非常灵活。您可以复制某些列，过滤某些行，复制表中的部分数据。复制是基于数据库对象的，而不像日志传送、镜像、集群、AlawysOn等需要以库和实例作为基本对象，此外更新的订阅还允许订阅端合并数据，没有任何一种其它的高可用性技术能做到这一点。
复制的基本概念
关于复制的基本概念，我在之前已经有一篇文章进行了阐述：http://www.cnblogs.com/CareySon/archive/2012/06/20/IntroductToSQLServerReplicationPart1.html。但这里我还是想再次对基本的概念进行阐述。
复制的模型参考的杂志发布的模型，由出版社发型杂志，由经销商分发杂志，由订户来消费这些杂志。这个概念看似简单，但可以归结出复制下面一些特点：
- 杂志社是否大，比如说全国发行的杂志需要总代理（单独分发服务器），而一个机关内部发型的文章直接在杂志社（发布服务器和分发服务器在同一台服务器）消费
- 是由订户去经销商自取（订阅服务器去分发服务器请求订阅），还是由经销商送到订户那里（分发服务器推送到订阅服务器）
- 是一次性订阅一本书（快照发布），还是每当有新的文章后就发给订户（事务订阅）
- 杂志会首先到达经销商那里，然后再给订户（数据会在分发服务器那里转存，一定时间过后，则丢弃暂存的数据）
- 经销商保留多久就处理掉过期期刊（分发服务器数据保留时间）
- 出版社不可能仅仅将杂志发布给某个订户看，而是会给多个订户看（一个发布可以允许多个订阅，但要考虑性能问题）
- 从出版社发型文章到经销商再到订户需要一定时间（发布服务器到分发服务器到订阅服务器可能存在5秒10秒15秒等延迟，因此事务复制不能用于做热备，只能用于做冷备和暖备）
- 出版社到经销商到订户中间可能存在杂志丢失的问题，原因可能是由于出版社的问题，快递的问题，经销商的问题，由于环节比较多，不太容易找出问题（复制相对难以调错）
复制的几种类型
下面来简单介绍几种复制类型在高可用性中可以作为的角色。
快照发布
快照复制本质上就是通过快照目录(共享目录)共享一堆文件(因为需要多个订阅端共享)，在早起版本,快照复制仅仅是一个文件，而相对更新的版本，复制会将文件分为多个。快照就是文章某一时间点发布的Article
是一种创建报表数据库的好方式。
对于快照复制的简单概念，如图1所示。
图1.快照发布的概念
事务复制
在初始化订阅后（可通过快照初始化，或者由备份初始化，请参阅：http://www.sql-server-performance.com/2012/replication-without-creating-snapshot/），由发布服务器上将需要被复制的部分的日志标记为复制.由分发服务器的log reader agent来读取发布服务器上这部分日志,当分发服务器将所有的日志传递给订阅服务器，则发布服务器上的日志就可以清空了
通过原理不难看出,每个数据库只能有一个log reader agent,因此数据库中发布内容过多，或者重复发布，则会产生严重的性能问题。此外log reader agent需要读取所有的日志，不会有任何奇迹发生来跳过那些没有被标记为复制的日志.因此当对复制的文章进行了筛选的话，会影响性能(这里可不像索引,设置了筛选条件能够提高查询速度)。
性能因素取决于很多地方,发布服务器的速度，更改频率，分发服务器的速度等等。
通常可以用于做实时报表，虽然会有些许延迟，但效果非常好。
合并复制
合并复制可以实现数据的多处更新，当更新冲突时，可以设置规则，比如北京和上海的服务器，我可以设置北京的服务器永远赢。
Peer-To-Peer复制
P2P复制是基于事务日志之上的一种复制类型，他允许每个节点都成为对等的实体。因此可以非常好的用于HA和负载均衡，即使某一个节点宕机，完全不会影响其它节点的可用性。
自SQL Server 2012以来，PeerToPeer复制已经成为了一种单独的发布类型。
一个Peer-To-Peer的简单例子如图2所示。
图2.对等复制
从图2中可以看出，节点A、B、C、D分别对同一份数据保存相同的副本，并且每个节点上都可以进行读写操作。我们可以假设每个节点都是在不同的地理位置，因此假如说节点A宕机，则可以直接将应用程序连接字符串重定向到其它节点，实现了高可用性。从图2中还可以看出，对于任一节点我们都可以进行读写操作，因此实现了负载均衡的效果。此外，NodeB进一步将数据发布到只读服务器上，进一步实现了读写分离。
因此，这种方式具有极大的灵活性，和其它高可用性技术结合可以实现多种数据库拓扑。
在SQL Server 2008之后的版本，当遇见数据更新冲突时，可以通过冲突查看器进行查看并解决冲突，还可以在数据更新冲突出现后，进行报警。
为什么选用复制
每一种高可用性技术都有其自身的优点和缺陷，如果某种技术相较与其它技术只有有点，没有缺陷，那”其它技术“一定会被淘汰。
相比较其它高可用性技术而言，复制有如下好处：
- 复制是对象级别，您可以仅复制您需要复制的内容
- 复制可以工作在简单恢复模式下。
- 您可以拥有无限多个订阅（日志传送也可以实现，但要考虑到网络带宽和性能问题，通常来说，订阅数量稍微多一点就要考虑请求订阅，将Distribution Agent的负载OffLoad到订阅服务器）
- 复制允许在高可用的另一端（也就是用于冗余的一端）进行更新，没有其它高可用性技术可以做到这一点
- 在故障转移的时候，不需要Redo或Rollback日志，只需要将应用重定向到仍然在线的节点
但同样，复制也有其自身局限性，比如：
- 复制建立、调错都相对比较复杂
- 复制是对象级别（没错，这一点既可以是优势，同样也是劣势，基于不同的场景）
- 分发库上不能建立镜像，因此分发库有可能成为Single-Point-Of-Failure
- 复制很容易影响发布服务器的性能
- 不能进行热备，这意味着就不能进行故障检测和故障排除
- 对于复制来说，故障转移容易，想转移回来就比较麻烦，因此这种情况下可以考虑P2P复制
但不得不说，复制的确是非常的强大，套用京东“首席DB Replicationor(自造词)”陈璟的话说就是：“想复制什么复制什么，想复制多远复制多远，想怎么复制就怎么复制，想复制的多复杂就多复杂”，同时结合其它技术可以实现很多有意思的拓扑，比如图3（同样来自陈璟同学）。
图3.利用复制分发写数据，同时实现高可用性
通过图3这种方式，分发了写压力，同时相同的读库实现了负载均衡以及高可用性，当某个读库宕机后，会有足够的时间进行修复。
