在现在大数据、高并发，到处都充斥着流量的互联网时代，能不能应对高并发俨然已经发展成一个衡量服务端架构是否合格的标准，作为程序媛我们思考如何利用语言在代码层面最优设计能应对并发的程序去并行处理任务。在程序中对于任务并行处理一般趋于使用：进程、线程，以及另外一种：协程。支持协程的语言有很多，比如：C/C++、Ruby、 Python（2.5+）、Golang等等，它们有些是本身语言支持协程，有些则是需要引入第三方包来使用。不过，我们主要来学习一下Golang这门语言（简称Go），它是如何理解以及实现协程的。

一、进程、线程和协程的前世今生

都知道一台计算机的核心是CPU，它承担着所有的运算。而计算机承载的操作系统（内核）则是负责所有任务的处理和调度CPU以及资源的分配。如果用人类来比喻，大脑是CPU，思维则是操作系统（内核）。

进程

最早的计算机每次只能运行一个程序，如果还有其他程序需要执行则要排队等待。后来CPU运算能力提高了，这种方式过于原始有些浪费性能，于是尝试让多个程序可以并行执行，但是这样面临一个新的问题：跑在同一个CPU中的程序都会使用计算机资源，那程序的运行状态和数据怎么保障？进程。

1

进程是内核资源管理分配的最小单位，每个进程都有独立的虚拟地址空间。内核中的每个程序都运行在独立进程的上下文中，上下文是由程序正常运行需要的一系列参数组成，参数包括存储器中的代码和数据，寄存器中的内容以及进程打开的文件描述符（文件句柄）等。可以把上下文通俗理解为：`环境`。

如果程序在运行过程中需要进行IO操作，IO操作阻塞了程序后面的计算，这时候CPU属于空闲状态，那内核会把CPU切换到其他进程去处理。不过当进程数量变高以后，计算机的大部分资源都被进程切换这个操作消耗掉了。为什么说进程切换操作消耗资源代价比较高？

1

所谓进程切换其实就是上下文切换，需要切换新的页表并加载新的虚拟地址空间、切换内核栈以及硬件上下文等。只要发生进程切换操作就得反复进入内核，加载切换一系列状态。

线程

为了减少这种开销，线程应运而生。

1

线程是内核调度CPU执行的最小单位，线程是运行在进程上下文的逻辑流，线程是具体执行程序的单位。一个进程至少包含一个主线程（可以拥有多个子线程），但是一个线程只能存在于一个进程中。

线程切换相比进程切换开销就小了很多，线程切换只需要把寄存器刷新即可。

协程

后面程序媛们发现线程这样还是有性能瓶颈（IO阻塞），无论是进程还是线程因为涉及到大量的计算机资源，所以都是由内核调度管理。能不能开发一种由代码控制的线程呢？这就是协程。

在和小伙伴讨论问题的时候，小伙伴突然问了我这样一个小问题，数据库中如何查找连续编号中的缺失编号？

1.描述

场景大概是这样，有一份连续数据ID：1 … 27，其中ID：6，7，14的数据丢了。结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

