一、开篇

在进行配置只读路由的时候，需要进行配置可用性组中的可用性副本，如下如所示：

每一项都是啥意思可以看看这个链接

https://msdn.microsoft.com/zh-cn/library/hh213002(v=sql.120).aspx

1. 在“可用性副本属性”对话框中，可以更改主角色和辅助角色的连接访问设置，如下所示：

   • 对于辅助角色，从“可读取辅助角色”下拉列表中选择一个新值，如下所示：

     否

     不允许与此副本的辅助数据库的用户连接。它们不可用于读访问。这是默认设置。

     仅读意向

     仅允许与此副本的辅助数据库的只读连接。辅助数据库全都可用于读访问。

     是

     允许与此副本的辅助数据库的所有连接，但仅限读访问。辅助数据库全都可用于读访问。

   • 对于主角色，从“主角色中的连接”下拉列表中选择一个新值，如下所示：

     允许所有连接

     主副本中的数据库允许所有连接。这是默认设置。

     允许读/写连接

     在 Application Intent 属性设置为 ReadWrite 或者未设置 Application Intent 连接属性时，将允许连接。不允许 Application Intent 连接属性设置为 ReadOnly 的连接。这可帮助阻止客户错误地将读意向工作负荷连接到主副本。有关 Application Intent 连接属性的详细信息，请参阅将连接字符串关键字用于 SQL Server Native Client。

看完之后几个地方很暧昧：

1.什么是“仅读意向”？

2.啥是“主角色中的连接”和“可读辅助副本”，它们都是做什么的？有啥联系？

特别对于“主角色中的连接”和“可读辅助副本”两个选项的解释，让人匪夷所思，扑朔迷离，看了网友的一些文章，基本都是配置完解释一下，但是也没讲清楚，不同的配置可能出现什么现象， 

于是乎我有点较真了，有时候我较真起来，都吓到了我自己，囧！！！

分析一下： 

首先：我们知道副本分为“主副本”和“辅助副本”，对应的就是上面的“主角色”和“辅助角色”，并且“主角色”只有一个

其次：像我图中的两个副本，他们的配置是一样的，是为了保证，当主副本和辅助副本因为故障切换之后，能够依然保证像故障前一样工作。

最后：我的理解是作为主角色的时候，副本的“可读辅助副本”是不生效的，而作为辅助角色时候“主角色中的连接”也是不生效的。

那么下面我就来具体看看，当只有两个副本时候，他们的不同组合会产生什么样的效果。

二、测试

1.环境呢依然是上一篇的环境：http://www.cnblogs.com/dcz2015/p/5444438.html

2.列出需要测试的观点：（测试图有点多，可以直接略过看结果和结论）

测试1：

配置：

结果：

测试2：

配置：

结果：

测试3：

配置：

结果：

测试4：

配置：

结果：

测试5：

配置：

写数据库：

读数据库：

结果：写数据库会路由到辅助副本，辅助副本是只读的，所以抛出异常

测试6：

配置：

结果：

测试7：

配置：

结果：

测试8：

配置：

结果：

测试9：

配置：

结果：

测试10：

配置：

结果：

测试11：

配置：

结果：

写操作：

读操作：

测试12：

配置：

结果：

写操作：

读操作：

三、总结 

经过上面的12次测试，进行一下总结：

结论一：客户端配置ApplicationIntent=ReadOnly;启用只读路由功能，所有的请求先交给辅助副本来处理

结论二：客户端不配置ApplicationIntent=ReadOnly;那么读和写请求处理，都是主副本进行处理的，如1、2、3、7、8、9

结论三：在4中，主副本处理只读请求先交给辅助路由，因为所有的辅助副本都是不可写的，所以再由自己来处理只读路由

　　　　在10中，所有的辅助副本都是不可写，但是主副本又不处理ReadOnly的请求，所以就异常了