base64的作用

二进制数据，每个字符取值范围[0, 255]，作为ascii码解析时，只有部分可显示(打印)

肉眼查看/作为文本拷贝这份数据，16进制优于二进制ascii码格式

但16进制表示法需两个字节才能表示表示原始数据的一个字节，即大小增加了一倍

base64算法保持编码后可打印特性的同时，大小只增加 1/3

base64算法原理

将二进制数据每三个字节（24位）看成一个单元，按每6位进行一次切割，切割成4个字节。切割后每个字节的范围是[0, 63]

[0, 63]的ascii码也并不都是可打印的，将[0, 63]再映射成可打印的字符

RFC 4648 映射关系定义：

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"

0对应A，1对应B，63对应 /

换算之后，三个字节变成可打印的四个字节内容

解码逻辑，将每个可打印的字符按映射表对应，每4个字节看成一个单位，按位运算还原出原始3个字节

原始数据长度不是3的倍数？

一种是最后剩1个字节，另一种是剩两个字节：

• 剩余1个字节时，1个字节编码成2个字节，剩余2个字节填充为 ==
• 剩余2个字节时，2个字节编码成3个字节，剩余1个字节填充为 =

即base64保证了编码后的字符串长度为4的倍数

作为url参数问题

base64编码后可能会出现 +/= 三个字符，会影响到整个url串的解析

例，https://example.com/all?key=1/2=

RFC 4648 中给出另一张映射表， + 替换成 -，/ 替换成 _

安装

curl https://get.acme.sh | sh
source ~/.bashrc

Wildcard Certificate

Let’s Encrypt Wildcard Certificate 必须用 DNS TXT 记录验证方式，且注意加2个 -d ddatsh.com -d *.ddatsh.com

其他 dns 或手工见 acme github wiki

export DP_Id="1xxx"
export DP_Key="xxxx"

acme.sh --issue --dns dns_dp -d ddatsh.com -d *.ddatsh.com --renew-hook "/root/.acme.sh/acme.sh --install-cert -d ddatsh.com  --key-file       /etc/nginx/conf.d/ssl/ddatsh.com.rsa.key    --fullchain-file /etc/nginx/conf.d/ssl/ddatsh.com.rsa.cer    --reloadcmd      \"systemctl force-reload nginx\""

acme.sh --issue --dns dns_dp -d ddatsh.com -d *.ddatsh.com -k ec-384  --renew-hook "/root/.acme.sh/acme.sh --install-cert -d ddatsh.com --ecc --key-file       /etc/nginx/conf.d/ssl/ddatsh.com.ecc.key    --fullchain-file /etc/nginx/conf.d/ssl/ddatsh.com.ecc.cer    --reloadcmd      \"systemctl force-reload nginx"\" --force

cron log

