开发笔记 第122页

来源： 爬虫进阶教程：抖音APP无水印视频批量下载

一、前言

本文为两类人准备：技术控和工具控。

• 如果你是工具控，想简单方便地下载无水印的视频，那么可以使用第三方去水印平台：

抖音短视频解析下载平台

• 如果你是技术控，想要使用自己写的代码下载视频，那么可以使用本文的方法，用python写爬虫下载视频，最新开源项目：

Python3批量下载抖音无水印视频

本文的代码已经不是最新的，但是抓取思路就是如此，可以参考，代码可以直接运行使用，持续维护中。

更新日志

• 2018.5.23：github代码已经修复无法下载问题。
• 2018.7.17：github代码已经修复参数验证问题。
• 2018.11.07：api更新

二、实战背景

抖音越来越火，感觉它有毒，越刷越上瘾，总感觉下一个视频一定会更精彩，根本停不下来。想将抖音里喜欢的小哥哥/小姐姐的视频全部存到电脑硬盘里该如何操作？不想有抖音的视频水印该如何处理？

当初写完代码的截屏：

三、实战

首先，希望你已经具备手机APP抓包分析的能力，如果不会请去自行学习：点击跳转

1、带水印视频下载

先说说带水印的视频如何抓去吧。在定好爬取目标的时候，我们应该知道自己需要那些步骤完成这项任务。比如本文中提到的任务：抖音APP固定用户的视频批量下载。

思考过程：

• 想要批量下载视频首先要获得这些视频的链接；
• 想要获得这些视频链接可以通过用户的主页进行查看，想进用户主页，我得知道用户主页链接；
• 用户主页链接可以通过抖音APP的搜索功能获取，那么搜索功能接口如何获取？当然是抓包看看喽！

瞧，这样思考下来，问题是不是梳理的很清楚？

搜索接口：

那么接下来就是抓包分析了，抓包过程请自行尝试。步骤是这样的：

• 配置好Fiddler，即确定Fiddler可以对手机APP进行抓包；
• 在手机APP搜索框中输入用户信息，点击搜索；
• 在Fiddler找到搜索接口；
• 分析这个接口传递参数规则；
• 写代码生成相应查询接口。

通过分析你会发现，我们通过搜索接口返回的JSON数据可以找到用户主页信息，接下里用同样的方法抓取主页用户信息再分析一波，这时候就遇到问题了，你会发现用户主页链接使用了as和cp参数进行了加密，这该如何是好？比如链接如下：

上述链接省略号部分是一些手机信息，这部分不是必须参数，可以省略。user_id是用户id可以通过上个搜索接口获取，count是用户视频数量，同样可以通过上个搜索接口获取。那最后的as和cp参数怎么办？

我没有逆向抖音APP，就是小小测试了一下，看看能不能绕过这个加密接口？抖音APP自带视频分享功能，分享链接格式如下：

中间参数都不重要，在此省略。www.douyin.com域名下存放的是分享的视频，那么这个用户主页信息是否可以通过这个域名进行访问呢？小小测试一下你会发现，完全没有问题！

这就是没有加密的接口，惊不惊喜，意不意外？根据这个用户主页接口，我们就可以轻松获取用户主页所有的视频链接了。

2、无水印视频下载

方法一：

无水印视频下载很简单，有一个通用的方法，就是使用去水印平台即可。

我使用的去水印平台是：http://douyin.iiilab.com/

在输入框中输入视频链接点击视频解析，就可以获得无水印视频链接。

这个网站当初我写代码的时候是好使的，当初用这个网站下了一些无水印视频，不过写这篇文章的时候发现这个取水印平台无法正常解析了，等它修复好了再用这个功能吧。

这个平台不仅包括抖音视频去水印，还支持火山、快手、陌陌、美拍等无水印视频。所以做一个这个网站的接口还是很合适的。

简单测试了一下，这个网站的API是需要付费解析的，如果通过模拟请求的方式有些困难，因此决定上浏览器模拟器Splinter。

Splinter是个好东西，跟Selenium使用类似，它的配置可以参考我的早期Selenium文章：http://blog.csdn.net/c406495762/article/details/72331737

Splinter有个很详细的英文文档：http://splinter.readthedocs.io/en/latest/

这里使用方法就不累述，不过有一点可以说的是，我们可以配置headless参数，来将Splinter配置为无头浏览器，啥事无头浏览器呢？就是运行Splinter不调出浏览器界面，直接在后台模拟各种请求，很是方便。

这部分的代码很简单，无非就是填充元素，确定解析按钮位置，点击按钮，获取视频下载链接即可。这点小问题，就自行分析吧。

整体代码：

方法二：

这个方法是通过网友@羽葵的反馈得知的，对下载链接直接修改即可得到无水印下载链接。

方法简单粗暴，很好用。好处就是处理速度飞快，缺点是这种方法通用性不强，不同视频发布平台的打码方法可能有不同，需要自行分析。

四、总结

玩爬虫的日子还是很有意思的，好久没有那种舒爽感了。还有，找工作也是蛮心累的事。

更多实战源码，请关注我的Github：https://github.com/Jack-Cherish/python-spider

来源： git pull的时候发生冲突的解决方法之“error: Your local changes to the following files would be overwritten by merge” – 菜鸟学飞ing – 博客园

今天在使用git pull 命令的时候发生了以下报错

目前git的报错提示已经相关友好了，可以直观的发现，这里可以通过commit的方式解决这个冲突问题，但还是想看看其他大佬是怎么解决这类问题的

在网上查了资料和其他大佬的博客，得到了两种解决方法：

方法一、stash

1 git stash
2 git commit
3 git stash pop

接下来diff一下此文件看看自动合并的情况，并作出相应修改。

git stash: 备份当前的工作区的内容，从最近的一次提交中读取相关内容，让工作区保证和上次提交的内容一致。同时，将当前的工作区内容保存到Git栈中。
git stash pop: 从Git栈中读取最近一次保存的内容，恢复工作区的相关内容。由于可能存在多个Stash的内容，所以用栈来管理，pop会从最近的一个stash中读取内容并恢复。
git stash list: 显示Git栈内的所有备份，可以利用这个列表来决定从那个地方恢复。
git stash clear: 清空Git栈。此时使用gitg等图形化工具会发现，原来stash的哪些节点都消失了。

方法二、放弃本地修改，直接覆盖

1 git reset --hard
2 git pull

参考原文：https://blog.csdn.net/lincyang/article/details/21519333

来源： mysql处理高并发，防止库存超卖_caomiao2006的专栏-CSDN博客_防止仓库库存超卖

今天王总又给我们上了一课，其实mySQL处理高并发，防止库存超卖的问题，在去年的时候，王总已经提过；但是很可惜，即使当时大家都听懂了，但是在现实开发中，还是没这方面的意识。今天就我的一些理解，整理一下这个问题，并希望以后这样的课程能多点。

先来就库存超卖的问题作描述：一般电子商务网站都会遇到如团购、秒杀、特价之类的活动，而这样的活动有一个共同的特点就是访问量激增、上千甚至上万人抢购一个商品。然而，作为活动商品，库存肯定是很有限的，如何控制库存不让出现超买，以防止造成不必要的损失是众多电子商务网站程序员头疼的问题，这同时也是最基本的问题。

从技术方面剖析，很多人肯定会想到事务，但是事务是控制库存超卖的必要条件，但不是充分必要条件。

举例：

总库存：4个商品

请求人：a、1个商品 b、2个商品 c、3个商品

程序如下：

beginTranse(开启事务)

try{

$result = $dbca->query(‘select amount from s_store where postID = 12345’);

if(result->amount > 0){

//quantity为请求减掉的库存数量

$dbca->query(‘update s_store set amount = amount – quantity where postID = 12345’);

}

}catch($e Exception){

rollBack(回滚)

}

commit(提交事务)

以上代码就是我们平时控制库存写的代码了，大多数人都会这么写，看似问题不大，其实隐藏着巨大的漏洞。数据库的访问其实就是对磁盘文件的访问，数据库中的表其实就是保存在磁盘上的一个个文件，甚至一个文件包含了多张表。例如由于高并发，当前有三个用户a、b、c三个用户进入到了这个事务中，这个时候会产生一个共享锁，所以在select的时候，这三个用户查到的库存数量都是4个，同时还要注意，mySQL innodb查到的结果是有版本控制的，再其他用户更新没有commit之前(也就是没有产生新版本之前)，当前用户查到的结果依然是就版本；

然后是update，假如这三个用户同时到达update这里，这个时候update更新语句会把并发串行化，也就是给同时到达这里的是三个用户排个序，一个一个执行，并生成排他锁，在当前这个update语句commit之前，其他用户等待执行，commit后，生成新的版本；这样执行完后，库存肯定为负数了。但是根据以上描述，我们修改一下代码就不会出现超买现象了，代码如下：

beginTranse(开启事务)

