[Golang] 自动健康上报
Charles http.Client mailx crontab
阅读更多
Go在1.11版本后开始支持modules，以go mod来实现包管理，那么该如何使用呢？
UPDATED 2020/04/10：
- 增加
GOPROXY设置，应对可能存在的网络连接问题 - 增加仓库发布实践操作部分，有效避坑指南
- 调整了文章结构
Charles http.Client mailx crontab
Go在1.11版本后开始支持modules，以go mod来实现包管理，那么该如何使用呢？
UPDATED 2020/04/10：
GOPROXY设置，应对可能存在的网络连接问题一个小demo，通过goroutine简单高效地实现并发的操作。
goroutine类似Python、C#中的coroutine，都可以使函数在独立的环境中运行，与之不同的是，goroutine某种程度上来说更为强大一些，它允许并行执行，可以通过channel进行进程间的通信。
当然，其他的区别也有很多，但不在本文讨论范围之内，之后会将这方面的知识归纳总结一次。
有限状态机(Finite State Machine)是一个非常有用的模型，理论上只要你考虑的状态足够多，就可以模拟世界上大部分事物。
当然了，这里的容器不是CNI之类的运行容器，而是指Golang中存储和组织数据的方式。
Go语言中的函数特性：
事务是并发控制地基本单位，为了保证事务地隔离性和一致性，DBMS需要对并发操作进行正确的调度。
并发操作带来的数据不一致性包括丢失数据、不可重复读、读脏数据。
丢失数据lost update：两个事务读入同一数据并修改，一个提交的结果破坏了另一个提交的结果，导致修改被丢失。
不可重复读non-repeatable read：指事务T1读取数据后，事务T2执行更新操作，使T无法再现前一次读取结果。具体分三种：
后两种不可重复读有时也被称为幻影(phamtom row)现象。
读脏数据dirty read：T1修改某一数据并写回磁盘，T2读该数据，T1 rollback，T2读到的数据与数据库中的数据不一致。
并发控制的主要技术：封锁(locking)，时间戳(timestamp)，乐观控制法(optimistic scheduler)，多版本并发控制(multi-version concurrency control,MVCC)
事务对某个数据进行加锁，在其释放前，其他食物不能更新此数据对象。
基本的封锁类型有两种：
封锁协议：规定合适申请X锁或S锁、持锁时间、何时释放等。
一级封锁协议：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括COMMIT, ROLLBACK。
一级封锁协议中，如果仅仅是读数据而不是对其进行修改，是不需要加锁的，所以它**不能保证 可重复读 和 不读脏数据。
二级封锁协议：在一级封锁协议的基础上，增加事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。
由于读完即可释放S锁，所以他不能保证 可重复读。
三级封锁协议：在一级封锁协议的基础上增加 事务T在读取数据R之前必须先对其加S锁，直到该事务结束之后才释放。
可解决不可重复读、读脏数据问题。
三级协议的主要区别在于什么操作需要申请封锁，以及合适释放锁。
活锁 ：T1封锁数据R，T2请求封锁R，后T3也请求封锁R，T1释放R后首先批准了T3的请求，也就是说T2被插队了，如果T2一直被插队，那么称之为活锁。
解决方法：先来先服务。
死锁 ：循环等待。
死锁的预防：
一次封锁法：要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。
缺陷：1.扩大封锁范围，降低并发度；2.很难事先确定需要封锁的数据对象。
顺序封锁法：预先对数据对象规定一个封锁顺序，所有事务都按照这个顺序实施封锁。
缺陷：1.数据库系统中封锁的数据对象极多，并且不断变化，要维护这样的资源的封锁顺序非常困难，成本很高；2.很难事先确定要封锁那些对象，一次也就很难按规定的顺序去施加封锁。
死锁的诊断与解除 ：
解除死锁：选择一个处理死锁代价最小的事务，将其撤销，释放此事务持有地所有锁。
可串行化调度：多个事务地并发执行是正确的，当且仅当其结果与按某一次序串行执行这些事务地结果相同时，称这种调度策略为可串行化serializable的。
可串行性是并发实物正确调度的准则。
冲突操作是指不同事务对同一数据的读写操作和写写操作。而其他操作是不冲突操作。
通过交换两个事务不冲突操作的次序得到另一个调度Sc‘，如果Sc’是串行的，则称调度Sc为冲突可串行化的调度。因此可以用这种方法来判断一个调度是否是冲突可串行化的。
冲突可串行化调度是可串行化调度的充分条件，不是必要条件。
所谓2PL协议是指所有事务必须分两个阶段对数据项加锁和解锁：
事务分为两个阶段，第一阶段是获得封锁，也成为扩展阶段，此阶段可以申请获得任何数据项上的任何类型的锁，但是不能释放任何锁；第二阶段是释放封锁，也称为收缩阶段，该阶段事务可以释放任何数据项上的任何类型的锁，但是不能再申请任何锁。
若并发执行的所有事务均遵循两段锁协议，则对这些事务的任何并发调度都是可串行化的。
严格两段锁协议：除要求满足两段锁协议规定外，还要求事务的排它锁必须在事务提交之后释放
强两段锁协议：除要求满足两段锁协议规定外，还要求事务的所有锁都必须在事务提交之后释放
事务遵守两段锁协议是可串行化调度的充分条件，而不是必要条件。
封锁对象的大小称为封锁的粒度，封锁粒度与系统的并发度和并发控制的开销密切相关。
封锁的粒度越大，数据库所能封锁的单元就越少，并发度越小，系统开销越小。
多粒度封锁：一个系统中同时支持多种封锁粒度供不同的事务选择。
引入多粒度树的概念，三级粒度树(数据库，关系，元组)，四级粒度树(数据库，数据分区，数据文件，数据记录)。多粒度封锁协议允许多粒度树中的每个结点被独立的加锁。对一个结点加锁意味着这个结点的所有后裔结点也被加以同样类型的锁。
显式封锁：应事务要求直接加到数据对象上的锁。
隐式封锁：该数据对象没有被独立加锁，而是由于其上级结点加锁而使该数据对象加上了锁。
一般地，对于某个数据对象加锁，系统要检查该数据对象上有无显式封锁与之冲突，还要检查上级结点传下来的隐式封锁是否冲突，以及传给下级结点的封锁是否冲突，这样的检查方法效率很低，因此引入意向锁。
意向锁：如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁；对任一结点加锁时，必须先对它的上层结点加意向锁。
三种常用的意向锁，意向共享锁(Intent Share Lock，IS锁)，意向排他锁(Intent Exclusive Lock, IX锁)，意向共享排他锁(Share Intent Exclusive Lock, SIX锁)
IS锁：如果对一个数据对象加IS锁，表示它的后裔结点拟加S锁。
例如，事务T1要对R1中某个元组加S锁，则要首先对关系R1和数据库加IS锁
IX锁：如果对一个数据对象加IX锁，表示它的后裔结点拟加X锁。
SIX锁：如果对一个对象加SIX锁，表示对它加S锁，再加IX锁，即SIX=S+IX。
课后题：
正确的调度->可串行化的调度->遵守两阶段封锁的调度->串行调度
在讨论数据库恢复计数之前先要明确事务的基本概念和事务的性质。
事务：用户定义的一个数据库操作序列，这些操作要么全做要么全不做，是一个不可分割的工作单位。在SQL中，定义事务的语句有3条：
BEGIN TRANSACTION
COMMIT
ROLLBACK
特性：ACID——原子性Atomisticy、一致性Consistency、隔离性Isolation、持续性Durability。
事务内部的故障：事务没有打到预期的终点(COMMIT或者显示的ROLLBACK)，因此，数据可可能出于不正确的状态。事务内部更多的故障是非预期的，是不能由应用程序处理的。
系统故障：系统故障是指造成系统停止运转的任何时间，是的系统要重新启动。如：CPU故障、操作系统故障、DBMS代码错误、系统断电等。发生系统故障时，一些尚未完成的事务结果可能已送入物理数据库，从而造成数据库可能出于不正确的状态。
恢复子系统必须在系统重新启动时让所有非正常中值的事务回滚，还需要重做REDO所有已提交的事务，以将数据库真正恢复到一致状态。
介质故障：系统故障常被成为软故障(soft crash) ，介质故障成为硬故障(hard crash) 。硬故障指外存故障，如磁盘损坏、磁头碰撞、瞬时强磁场干扰等。发生几率小，但破坏性巨大。
计算机病毒
恢复的基本原理：冗余。也就是说数据库中任何一部分被破坏或不正确的数据可与根据存储在系统别处的冗余数据来重建。
恢复机制关键问题：如何建立冗余数据，如何利用这些冗余数据实施数据库恢复。
建立冗余数据最常用的技术时数据转储和登记日志文件logging(通常二法并用)。
转储即数据库管理员定期地将整个数据库复制到磁盘、磁带或其他存储介质上保存起来的过程。这些备用数据成为后备副本backup。转储是十分耗费时间和资源的，不能频繁进行，应根据数据库使用情况确定一个适当的转储周期。
静态转储：系统中午运行事务时进行的转储操作。 即转储操作开始的时刻，数据库出游一致性状态，而转储期间不允许对数据库的任何存取、修改活动。缺点：降低数据库的可用性。
动态转储：转储期间允许对数据库进行存取或修改。缺点：转储结束时backup上的数据并不能保证正确有效，可能已经是过时的数据了。
解决方法：将转储期间各事务对数据库的修改活动登记下来，建立日志文件log file。
转储还分为海量转储和增量转储两种方式。
日志文件的格式和内容
日志文件：用来记录事务对数据库的更新操作的文件。分为已记录为单位的日志文件和以数据块为单位的日志文件。
日志文件中需要登记的内容：
日志文件的作用：
为保证数据库是可恢复的，登记日志文件时必须遵循两条原则：
事务故障的恢复 ：事务在运行至正常终止点前被终止，恢复子系统应利用日志文件撤销UNDO此事务一堆数据库进行的修改。由系统自动完成 ，对用户是透明的，步骤为：
系统故障的恢复 ，成因有两个：1.未完成事务对数据库的更新已写入数据库；2.已提交事务对数据库的更新还留在缓冲区。该恢复由系统在重新启动时自动完成，不需要用户干预。
恢复步骤：
BEGIN TRANSACTION 和 COMMIT)，标记记入重做队列(REDO LIST)，同时找出故障发生时尚未完成的事务(只有BEGIN TRANSACTION无COMMIT)，标记记入撤销队列(UNDO LIST)介质故障的恢复 ，恢复方法：重装数据库，重做已完成的事务。(装入最新backup，装入相应的日志文件副本)
在日志文件中增加一个新的记录——检查点checkpoint记录，增加一个重新开始文件，并让恢复子系统在登录日志文件期间动态地维护日志。
checkpoints记录内容:
动态维护日志文件的方法是，周期性地执行建立检查点、保存数据库状态地操作。
使用检查点方法可以改善恢复效率。
数据库系统的特点：
数据管理的三个阶段：人工管理阶段——文件系统阶段——数据库系统阶段
1.如何组织数据——数据模型、规范化理论
2.如何存取数据——数据定义与操作语言
3.哪些人可以操作哪些数据——安全性相关
4.很多人在操作统一数据时如何避免发生冲突——并发控制
5.故障后怎么办——数据恢复
数据模型：概念模型、逻辑模型
分两个模型的原因：逻辑模型 为了方便把 概念模型 存放到计算机中，事实上二者是同一概念。
数据模型的组成要素：数据结构、数据操作、数据的完整性约束条件
概念模型：实体 属性 码 域 实体性 实体集 联系
常用的逻辑数据模型：
E-R图 —————- P19 实体-矩形 属性-椭圆 关系-菱形。
关系模型：关系(Relation)、元组(Tuple)、属性(Attribute)、码(Key)、域(Domain)、分量。
关系的完整性约束条件：实体完整性、参照完整性、用户定义完整性。
优点：数学基础、概念单一(都是二维表)、存取路径对用户透明。
缺点；效率、优化会增加开发难度。
数据库的三级模式：
数据库的二级映像：
看书做题就行
候选码：关系中能唯一标识一个元组的值。
主属性：候选码中的属性。
关系的三种类型：基本类型(基本表)、查询表、视图表。
注：
连接操作中，可能会丢失一些值，为了保留这些值而留出空值叫做外连接
要看除运算
特点：
修改基本表：
ALTER TABLE <表明>
例：
ALTER TABLE Student ADD S_entrance DATE;
ALTER TABLE Student ALTER COLUMN Sage INT;
ALTER TABLE Course ADD UNIQUE(Cname);
查询中的字符匹配：
例：
SELECT Sname, Sno, Ssex FROM Student WHERE Sname LIKE ‘刘%’;
匹配所有姓刘的同学
SELECT Sname FROM Student WHERE Sname LIKE ‘欧阳__’;
匹配 欧阳X
having
ORDER BY ASC(升序) DESC(降序) 缺省情况为升序
计算机系统安全性：
用户表示与鉴别Identification & Authentication —— 最外层安全保护措施
存取控制：
定义用户权限，并将用户权限登记到数据字典中
合法权限检查
自主存取控制(Discretionary Access Control, DAC) C1级别
用户对于不同的数据库对象由不同的存取权限，不同的用户对同一对象也有不同的权限，用户可将其拥有的存取权限授权给其他用户
强制存取控制(Mandatory Access Control, MAC) B1级别
每一个数据库对象被标以一定的密级，每一个用户也被授予某一级别的许可证。
授权与回收：
GRANT
GRANT SELECT ON TABLE Student TO U1;
REVOKE 回收权限，形式与上面类似
数据库角色——权限的集合，用于简化授权
1.角色的创建
CREATE ROLE
2.给角色授权
略
3.将一个角色授予其他用户
略
4.角色权限的收回
在MAC中DBMS所管理的全部实体被分为主体和客体两大类。
主体：系统中的活动实体，既包括DBMS所管理的实际用户，也包括代表用户的各进程。
客体：系统中的被动实体，包括文件、基本表、索引、视图，受主题操纵。
对于主体和客体，DBMS为它们每个实例指派一个敏感度标记(Label)。分为绝密Top Secret、机密Secret、可信Confidential、公开Public，主体的敏感度标记称为许可证级别，客体的敏感度标记为密级。
规则：
原因：禁止了拥有高许可证级别的主体更新低密度的数据对象，造成敏感数据的泄露。
实体完整性、参照完整性、用户自定义的完整性
DBMS为维护数据库的完整性，必须能够；
1.提供定义完整性约束条件的机制
2.提供完整性检查的方法
3.违约处理
实体完整性的定义：列级约束条件、表级约束条件
实体完整性检查和违约处理：检查主码值是否唯一；检查主码的各属性是否为空
参照完整性定义：FOREIGN KEY，对外码的取值做一个约束：空值或存在值。
用户自定义完整性：1.NOT NULL; 2.UNIQUE; 3.CHECK;
函数依赖(Functional Dependency,FD)：属性间类似数学中的函数y=f(x)的依赖关系，被称为函数依赖。记作X→Y。
非平凡函数依赖：X→Y，但Y不是X的子集。
平凡函数依赖：X→Y，Y是X的子集。
完全函数依赖：X→Y，并且对于X的任何一个真子集X‘，都有Y不函数依赖于X’。
部分函数依赖：X→Y，Y不 完全函数依赖 于X。u’s
传递函数依赖：X→Y, Y→Z, 且Y不→X。
主属性(Prime Attribute)：任何候选码中的属性。
非主属性(Nonprime Attribute)：不包含在任何码中的属性。也称非码属性(Non-key Attribute)。
第一范式(1NF)：每一个分量必须是不可分的数据项。
第二范式(2NF)：1NF的基础下，每一个非主属性完全依赖于码
规范化(normalization)：一个低一级范式的关系模式，通过模式分解可以转化为若干个高一级范式的关系模式的集合。
第三范式(3NF)：每一个非主属性 既不部份依赖于码，也不传递依赖于码。
BCNF：关系模式R<U,F>∈1NF，若X→Y且Y不是X子集时，X必含有码。即，每一个决定因素都含有码。
一个满足BCNF的关系模式：
BCNF修正了3NF主属性内部部分函数依赖
多值依赖(Multivalued Dependency,MVD)
—————————————————19分钟两类考题——————————————————–
DBMS查询处理分为4个阶段：查询分析、查询检查、查询优化、查询执行。
计算题：P268
数据库设计重点： 概念设计->逻辑设计 ， 每一阶段目的是什么。
数据库设计方法：新奥尔良方法、基于E-R模型的数据库设计方法、3NF的设计方法、ODL方法、UML方法
数据库设计的基本步骤：
准备工作：1.系统分析人员、数据库设计人员；2.用户代表和数据库管理员；3.应用开发人员
需求分析
小结：充分考虑可能的扩充和改变，使设计易于更改，系统易于扩充；强调用户参与。
概念结构设计
特点：
四类方法：(常用：自顶向下需求分析，自底向上设计概念结构)
视图的集成：多个E-R一次继承(难度较大)；逐步继承
合并冲突：
逻辑结构设计
物理结构设计
数据库实施
数据库运行与维护
之前使用的脚本基本可以完成hugo的自动编译和push，但我的笔记基本都放在了移动硬盘中，因此需要脚本对移动硬盘中的笔记进行扫描，增量地进行更新。