[root@VM-0-7-centos ~]# acme.sh --cron
[Tue Dec 15 12:04:51 CST 2020] ===Starting cron===
[Tue Dec 15 12:04:51 CST 2020] Renew: 'ddatsh.com'
[Tue Dec 15 12:04:52 CST 2020] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Tue Dec 15 12:04:52 CST 2020] Multi domain='DNS:ddatsh.com,DNS:*.ddatsh.com'
[Tue Dec 15 12:04:52 CST 2020] Getting domain auth token for each domain
[Tue Dec 15 12:04:57 CST 2020] Getting webroot for domain='ddatsh.com'
[Tue Dec 15 12:04:57 CST 2020] Getting webroot for domain='*.ddatsh.com'
[Tue Dec 15 12:04:58 CST 2020] ddatsh.com is already verified, skip dns-01.
[Tue Dec 15 12:04:58 CST 2020] *.ddatsh.com is already verified, skip dns-01.
[Tue Dec 15 12:04:58 CST 2020] Verify finished, start to sign.
[Tue Dec 15 12:04:58 CST 2020] Lets finalize the order.
[Tue Dec 15 12:04:58 CST 2020] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/105392664/6749057114'
[Tue Dec 15 12:05:00 CST 2020] Downloading cert.
[Tue Dec 15 12:05:00 CST 2020] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/04b7648ffb2c2a2887a2b85e7ed662421226'
[Tue Dec 15 12:05:01 CST 2020] Cert success.
-----BEGIN CERTIFICATE-----
MIIFKxxx
-----END CERTIFICATE-----
[Tue Dec 15 12:05:01 CST 2020] Your cert is in  /root/.acme.sh/ddatsh.com/ddatsh.com.cer 
[Tue Dec 15 12:05:01 CST 2020] Your cert key is in  /root/.acme.sh/ddatsh.com/ddatsh.com.key 
[Tue Dec 15 12:05:01 CST 2020] The intermediate CA cert is in  /root/.acme.sh/ddatsh.com/ca.cer 
[Tue Dec 15 12:05:01 CST 2020] And the full chain certs is there:  /root/.acme.sh/ddatsh.com/fullchain.cer 
[Tue Dec 15 12:05:02 CST 2020] Run renew hook:'/root/.acme.sh/acme.sh --install-cert -d ddatsh.com  --key-file       /etc/nginx/conf.d/ssl/ddatsh.com.rsa.key    --fullchain-file /etc/nginx/conf.d/ssl/ddatsh.com.rsa.cer    --reloadcmd      "systemctl force-reload nginx"'
[Tue Dec 15 12:05:02 CST 2020] Installing key to:/etc/nginx/conf.d/ssl/ddatsh.com.rsa.key
[Tue Dec 15 12:05:02 CST 2020] Installing full chain to:/etc/nginx/conf.d/ssl/ddatsh.com.rsa.cer
[Tue Dec 15 12:05:02 CST 2020] Run reload cmd: systemctl force-reload nginx
[Tue Dec 15 12:05:03 CST 2020] Reload success
[Tue Dec 15 12:05:03 CST 2020] Renew: 'ddatsh.com'
[Tue Dec 15 12:05:04 CST 2020] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Tue Dec 15 12:05:04 CST 2020] Multi domain='DNS:ddatsh.com,DNS:*.ddatsh.com'
[Tue Dec 15 12:05:04 CST 2020] Getting domain auth token for each domain
[Tue Dec 15 12:05:10 CST 2020] Getting webroot for domain='ddatsh.com'
[Tue Dec 15 12:05:10 CST 2020] Getting webroot for domain='*.ddatsh.com'
[Tue Dec 15 12:05:10 CST 2020] ddatsh.com is already verified, skip dns-01.
[Tue Dec 15 12:05:10 CST 2020] *.ddatsh.com is already verified, skip dns-01.
[Tue Dec 15 12:05:10 CST 2020] Verify finished, start to sign.
[Tue Dec 15 12:05:10 CST 2020] Lets finalize the order.
[Tue Dec 15 12:05:10 CST 2020] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/105392664/6749062076'
[Tue Dec 15 12:05:12 CST 2020] Downloading cert.
[Tue Dec 15 12:05:12 CST 2020] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/038811d00702ddb48ba0ab38fce9fc554a9e'
[Tue Dec 15 12:05:13 CST 2020] Cert success.
-----BEGIN CERTIFICATE-----
MIIEezxxx
-----END CERTIFICATE-----
[Tue Dec 15 12:05:13 CST 2020] Your cert is in  /root/.acme.sh/ddatsh.com_ecc/ddatsh.com.cer 
[Tue Dec 15 12:05:13 CST 2020] Your cert key is in  /root/.acme.sh/ddatsh.com_ecc/ddatsh.com.key 
[Tue Dec 15 12:05:13 CST 2020] The intermediate CA cert is in  /root/.acme.sh/ddatsh.com_ecc/ca.cer 
[Tue Dec 15 12:05:13 CST 2020] And the full chain certs is there:  /root/.acme.sh/ddatsh.com_ecc/fullchain.cer 
[Tue Dec 15 12:05:13 CST 2020] Run renew hook:'/root/.acme.sh/acme.sh --install-cert -d ddatsh.com --ecc  --key-file       /etc/nginx/conf.d/ssl/ddatsh.com.ecc.key    --fullchain-file /etc/nginx/conf.d/ssl/ddatsh.com.ecc.cer    --reloadcmd      "systemctl force-reload nginx"'
[Tue Dec 15 12:05:13 CST 2020] Installing key to:/etc/nginx/conf.d/ssl/ddatsh.com.ecc.key
[Tue Dec 15 12:05:13 CST 2020] Installing full chain to:/etc/nginx/conf.d/ssl/ddatsh.com.ecc.cer
[Tue Dec 15 12:05:13 CST 2020] Run reload cmd: systemctl force-reload nginx
[Tue Dec 15 12:05:13 CST 2020] Reload success
[Tue Dec 15 12:05:13 CST 2020] ===End cron===