try{

//quantity为请求减掉的库存数量
$dbca->query(‘update s_store set amount = amount – quantity where postID = 12345’);

$result = $dbca->query(‘select amount from s_store where postID = 12345’);

if(result->amount < 0){

throw new Exception(‘库存不足’);

}

}catch($e Exception){

rollBack(回滚)

}

commit(提交事务)

另外，更简洁的方法：

beginTranse(开启事务)

try{

//quantity为请求减掉的库存数量
$dbca->query(‘update s_store set amount = amount – quantity where amount>=quantity and postID = 12345′);

}catch($e Exception){

rollBack(回滚)

}

commit(提交事务)

=====================================================================================

1、在秒杀的情况下，肯定不能如此高频率的去读写数据库，会严重造成性能问题的
必须使用缓存，将需要秒杀的商品放入缓存中，并使用锁来处理其并发情况。当接到用户秒杀提交订单的情况下，先将商品数量递减（加锁/解锁）后再进行其他方面的处理，处理失败在将数据递增1（加锁/解锁），否则表示交易成功。
当商品数量递减到0时，表示商品秒杀完毕，拒绝其他用户的请求。

2、这个肯定不能直接操作数据库的，会挂的。直接读库写库对数据库压力太大，要用缓存。
把你要卖出的商品比如10个商品放到缓存中；然后在memcache里设置一个计数器来记录请求数，这个请求书你可以以你要秒杀卖出的商品数为基数，比如你想卖出10个商品，只允许100个请求进来。那当计数器达到100的时候，后面进来的就显示秒杀结束，这样可以减轻你的服务器的压力。然后根据这100个请求，先付款的先得后付款的提示商品以秒杀完。

3、首先，多用户并发修改同一条记录时，肯定是后提交的用户将覆盖掉前者提交的结果了。

这个直接可以使用加锁机制去解决，乐观锁或者悲观锁。
乐观锁，就是在数据库设计一个版本号的字段，每次修改都使其+1，这样在提交时比对提交前的版本号就知道是不是并发提交了，但是有个缺点就是只能是应用中控制，如果有跨应用修改同一条数据乐观锁就没办法了，这个时候可以考虑悲观锁。
悲观锁，就是直接在数据库层面将数据锁死，类似于oralce中使用select xxxxx from xxxx where xx=xx for update，这样其他线程将无法提交数据。
除了加锁的方式也可以使用接收锁定的方式，思路是在数据库中设计一个状态标识位，用户在对数据进行修改前，将状态标识位标识为正在编辑的状态，这样其他用户要编辑此条记录时系统将发现有其他用户正在编辑，则拒绝其编辑的请求，类似于你在操作系统中某文件正在执行，然后你要修改该文件时，系统会提醒你该文件不可编辑或删除。

4、不建议在数据库层面加锁，建议通过服务端的内存锁（锁主键）。当某个用户要修改某个id的数据时，把要修改的id存入memcache，若其他用户触发修改此id的数据时，读到memcache有这个id的值时，就阻止那个用户修改。

5、实际应用中，并不是让mySQL去直面大并发读写，会借助“外力”，比如缓存、利用主从库实现读写分离、分表、使用队列写入等方法来降低并发读写。

来源： 谈谈高并发系统的限流 – nick hao – 博客园

开涛大神在博客中说过：在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。本文结合作者的一些经验介绍限流的相关概念、算法和常规的实现方式。

缓存

缓存比较好理解，在大型高并发系统中，如果没有缓存数据库将分分钟被爆，系统也会瞬间瘫痪。使用缓存不单单能够提升系统访问速度、提高并发访问量，也是保护数据库、保护系统的有效方式。大型网站一般主要是“读”，缓存的使用很容易被想到。在大型“写”系统中，缓存也常常扮演者非常重要的角色。比如累积一些数据批量写入，内存里面的缓存队列（生产消费），以及HBase写数据的机制等等也都是通过缓存提升系统的吞吐量或者实现系统的保护措施。甚至消息中间件，你也可以认为是一种分布式的数据缓存。

降级

服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。降级往往会指定不同的级别，面临不同的异常等级执行不同的处理。根据服务方式：可以拒接服务，可以延迟服务，也有时候可以随机服务。根据服务范围：可以砍掉某个功能，也可以砍掉某些模块。总之服务降级需要根据不同的业务需求采用不同的降级策略。主要的目的就是服务虽然有损但是总比没有好。

限流

限流可以认为服务降级的一种，限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说系统的吞吐量是可以被测算的，为了保证系统的稳定运行，一旦达到的需要限制的阈值，就需要限制流量并采取一些措施以完成限制流量的目的。比如：延迟处理，拒绝处理，或者部分拒绝处理等等。

限流的算法

常见的限流算法有：计数器、漏桶和令牌桶算法。

计数器

计数器是最简单粗暴的算法。比如某个服务最多只能每秒钟处理100个请求。我们可以设置一个1秒钟的滑动窗口，窗口中有10个格子，每个格子100毫秒，每100毫秒移动一次，每次移动都需要记录当前服务请求的次数。内存中需要保存10次的次数。可以用数据结构LinkedList来实现。格子每次移动的时候判断一次，当前访问次数和LinkedList中最后一个相差是否超过100，如果超过就需要限流了。

很明显，当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。

示例代码如下：

//服务访问次数，可以放在Redis中，实现分布式系统的访问计数
Long counter = 0L;
//使用LinkedList来记录滑动窗口的10个格子。
LinkedList<Long> ll = new LinkedList<Long>();

public static void main(String[] args)
{
    Counter counter = new Counter();

    counter.doCheck();
}

private void doCheck()
{
    while (true)
    {
        ll.addLast(counter);
        
        if (ll.size() > 10)
        {
            ll.removeFirst();
        }
        
        //比较最后一个和第一个，两者相差一秒
        if ((ll.peekLast() - ll.peekFirst()) > 100)
        {
            //To limit rate
        }
        
        Thread.sleep(100);
    }
}

漏桶算法

漏桶算法即leaky bucket是一种非常常用的限流算法，可以用来实现流量整形（Traffic Shaping）和流量控制（Traffic Policing）。贴了一张维基百科上示意图帮助大家理解：

漏桶算法的主要概念如下：

• 一个固定容量的漏桶，按照常量固定速率流出水滴；
• 如果桶是空的，则不需流出水滴；
• 可以以任意速率流入水滴到漏桶；
• 如果流入水滴超出了桶的容量，则流入的水滴溢出了（被丢弃），而漏桶容量是不变的。

漏桶算法比较好实现，在单机系统中可以使用队列来实现（.Net中TPL DataFlow可以较好的处理类似的问题，你可以在这里找到相关的介绍），在分布式环境中消息中间件或者Redis都是可选的方案。

令牌桶算法

令牌桶算法是一个存放固定容量令牌（token）的桶，按照固定速率往桶里添加令牌。令牌桶算法基本可以用下面的几个概念来描述：

• 令牌将按照固定的速率被放入令牌桶中。比如每秒放10个。
• 桶中最多存放b个令牌，当桶满时，新添加的令牌被丢弃或拒绝。
• 当一个n个字节大小的数据包到达，将从桶中删除n个令牌，接着数据包被发送到网络上。
• 如果桶中的令牌不足n个，则不会删除令牌，且该数据包将被限流（要么丢弃，要么缓冲区等待）。

如下图：

令牌算法是根据放令牌的速率去控制输出的速率，也就是上图的to network的速率。to network我们可以理解为消息的处理程序，执行某段业务或者调用某个RPC。

漏桶和令牌桶的比较

令牌桶可以在运行时控制和调整数据处理的速率，处理某时的突发流量。放令牌的频率增加可以提升整体数据处理的速度，而通过每次获取令牌的个数增加或者放慢令牌的发放速度和降低整体数据处理速度。而漏桶不行，因为它的流出速率是固定的，程序处理速度也是固定的。

整体而言，令牌桶算法更优，但是实现更为复杂一些。

限流算法实现

Guava

Guava是一个Google开源项目，包含了若干被Google的Java项目广泛依赖的核心库，其中的RateLimiter提供了令牌桶算法实现：平滑突发限流(SmoothBursty)和平滑预热限流(SmoothWarmingUp)实现。

1. 常规速率：

创建一个限流器，设置每秒放置的令牌数：2个。返回的RateLimiter对象可以保证1秒内不会给超过2个令牌，并且是固定速率的放置。达到平滑输出的效果

public void test()
{
    /**
     * 创建一个限流器，设置每秒放置的令牌数：2个。速率是每秒可以2个的消息。
     * 返回的RateLimiter对象可以保证1秒内不会给超过2个令牌，并且是固定速率的放置。达到平滑输出的效果
     */
    RateLimiter r = RateLimiter.create(2);

    while (true)
    {
        /**
         * acquire()获取一个令牌，并且返回这个获取这个令牌所需要的时间。如果桶里没有令牌则等待，直到有令牌。
         * acquire(N)可以获取多个令牌。
         */
        System.out.println(r.acquire());
    }
}

