0%

如果是可重复读隔离级别,事务T启动的时候会创建一个视图 read-view,之后事务 T 执行期间,即使有其他事务修改了数据,事务 T 看到的仍然跟在启动时看到的一样。也就是说,一个在可重复读隔离级别下执行的事务,好像与世无争,不受外界影响。但在MySQL锁机制中一个事务要更新一行,如果刚好有另外一个事务拥有这一行的行锁,它会被锁住,进入等待状态。问题是,既然进入了等待状态,那么等到这个事务自己获取到行锁要更新数据的时候,它读到的值又是什么呢?

mark

关于MySQL的锁机制问题,在之前的博客中有谈到 《探究MySQL锁机制》 ,里面对锁的讲解比较详细,现在是在原来的基础上谈谈数据库事务相关的问题。简单来说事务就是要保证一组数据库操作,要么全部成功,要么全部失败。在MySQL中,事务支持是在引擎层实现的。你现在知道,MySQL是一个支持多引擎的系统,但并不是所有的引|擎都支持事务。比如MySQL原生的MyISAM引擎就不支持事务,这也是MyISAM被InnoDB取代的重要原因之一。首先要知道的是数据库事务四大特性:ACID

密集索引:文件中的每个搜索码值都对应一个索引值,就是叶子节点保存了整行,比如InnoDB

稀疏索引:文件只为索引码的某些值建立索引项,比如MyISAM

mark

密集索引的表数据按顺序存储,即索引顺序和表记录物理存储顺序一致,所以一个表只能创建一个密集索引

其实在之前的文章说说到过MySQL索引,只不过没细说, 《JOIN查询与索引简介》 ,现在来看看回顾一下索引相关的数据结构,首先看看索引的定义: 索引(Index)是帮助MySQL高效获取数据的数据结构。 我不会索引就是类似于字典这样的话泛泛而谈,而是如何真正去理解索引。

mark

HTTP协议的信息传输完全以明文方式,不做任何加密,相当于是在网络上"裸奔"。意思就是如果我们以HTTP来传输数据的话由于是明文数据,则很容易发生不安全事故,比如我登陆一个网站,那么如果是HTTP明文传输肯定就会直接把用户名和密码放在明文中,这样是非常不安全的,处在同一个局域网下的小伙伴直接抓包就可以获取你的用户名和密码,那么应该怎么办呢?

mark

之前介绍了TCP的报文格式( 《TCP协议基本特性》 ),TCP的连接管理,学习了TCP如何建立连接,释放连接以及一些网络安装方面的问题,现在还剩下TCP的几个关键机制,主要是TPC的延迟应答和捎带应答、超时重传、快重传和快恢复、滑动窗口机制、拥塞避免算法;然后最后还记录了TCP的粘包问题和解决方案!

HTTP的全称 HyperText Transfer Protocol,即超文本传输协议,程序员自己发明的协议之一,基于TCP的应用层协议。 HTTP协议是基于请求-响应的模式:

mark

HTTP是一种无状态协议,HTTP协议自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个级别,协议对于发送过的请求或响应都不做持久化处理。

mark

现在即将开始真正踏上构造自己的容器的道路。我们会基于当前的操作系统创建一个与宿主机隔离的容器环境,下面就开始吧。在开始之前我们需要先对Linux的proc文件系统做一个介绍:

如果你对这些基本知识已经很熟悉了,请直接略过。Linux下的/proc文件系统是由内核提供的,它其实不是一个真正的文件系统,只包含了系统运行时的信息(比如系统内存、mount设备信息、一些硬件配置等),它只存在于内存中,而不占用外存空间。它以文件系统的形式,为访问内核数据的操作提供接口。实际上,很多系统工具都是简单地去读取这个文件系统的某个文件内容,比如lsmod,其实就是cat /proc/modules。当遍历这个目录的时候,会发现很多数字,这些都是为每个进程创建的空间,数字就是它们的PID。

mark