网上购物看到自己喜欢的东西加入购物车然后付款，但是在付款的突然不想要了 … 往往这个订单会给一个30分钟的支付时间，时间一到就自动关闭了 所以这是怎么做到的呢？

1.实现方式

• 轮询

  1	脚本每隔一定时间就去数据表检查一下状态，是否过期需要关闭。

• 定时器

  1	创建订单时开始计时，计时结束后直接处理关闭订单。

• 数据库事件+存储过程

  1	数据库建立检查事件，每隔一定时间去执行一次存储过程。

• Key事件通知

  1	对于更改任何Redis Key的每个操作，都可以配置Redis将消息发布到Pub/Sub，然后订阅这些通知。

2.数据库事件+存储过程

不多说，直接上SQL

碰上github网络抽风的时候，恰巧你又需要拉取github上托管的项目，这个时候看着2kb/s的下载速度是不是很抓狂？

粗暴的解决方式

打开ipaddress查询以下三个域名的ip，写到hosts文件中。

• github.com
• github.global.ssl.fastly.net
• codeload.github.com

进阶的方式

在现在大数据、高并发，到处都充斥着流量的互联网时代，能不能应对高并发俨然已经发展成一个衡量服务端架构是否合格的标准，作为程序媛我们思考如何利用语言在代码层面最优设计能应对并发的程序去并行处理任务。在程序中对于任务并行处理一般趋于使用：进程、线程，以及另外一种：协程。支持协程的语言有很多，比如：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，怎么拆呢？结构如下：