nessus 特征库更新插件为什么特征库需要更新

转载

编程艺术大师 2024-06-29 21:25:15

文章标签 nessus 特征库更新插件数据库 c/c++ golang 客户端 文章分类 架构后端开发

1.目的

1.1 合适人群

1.数据库事务特征我只是背过，并没有很深刻的理解。
2.数据库事务的隔离级别只是了解，并没有深刻理解，也没有在实际工作中体验使用过。
3.经常面试被人问起数据库加锁情况，一头雾水，很懵。
4.在网上找过很多博客，有的写得太多没耐心看，有的写得摘抄的定义，泛泛而谈，没有实操更没有讲解。
5.福利彩蛋

1.2 关于这篇分享对以上问题的解决

1.实践出真知，如果认真读完，并实操，实操过后反复咀嚼，相信上面的问题，除了你有没有耐心看等主观因素，其他的都能一一解决。
2.希望这是理解数据库事务问题的一篇好文章。
3.如果有什么问题，请评论下， 我们多交流谢谢。

2.事务本质剖析

2.1 什么是事务？

2.2.1 如下表格所示：

| 事务类别(不考虑分布式事物) | 事务本质 | 并发事务解决方案|并发事务方案解决的问题|并发事务解决方案实现原理|
| -----| ----- | ----- | -----| ----- | ----- |
| 数据库事务(狭义理解)| 数据库sql执行过程 | 控制事务隔离级别 | 确保数据完整、安全、一致性，在此基础上实现高性能访问（鱼和熊掌不可兼得） |不同的加锁策略|
| 应用层事务(广义理解)| 业务逻辑 | 制定多线程访问策略，如悲观锁(同步)、乐观锁（无锁，CAS思想） | 确保线程之间操作不会相互影响，保证各访问能保证得到期望结果，并在此基础上实现最大可能性的高性能访问 |不同的加锁策略|

2.2.2 对上述表格内容的解释

##msyql事务
1.mysql:传统理解 mysql 中的一次操作过程(sql 执行)是一次事务。
2.mysql:那么多个线程 同时操作 mysql 中的数据（同一条数据，一个范围内数据）就叫并发事务。
3.mysql:数据库层面使用不同的事务隔离级别来进行并发事务的控制，不同的隔离级别是因为数据库中内部锁机制的使用方式不同，例如有的是在select完成之后立马释放锁，有的是在整个事务commit 之后释放锁
。
--------------------------------------------------------------------------------------------------------------
##应用层事务
1.应用：其实每一个线程调用服务本质上也是事务。
2.应用：多个线程同时调用服务，叫并发调用服务，也可以叫并发事务。
3.应用：应用层应对并发事务(访问)解决方案有同步(悲观锁)、乐观锁(无锁CAS)。我们对并发访问做系统应用层控制也会使用到锁。

个人理解这就是事务的本质。事务不应该只仅限于数据库。

2.2 关于ACID

举例子说明

1.A 原子性：事务可以简单理解为一次数据库操作，也就是执行sql的过程，要么执行，要么不执行，整个执行结果只有两种执行成功，执行失败。
2.C 一致性：A有100块钱，转1块钱给另外一个帐户，还有99块钱，在整个事务执行过程中，钱数总是100块，不会变，这就是一致性。
3.I 隔离性：事务执行过程相互隔离，不会相互之间产生影响（这只是美好的愿望）。意思是多个事务并发执行的话，结果应该与多个事务串行执行效果是一样的。但并发情况下需要考虑性能，所以就需要在隔离性上做些手脚（妥协），也就是制定不同的隔离级别达到不同的并发性能。
4.D 持久性：事务每一次的执行结果都应该持久化（存储）到数据库中（磁盘数据）。想想除了select，其他的update/delete/insert都会产生这样的结果，持久化在应用场景中是必须的，除非你写了假接口。哈哈。

3.数据库事务的隔离级别

3.1 为什么需要隔离级别?

1.四个特性之隔离性的体现。
2.对不同并发事务应用场景提供不同解决方案。解决方案本质，加锁。
3.如果不需要隔离别会出现什么情况？
   假设一个场景，数据库中任何数据在被并发 curd 时不设置隔开级别，也就是不加锁，情景平移，我们学习多线程时，对线程对公共变量的并发操作不加锁会导致各种异常情况的发生。所以不设置数据库隔离级别，数据的变化我们是不能祈求数据库中数据按照我们预期去改变的。

现在我们知道数据库隔离级别的必要性，接下来讨论不同隔离级别会带来的问题。

3.2 不同隔离级别带来的问题（重要！含实操部分，最好可以实践下）

1.前置条件--几个概念的理解（重要）