Service Provider Interface

“接口＋策略模式＋配置文件” 组合实现的动态加载机制

SPI 应用之一是可替换的插件机制

1. 定义一组接口

2. 写接口的一个或多个实现

3. src/main/resources/META-INF/services/接口名文件， 内容是要应用的实现类

4. 用 ServiceLoader 加载配置文件中指定的实现

主要被框架的开发人员使用，如 java.sql.Driver 接口，不同厂商可以针对同一接口做出不同的实现

Read UnCommited

可解决丢失更新

create table users (
    id int auto_increment not null primary key,
    name char(10) not null,
    state int not null
); 
insert into users values(1,'dd',0);

事务1

set autocommit = 0;
set global transaction isolation level read uncommitted ;
set session transaction isolation level read uncommitted ; 
start transaction;
update users set state=state+1 where id=1;
select sleep(10);
commit;

事务2

set autocommit = 0;
set global transaction isolation level read uncommitted ;
set session transaction isolation level read uncommitted ; 
start transaction;
update users set state=state+1 where id=1;
commit;

数据库的一级封锁锁（修改前加X锁，事务结束释放X锁，读不加锁）

事务1先执行修改，修改前申请持有X锁，事务结束释放X锁；事务2也执行修改操作，修改前也申请持有X锁

事务1，10秒才提交释放锁，事务2申请持锁需要等待，直到事务1结束才能获取到锁的持有权进行修改

这样对同一数据的修改会变成串行化的修改，所以不会出现因为并发只进行一次+1的情况，也就不会出现丢失修改的问题

RU 不能解决脏读和不可重复读

另一个事务回滚就会产生脏读

set autocommit = 0;
set global transaction isolation level read uncommitted ;
set session transaction isolation level read uncommitted ; 
start transaction;
update users set state=1 where id=1;
select sleep(5);
rollback;

set autocommit = 0;
set global transaction isolation level read uncommitted ;
set session transaction isolation level read uncommitted ; 
start transaction;
select * from users where id=1;
commit; 

事务2结果=1

事务1和事务2都执行结束时，再进行一次查询=0

事务1先修改，修改前申请持有X锁，

事务2读，不需要申请持锁，读出的数据是事务1修改后的，而此时事务1回滚，修改的数据被还原，产生脏读现象

5.6

引入GTID，server uuid(auto.cnf)和事务ID组成

并行只基于库(Schema)

1. Crash Safe 不好做，可能后执行的事务由于并行复制先完成执行
2. 性能不高单库多表比多库多表更常见

基于GTID的Replication好处

传统复制

发生故障后，主从切换，需找到binlog和pos点，然后change master to指向新的master，麻烦易错

GTID后只需要知道master ip，port，自动找点同步

A 宕机，需要切到 B上。同时又需要将C的复制源改成B

CHANGE MASTER TO MASTER_HOST='xxx', MASTER_LOG_FILE='xxx', MASTER_LOG_POS=nnnn

难点在于，同一个事务在每台机器上所在的binlog名字和位置都不一样，怎么找到C当前同步停止点，对应B的master_log_file和master_log_pos是什么

M-S复制集群需要使用 MMM/MMA 这样的额外管理工具的一个重要原因

多线程复制（基于库） MGR

5.6基于库

5.7基于表(真正意义上多线程复制)

slave-parallel-type

• DATABASE：默认值，基于库的并行复制方式
• LOGICAL_CLOCK：基于组提交的并行复制方式(last_committed 和 sequence_number)

binlog 字段 last_committed 和 sequence_number