上面代码执行的结果如下图，基本是0.5秒一个数据。拿到令牌后才能处理数据，达到输出数据或者调用接口的平滑效果。acquire()的返回值是等待令牌的时间，如果需要对某些突发的流量进行处理的话，可以对这个返回值设置一个阈值，根据不同的情况进行处理，比如过期丢弃。

2. 突发流量：

突发流量可以是突发的多，也可以是突发的少。首先来看个突发多的例子。还是上面例子的流量，每秒2个数据令牌。如下代码使用acquire方法，指定参数。

System.out.println(r.acquire(2));
System.out.println(r.acquire(1));
System.out.println(r.acquire(1));
System.out.println(r.acquire(1));

得到如下类似的输出。

如果要一次新处理更多的数据，则需要更多的令牌。代码首先获取2个令牌，那么下一个令牌就不是0.5秒之后获得了，还是1秒以后，之后又恢复常规速度。这是一个突发多的例子，如果是突发没有流量，如下代码：

System.out.println(r.acquire(1));
Thread.sleep(2000);
System.out.println(r.acquire(1));
System.out.println(r.acquire(1));
System.out.println(r.acquire(1));

得到如下类似的结果：

等了两秒钟之后，令牌桶里面就积累了3个令牌，可以连续不花时间的获取出来。处理突发其实也就是在单位时间内输出恒定。这两种方式都是使用的RateLimiter的子类SmoothBursty。另一个子类是SmoothWarmingUp，它提供的有一定缓冲的流量输出方案。

/**
* 创建一个限流器，设置每秒放置的令牌数：2个。速率是每秒可以210的消息。
* 返回的RateLimiter对象可以保证1秒内不会给超过2个令牌，并且是固定速率的放置。达到平滑输出的效果
* 设置缓冲时间为3秒
*/
RateLimiter r = RateLimiter.create(2,3,TimeUnit.SECONDS);

while (true) {
    /**
     * acquire()获取一个令牌，并且返回这个获取这个令牌所需要的时间。如果桶里没有令牌则等待，直到有令牌。
     * acquire(N)可以获取多个令牌。
     */
    System.out.println(r.acquire(1));
    System.out.println(r.acquire(1));
    System.out.println(r.acquire(1));
    System.out.println(r.acquire(1));
}

输出结果如下图，由于设置了缓冲的时间是3秒，令牌桶一开始并不会0.5秒给一个消息，而是形成一个平滑线性下降的坡度，频率越来越高，在3秒钟之内达到原本设置的频率，以后就以固定的频率输出。图中红线圈出来的3次累加起来正好是3秒左右。这种功能适合系统刚启动需要一点时间来“热身”的场景。

Nginx

对于Nginx接入层限流可以使用Nginx自带了两个模块：连接数限流模块ngx_http_limit_conn_module和漏桶算法实现的请求限流模块ngx_http_limit_req_module。

1. ngx_http_limit_conn_module

我们经常会遇到这种情况，服务器流量异常，负载过大等等。对于大流量恶意的攻击访问，会带来带宽的浪费，服务器压力，影响业务，往往考虑对同一个ip的连接数，并发数进行限制。ngx_http_limit_conn_module 模块来实现该需求。该模块可以根据定义的键来限制每个键值的连接数，如同一个IP来源的连接数。并不是所有的连接都会被该模块计数，只有那些正在被处理的请求（这些请求的头信息已被完全读入）所在的连接才会被计数。

我们可以在nginx_conf的http{}中加上如下配置实现限制：

#限制每个用户的并发连接数，取名one
limit_conn_zone $binary_remote_addr zone=one:10m;

#配置记录被限流后的日志级别，默认error级别
limit_conn_log_level error;
#配置被限流后返回的状态码，默认返回503
limit_conn_status 503;

然后在server{}里加上如下代码：

#限制用户并发连接数为1
limit_conn one 1;

然后我们是使用ab测试来模拟并发请求：
ab -n 5 -c 5 http://10.23.22.239/index.html

得到下面的结果，很明显并发被限制住了，超过阈值的都显示503：

另外刚才是配置针对单个IP的并发限制，还是可以针对域名进行并发限制，配置和客户端IP类似。

#http{}段配置

limit_conn_zone $ server_name zone=perserver:10m;

#server{}段配置

limit_conn perserver 1;

2. ngx_http_limit_req_module

上面我们使用到了ngx_http_limit_conn_module 模块，来限制连接数。那么请求数的限制该怎么做呢？这就需要通过ngx_http_limit_req_module 模块来实现，该模块可以通过定义的键值来限制请求处理的频率。特别的，可以限制来自单个IP地址的请求处理频率。 限制的方法是使用了漏斗算法，每秒固定处理请求数，推迟过多请求。如果请求的频率超过了限制域配置的值，请求处理会被延迟或被丢弃，所以所有的请求都是以定义的频率被处理的。

在http{}中配置

#区域名称为one，大小为10m，平均处理的请求频率不能超过每秒一次。

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

在server{}中配置

#设置每个IP桶的数量为5
limit_req zone=one burst=5;

上面设置定义了每个IP的请求处理只能限制在每秒1个。并且服务端可以为每个IP缓存5个请求，如果操作了5个请求，请求就会被丢弃。

使用ab测试模拟客户端连续访问10次：ab -n 10 -c 10 http://10.23.22.239/index.html

如下图，设置了通的个数为5个。一共10个请求，第一个请求马上被处理。第2-6个被存放在桶中。由于桶满了，没有设置nodelay因此，余下的4个请求被丢弃。

来源： 处理高并发，防止库存超卖 – 吴桂鑫 – 博客园

资料：

（1）分布式系统事务一致性解决方案：

http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency

（2）MySQL事务隔离级别的实现原理：

https://www.cnblogs.com/cjsblog/p/8365921.html

（3）当前读和快照读：

https://www.cnblogs.com/cat-and-water/p/6427612.html

（4）mySQL处理高并发，防止库存超卖：

https://blog.csdn.net/caomiao2006/article/details/38568825?utm_source=blogxgwz2

（5）Redis和Memcache对比及选择：

https://blog.csdn.net/sunmenggmail/article/details/36176029

（6）高并发下防止商品超卖的Redis实现（通过 jMeter 模拟并发）：

https://blog.csdn.net/Allen_jinjie/article/details/79292163?utm_source=blogxgwz0

（7）Redis和请求队列解决高并发：

https://blog.csdn.net/ZHJUNJUN93/article/details/78560700?utm_source=blogxgwz17

（7）redis集群和kafka集群作为消息队列比较（优先考虑kafka）：

https://www.2cto.com/kf/201701/587505.html

（8）面试中关于Redis的问题看这篇就够了（业务上避免过度复用一个 redis，它只是一个单线程。既用它做缓存、做计算，还拿它做任务队列，这样不好。）：

https://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA%3D%3D&idx=1&mid=2247483867&sn=39a06fa3d6d8f09eefaaf3d2b15b40e4

（9）Kafka，Mq和Redis作为消息队列使用时的差异有哪些？

https://www.wukong.com/answer/6527968849956962568/

（10）Redis与RabbitMQ作为消息队列的比较：

https://blog.csdn.net/gb4215287/article/details/79457445

（11）如何设计一个秒杀系统：

https://www.cnblogs.com/wangzhongqiu/p/6557596.html

（12）基于 SpringBoot+Mybatis+Redis+RabbitMQ 秒杀系统：

https://blog.csdn.net/qq_33524158/article/details/81675011

一、事务的四大特性：

1.原子性（Atomicity）（要么不执行，要么全部执行）

2.一致性（Consistency）（假设有多个数据库服务器，当修改了某一个数据库中的某一记录之后，【其他的数据库也要进行同步修改】）

3.隔离性（Isolation）（假设有事务1和事务2，则事务1绝不可以影响到事务2，事务2也绝不可以影响到事务1，即【事务1和事务2是相互独立的事件】）

4.持久性（Durability）（将【某应用服务器】的事务通过事务管理器记录到日志文件中，则当该应用服务器重启时，可以读取这些日志文件）

二、悲观锁和乐观锁的区别：

三、MySQL事务隔离级别：

1.读未提交：一个事务可以读取到另一个事务未提交的修改。这会带来脏读、幻读、不可重复读问题。（基本没用）

2.读已提交（Committed-Read）：一个事务只能读取另一个事务已经提交的修改。其避免了脏读，但仍然存在不可重复读和幻读问题。

3.可重复读（Repeatable-Read）（乐观锁）：同一个事务中多次读取相同的数据返回的结果是一样的。其避免了脏读和不可重复读问题。

4.串行化（Serializable_Read）（悲观锁）：事务串行执行。避免了以上所有问题，包括幻读。

