Always on环境的建立，网上资料很多，主要是windows集群的建立以及Sql Server Always on的建立，略

容易忽略的是Sql server账号同步问题（Always on能实现数据库内部的同步，但是没法实现instance级别的同步，比如job、账号等）

下面来说说几种解决方式：

1. SQL账号采用域账号，让IIS运行于域账号下
   1. 如果现状下的本地sql账号较少的话还好，否则推行困难，而且还要加入域
2. SQL账号采用域账号，让IIS运行于本地账号下，但是在web.config或machine.config中配置模拟账号
   1. 基本上与第一种相同
3. SQL账号采用本地账号，客户端连接字符串采用user/pwd方式连接，并且在windows集群中增加一个通用服务，目的是当主sql server服务迁移到另外一台服务器后执行一段sql脚本，这段脚本的作用是重新map本地sql账号与db的权限关系
   1. 需要与集群的通用服务一起考虑
   2. 需要自己写脚本，下载
   3. 麻烦
4. SQL账号采用本地账号+域账号公用方式，域账号权限关联到数据库，并且设置本地sql账号拥有模拟域账号权限，同时客户端使用user/pwd方式连接，并且还需要修改框架：让每次执行sql操作时先执行切换上下文用户：EXECUTE AS LOGIN 'domain\user1'
   1. 麻烦点转移到了框架级别：C#的SqlHelper等需要注入一行SQL来模拟域账号
   2. 配置也麻烦
5. SQL账号采用本地账号，但是账号的建立不是直接建立，步骤：从源SQL服务器上导出带SID的脚本，然后在Always on数据库中导入带SID的脚本
   1. 初次时运行
   2. 增加user时，也需要运行
   3. 无需域账号
   4. 对客户端没影响
   5. 这里的脚本用法说明
6. 使用Always on插件，不成熟，也不清楚能否自动同步
   1. sqlskills.com插件
      1. 能实现user、job、User-defined Server Roles的同步
   2. 都是第三方的，不敢用
7. 使用Contained Database，这种数据库能将login user/pwd包含于db级别中，但是连接的时候必须指定具体数据库名，否则无法建立连接
   1. sql 2012开始支持包含的数据库
   2. 如果数据库不多，这种最好
   3. 缺点是如果每个db的账号多了，同步、维护这些账号比较麻烦

性能方面的思考：

• 采用了Always on后，所有的提交行为都由Master SQL来处理，因此Master的CPU占用很高（考虑到1台master，5台slave, 并且设置了3台提交成功才算整体的提交成功），而Slave的CPU几乎闲置。因此最好是用读写分离来连接侦听器IP（写入）、以及读取IP（哈西算法）
• 主要功能是HA+中等的性能考虑
• 不适用于非常高并发的场景（还是得拆分库，或者写DAL）