每一个任务都需要编写一个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）

索引用于快速查找具有特定列值的行。没有索引，MySQL必须从第一行开始，然后通读整个表以找到相关的行。如果表中有相关​​列的索引，MySQL可以快速确定要在数据文件中间查找的位置，而不必查看所有数据。这比顺序读取每一行要快得多。
InnoDB和MyIsam只支持Btree，因此默认均是Btree，Memory和Heap支持Hash和Btree，如无明确声明，则默认索引均是Hash（包括主键）。

1.Mysql有哪些常用的索引

主键索引：数据列不允许重复，不允许为null，一个表只能有一个主键。

唯一索引：数据列不允许重复，允许为null，一个表允许多个列创建唯一索引。

普通索引：基本的索引类型，没有唯一性的限制，允许为null。

全文索引：全文索引是目前实现大数据搜索的关键技术。

2.Mysql索引的建立原则

Mysql的索引遵循最左原则，在创建多列索引时，要根据业务需求，where条件中使用最频繁的一列放在最左边。

什么是事务？事务（Transaction）一般是指要做的或所做的事情。在计算机术语中是指访问并可能更新数据库中各种数据项的一个程序执行单元(unit)，具有4个特性：原子性、一致性、隔离性、持久性，简称ACID。

那么Mysql的事务隔离级别又是什么呢？Mysql的事务隔离级别分别是4种：未提交读（Read Uncommitted）、已提交读（Read Committed）、Repeatable Read（可重复读）、Serializable（可串行化）。可以简单理解为Mysql事务的4种执行标准。

一、ACID特性

原子性（Atomicity）：一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。

一致性（Consistency）：事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。

隔离性（Isolation）：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

持久性（Durability）：指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。

二、Mysql事务隔离级别

未提交读（Read Uncommitted），指当前事务可以读取到其他事务还未提交的数据变化，最容易带来的问题是脏读（Dirty Read），很少应用到生产环境。

已提交读（Read Committed），大部分数据库默认隔离级别但不包括Mysql，指当前事务可以读取其他事务已提交的数据变化，具有隔离性的基本标准，但是在出现交叉事务的并发操作场景中会发生两次读取的数据结果集不一致的问题，即不可重复读（Nonrepeatable Read）。

Repeatable Read（可重复读），Mysql数据库的默认隔离级别，这里顺便解释一下为什么Mysql的隔离级别不是Read Committed，因为在Mysql5.0之前日志格式只有statement这一种，这种格式导致主从复制一致性很难得到保证。这种隔离级别可以解决Nonrepeatable Read的问题，但如果也出现在交叉事务的并发操作场景会出现幻读（Phantom Read）的现象，这一行为状态是当前事务不能及时有效的读取其他事务的数据变化。

Serializable（可串行化），Mysql事务隔离最高级别，望文生义大概意思是事务的执行是有序（串行化顺序）的，不存在事务交叉执行的场景从而解决了Phantom Read的问题，但是在高并发的业务场景下请求会出现阻塞、超时、锁竟抢的问题，系统的可用性也随之降低。

收尾

https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html // Mysql事务官方文档

什么是锁？在多进程（线程）编程中为了数据的一致性、有效性，如果一资源被某进程（线程）上锁，那么在释放锁之前其他进程（线程）无法进行操作或者等待获取（上）锁。

一、悲观锁

悲观锁（Pessimistic locking），顾名思义对待任何事务都持悲观态度，做任何事情都会认为会有竞抢行为~所以在进行任何操作之前都要做好万全准备（上锁）才会继续执行后续的操作。通常是利用系统提供的锁机制来实现。
比如：

1
2

Mysql中的上锁命令：for update、lock in share mode等
Redis中的一些操作命令：setnx、getset等（原子操作）

二、乐观锁

乐观锁（Optimistic locking），和悲观锁相反对待任何事务都持乐观态度，只会在最后即将执行操作的时刻前才会进行验证。通常是通过程序配合来实现。
比如：

1

update `orders` set hash = md5(now()) where uid = 1 and hash = {lastHash};

三、优缺点

悲观锁优点很鲜明，因为每次执行的操作都是独占的，数据的一致性、有效性、安全性较高。但缺点同样突出，每次操作都会产生上锁的开销，在并发请求比较密集的情况下容易阻塞或者驳回请求，甚至是造成死锁，也大大降低了系统的性能。

乐观锁优点是省去了锁的开销，能较高的提高系统吞吐量，缺点是如果出现在并发高且竟抢（冲突）行为比较多的场景下数据的一致性很难保证。