下一个事务在主库配置好组提交以后，last_committed 和上一个事务的 sequence_number 相等，因为事务是顺序提交的

最后两个事务的 last_committed 相同，意味着这两个事务作为一个组提交，两个事务在 Perpare 阶段获取相同的 last_committe 而且相互不影响，最终是会作为一个组进行提交

组提交是并行复制的基础

组提交的事务可以在slave并行回放

master

• binlog_group_commit_sync_delay

全局动态变量，单位微妙，默认 0，范围：0～1000000（1秒）

binlog 提交后等待延迟多少时间再同步到磁盘，默认0 ，不延迟

0 以上时，允许多个事务的日志同时一起提交，就是组提交。组提交是并行复制的基础，大于 0 就代表打开了组提交的功能

• binlog_group_commit_sync_no_delay_count

全局动态变量，单位个数，默认 0，范围：0～1000000

等待延迟提交的最大事务数，如果上面参数的时间没到，但事务数到了，则直接同步到磁盘。若 binlog_group_commit_sync_delay 没有开启，则该参数也不会开启

slave

slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=4

MGR不是强同步的，但是最终会一致的

确切的说：事务会按照相同的顺序发送给这个group的所有成员，但是事务的执行、commit完全由成员自行处理，并不是同步进行的

Group Replication Limitations

MGR在GTID基础上构建，GTID的限制不能使用event的checksums

--binlog-checksum=NONE 必须这样设置

Gap locks ， 建议设置隔离级别为 READ COMMITTED

认证阶段无法使用gap lock，所以建议使用隔离级别为READ COMMITTED，READ COMMITTED 不适用gap locks

SERIALIZABLE , MGR不支持SERIALIZABLE隔离级别

• 并发DDL和DML在同一个对象上的操作，会有问题

举例： 
	A实例 表t进行DDL  
	B实例 表t进行dml
	会导致冲突无法检测到，会有很高的风险  
	这种情况一般在multi-primary模式下容易遇到（因为多实例写嘛的原因嘛），所以DDL要特别小心

• 外键级联约束

• 大事务

在5秒钟的世界窗口中如果无法将事务copy到其他成员的话，那么MGR的通信会失败，重传，会有严重影响  
建议切分、限制 事务大小

• multi-primary的死锁检测

多主模式下，如果使用SELECT .. FOR UPDATE 会导致死锁  

主要是lock无法跨越多服务器

• 复制过滤

MGR中不要使用任何复制的filter

FAQ

MGR成员数量最大9个

MGR来scale-out写压力

a）并不是直接的扩展方式，每一个成员都有完整的数据copy

b）但是其他server并不是做完全一样的写动作，MGR通过ROW模式复制，其他server只需要apply row即可，并不是re-executed事务了，因此会快且压力小很多

c）更进一步讲，row-based应用都是经过压缩过的，可以减少很多IO动作，相比master上的执行压力会小很多的

d）总结，可以scale-out写，在没有写冲突事务的时候在多台服务器上执行事务是可以做到scale-out的

如果网络临时有问题，组成员会自动重新加入group吗

取决于是什么网络问题 短暂，瞬间，MGR错误检测机制根本还没来得及探测到此问题，该成员不会被移除出组 长时间问题，错误检测机制最终会认为它除了问题，将此server移除出组

一旦移除出组，需要让他重新加入一次，换句话说，需要手工来处理，或用脚本来自动处理

如果一个节点严重延迟，会产生什么问题

没有一个很好的策略来自动判断什么时候去驱逐一个成员 需要找到为什么它会延迟，并解决它，或移除它 否则，当一个server慢到触发流控，然后整个group都会变的慢下来

• 懒汉,线程不安全

适合单线程程序，多线程需要保护getInstance()，否则可能产生多个Singleton对象实例

public class Singleton {

    private Singleton() {
    }

    private static Singleton instance = null;

    public static Singleton getInstance() {
        if (Singleton.instance == null) {
            Singleton.instance = new Singleton();
        }
        return Singleton.instance;
    }
}

Linux I/O体系七层：

• VFS

  适配各种文件系统，对外提供统一API

  磁盘：EXT,XFS …

  网络：NFS, CIFS …

  特殊：/proc，裸设备