不同隔离级别带来的数据操作问题：
 1.脏读：两个事务，t1事务可以读取到t2事务正在做更改的数据的中间状态(t2事务执行过程中)，而这个数据的更改有可能不会被持久化(commit)，而是rollback，导致t1在同一事务内的两次读取同一行数据得到结果不同。
 2.不可重复读：t1事务在整个事务执行过程中读取某一条记录多次，发现读取的此条记录不是每次都一样。
 3.幻读：t1事务在整个事务执行过程中读取某一范围内的数据，在第二次读取时发现多了几行或者少了几行。
-----------------------------------------------------------------------------------------------
数据库中的几种隔离级别
read uncommited--读未提交
    该隔离级别指即使一个事务的更新语句没有提交,但是别的事务可以读到这个改变，几种异常情况都可能出现。极易出错，没有安全性可言，基本不会使用。
read committed --读已提交
    该隔离级别指一个事务只能看到其他事务的已经提交的更新，看不到未提交的更新，消除了脏读和第一类丢失更新，这是大多数数据库的默认隔离级别，如Oracle,Sqlserver。
repeatable read --可重复读
    该隔离级别指一个事务中进行两次或多次同样的对于数据内容的查询，得到的结果是一样的，但不保证对于数据条数的查询是一样的，只要存在读改行数据就禁止写，消除了不可重复读和第二类更新丢失，这是Mysql数据库的默认隔离级别。
serializable --序列化读
     意思是说这个事务执行的时候不允许别的事务并发写操作的执行.完全串行化的读，只要存在读就禁止写,但可以同时读，消除了幻读。这是事务隔离的最高级别，虽然最安全最省心，但是效率太低，一般不会用。
------------------------------------------------------------------------------------------------
数据库中的锁：
1.共享锁（Share locks简记为S锁）：也称读锁，事务A对对象T加s锁，其他事务也只能对T加S，多个事务可以同时读，但不能有写操作，直到A释放S锁。

2.排它锁（Exclusivelocks简记为X锁）：也称写锁，事务A对对象T加X锁以后，其他事务不能对T加任何锁，只有事务A可以读写对象T直到A释放X锁。

3.更新锁（简记为U锁）：用来预定要对此对象施加X锁，它允许其他事务读，但不允许再施加U锁或X锁；当被读取的对象将要被更新时，则升级为X锁，主要是用来防止死锁的。因为使用共享锁时，修改数据的操作分为两步，首先获得一个共享锁，读取数据，然后将共享锁升级为排它锁，然后再执行修改操作。这样如果同时有两个或多个事务同时对一个对象申请了共享锁，在修改数据的时候，这些事务都要将共享锁升级为排它锁。这些事务都不会释放共享锁而是一直等待对方释放，这样就造成了死锁。如果一个数据在修改前直接申请更新锁，在数据修改的时候再升级为排它锁，就可以避免死锁。

接下来化繁为简，配合实操，来看看每种隔离级别场景。不要觉得繁琐，一定要读下去。

演示场景配置：
数据库：mysql 5.7
命令行工具：iterm2.0

1.read uncommited--读未提交
前置条件：
1.开启两个 mysql 客户端终端

nessus 特征库更新插件为什么特征库需要更新_c/c++

开启客户端终端.png

2.查看当前客户端事务隔离级别

命令为：select @@session.tx_isolation;

nessus 特征库更新插件为什么特征库需要更新_nessus 特征库更新插件_02

屏幕快照 2017-03-24 下午2.05.57.png

3.选择数据库，建立演示表test，并设置当前客户端事务隔离级别为read uncommitted.

1.mysql> show databases;
2.mysql> use 你的演示数据库
3.mysql> CREATE TABLE `test` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=20 DEFAULT CHARSET=utf8;
4.insert into test values(1,'张三'),(2,'李四'),(3,'王五');  
4.select @@session.tx_isolation;
5.set session transaction isolation level read uncommitted;
6.select @@session.tx_isolation;

注意：两个客户端都需执行set session transaction isolation level read uncommitted;

4.客户端1，客户端2设置事务提交模式为 set autocommit = 0;表示关闭默认的自动提交事务功能。

命令：set autocommit = 0;

5.开启事务

begin;

6.客户端1 执行如下脚本

select name from test where id = 1 ;

结果如下图所示：

nessus 特征库更新插件为什么特征库需要更新_nessus 特征库更新插件_03

屏幕快照 2017-03-24 下午3.53.29.png

7.客户端2 执行如下脚本

update test set name = '张八' where id = 1;

结果如下图所示：

nessus 特征库更新插件为什么特征库需要更新_nessus 特征库更新插件_04

屏幕快照 2017-03-24 下午3.57.05.png

8.切换到客户端1执行如下脚本

select name  from test where id = 1;

结果如下图所示：

nessus 特征库更新插件为什么特征库需要更新_客户端_05

屏幕快照 2017-03-24 下午3.58.28.png

我们发现此时客户端1再次读id = 1的记录时，name 已经从 ‘张三’ 更改为 ‘张八’。

我们继续执行下一步操作
9.客户端2执行回滚操作,脚本如下所示

rollback;

