“见证服务器-伙伴仲裁”包含见证服务器和一个伙伴。
“伙伴-伙伴仲裁”包含伙伴双方。
下图显示了这三种类型的仲裁。只要当前的主体服务器具有仲裁，它就拥有主体服务器的角色并可继续操作数据库，除非数据库所有者执行手动故障转移。如果主体服务器失去仲裁，它将停止操作数据库。仅当主体服务器失去仲裁时，才会发生自动故障转移，这确保它不再操作数据库。 断开连接的服务器实例将保存其在会话中的最新角色。通常，断开连接的服务器实例将在重新启动并重新获得仲裁时重新连接到会话。 重要提示： 只有在需要使用具有自动故障转移功能的高安全性模式时，才应设置见证服务器。在高性能模式下，由于从不需要见证服务器，因此极力建议将 WITNESS 属性设置为 OFF。有关见证服务器如何影响高性能模式会话中数据库可用性的信息，请参阅异步数据库镜像（高性能模式）。
高安全性模式会话中的仲裁在高安全性模式下，仲裁通过提供上下文来允许自动故障转移，在这个上下文中，具有仲裁的服务器实例可以判定哪个伙伴拥有主体服务器角色。主体服务器如果具有仲裁就可以操作数据库。如果在同步的镜像服务器和见证服务器仍具有仲裁的时候主体服务器丢失仲裁，则会发生自动故障转移。 高安全性模式的仲裁方案包括： 包含伙伴双方和见证服务器的“完全仲裁”。
所有三个服务器实例通常都参与三方仲裁，这称为“完全仲裁”。使用完全仲裁，主体服务器和镜像服务器一直执行其各自的角色（除非发生手动故障转移）。
包含见证服务器和一个伙伴的“见证服务器-伙伴仲裁”。
如果因为其中一个伙伴丢失而中断伙伴之间的网络连接，则可能发生下列两种情况：
镜像服务器丢失，主体服务器和见证服务器仍具有仲裁。
在这种情况下，主体服务器将数据库设置为 DISCONNECTED，并在镜像处于 SUSPENDED 状态的情况下运行。（因为数据库当前尚未镜像，所以这称为“公开运行”。）镜像服务器重新联接会话时，它将作为镜像服务器重新获得仲裁，并开始与其数据库副本重新同步。
主体服务器丢失，见证服务器和镜像服务器仍具有仲裁。
在这种情况下，发生自动故障转移。有关详细信息，请参阅自动故障转移。
两个伙伴与见证服务器之间保持连接时，故障转移伙伴之间的网络连接很少会断开。在这种情况下，存在两个分开的见证服务器-伙伴仲裁，见证服务器作为连接。见证服务器将通知镜像服务器：主体服务器仍在连接状态。因此，不会出现自动故障转移。而镜像服务器将保留镜像角色并等待重新连接到主体服务器。如果此时重做队列包含日志记录，镜像服务器将继续前滚镜像数据库。重新连接后，镜像服务器将与镜像数据库重新同步。
包含伙伴双方的“伙伴-伙伴仲裁”。
只要伙伴仍具有仲裁，数据库就会继续处于 SYNCHRONIZED 状态，手动故障转移就可以进行。如果没有见证服务器，则无法使用自动故障转移功能；但当见证服务器重新获得仲裁时，会话将恢复正常操作，并重新支持自动故障转移。
会话丢失仲裁。
如果所有服务器实例此间的连接断开，就称为会话“丢失仲裁”。当服务器实例恢复彼此间的连接时，它们将重新获得相互仲裁。
如果主体服务器与其他服务器实例中的任何一个重新连接，即可使用数据库。
如果主体服务器依旧断开连接，但镜像服务器和见证服务器恢复了相互之间的连接，则不能进行自动故障转移，因为可能会丢失数据。因此，在主体服务器重新加入会话之前，依旧不能使用数据库。
当三个服务器实例全部恢复连接时，将重新获得完全仲裁，会话将恢复其正常操作。
重要提示： 当会话具有伙伴-伙伴仲裁时，如果任一伙伴失去仲裁，会话将失去仲裁。因此，如果您希望见证服务器在很长一段时间内保持断开，我们建议您暂时将见证服务器从会话中删除。如果删除见证服务器，则不再需要仲裁。然后，如果镜像服务器断开连接，则主体服务器可以继续操作数据库。有关如何添加或删除见证服务器的信息，请参阅数据库镜像见证服务器。
仲裁如何影响数据库可用性下图显示的是见证服务器与伙伴如何相互作用，以确保在给定时间内，只有一个伙伴拥有主体服务器角色并且只有当前主体服务器才能使其数据库在线。两个方案都以完全仲裁（Partner_A 具有主体角色，Partner_B 具有镜像角色）为起点。方案1 显示的是：在原始主体服务器 (Partner_A) 失败后，见证服务器和镜像服务器如何同时认定主体 Partner_A 不再可用并构造仲裁。然后，镜像服务器 Partner_B 承担主体角色。出现自动故障转移时，Partner_B 使其数据库副本在线。然后 Partner_B 出现故障，数据库离线。随后，先前的主体服务器 Partner_A 重新连接到见证服务器重新获取仲裁，但是通过与见证服务器通信，Partner_A 获知不能使其数据库副本在线，因为 Partner_B 现在拥有主体角色。当 Partner_B 重新加入会话时，将使数据库恢复在线。在方案 2 中，见证服务器丢失仲裁，而伙伴 Partner_A 和Partner_B 彼此保留仲裁，数据库保持在线。然后，伙伴们也失去其仲裁，数据库处于离线状态。随后，主体服务器 Partner_A 重新连接到见证服务器以重新获取仲裁。见证服务器确认 Partner_A 仍拥有主体角色，并且 Partner_A 使数据库恢复在线。
P2P的问题很复杂,关于链路传输有如下几点供参考.1) 首先作为P2P的营运商，可以多设几台P2P种子服务器，分布在不同的网段中。比如：北方网通设一台(组)，南方电信设一台(组)，种子的内容是一样的。种子服务器多了，可以降低优化算法的难度。
(2) 种子服务器和普通节点的优先级：种子服务器的优先级总数低于普通节点的，如果普通节点的速度快了，就减少从种子服务器获取的数据量。
(3) 全球IP地址表。P2P节点仲裁服务器中，应该有一个全球IP地址表，分中国大陆、香港、台湾、北美、欧洲、澳洲、其它。中国大陆先按照营运商分：电信、网通、铁通、联通、教育网等，再按照省份分类。(网上有下载，可以整理)
(4) 高速网段表。在P2P访问中，节点动态地将速度快的其它节点IP地址传回服务器，服务器根据全球IP地址表算出网段，以网段-网段的方式记录在数据库中。
(5) 当一个新用户连入节点时，在全球IP地址表中找到最近的节点，按照比例依次分配最快网段的节点最近的节点差一个级别的稍近的节点随机节点以及种子服务器。
(6) P2P在数据传送中，可以将30秒数据文件作为1块数据包数据包中按照每16KB作为一个数据块。每个时间段(如2秒)，本节点向其它节点交换一下数据块的传送情况，然后计算一下数据包中每个数据块的拥有率，优先传送拥有率低的数据块。在拥有率相当的情况下，随机选择。
(7) 在数据交换中，对于传送慢的节点，定期剔除，然后问节点仲裁服务器要新的节点。
(8) 如果数据包中小于10%的数据块没有传送完毕，在时间充足的情况下，对于余下的数据块，可以同一个数据块向多个节点请求。
(9) 节点仲裁服务器也会将新的P2P节点强行加载到另一个节点上，但不能超过节点最大连接数。
下面解释一下上面的文章中没有提及或者说我觉得比较欠缺的地方.
私有地址/端口和公有地址/端口:我们知道,现在大部分网络采用的都是NAPT(Network Address/Port Translator)了,这个东东的作用是一个对外的对话在经过NAT之后IP地址和端口号都会被改写,在这里把一次会话中客户自己认为在使用的IP地址和端口号成为私有地址/端口,而把经过NAPT之后被改写的IP地址和端口号称为公有地址/端口.或者可以这么理解,私有地址/端口是你家里人对你的昵称而公有地址/端口则是你真正对外公开的名字.如何获得用户的私用地址/端口号,这个很简单了,而要得到公有地址/端口号就要在连接上另一台机器之后由那台机器看到的IP地址和端口号来表示.
如果明白了上面的东西,下面进入我们的代码,在这里解释一下关键部分的实现:
客户端首先得到自己的私有地址/终端,然后向server端发送登陆请求,server端在得到这个请求之后就可以知道这个client端的公有地址/终端,server会为每一个登陆的client保存它们的私有地址/端口和公有地址/端口.
OK,下面开始关键的打洞流程.假设client A要向client B对话,但是A不知道B的地址,即使知道根据NAT的原理这个对话在第一次会被拒绝,因为client B的NAT认为这是一个从没有过的外部发来的请求.这个时候,A如果发现自己没有保存B的地址,或者说发送给B的会话请求失败了,它会要求server端让B向A打一个洞,这个B->A的会话意义在于它使NAT B认为A的地址/端口是可以通过的地址/端口,这样A再向B发送对话的时候就不会再被NAT B拒绝了.打一个比方来说明打洞的过程,A想来B家做客,但是遭到了B的管家NAT B的拒绝,理由是:我从来没有听我家B提过你的名字,这时A找到了A,B都认识的朋友server,要求server给B报一个信,让B去跟管家说A是我的朋友,于是,B跟管家NAT B说,A是我认识的朋友,这样A的访问请求就不会再被管家NAT B所拒绝了.简而言之,UDP打洞就是一个通过server保存下来的地址使得彼此之间能够直接通信的过程,server只管帮助建立连接,在建立间接之后就不再介入了.
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）