SQL 复制和均衡使用

lanxi256

　　复制
　　复制是一个开发范畴的技术，但是也可以像日志传送一样作为高可用技术的一个后备选项。
　　一、复制的拓扑

　　二、复制的冲突处理
　　在执行复制时，源数据库与目标数据库都是敞开式的，因此在写入记录时可能发生冲突。为解决冲突，常用的方法有以下两种：
　　1. 合并复制
　　合并复制允许存在冲突。当冲突发生时，合并复制将比较这些记录的时间戳，仅保留最新的记录（时间戳最后的那条记录）。
　　2. 专用的写入区
　　一种方式是将read请求随机发送给任意一个数据库，而将write指定只写入发布服务器。
　　另一种方式是设置专用的写入区，所有写入被事先隔离，从而避免冲突。例如，一个table被分割成3个table，分别保存3个分公司的数据。
　　三、复制在负载均衡中的应用
　　在一些稍微容忍数据同步存在延迟的场合，复制可以作为负载均衡的手段。这种实现方法，其实质是通过复制实现分布式数据库。
　　例如：工厂的流水线生产过程中的数据采集，可以根据车间与流水线的分布情况，部署多套SQL Server，然后通过复制实现数据的分布式存储、查询。

　　均衡
　　一、服务的类型
　　1. 无状态的服务（stateless service）
　　对单次请求的处理，不依赖其他请求。
　　处理一次请求所需的全部信息都包含在这个请求里或者可以从外部获取（例如，数据库），服务本身不存储任何信息。
　　IIS（Web服务）可以设计成无状态的服务，可以实现池化（负载均衡），从而横向扩展。
　　2. 有状态的服务（stateful service）
　　会在自身保存一些数据。
　　先后的请求是有关联的，通常用于实现事务。
　　数据库服务一般是有状态的服务。
　　二、区别
　　1. 高可用
　　高可用是针对“有状态”的服务，其目标是为了减少硬件或软件故障造成的影响，保持业务的连续性，从而将用户可以察觉到的停机时间送到最少。

　　2. 负载平衡
　　负载平衡是针对“无状态”的服务，其目标是通过对服务的“池化”（多个服务，形成一个“池”）使客户端的请求被分摊到多个服务。

　　三、联系
　　高可用技术中兼具一部分的负载分摊功能。例如，AlwaysOn可用性组的辅助副本可以提供只读访问，从而分摊一部分的只读请求给报表等应用程序。
　　负载均衡给客户端的感觉就像高可用技术一样，保持了业务的连续性。例如，客户端连接到IIS池，池中的某台IIS服务器发生故障后，客户端的连接被重定向到池中的其它IIS服务器。
　　数据库产品几乎都没有宣称自己的“产品功能”（feature）中包含有负载均衡、读写分离等技术特性。对于SQL Server来说，负载分摊、读写分享应当作为一个解决方案（Solution）来实现。例如，指定一个只读副本专门用来查询，应当从业务需求角度事先进行设计。
　　四、SQL Server 负载分离示例
　　生产环境通常在设计时就要考虑到未来的数据增长，并且预留负载分离的接口。
　　以下案例显示了一家OTA企业在遇到数据库规模迅速增长时，依次实施了三期部署。
　　第一期：数据库将所有数据都存放在一台服务器。

　　第二期：进行了负载分离，将原先的单台服务器根据业务类型进行分离。

　　第三期：继续进行分离。