CREATE TABLE `letter`  (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 27 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Compact;

INSERT INTO `letter` VALUES (1, 'A');
INSERT INTO `letter` VALUES (2, 'B');
INSERT INTO `letter` VALUES (3, 'C');
INSERT INTO `letter` VALUES (4, 'D');
INSERT INTO `letter` VALUES (5, 'E');
# INSERT INTO `letter` VALUES (6, 'F');
# INSERT INTO `letter` VALUES (7, 'J');
INSERT INTO `letter` VALUES (8, 'H');
INSERT INTO `letter` VALUES (9, 'I');
INSERT INTO `letter` VALUES (10, 'J');
INSERT INTO `letter` VALUES (11, 'K');
INSERT INTO `letter` VALUES (12, 'L');
INSERT INTO `letter` VALUES (13, 'M');
# INSERT INTO `letter` VALUES (14, 'N');
INSERT INTO `letter` VALUES (15, 'O');
INSERT INTO `letter` VALUES (16, 'P');
INSERT INTO `letter` VALUES (17, 'Q');
INSERT INTO `letter` VALUES (18, 'R');
INSERT INTO `letter` VALUES (19, 'S');
INSERT INTO `letter` VALUES (20, 'T');
INSERT INTO `letter` VALUES (21, 'U');
INSERT INTO `letter` VALUES (22, 'V');
INSERT INTO `letter` VALUES (23, 'W');
INSERT INTO `letter` VALUES (24, 'X');
INSERT INTO `letter` VALUES (25, 'Y');
INSERT INTO `letter` VALUES (26, 'Z');

怎么把6，7，14这三条数据找出来？方法有很多种哈，今天我们说一下如何利用SQL快速查询出来。大概思路是把ID+1，然后查询ID+1这个值是否存在ID列表中，如果不存在那肯定就是缺失的。SQL如下：

1
2
3
4
5
6

SELECT
	id + 1 AS id 
FROM
	`letter` 
WHERE
	id + 1 NOT IN ( SELECT id FROM `letter` )

但是这样会有一个小问题，就是MAX(id)+1（27）也会被查询出来，所以：

1
2
3
4
5
6
7
8
9
10
11
12

SELECT
	id + 1 AS id 
FROM
	`letter` 
WHERE
	id + 1 NOT IN ( SELECT id FROM `letter` ) 
	AND id <(
	SELECT
		max( id ) 
	FROM
	`letter` 
	)

2.优化

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

SELECT
	start_id,
	( SELECT MIN(id)- 1 FROM `letter` WHERE id > start_id ) AS end_id 
FROM
	(
	SELECT
		id + 1 AS start_id 
	FROM
		`letter` 
	WHERE
		id + 1 NOT IN ( SELECT id FROM `letter` ) 
		AND id <(
		SELECT
			max(id) 
		FROM
			`letter` 
		) 
	) AS max_id 
ORDER BY
	start_id

这种情况适用于查找整数类型的连续编号，那么如果编号是string类型的呢？后面有机会再补充进来=,=。

之前粗浅的学习了Redis三种集群策略的主从复制和哨兵策略，现在最后这篇来学习一下Redis Cluster也就是最后一个集群策略。

1.什么是集群？

集群（Cluster），Redis2.6版本（正式版本是3.0）推出的分布式解决方案，有效解决了单Master节点写操作的压力并且分布式存储数据，大大提高了负载能力。

在Redis发布3.0正式版本前，一般使用代理中间件来实现分布式集群策略。这里不展开学习了，有兴趣的小伙伴自行研究。

• 特点

  1. Cluster策略是分布式部署，节点间相互协调工作。

     因为对主从复制和哨兵策略都称为集群策略，所以为了防止误解在下文中提及的集群（Cluster）策略，直接用Cluster称呼。

  2. Cluster至少要3个Master节点，并且是无中心化设计。
  3. 客户端使用Cluster，不需要连接所有节点，只需要连接Cluster中任意一个可用节点即可。
  4. 数据的分布式存储不需要指定，Cluster会自动完成。

• 优点

  1. Cluster策略拥有主从复制和哨兵策略的优点。
  2. 解决了单Master节点写操作的压力。
  3. 分布式存储数据，提高了负载能力。
  4. 支持线性扩容。

现在这篇来学习一下Redis Sentinel即哨兵策略的相关知识。

1.什么是哨兵？

哨兵（Sentinel），Redis2.6版本（正式版本是2.8，现2.6版本已被废弃）开始提供的一种集群策略，核心思想是解决了主从复制（Replication）在Master节点故障，无法自动切换Slave节点为新Master节点的问题。

• 特点

  1. 哨兵策略是分布式部署，节点间相互协调工作。
  2. 哨兵集群至少要3个节点。
  3. 可以把哨兵看作是一种特殊的Redis服务。

• 优点

  1. 哨兵策略拥有主从复制的优点。
  2. 哨兵策略解决了Master节点故障，无法自动切换Slave节点为新Master节点的问题。

Redis单点配置的情况下如果服务出现故障宕机，那么服务也就处于不可用状态，假如是生产环境那么带来的后果会有很严重，所以出现了高可用方案：集群策略。

1.三种集群策略

Redis提供了三种集群策略，它们分别是：

• 主从复制（Replication）
• 哨兵（Sentinel）
• 集群（Cluster）

这三种策略会逐一学习，本篇主要学习策略之一主从复制（Replication）。

2.主从复制的概念

在主从复制（Replication）策略中，服务分为两类：Master节点、Slave节点。

• 特点

  1. Master节点可以拥有多个Slave节点，但Slave节点只能服务一个Master节点。
  2. 数据复制方向只能是Master节点->Slave节点。

• 优点

  1. 实现了多机热数据备份，提高了面对宕机数据恢复的灾备能力。
  2. 在主从复制的基础上实现读写分离提高服务吞吐量，即：Master节点提供写服务，Slave节点提供读服务。
  3. 如果Master节点宕机可以快速切换使用Slave节点提供服务。

之前在复习Mysql主从知识的同时，小伙伴考了我一个问题，分片和分区有什么差别 … 乍一听可能只是名词上的不同，但其实它们俩的确不是同一个东西。

1.什么是分片（Sharding）？

我们举个例子，一张文章表。
结构如下：

1
2
3
4
5
6
7
8
9

CREATE TABLE `mark`.`article`  (
  `id` int NOT NULL AUTO_INCREMENT,
  `type` varchar(20) NOT NULL COMMENT '类型',
  `title` varchar(255) NOT NULL COMMENT '标题',
  `content` longtext NOT NULL COMMENT '内容',
  `author` varchar(20) NOT NULL COMMENT '作者',
  `date` datetime NOT NULL COMMENT '日期',
  PRIMARY KEY (`id`)
);

需求如下：

1. 用户打开app会直接展示文章列表（类型，标题，作者，日期）
2. 点击文章查看详情

那么这张表在数据量比较小的初期应对访问是没什么问题的。但是随着数据量日益膨胀，查询效率会越来越低，因为里面content字段非常巨大。

这时候要怎么优化呢？把content字段拆出去，因为访问最多的请求并不需要content，怎么拆呢？结构如下：

之前学习了LRU算法和Mysql缓冲池使用的LRU变体算法，其中有个共同点就是当LRU链表写满以后如果再有新数据进来会淘汰尾部的数据，那么Mysql淘汰这些尾部数据的时候是否会进行什么操作呢？这就是我们在最后提到了一个参数Modified db pages，即脏页。

1.什么是脏页？

• 脏页，这个名词很抽象从字面意思去看可能很不解，脏页是当内存中的数据页和磁盘中的数据页内容不一致时，这个数据页称之为脏页。因为从操作系统的角度来讲，自己读入的数据被外部所修改等于被污染，所以叫脏页。
• 当内存中的数据页和磁盘中的数据页数据一致，叫干净页。

2.脏页什么时候会刷新？

1. 缓冲池（buffer pool）空间不足，也就是LRU链表写满时，新数据进来时淘汰掉的尾部数据脏页。
2. redo log不可用时，需要强制将脏页列表中的一些数据页刷入磁盘。
3. Mysql在服务器负载较小时，会主动进行刷脏操作。
4. Mysql服务正常关闭，会刷新所有脏页。

3.什么是redo log？

InnoDB中两块非常重要的日志，一个是undo log，另外一个就是我们接下来要学习的redo log。前者用来保证事务的原子性以及InnoDB的MVCC（Mutil-Version Concurrency Control），后者用来保证事务的持久性。

那么什么时候写redo log呢？当数据库对数据做修改的时候，需要把数据页从磁盘读到缓冲池中，然后在缓冲池中进行修改。但是InnoDB采用的是WAL（Write Ahead Log）策略来防止数据丢失，也就是事务提交时，先写redo log才会再去修改内存数据页。

redo log的文件名默认以ib_logfile{NUM}，存储在my.cnf中datadir目录下面，受以下两个参数控制

• innodb_log_file_size，日志大小
• innodb_log_files_in_group，日志个数，默认是2个。

所以redo log的大小等于innodb_log_files_in_group*innodb_log_file_size。

既然redo log会产生，那么什么时候会被覆盖呢？redo log被设计成可循环使用，当日志文件写满时那些已经被刷入磁盘中的数据就可以被覆盖啦。

WAL（Write Ahead Log），是关系数据库系统中用于提供原子性和持久性（ACID属性中的两个）的一系列技术，ARIES是WAL系列技术常用的算法，在文件系统中WAL通常称为journaling。WAL的主要思想是将元数据的实时变更操作写入日志文件中，然后在系统负载较小时再把日志刷入磁盘。主要是为了减少磁盘的IO操作，此处就不展开学习了。先Mark一下

1.什么是LRU？

LRU（Least recently used，最近最少使用）算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“最近使用的页面数据会在未来一段时期内仍然被使用,已经很久没有使用的页面很有可能在未来较长的一段时间内仍然不会被使用”。

2.LRU的实现

LRU算法最常见的实现是使用链表来保存数据，该链表是双向链表，然后利用先进先出的特性，最新写入的数据会最快被获取。

• 访问不存在的数据时，缓存数据则会写入链表的头部，链表写满时会淘汰掉尾部的缓存数据。
• 当缓存数据被访问时，则将该缓存数据向链表头部移动。

优点：面对频繁访问的热点数据，查询效率高

缺点：如果一次查询扫描全表，那么LRU列表会被污染

3.Mysql LRU算法有何不同？

Mysql（InnoDB）的缓冲池（buffer pool）使用了LRU算法的变体，将链表分为三个部分：young、midpoint、old。链表比例(5、3)分配给young、old。其中young占据5/8，old占据3/8，此比例受参数innodb_old_blocks_pct控制。

young是链表中最近访问过的新子表。

old是链表中最近访问的旧子表。

midpoint是介于新子表 & 旧子表的边界中间位置（也可以理解为旧子表的头部）。