读写分离死锁解决方案、事务发布死锁解决方案、发布订阅死锁解决方案

前言：

        因为网站访问压力的问题，综合分析各类因素后结合实际状况，采用数据库读写分离模式来解决当前问题。实际方案中采用“事务发布”模式实现主数据库和只读数据库的同步，其中：

　　　　发布服务器1台：sql2008，推送订阅模式

　　　　订阅服务器2台：sql2008

问题：

        以上方案后实施后，数据同步正常，但从日志中发现了死锁状况。错误提示如：事务(进程 ID *)与另外一个进程被死锁在 锁 资源上，而且已被选做死锁牺牲品。请从新运行该事务。

查询一些资料后，肯定是数据同步的同时资源被锁，同时用户访问页面请求，致使死锁产生，按照事务优先级，应用程序产生死锁。

解决方法：

        找到大体思路后，查询了一些资料，大部分资料显示是死锁如何产生，若是跟踪日志，而后根据日志优化查询等方向，尝试一些方案后死锁减小，但并无完全解决，最后转换思路，从项目实际状况来看，主要是资讯信息的查询，对查询结果的安全性要求相对不高，因此能够接受“脏”数据的状况，在某种状况下又能提高查询的性能，因而在一些查询频繁和数据量比较大的几个表的select语句中加入with(nolock)，死锁问题完全解决。

 

建议：

        处理一个数据库死锁的异常时候，其中一个建议就是使用 NOLOCK 或者 READPAST，对于非银行等严格要求事务的行业，搜索记录中出现或者不出现某条记录，都是在可容忍范围内，因此碰到死锁，应该首先考虑，咱们业务逻辑是否能容忍出现或者不出现某些记录，而不是寻求对双方都加锁条件下如何解锁的问题。

NOLOCK 和 READPAST 都是处理查询、插入、删除等操做时候，如何应对锁住的数据记录。可是这时候必定要注意NOLOCK 和 READPAST的局限性，确认你的业务逻辑能够容忍这些记录的出现或者不出现： 
简单来讲：

NOLOCK 可能把没有提交事务的数据也显示出来．

READPAST 会把被锁住的行不显示出来 

不使用 NOLOCK 和 READPAST ，在 Select 操做时候则有可能报错误：事务(进程 ID **)与另外一个进程被死锁在 锁 资源上，而且已被选做死锁牺牲品。 

 

作此记录，但愿给遇到一样的问题的朋友一些帮助。