MySQL默认的隔离级别是【可重复读】。

四、避免库存超卖

（1）非秒杀的正常的、避免库存超卖的方法（利用关系型数据库的Repeatable-Read事务隔离级别）

（2）在秒杀的情况下，肯定不能如方法一那样高频率的去读写数据库，会严重造成性能问题的，
必须使用缓存，将需要秒杀的商品放入缓存中，再为每个缓存商品建立请求队列，以最快的速度缓存请求并响应客户端，最后再悠闲地处理队列中的请求。

五、各个消息队列的比较

1.利用redis实现的消息队列：一个轻量级的消息队列（数据量越大，效率越低，一般用于数据量较小的即时秒杀系统）

2.rabbitmq：一个重量级的、可靠的消息队列（数据量越大，效率越低，一般用于缓存可延迟的操作，比如银行转账）

3.kafka/Jafka：一个追求高吞吐量的、较不可靠的消息队列（一般用于缓存大数据中采集的数据）

来源： 高并发请求的缓存设计策略 – 老白讲互联网 – 博客园

前几天，我司出了个篓子。当时正值某喜闻乐见的关键比赛结束，一堆人打开我司app准备看点东西，结果从来没有感受到过这么多关注量的该功能瞬间幸福到眩晕，触发了熔断，结果就是大量兴致冲冲打开app准备看该比赛结果的人被迫刷了十分钟三天前的野外跑酷，负责内容的人火大到直接骂娘。

虽然这个业务不是我负责，但是也跟相关的人聊了下情况，感慨了一下，于是有了这一篇文章。

1.为何需要缓存？

在高并发请求时，为何我们频繁提到缓存技术？最直接的原因是，目前磁盘IO和网络IO相对于内存IO的成百上千倍的性能劣势。
做个简单计算，如果我们需要某个数据，该数据从数据库磁盘读出来需要0.1s，从交换机传过来需要0.05s，那么每个请求完成最少0.15s（当然，事实上磁盘和网络IO也没有这么慢，这里只是举例），该数据库服务器每秒只能响应67个请求；而如果该数据存在于本机内存里，读出来只需要10us，那么每秒钟能够响应100，000个请求。

通过将高频使用的数据存在离cpu更近的位置，以减少数据传输时间，从而提高处理效率，这就是缓存的意义。

2.在哪里用缓存？

一切地方。例如：

• 我们从硬盘读数据的时候，其实操作系统还额外把附近的数据都读到了内存里
• 例如，CPU在从内存里读数据的时候，也额外读了许多数据到各级cache里
• 各个输入输出之间用buffer保存一批数据统一发送和接受，而不是一个byte一个byte的处理

上面这是系统层面，在软件系统设计层面，很多地方也用了缓存：

• 浏览器会缓存页面的元素，这样在重复访问网页时，就避开了要从互联网上下载数据（例如大图片）
• web服务会把静态的东西提前部署在CDN上，这也是一种缓存
• 数据库会缓存查询，所以同一条查询第二次就是要比第一次快
• 内存数据库（如redis）选择把大量数据存在内存而非硬盘里，这可以看作是一个大型缓存，只是把整个数据库缓存了起来
• 应用程序把最近几次计算的结果放在本地内存里，如果下次到来的请求还是原请求，就跳过计算直接返回结果

3.本次事故分析

回到本文开始的问题上，该系统是怎么设计的呢？底层是数据库，中间放了一层redis，前面的业务系统所需的数据都直接从redis里取，然后计算出结果返回给app；数据库和redis的同步另外有程序保证，避免redis的穿透，防止了程序里出现大量请求从redis里找不到，于是又一窝蜂的去查数据库，直接压垮数据库的情况。从这个角度讲，其实这一步是做的还可以的。

但是这个系统有两个问题：
1.业务系统需要的数据虽然都在redis里，但是是分开存放的。什么意思呢，比如我前台发起一个请求，后台先去redis里取一下标题，然后再取一下作者，然后再取一下内容，再取一下评论，再取一下转发数等等……结果前台一次请求，后台要请求redis十几次。高并发的时候，压力一下被放大十几倍，redis响应、网络响应必然会变慢。
2.其实做业务的那波人也意识到了这个情况可能发生，所以做了熔断机制，另起了一个缓存池，里面放了一些备用数据，如果主业务超时，直接从缓存池里取数据返回。但是他们设计的时候没想周全，这个备选池的数据过期时间设计的太长了，里面居然还有三天前更新进去的数据，最终导致了一大波用户刷出来三天前的野外生态小视频……

说到这，不知道读者有没有意识到他们最致命的一个问题：这个业务系统完全没有考虑本地缓存（也就是在业务服务器内存里做缓存）。比如像我们这种app，一旦大量用户同一时间涌进来，必定都是奔着少数几个内容去的，这种特别集中的高频次极少量数据访问，又不需要对每个用户做特化的，简直就是在脸上写上“请缓存我”。
这时候，如果能在业务端做一层本地缓存，直接把算好的数据本地存一份，那么就会极大减少网络和redis的压力，不至于当场触发熔断了。

4.浅谈缓存的那些坑

缓存很有用，但是缓存用不好也会埋很多坑：

缓存穿透

缓存穿透是说收到了一个请求，但是该请求缓存里没有，只能去数据库里查询，然后放进缓存。这里面有两个风险，一个是同时有好多请求访问同一个数据，然后业务系统把这些请求全发到了数据库；第二个是有人恶意构造一个逻辑上不存在的数据，然后大量发送这个请求，这样每次请求都会被发送到数据库，可能导致数据挂掉。

怎么应对这种情况呢？对于恶意访问，一个思路是事先做校验，对恶意数据直接过滤掉，不要发到数据库层；第二个思路是缓存空结果，就是对查询不存在的数据仍然记录一条该数据不存在在缓存里，这样能有效的减少查询数据库的次数。

那么非恶意访问呢？这个要结合缓存击穿来讲。

缓存击穿

上面提到的某个数据没有，然后好多请求都被发到数据库其实可以归为缓存击穿的范畴：对于热点数据，当数据失效的一瞬间，所有请求都被下放到数据库去请求更新缓存，数据库被压垮。

怎么防范这种问题呢？一个思路是全局锁，就是所有访问某个数据的请求都共享一个锁，获得锁的那个才有资格去访问数据库，其他线程必须等待。但是现在的业务都是分布式的，本地锁没法控制其他服务器也等待，所以要用到全局锁，比如用redis的setnx实现全局锁。

另一个思路是对即将过期的数据主动刷新，做法可以有很多，比如起一个线程轮询数据，比如把所有数据划分为不同的缓存区间，定期分区间刷新数据等等。这第二个思路又和我们接下来要讲的缓存雪崩有关系。

缓存雪崩

缓存雪崩是指比如我们给所有的数据设置了同样的过期时间，然后在某一个历史性时刻，整个缓存的数据全部过期了，然后瞬间所有的请求都被打到了数据库，数据库就崩了。

解决思路要么是分治，划分更小的缓存区间，按区间过期；要么是给每个key的过期时间加个随机值，避免同时过期，达到错峰刷新缓存的目的。

缓存刷新

说到刷新缓存，其实也有坑的。比如我之前的一份工作里，有一次大活动，正是如火如荼的时候，所有的广告位突然都变空白了。后来追查原因，所有的广告素材都在缓存里，然后起了个程序，专门负责刷新缓存，每次把当前的素材全量刷新。

坏就坏在这个全量上。因为大活动的时候流量极大，广告更新压力也很大，把负责提供更新素材的程序压崩了。刷新缓存的程序在请求时，收到了一个返回结果Null。接下来就喜闻乐见了，刷新程序根据这个null，清空了整个缓存，所有广告素材都失效了。

总之，想要做好高并发系统的缓存，就要考虑到各种边角情况，小心设计，任何细小的疏忽都可能导致系统崩溃。

一.概念 在介绍资源等待PAGEIOLATCH之前，先来了解下从实例级别来分析的各种资源等待的dmv视图sys.dm_os_wait_stats。它是返回执行的线程所遇到的所有等待的相关信息，该视图是从一个实际

来源： sql server 性能调优 资源等待之PAGEIOLATCH_技术文档

一.概念

在介绍资源等待PAGEIOLATCH之前，先来了解下从实例级别来分析的各种资源等待的dmv视图sys.dm_os_wait_stats。它是返回执行的线程所遇到的所有等待的相关信息，该视图是从一个实际级别来分析的各种等待,它包括200多种类型的等待，需要关注的包括PageIoLatch（磁盘I/O读写的等待时间）,LCK_xx（锁的等待时间），WriteLog（日志写入等待），PageLatch（页上闩锁）Cxpacket（并行等待）等以及其它资源等待排前的。

1.  下面根据总耗时排序来观察，这里分析的等待的wait_type 不包括以下