结果如下所示：

nessus 特征库更新插件为什么特征库需要更新_客户端_06

屏幕快照 2017-03-24 下午4.00.41.png

10.客户端1继续查看id ＝ 1的记录,如下脚本

select name from test where id = 1;

结果如下所示：

nessus 特征库更新插件为什么特征库需要更新_nessus 特征库更新插件_07

屏幕快照 2017-03-24 下午4.02.27.png

我们发现在客户端1的一次事务中id ＝ 1 的记录的name 发生了变化，这种变化就称之为脏读。
下面我们分析下 read uncommitted 情况下的加锁情况。
吐槽一句，现在网上的博客对这个隔离级别的加锁分析五花八门。
分为三大门派：

1.美团博客说不加锁，链接在这：http://tech.meituan.com/innodb-lock.html 
2.还有说读不加锁（这个我认同），写加行级共享锁。链接在这：
[http://www.hollischuang.com/archives/943](http://www.hollischuang.com/archives/943)
3.还有说读不加锁，写加行级排他锁（这个我也认同，我做过实践，稍后会演示），但是说写完立马释放行级排他锁。

那么到底是什么样子呢，我们看一下：
演示过程，打开3个命令行终端，其中两个做演示，最后一个客户端查询当前 innodb 锁状态设置事务隔离级别为read uncommitted。
做如下演示：
1.客户端1做如下操作：

update test set name = 'fxliutao' where id = 32;

nessus 特征库更新插件为什么特征库需要更新_golang_08

屏幕快照 2017-03-26 下午2.53.34.png

2.客户端2做与客户端相同操作，如下所示

update test set name = 'fxliutao' where id = 32;

我们发现update 操作并没有执行，而是静止了
如下图所示我们分析了在客户端2锁等待情况下的加锁情况：
命令为：

select * from information_schema.INNODB_LOCKS\G;

nessus 特征库更新插件为什么特征库需要更新_客户端_09

屏幕快照 2017-03-26 下午2.58.48.png

可以得出结论，read uncommitted 隔离级别下，写操作是有锁的，而且是 X 排他锁，可以灭掉上述两个门派。

并且我们看下上述客户端2情景下的事务状态
如下图所示：

nessus 特征库更新插件为什么特征库需要更新_golang_10

屏幕快照 2017-03-26 下午3.04.47.png

trx_id 为208579的代表的就是客户端2的事务，trx_state代表的是锁状态，代表客户端2的事务处于锁等待状态，为什么是锁等待状态呢，因为客户端2的事务在更改 id ＝ 32 的记录时在主键上添加了 X(行级排他锁) 锁，你可能会有疑问，客户端1 的更新动作不是已经完成了么，那么客户端1 肯定已经释放了在主键 id = 32 上的排他锁了呀，要不为什么客户端2 能读到客户端1 更改 id = 32 记录后的脏数据呢？
但是真正的真相是客户端1在更新完后并没有释放排他锁，因为如果释放成功，那么客户端2的事务是能将 id ＝ 32 的记录更新成功的，但是并没有。那既然客户端1在更新完后并没有释放排他锁，那客户端2为什么还能读到脏数据呢，这跟排他锁的属性是相悖的呀(排他锁会阻塞除当前操作外的其他事务的所有读写操作)。
这就是最矛盾的问题，我再SqlServer的官网上找到这句话，事实上也正是这句话让我茅塞顿开，如下：

Transactions running at the READ UNCOMMITTED level do not issue shared locks to prevent other transactions from modifying data read by the current transaction. READ UNCOMMITTED transactions are also not blocked by exclusive locks that would prevent the current transaction from reading rows that have been modified but not committed by other transactions. When this option is set, it is possible to read uncommitted modifications, which are called dirty reads. Values in the data can be changed and rows can appear or disappear in the data set before the end of the transaction. This option has the same effect as setting NOLOCK on all tables in all SELECT statements in a transaction. This is the least restrictive of the isolation levels.

翻译是：

在READ UNCOMMITTED级别运行的事务不会发出共享锁，以防止其他事务修改当前事务读取的数据。读取UNCOMMITTED事务也不被排他锁阻止，这将阻止当前事务读取已被修改但未被其他事务提交的行。设置此选项时，可以读取未提交的修改，称为脏读。可以更改数据中的值，并且行可以在事务结束之前在数据集中显示或消失。此选项与在事务中的所有SELECT语句中的所有表上设置NOLOCK具有相同的效果。这是隔离级别的最小限制。

看到了吧读取UNCOMMITTED事务也不被排他锁(排他锁将阻止当前事务读取已被修改但未被其他事务提交的行)阻止
其实想想也对，应为排它锁对任何其他的事务开始之前申请的排它锁，共享锁都不兼容。但是如果我读不申请锁，就不会产生上述问题了呀。

所以最终结论是：read uncommitted 读不加锁，写加排他锁，并到事务结束之后释放。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。