• 磁盘缓存

  磁盘数据驻留 RAM

  • Dentry cache
  • Page cache
  • Buffer cache

• 映射层

  确定数据在物理设备上的位置

• 通用块层

  绝大多数I/O操作是跟块设备打交道

  下层对接各种不同属性的块设备，对上提供统一的Block IO请求标准

• I/O调度层

  管理块设备的请求队列，有利于减少磁盘寻址时间，提高全局吞吐量

  大多数块设备都是磁盘设备

  根据设备及应用特点设置不同的调度器

• 块设备驱动

  设备操作接口

• 物理硬盘

分布式系统面临的问题

• 通信异常

  不可用、延时、丢失

• 网络分区(脑裂)

  系统分化出两个网络组，组内都正常通讯，但组间通讯被阻隔

• 三态

  成功，失败和超时时（请求者无法判断当前请求是否成功处理）

• 节点故障

  宕机，僵死，器件损坏等

锁作用

• 保证共享资源一致性

• 实现事务隔离性

锁粒度(等级)

• 表级锁：开销小，加锁快； 不会死锁；锁定粒度大，发生锁冲突的概率最高 ，并发度最低
• 行级锁：开销大，加锁慢；会出现死锁（锁是逐步获得的）；锁定粒度最小，发生锁冲突的概率最低，并发度也最高
• 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般

存储引擎各自实现锁机制，server层不感知存储引擎的锁实现

InnoDB锁模式

行锁

• 共享锁（S）

• 排他锁（X）

表锁

• 意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的 IS 锁

• 意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的 IX 锁

允许行锁和表锁共存，实现多粒度锁机制

详解 MySql InnoDB 中意向锁的作用

隐式& 显式 锁定

隐式锁定

事务执行过程中，使用两阶段锁协议：

• 随时都可以执行锁定，InnoDB会根据隔离级别在需要的时候自动加锁

• 锁只有在执行commit或者rollback的时候才会释放，并且所有的锁都是在 ``同一时刻` 被释放

显式锁定 ：

select ... lock in share mode
select ... for update

乐观&悲观锁

乐观锁

select id,value,version from TABLE where id = #{id}

更新时，为防止发生冲突，需要这样操作

update TABLE
set value=2,version=version+1
where id=#{id} and version=#{version}

失败后重试或回滚

悲观锁

直接调用数据库的相关语句

悲观锁涉及的另外两个锁概念：共享锁与排它锁

共享锁（S）：

SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE

确保自己查到的数据没有被其他的事务正在修改，也就是说确保查到的数据是最新的数据，并且不允许其他人来修改数据（获取数据上的排他锁）

自己不一定能够修改数据，因为有可能其他的事务也对这些数据 使用了 in share mode 的方式上了 S 锁

当前事务对读锁进行修改操作，很可能会造成死锁

create table innodb_lock(
id bigint primary key auto_increment,
v int
);

insert into innodb_lock (id,v) values(1,'dd');

排他锁（X)：

SELECT * FROM table_name WHERE ... FOR UPDATE

自己查到的数据确保是最新数据，并且查到后的数据只允许自己来修改

一是内存爆了要用 LRU、LFU、FIFO 清理，否则磁盘SWAP，性能急剧下降

二是超时键过期要删除，用主动或惰性的方法

通用过期策略

• 定时过期：

  每个设置过expire时间的key都要创建一个定时器，到期立即清除

  该策略可以立即清除过期的数据，对内存很友好

  但占用大量CPU资源处理过期数据，从而影响响应时间和吞吐量

• 惰性过期：

  访问key才会判断该key是否已过期，过期则清除

  该策略可最大化节省CPU资源，却对内存非常不友好

  极端情况可能出现大量过期key没有再次被访问，而不会被清除，占用大量内存

• 定期过期：

  每隔一定的时间，扫描一定数量expires字典中一定数量的key，并清除其中已过期的key

  该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可在不同情况下使CPU和内存资源达到最优的平衡效果

  (expires字典，key指向键的指针，value是该键的毫秒精度UNIX时间戳)

Redis同时使用惰性过期和定期过期两种