SELECT  wait_type ,
        waiting_tasks_count,
        signal_wait_time_ms ,
        wait_time_ms,
        max_wait_time_ms
FROM    sys.dm_os_wait_stats
WHERE   wait_time_ms > 0
        AND wait_type NOT IN ( 'CLR_SEMAPHORE', 'CLR_AUTO_EVENT',
                               'LAZYWRITER_SLEEP', 'RESOURCE_QUEUE',
                               'SLEEP_TASK', 'SLEEP_SYSTEMTASK',
                               'SQLTRACE_BUFFER_FLUSH', 'WAITFOR',
                               'LOGMGR_QUEUE', 'CHECKPOINT_QUEUE',
                               'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT',
                               'BROKER_TO_FLUSH', 'BROKER_TASK_STOP',
                               'CLR_MANUAL_EVENT',
                               'DISPATCHER_QUEUE_SEMAPHORE',
                               'FT_IFTS_SCHEDULER_IDLE_WAIT',
                               'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN',
                               'SQLTRACE_INCREMENTAL_FLUSH_SLEEP' )
ORDER BY signal_wait_time_ms DESC

下图排名在前的资源等待是重点需要去关注分析：

通过上面的查询就能找到PAGEIOLATCH_x类型的资源等待，由于是实例级别的统计，想要获得有意义数据，就需要查看感兴趣的时间间隔。如果要间隔来分析，不需要重启服务，可通过以下命令来重置

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);

wait_type:等待类型
waiting_tasks_count:该等待类型的等待数
wait_time_ms:该等待类型的总等待时间(包括一个进程悬挂状态(Suspend)和可运行状态(Runnable)花费的总时间)
max_wait_time_ms:该等待类型的最长等待时间
signal_wait_time_ms:正在等待的线程从收到信号通知到其开始运行之间的时差(一个进程可运行状态(Runnable)花费的总时间)
io等待时间==wait_time_ms – signal_wait_time_ms

二. PAGEIOLATCH_x

2.1 什么是Latch

在SQL server里latch是轻量级锁，不同于lock。latch是用来同步SQLServer的内部对象(同步资源访问)，而lock是用来对于用户对象包括(表，行，索引等)进行同步，简单概括：Latch用来保护SQL server内部的一些资源（如page）的物理访问，可以认为是一个同步对象。而lock则强调逻辑访问。比如一个table，就是个逻辑上的概念。关于lock锁这块在”sql server 锁与事务拨云见日“中有详细说明。

2.2 什么是PageIOLatch

当查询的数据页如果在Buffer pool里找到了，则没有任何等待。否则就会发出一个异步io操作，将页面读入到buffer pool,没做完之前，连接会保持在PageIoLatch_ex(写)或PageIoLatch_sh(读)的等待状态，是Buffer pool与磁盘之间的等待。它反映了查询磁盘i/o读写的等待时间。
当sql server将数据页面从数据文件里读入内存时，为了防止其他用户对内存里的同一个数据页面进行访问，sql server会在内存的数据页同上加一个排它锁latch,而当任务要读取缓存在内存里的页面时，会申请一个共享锁，像是lock一样，latch也会出现阻塞，根据不同的等待资源，等待状态有如下：PAGEIOLATCH_DT，PAGEIOLATCH_EX，PAGEIOLATCH_KP，PAGEIOLATCH_SH，PAGEIOLATCH_UP。重点关注PAGEIOLATCH_EX（写入）和PAGEIOLATCH_SH(读取)二种等待。

2.1  AGEIOLATCH流程图

有时我们分析当前活动用户状态下时，一个有趣的现象是，有时候你发现某个SPID被自己阻塞住了(通过sys.sysprocesses了查看) 为什么会自己等待自己呢？ 这个得从SQL server读取页的过程说起。SQL server从磁盘读取一个page的过程如下：

(1)：由一个用户请求，获取扫描X表,由Worker x去执行。

(2)：在扫描过程中找到了它需要的数据页同1:100。

(3)：发面页面1:100并不在内存中的数据缓存里。

(4)：sql server在缓冲池里找到一个可以存放的页面空间，在上面加EX的LATCH锁，防止数据从磁盘里读出来之前，别人也来读取或修改这个页面。

(5)：worker x发起一个异步i/o请求,要求从数据文件里读出页面1:100。

(6)：由于是异步i/o(可以理解为一个task子线程)，worker x可以接着做它下面要做的事情，就是读出内存中的页面1:100,读取的动作需要申请一个sh的latch。

(7)：由于worker x之前申请了一个EX的LATCH锁还没有释放，所以这个sh的latch将被阻塞住，worker x被自己阻塞住了，等待的资源就是PAGEIOLATCH_SH。

最后当异步i/o结束后，系统会通知worker x，你要的数据已经写入内存了。接着EX的LATCH锁释放，worker x申请得到了sh的latch锁。

总结：首先说worker是一个执行单元,下面有多个task关联Worker上， task是运行的最小任务单元，可以这么理解worker产生了第一个x的task任务，再第5步发起一个异步i/o请求是第二个task任务。二个task属于一个worker，worker x被自己阻塞住了。 关于任务调度了解查看sql server 任务调度与CPU。

2.2 具体分析

通过上面了解到如果磁盘的速度不能满足sql server的需要，它就会成为一个瓶颈，通常PAGEIOLATCH_SH 从磁盘读数据到内存，如果内存不够大，当有内存压力时候它会释放掉缓存数据，数据页就不会在内存的数据缓存里,这样内存问题就导致了磁盘的瓶颈。PAGEIOLATCH_EX是写入数据，这一般是磁盘的写入速度明显跟不上，与内存没有直接关系。

下面是查询PAGEIOLATCH_x的资源等待时间：

select wait_type,
waiting_tasks_count,
wait_time_ms ,
max_wait_time_ms,
signal_wait_time_ms
from sys.dm_os_wait_stats
where wait_type like 'PAGEIOLATCH%' 
order by wait_type

下面是查询出来的等待信息：

PageIOLatch_SH 总等待时间是(7166603.0-15891)/1000.0/60.0=119.17分钟，平均耗时是(7166603.0-15891)/297813.0=24.01毫秒,最大等待时间是3159秒。

PageIOLatch_EX 总等待时间是(3002776.0-5727)/1000.0/60.0=49.95分钟，    平均耗时是(3002776.0-5727)/317143.0=9.45毫秒，最大等待时间是1915秒。

关于I/O磁盘 sys.dm_io_virtual_file_stats 函数也做个参考

SELECT  
       MAX(io_stall_read_ms) AS read_ms,
         MAX(num_of_reads) AS read_count,
       MAX(io_stall_read_ms) / MAX(num_of_reads) AS 'Avg Read ms',
         MAX(io_stall_write_ms) AS write_ms,
        MAX(num_of_writes) AS write_count,
         MAX(io_stall_write_ms) /  MAX(num_of_writes) AS 'Avg Write ms'
FROM    sys.dm_io_virtual_file_stats(null, null)
WHERE   num_of_reads > 0 AND num_of_writes > 0

总结：PageIOLatch_EX(写入)跟磁盘的写入速度有关系。PageIOLatch_SH(读取)跟内存中的数据缓存有关系。通过上面的sql统计查询，从等待的时间上看，并没有清晰的评估磁盘性能的标准，但可以做评估基准数据，定期重置，做性能分析。要确定磁盘的压力，还需要从windows系统性能监视器方面来分析。 关于内存原理查看”sql server 内存初探“磁盘查看”sql server I/O硬盘交互” 。

内容转自网络，版权归原作者所有，转载请以链接形式标明本文地址
本文地址：http://www.xiaoyuhost.com/tech/100.html

来源： SQL Server常用的性能诊断语句 – 召冠 – 博客园

/*
常规服务器动态管理对象包括：
dm_db_*：数据库和数据库对象
dm_exec_*：执行用户代码和关联的连接
dm_os_*：内存、锁定和时间安排
dm_tran_*：事务和隔离
dm_io_*：网络和磁盘的输入/输出
*/

— 运行下面的 DMV 查询以查看 CPU、计划程序内存和缓冲池信息。
select
cpu_count,
hyperthread_ratio,
scheduler_count,
physical_memory_in_bytes / 1024 / 1024 as physical_memory_mb,
virtual_memory_in_bytes / 1024 / 1024 as virtual_memory_mb,
bpool_committed * 8 / 1024 as bpool_committed_mb,
bpool_commit_target * 8 / 1024 as bpool_target_mb,
bpool_visible * 8 / 1024 as bpool_visible_mb
from sys.dm_os_sys_info

