之前学习了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）

…等

Elasticsearch是Elastic Stack核心的分布式搜索和分析引擎。

1.背景

因为业务调整采用了ES作为数据库，所以需要了解ES对于这一块的设计如何实现类似Mysql中Group By的查询的效果。

2.实现方式

ES实现Group By有两种方式：TermsAgg、CompositeAgg，它们也具有不同程度的优缺点。

TermsAgg的使用方式非常粗暴，直接进行桶嵌套即可，如下:

TermsAgg请求DSL语句

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

{
	"aggregations": {
		"group_app": {
			"terms": {
				"field": "app",
				"size": 1000000
			},
			"aggregations": {
				"group_campaign_id": {
					"terms": {
						"field": "campaign_id",
						"size": 1000000
					}
				}
			}
		}
	},
	"size": 0
}

TermsAgg执行结果

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
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

{
    "took": 142,
    "timed_out": false,
    "_shards": {
        "total": 5,
        "successful": 5,
        "skipped": 0,
        "failed": 0
    },
    "hits": {
        "total": 175033,
        "max_score": 0.0,
        "hits": []
    },
    "aggregations": {
        "group_app": {
            "doc_count_error_upper_bound": 0,
            "sum_other_doc_count": 0,
            "buckets": [
                {
                    "key": "com.aa.bb.cc",
                    "doc_count": 59929,
                    "group_campaign_id": {
                        "doc_count_error_upper_bound": 0,
                        "sum_other_doc_count": 0,
                        "buckets": [
                            {
                                "key": "Campaign_118",
                                "doc_count": 56466
                            },
                            {
                                "key": "Campaign_119",
                                "doc_count": 1937
                            }
                        ]
                    }
                },
                {
                    "key": "com.dd.ee.ff",
                    "doc_count": 23231,
                    "group_campaign_id": {
                        "doc_count_error_upper_bound": 0,
                        "sum_other_doc_count": 0,
                        "buckets": [
                            {
                                "key": "Campaign_120",
                                "doc_count": 16692
                            },
                            {
                                "key": "Campaign_121",
                                "doc_count": 5336
                            }
                        ]
                    }
                }
            ]
        }
    }
}

CompositeAgg的使用方式略微有一些不同，下面：

CompositeAgg请求DSL语句

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

{
	"aggregations": {
		"group_by": {
			"composite": {
				"sources": [
					{
					    "app": {
					        "terms": {
					            "field": "app"
					        }
					    }
					},
					{
					    "campaign_id": {
						    "terms": {
						        "field": "campaign_id"
						    }
					    }
					}
				],
                "size": 1000
			}
		}
	},
	"size": 0
}

CompositeAgg执行结果

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
33
34
35
36
37
38
39

{
    "took": 14,
    "timed_out": false,
    "_shards": {
        "total": 5,
        "successful": 5,
        "skipped": 0,
        "failed": 0
    },
    "hits": {
        "total": 175033,
        "max_score": 0.0,
        "hits": []
    },
    "aggregations": {
        "group_by": {
            "after_key": {
                "app": "com.dd.ee.ff",
                "campaign_id": "Campaign_120"
            },
            "buckets": [
                {
                    "key": {
                        "app": "com.aa.bb.cc",
                        "campaign_id": "Campaign_119"
                    },
                    "doc_count": 182
                },
                {
                    "key": {
                        "app": "com.dd.ee.ff",
                        "campaign_id": "Campaign_120"
                    },
                    "doc_count": 40
                }
            ]
        }
    }
}

3.优缺点

TermsAgg

优点：使用简单、没有数据量限制。

缺点：数据结构层次深、不支持分页。

CompositeAgg

优点：使用简单、数据结构清晰可读，支持分页。

缺点：有数据量限制。

最后

至于ES这两种分组方式的性能方面还没有研究，后续学习笔记会更新性能上面的差异。

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-composite-aggregation.html // 附上ES官方文档

代理通常用于在几台服务器之间分配负载，无缝显示来自不同网站的内容或通过除 HTTP 之外的协议将处理请求传递给应用服务器。

1.代理的常用场景及优点

正向代理

gfw 科学上网。

客户端访问鉴权。

反向代理

负载均衡。

保证内网的安全，阻止 web 攻击。

2.正向代理和反向代理有什么不同

比较通俗的来解释：正向代理代理的是客户端，服务端不知道实际发起请求的客户端、反向代理代理的是服务端，客户端不知道实际接收请求的服务端。

一张图表示（来源：知乎 wplulala）