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是介于新子表 & 旧子表的边界中间位置（也可以理解为旧子表的头部）。

创建数据表的时候我们总是要考虑存储数据的字段该用哪种类型、多少长度比较合适，不过在Mysql中如果字段类型是Int，此时长度是不生效的。

1.Int类型的长度问题

1
2
3
4
5

CREATE TABLE `test` (
  `id` int(3) NOT NULL,
  `name` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

有这样一张表，id是Int类型长度3的字段，那么理论上是不能存储长度超过3的值，比如：

1

INSERT INTO `test`(`id`, `name`) VALUES (1000000, 'name');

不过结果是意外的，这条数据可以正常写入。

2.Int类型的长度为什么不生效

翻了一下Mysql的数据类型文档，发现这么一句话：

对于整数类型，M表示最大显示宽度。 对于浮点和定点类型，M是可以存储的总位数（精度）。 对于字符串类型，M是最大长度。 M的最大允许值取决于数据类型。

所以这个Int类型的“长度”其实叫宽度，也可以理解为显示长度。

3.如果存储的数据长度低于显示宽度会怎样？

1

INSERT INTO `test`(`id`, `name`) VALUES (1, 'name');

当然是可以写入的，但是好像并没有什么特别的不一样，不过我们再执行一条SQL

1

ALTER TABLE `test` MODIFY COLUMN `id` int(3) UNSIGNED ZEROFILL;

这次数据产生变化了，变成了这样

1
2
3

id      |   name
001     |   name
1000000 |   name

4.为什么要设计显示宽度？

我也没有得出明确的答案，和小伙伴讨论这个问题~ta觉得是为了方便排序，你觉得呢？

每一个任务都需要编写一个Crontab命令，这是件很麻烦且很不友好的事情。 任务调度器允许你以代码的形式定义调度命令，并且服务器上只需要一个Crontab命令即可, 任务调度又是我们俗称的 “计划任务”

1.工欲善其事，必先利其器

Github一番搜索，发现Golang有个cron包（robfig/cron）大概满足需求，于是学习一下。

2.介绍

看了一遍文档，cron包支持的已经很全面了~~~不用自己造轮子了。

表达式

兼容Linux的crontab表达式（支持分钟级别）。

日志

可以很详细的记录调度的任务状态

时区

支持任务级别的时区配置

预定义计划

支持在未来指定的时间去运行

线程安全问题

该cron lib管理任务队列的slice没有做并发安全考虑，可能会出现任务竟抢行为。

PHP 项目在数据库迁移使用 ADB（aliyundb）时发现这个问题，具体错误描述是：

1

SQLSTATE[HY000]: General error: 1815 [15022, 2020010711034801025210201503151413416] statement type: class com.alibaba.fastsql.sql.ast.statement.SQLSetStatement is NOT supported! (SQL: select * from `users`)

在排查该问题的过程中，尝试了各种方式，降版本、使用原生语句等，甚至查找 ADB 手册和 Issue 还是无法解决。

1.原因

因为 ADB 兼容 Mysql 但是有些机制还是略有不同，阅读源码后发现比如：ADB 就不能很好的支持本地预处理语句，这也是该异常的原因。

2.解决方案

PHP PDO 链接的属性值PDO::ATTR_EMULATE_PREPARES需要设置为true

1

PDO::ATTR_EMULATE_PREPARES => true

Gin 是一个用 Go (Golang) 编写的 HTTP web 框架。 它是一个类似于 martini 但拥有更好性能的 API 框架, 由于 httprouter，速度提高了近 40 倍。

1.有哪些优点

较高的性能（Golang Web框架比对数据）

简单易用的中间件

使用了性能高可扩展的HTTP路由httprouter

社区长期有着很高的活跃度

Github星星多（Orz）

…等