— 高I/O开销的查询 Identifying Most Costly Queries by I/O
SELECT TOP 10
[Average IO] = (total_logical_reads + total_logical_writes) / qs.execution_count
, [Total IO] = (total_logical_reads + total_logical_writes)
, [Execution count] = qs.execution_count
, [Individual Query] = SUBSTRING (qt.text,qs.statement_start_offset/2,
(CASE WHEN qs.statement_end_offset = -1
THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2
ELSE qs.statement_end_offset END – qs.statement_start_offset)/2)
,[Parent Query] = qt.text
, DatabaseName = DB_NAME(qt.dbid)
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_SQL_text(qs.SQL_handle) as qt
ORDER BY [Average IO] DESC;

— 高CPU开销的查询 Identifying Most Costly Queries by CPU
SELECT TOP 10
[Average CPU used] = total_worker_time / qs.execution_count
, [Total CPU used] = total_worker_time
, [Execution count] = qs.execution_count
, [Individual Query] = SUBSTRING (qt.text,qs.statement_start_offset/2,
(CASE WHEN qs.statement_end_offset = -1
THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2
ELSE qs.statement_end_offset END – qs.statement_start_offset)/2)
, [Parent Query] = qt.text
, DatabaseName = DB_NAME(qt.dbid)
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
ORDER BY [Average CPU used] DESC;

— 高开销的缺失索引 Cost of Missing Indexes
SELECT TOP 10
[Total Cost] = ROUND(avg_total_user_cost * avg_user_impact * (user_seeks + user_scans),0)
, avg_user_impact
, TableName = statement
, [EqualityUsage] = equality_columns
, [InequalityUsage] = inequality_columns
, [Include Cloumns] = included_columns
FROM sys.dm_db_missing_index_groups g
INNER JOIN sys.dm_db_missing_index_group_stats s
ON s.group_handle = g.index_group_handle
INNER JOIN sys.dm_db_missing_index_details d
ON d.index_handle = g.index_handle
ORDER BY [Total Cost] DESC;

— 最常执行的查询 Identifying Queries that Execute Most Often
SELECT TOP 10
[Execution count] = execution_count
,[Individual Query] = SUBSTRING (qt.text,qs.statement_start_offset/2,
(CASE WHEN qs.statement_end_offset = -1
THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2
ELSE qs.statement_end_offset END – qs.statement_start_offset)/2)
,[Parent Query] = qt.text
,DatabaseName = DB_NAME(qt.dbid)
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
ORDER BY [Execution count] DESC;

— 重复编译的查询（plan_generation_num 指示该查询已重新编译的次数）
select top 25
sql_text.text,
sql_handle,
plan_generation_num,
execution_count,
dbid,
objectid
from sys.dm_exec_query_stats a
cross apply sys.dm_exec_sql_text(sql_handle) as sql_text
where plan_generation_num > 1
order by plan_generation_num desc

— 服务器等待的原因 SQL Query Records Causes of Wait Times
SELECT TOP 10
[Wait type] = wait_type,
[Wait time (s)] = wait_time_ms / 1000,
[% waiting] = CONVERT(DECIMAL(12,2), wait_time_ms * 100.0
/ SUM(wait_time_ms) OVER())
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE ‘%SLEEP%’
ORDER BY wait_time_ms DESC;

— 读和写 Identifying the Most Reads and Writes
SELECT TOP 10
[Total Reads] = SUM(total_logical_reads)
,[Execution count] = SUM(qs.execution_count)
,DatabaseName = DB_NAME(qt.dbid)
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
GROUP BY DB_NAME(qt.dbid)
ORDER BY [Total Reads] DESC;

SELECT TOP 10
[Total Writes] = SUM(total_logical_writes)
,[Execution count] = SUM(qs.execution_count)
,DatabaseName = DB_NAME(qt.dbid)
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
GROUP BY DB_NAME(qt.dbid)
ORDER BY [Total Writes] DESC;

— 运行下面的 DMV 查询以查找 I/O 闩锁等待统计信息。
select wait_type, waiting_tasks_count, wait_time_ms, signal_wait_time_ms, wait_time_ms / waiting_tasks_count
from sys.dm_os_wait_stats
where wait_type like ‘PAGEIOLATCH%’ and waiting_tasks_count > 0
order by wait_type

— 查看SQL阻塞信息
with tmp as (
select * from master..sysprocesses t where t.blocked != 0
union all
select b.* from master..sysprocesses b
join tmp t on b.spid = t.blocked
)
select t.spid, t.blocked, t.status, t.lastwaittype, t.waitresource, t.waittime
, DB_NAME(t.dbid) DbName, t.login_time, t.loginame, t.program_name, dc.text
from (select spid from tmp group by spid) s
join master..sysprocesses t on s.spid = t.spid
cross apply master.sys.dm_exec_sql_text(t.sql_handle) dc

–kill 53;

— 查看所有会话的状态、等待类型及当前正在执行SQL脚本
select t.spid, t.kpid, t.blocked, t.status, t.lastwaittype, t.waitresource, t.waittime
, DB_NAME(t.dbid) DbName, t.last_batch, t.loginame, t.program_name, t.hostname, t.hostprocess , t.cmd, t.stmt_start, t.stmt_end, t.request_id, dc.text
from master.sys.sysprocesses t
outer apply master.sys.dm_exec_sql_text(t.sql_handle) dcwhere t.spid >= 50

select s.spid, s.kpid, s.blocked, s.hostname, s.hostprocess, s.program_name, s.loginame       , s.status, s.lastwaittype, s.waitresource, s.waittime       , t.transaction_id, t.name, t.transaction_begin_time, dc.text   from sys.sysprocesses s      join sys.dm_tran_session_transactions st on s.spid = st.session_id      join sys.dm_tran_active_transactions t on st.transaction_id = t.transaction_id      outer apply master.sys.dm_exec_sql_text(s.sql_handle) dc

—补充，查看所有会话当前持有和申请的锁资源(选择在特定的业务库执行，测试模拟，建议将隔离级别改为可重复读)
set transaction isolation level repeatable read
select  l.request_session_id,          l.resource_type,          l.resource_subtype,          l.request_status,          l.request_mode,          l.resource_description,          db_name(l.resource_database_id) as dbName,          case l.resource_type               when ‘database’ then DB_NAME(l.resource_database_id)              when ‘object’ then object_name(l.resource_associated_entity_id)              else OBJECT_NAME(p.object_id)          end as obj_name,          p.index_id,          l.request_lifetime  from sys.dm_tran_locks l      left join sys.partitions p on l.resource_associated_entity_id = p.hobt_id  order by l.request_session_id, l.resource_type
—查看所有会话的 找到活动事务对应的执行语句
select dc.session_id,
ds.login_name,
ds.login_time,
dc.connect_time,
dc.net_transport,
dc.client_net_address,
ds.host_name,
ds.program_name,
case ds.status when ‘sleeping’ then ‘睡眠 – 当前没有运行任何请求 ‘
when ‘running’ then ‘正在运行 – 当前正在运行一个或多个请求 ‘
when ‘Dormancy’ then ‘休眠 – 会话因连接池而被重置，并且现在处于登录前状态’
when ‘Pre-connected’ then ‘预连接 – 会话在资源调控器分类器中’
end as status ,
ds.cpu_time as cpu_time_ms,
ds.memory_usage*8 as memory_kb,
ds.total_elapsed_time as total_elapsed_time_ms,
case ds.transaction_isolation_level when 0 then ‘未指定’
when 1 then ‘未提交读取’
when 2 then ‘已提交读取’
when 3 then ‘可重复’
when 4 then ‘可序列化’
when 5 then ‘快照’
end ‘会话的事务隔离级别’,
dt.text
from sys.dm_exec_connections dc –执行连接，最近执行的查询信息
cross apply sys.dm_exec_sql_text(dc.most_recent_sql_handle) dt
join sys.dm_exec_sessions ds on dc.session_id=ds.session_id
where ds.login_name= ‘LCGS609999’
–where ds.program_name = ‘.Net SqlClient Data Provider’
ORDER BY dt.text

来源： 了解SQL Server锁争用：NOLOCK 和 ROWLOCK 的秘密 – Athrun – 博客园

来源： SQL Server中的锁 详解 nolock,rowlock,tablock,xlock,paglock – Alfa – 博客园

高手进 锁 nolock,rowlock,tablock,xlock,paglock
锁 nolock,rowlock,tablock,xlock,paglock
请问大哥，在什么情况下用什么样的锁，小弟不太明白。

——解决方案——————–
SQL code
锁定提示 描述
HOLDLOCK 将共享锁保留到事务完成，而不是在相应的表、行或数据页不再需要时就立即释放锁。HOLDLOCK 等同于 SERIALIZABLE。
NOLOCK 不要发出共享锁，并且不要提供排它锁。当此选项生效时，可能会读取未提交的事务或一组在读取中间回滚的页面。有可能发生脏读。仅应用于 SELECT 语句。
PAGLOCK 在通常使用单个表锁的地方采用页锁。
READCOMMITTED 用与运行在提交读隔离级别的事务相同的锁语义执行扫描。默认情况下，SQL Server 2000 在此隔离级别上操作。
READPAST 跳过锁定行。此选项导致事务跳过由其它事务锁定的行（这些行平常会显示在结果集内），而不是阻塞该事务，使其等待其它事务释放在这些行上的锁。READPAST 锁提示仅适用于运行在提交读隔离级别的事务，并且只在行级锁之后读取。仅适用于 SELECT 语句。
READUNCOMMITTED 等同于 NOLOCK。
REPEATABLEREAD 用与运行在可重复读隔离级别的事务相同的锁语义执行扫描。
ROWLOCK 使用行级锁，而不使用粒度更粗的页级锁和表级锁。
SERIALIZABLE 用与运行在可串行读隔离级别的事务相同的锁语义执行扫描。等同于 HOLDLOCK。
TABLOCK 使用表锁代替粒度更细的行级锁或页级锁。在语句结束前，SQL Server 一直持有该锁。但是，如果同时指定 HOLDLOCK，那么在事务结束之前，锁将被一直持有。
TABLOCKX 使用表的排它锁。该锁可以防止其它事务读取或更新表，并在语句或事务结束前一直持有。
UPDLOCK 读取表时使用更新锁，而不使用共享锁，并将锁一直保留到语句或事务的结束。UPDLOCK 的优点是允许您读取数据（不阻塞其它事务）并在以后更新数据，同时确保自从上次读取数据后数据没有被更改。
XLOCK 使用排它锁并一直保持到由语句处理的所有数据上的事务结束时。可以使用 PAGLOCK 或 TABLOCK 指定该锁，这种情况下排它锁适用于适当级别的粒度

——解决方案——————–
SQL code
就启明星提出的在SQL Server中使用加锁的问题，我就以前的经验和收集的一些资料简单的提出我自己的一些看法，不知道对启明星是否有所帮助：
一般而言，下面是个典型的打开数据库的过程。
<%
’游标类型
Const adOpenForwardOnly = 0
Const adOpenKeyset = 1
Const adOpenDynamic = 2
Const adOpenStatic = 3

’加锁类型
Const adLockReadOnly = 1
Const adLockPessimistic = 2
Const adLockOptimistic = 3
Const adLockBatchOptimistic = 4
>%

<% set conn = server.createobject(’adodb.connection’) >%
<% set rsmov = server.createobject(’adodb.recordset’) >%
<% conn.open ’soc’, ’’, ’’ >%
<% rsmov.open sqlmov, conn, adopenkeyset, adlockreadonly >%
游标使用时是比较灵活的，它有时用来描述一个记录集，有时又是用来描述当前记录集中某一条记录的指针。游标主要是用来建立一个关系数据库中行/列关系的一种SQL可利用的访问格。与游标有关系的技术术语还有一个叫Bookmark的。如果你选择的游标方式支持Bookmarks。数据库将提供有关记录数目的强大功能。在上面写出的那么多游标方式中，adOpenDynamic是没有太的用处的，虽然它提供实时显示数据库中的记录的所有更新操作的功能，但是因为并不是所有的数据库都支持该游标方式，没有移植性的游标方式对当前错综复杂的数据库来说真是用处不大。在实际的编程中，我相信大家使用得最频繁的是adOpenStatic方式，当然这种方式的缺点是不能够就、实时反应出数据库中内容改变时的状况。如果要想看到数据库被其它用户改变的状况，可使用adOpenKeyse方式（但是它只能够反应出被编辑的改变情况，也就是说不能够反映出新增和删除记录的改变情况。）
其实上面的内容大家一般都可以在微软的技术参考资料中找到，下面来说说在使用这些游标
方式和加锁方式时要注意到的问题。
1。首先要注意到的是这两种方式在混合使用时的问题，就是说你同时设置游标方式和加锁方式。
除非你是在使用Access数据库，一般而言当你混合使用时是并不能够得到你预期想要的游标方式和加锁方式的。例如，如果你同时将游标设置为adOpenStatic方式，而将加锁设置为adLockOptimistic，你将得不到adOpenStatic方式的游标，你这时使用的游标方式将是
adOpenKeyset，也就是说你使用ADO的话，它将返回adOpenKeyset的游标。
2。其次，游标和加锁的混合使用还会导致ADO返回的不是你想要的加锁方式，ADO会改变你的加锁
方式。例如，在默认状态下游标方式是adOpenForwardOnly，在使用这种游标方式的同时如果
你使用的加锁方式为-1（就是让数据源来判断加锁方式）或则adLockReadOnly，那么这种混合方式基本上不支持RecordSet的任何方法，也就是说RecordSet的任何方法将返回False
(你的recordcount,absoultpage,addnew,delete,update等都会返回-1，-1就是表示不支持该属性)，但是这时如果你使用的是adOpenForwardOnly游标方式和其它的加锁方式混合，它反而
会支持填加，删除和更新。

————————————————————————–

SELECT 语句中“加锁选项”的功能说明

SQL Server提供了强大而完备的锁机制来帮助实现数据库系统的并发性和高性能。用户既能使用SQL Server的缺省设置也可以在select 语句中使用“加锁选项”来实现预期的效果。 本文介绍了SELECT语句中的各项“加锁选项”以及相应的功能说明。
功能说明：
NOLOCK（不加锁）
此选项被选中时，SQL Server 在读取或修改数据时不加任何锁。 在这种情况下，用户有可能读取到未完成事务（Uncommited Transaction）或回滚(Roll Back)中的数据, 即所谓的“脏数据”。

HOLDLOCK（保持锁）
此选项被选中时，SQL Server 会将此共享锁保持至整个事务结束，而不会在途中释放。

UPDLOCK（修改锁）
此选项被选中时，SQL Server 在读取数据时使用修改锁来代替共享锁，并将此锁保持至整个事务或命令结束。使用此选项能够保证多个进程能同时读取数据但只有该进程能修改数据。

TABLOCK（表锁）
此选项被选中时，SQL Server 将在整个表上置共享锁直至该命令结束。 这个选项保证其他进程只能读取而不能修改数据。

PAGLOCK（页锁）
此选项为默认选项， 当被选中时，SQL Server 使用共享页锁。

TABLOCKX（排它表锁）
此选项被选中时，SQL Server 将在整个表上置排它锁直至该命令或事务结束。这将防止其他进程读取或修改表中的数据。

使用这些选项将使系统忽略原先在SET语句设定的事务隔离级别（Transaction Isolation Level)。 请查阅SQL Server 联机手册获取更多信息。
————————————————————————-

1 如何锁一个表的某一行

A 连接中执行

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ

begin tran

select * from tablename with (rowlock) where id=3

waitfor delay ’00:00:05’

commit tran

B连接中如果执行

update tablename set colname=’10’ where id=3 –则要等待5秒

update tablename set colname=’10’ where id <>3 –可立即执行

2 锁定数据库的一个表

SELECT * FROM table WITH (HOLDLOCK)

注意: 锁定数据库的一个表的区别

SELECT * FROM table WITH (HOLDLOCK)
其他事务可以读取表，但不能更新删除

SELECT * FROM table WITH (TABLOCKX)
其他事务不能读取表,更新和删除

select * from table with (..)

SELECT 语句中“加锁选项”的功能说明
SQL Server提供了强大而完备的锁机制来帮助实现数据库系统的并发性和高性能。用户既能使用SQL Server的缺省设置也可以在select 语句中使用“加锁选项”来实现预期的效果。 本文介绍了SELECT语句中的各项“加锁选项”以及相应的功能说明。
功能说明：
NOLOCK（不加锁）
此选项被选中时，SQL Server 在读取或修改数据时不加任何锁。 在这种情况下，用户有可能读取到未完成事务（Uncommited Transaction）或回滚(Roll Back)中的数据, 即所谓的“脏数据”。

HOLDLOCK（保持锁）
此选项被选中时，SQL Server 会将此共享锁保持至整个事务结束，而不会在途中释放。

UPDLOCK（修改锁）
此选项被选中时，SQL Server 在读取数据时使用修改锁来代替共享锁，并将此锁保持至整个事务或命令结束。使用此选项能够保证多个进程能同时读取数据但只有该进程能修改数据。

TABLOCK（表锁）
此选项被选中时，SQL Server 将在整个表上置共享锁直至该命令结束。 这个选项保证其他进程只能读取而不能修改数据。

PAGLOCK（页锁）
此选项为默认选项， 当被选中时，SQL Server 使用共享页锁。

TABLOCKX（排它表锁）
此选项被选中时，SQL Server 将在整个表上置排它锁直至该命令或事务结束。这将防止其他进程读取或修改表中的数据。

使用这些选项将使系统忽略原先在SET语句设定的事务隔离级别（Transaction Isolation Level)。 请查阅SQL Server 联机手册获取更多信息。

————————————————

什幺是事务
事务(Transaction)是并发控制的基本单位。所谓事务,它是一个操作序列，这些操作要幺都执行，要幺都不执行，它是一个不可分割的工作单位。例如，银行转帐工作：从一个帐号扣款并使另一个帐号增款，这两个操作要幺都执行，要幺都不执行。所以，应该把他们看成一个事务。事务是数据库维护数据一致性的单位，在每个事务结束时，都能保持数据一致性。

数据一致性问题
多用户并发存取同一数据将会导致以下的数据不一致性问题。
• 丢失修改（ Lost Update）
在下表中，T1、T2、T3和T4表示顺序的时间。
用户T 1T 2T 3T 4
Ax = 40X = x-30
BX = 40X = x-20

假设用户A和B都读取x ( x = 40 ) ,然后分别把x减少30和20。用户A在t3把改后的x ( x = 10 )写入数据库。随后，用户B在t4把改后的x ( x = 20 )写入数据库。于是，对用户A而言，他的修改在t4
处丢失了。
• 脏读数据（ Dirty Read）
请看下表，
用户T1T2T3T4
Ax = 40X = x + 30X = x – 30rollback
BX = 70X = x-20
用户A在t2把x增加30（尚没写入数据库），用户B在t3由数据缓存读出x = 70。但用户A在t4时撤消（Undo）了对x的修改，数据库中仍维持x = 40。但用户B已把改变的数据（ x = 70）取走。
• 不能重复读（Non-Repeatable Read）
用户T1T2T3T4T5T6
AX=40Y=30 X+Y=70Z=30 X+Y+Z=100
Bx=40X=X+20CommitX=x-20
用户A、用户B分别读取x = 40后，在t 3用户A取出y = 30并计算x + y = 70。在t4时用户B把x增加20，并于t 5把x ( x = 60 )写入数据库。在t6时，用户A取出z ( z = 30 )并继续计算x + y + z = 100。但如果用户A为进行核算而把x、y、x重读一次再进行计算，却出现x + y + z = 120！（x已增加20）。

如何标识一个事务
在SQL Server中，通常事务是指以BEGIN TRAN开始，到ROLLBACK或一个相匹配的COMMIT之间的所有语句序列。ROLLBACK表示要撤消（ U n d o）该事务已做的一切操作，回退到事务开始的状态。COMMIT表示提交事务中的一切操作，使得对数据库的改变生效。
在SQL Server中，对事务的管理包含三个方面：
• 事务控制语句：它使程序员能指明把一系列操作（ Transact – SQL命令）作为一个工作单
位来处理。
• 锁机制（ Locking）：封锁正被一个事务修改的数据，防止其它用户访问到“不一致”的数据。
• 事务日志( Transaction Log)：使事务具有可恢复性。

SQL Server的锁机制
所谓封锁,就是一个事务可向系统提出请求，对被操作的数据加锁( Lock )。其它事务必须等到此事务解锁（ Unlock）之后才能访问该数据。从而，在多个用户并发访问数据库时,确保不互相干扰。可锁定的单位是：行、页、表、盘区和数据库。
1. 锁的类型
SQL Server支持三种基本的封锁类型：共享（ S）锁，排它（X）锁和更新（U）锁。封锁的基本粒度为行。
1) 共享（S）锁：用于读操作。
• 多个事务可封锁一个共享单位的数据。
• 任何事务都不能修改加Ｓ锁的数据。

通常是加Ｓ锁的数据被读取完毕，Ｓ锁立即被释放。
2) 独占（Ｘ）锁：用于写操作。
• 仅允许一个事务封锁此共享数据。
• 其它任何事务必须等到Ｘ锁被释放才能对该数据进行访问。
• Ｘ锁一直到事务结束才能被释放。
3) 更新（Ｕ）锁。
• 用来预定要对此页施加Ｘ锁，它允许其它事务读，但不允许再施加Ｕ

锁或Ｘ锁。
• 当被读取数据页将要被更新时，则升级为Ｘ锁。
• Ｕ锁一直到事务结束时才能被释放。
2. 三种锁的兼容性
如下表简单描述了三种锁的兼容性：
通常，读操作（SELECT）获得共享锁，写操作（ INSERT、DELETE）获得独占锁；而更新操作可分解为一个有更新意图的读和一个写操作，故先获得更新锁，然后再升级为独占锁。
执行的命令获得锁其它进程可以查询？其它进程可以修改？
Select title_id from titlesSYesNo
delete titles where price>25XNoNo
insert titles values( …)XNoNo
update titles set type=“general”UYesNo
where type=“business”然后ＸNONo

使用索引降低锁并发性
我们为什幺要讨论锁机制？如果用户操作数据时尽可能锁定最少的数据，这样处理过程,就不会等待被锁住的数据解锁，从而可以潜在地提高SQL Server的性能。如果有200个用户打算修改不同顾客的数据，仅对存储单个顾客信息的单一行进行加锁要比锁住整个表好得多。那幺，用户如何只锁定行而不是表呢？当然是使用索引了。正如前面所提到的，对存有要修改数据的字段使用索引可以提高性能，因为索引能直接找到数据所在的页面，而不是搜索所有的数据页面去找到所需的行。如果用户直接找到表中对应的行并进行更新操作，只需锁定该行即可，而不是锁定多个页面或者整个表。性能的提高不仅仅是因为在修改时读取的页面较少，而且锁定较少的页面潜在地避免了一个用户在修改数据完成之前其它用户一直等待解锁的情况。

事务的隔离级别
ANSI标准为SQL事务定义了4个隔离级别(isolation level)，隔离级别越高,出现数据不一致性的可能性就越小(并发度也就越低)。较高的级别中包含了较低级别中所规定了的限制。
• 隔离级别0：防止“丢失修改”，允许脏读。
• 隔离级别1：防止脏读。允许读已提交的数据。
• 隔离级别2：防止“不可重复读”。
• 隔离级别3：“可串行化”（serializable）。其含义为，某组并行事务的一种交叉调度产生的结果和这些事务的某一串行调度的结果相同（可避免破坏数据一致性）。SQL Server支持四种隔离级别，级别1为缺省隔离级别，表中没有隔离级别2， 请参考表：
SQL Server支持的隔离级别封锁方式数据一致性保证
X锁施加于被修改的页S锁施加于被读取的页防止丢失修改防止读脏数据可以重复读取
级别0封锁到事务结束是
级别1（缺省）封锁到事务结束读后立即释放是是
级别3封锁到事务结束封锁到事务结束是是是
在SQL Server也指定级别2，但级别3已包含级别2。ANSI-92 SQL中要求把级别3作为所有事务的缺省隔离级别。
SQL Server用holdlock选项加强S锁的限制，实现隔离级别3。SQL Server的缺省隔离级别为级别1，共享读锁（S锁）是在该页被读完后立即释放。在select语句中加holdlock选项，则可使S锁一直保持到事务结束才释放。她符合了ANSI隔离级别3的标准─“可串行化”。

下面这个例子中，在同一事务中对avg ( advance )要读取两次，且要求他们取值不变─“可重复读”，为此要使用选项holdlock。
BEGIN tran
DECLARE @avg-adv money
SELECT @avg-adv = avg(advance)
FROM titles holdlock
WHERE type = “business“
if @avg-adv > 5000
SELECT title from titles
WHERE type=“business“ and advance >@avg_adv
COMMIT tran
在SQL Server中设定事务隔离级别的方法有三种：

• 会话层设定
语法如下：
SET TRANSACTION ISOLATION LEVEL
{
READ COMMITTED
| READ UNCOMMITTED
| REPEATABLE READ
| SERIALIZABLE
}
系统提供的系统存储过程将在级别1下执行，它不受会话层设定的影响。
• 语法层设定
在SELECT、DECLARE cursor及read text语句中增加选项。比如：
SELECT…at isolation{0|read uncommitted}
注意：语法层的设定将替代会话层的设定。
• 利用关键词设定
─在SELECT语句中，加选项holdlock则设定级别3
─在SELECT语句中，加noholdlock则设定级别0

如下程序清单中所列的脚本实例在authors表上持有一个共享锁，它将用户检查服务器当前活动的时间推迟两分钟。
程序清单测试事务隔离等级
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
GO
BEGIN TRAN
SELECT *
FROM authors
WHERE au_lname = ’Green’
WAITFOR DELAY ’00:02:00’
ROLLBACK TRAN
GO
Activity Legend(活动图标)表明：当SQL Server检索数据时会去掉页面表意向锁。Current Activity窗口(见图3 – 3 )显示共享锁一直被保持直到事务完成为止(也就是说，直到WAITFOR和ROLLBACK TRAN语句完成)。
使用锁定优化程序提示
让我们再深入考察程序清单的实例。通过改变优化程序提示，用户可以令SQL Server在authors表上设置一个独占表锁(如程序所示)。
BEGIN TRAN
SELECT *
FROM authors (tablockx)
WHERE au_lname = ’Green’
WAITFOR DELAY ’00:02:00’
ROLLBACK TRAN
GO