MySQL当前存在的三种复制模式有：异步模式、半同步模式和组复制模式。注意：MySQL复制模式没有“同步复制”这一项的，文章中只是为了读者方便理解半同步复制的概念才介绍了同步复制概念 https://dev.mysql.com/doc/refman/8.0/en/replication-semisync.html

从MySQL5.5开始，MySQL以插件的形式支持半同步复制。

1. 异步复制（Asynchronous replication）

MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。

异步复制是MySQL最早的也是当前使用最多的复制模式，异步复制提供了一种简单的主-从复制方法，包含一个主库（master）和备库（一个，或者多个） 之间，主库执行并提交了事务，在这之后（因此才称之为异步），这些事务才在从库上重新执行一遍（基于statement）或者变更数据内容（基于 row），主库不检测其从库上的同步情况。在服务器负载高、服务压力大的情况下主从产生延迟一直是其诟病。工作流程简图如下：

[][1]

**而同步复制（Fully synchronous replication，MySQL中没有此复制概念）**指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

2. 半同步复制（Semisynchronous replication）

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

MySQL5.5 的版本在异步同步的基础之上，以插件的形式实现了一个变种的同步方案，称之为半同步复制（semi-sync replication）。这个插件在原生的异步复制上，添加了一个同步的过程：当从库接收到了主库的变更（即事务）时，会通知主库。主库上的操作有两种：接收到这个通知以后才去commit事务；接受到之后释放session。这两种方式是由主库上的具体配置决定的。当主库收不到从库的变更通知超时时，由半同步复制自动切换到异步同步，这样就极大了保证了数据的一致性（至少一个从库），但是在性能上有所下降，特别是在网络不稳定的情况下，半同步和同步之间来回切换，对正常的业务是有影响的。其工作流程简图如下：

[][2]

3、Group Replication（组复制）

不论是异步复制还是半同步复制，都是一个主下面一个从或是多个从的模式，在高并发下高负载下，都存在延迟情况，此时如果主节点出现异常，那么就会出现数据不 一致的情况，数据可能会丢，在金融级数据库中是不能容忍的。在这种情况下，急需出现一种模式来解决这些问题。在MySQL5.7.17的版本中，带着这些期待，新的复制模式“组复制“由此产生并GA了。

组复制的工作流程图如下：[][3]

组复制的工作原理

MySQL组复制是一个MySQL插件，它建立在现有的MySQL复制基础结构上，利用了二进制日志，基于行的日志记录和全局事务标识符等功能。它集成了当前的MySQL框架，如性能模式、插件和服务基础设施等。

组复制（Group Replication）基于分布式一致性算法(Paxos协议的变体)实现，一个组允许部分节点挂掉，只要保证绝大多数节点仍然存活并且之间的通讯是没有问题的，那么这个组对外仍然能够提供服务，它是一种被使用在容错系统中的技术。Group Replication（复制组）是由能够相互通信的多个服务器（节点）组成的。在通信层，Group replication实现了一系列的机制：比如原子消息（atomic message delivery）和全序化消息（totalordering of messages）。这些原子化、抽象化的机制，为实现更先进的数据库复制方案提供了强有力的支持。

MySQL Group Replication正是基于这些技术和概念，实现了一种多主全更新的复制协议。简而言之，一个Group Replication就是一组节点，每个节点都可以独立执行事务，而读写事务则会在于group内的其他节点进行协调之后再commit。因此，当一个事务准备提交时，会自动在group内进行原子性的广播，告知其他节点变更了什么内容/执行了什么事务。这种原子广播的方式，使得这个事务在每一个节点上都保持着同样顺序。这意味着每一个节点都以同样的顺序，接收到了同样的事务日志，所以每一个节点以同样的顺序重演了这些事务日志，最终整个group保持了完全一致的状态。然而，不同的节点上执行的事务之间有可能存在资源争用。这种现象容易出现在两个不同的并发事务上。假设在不同的节点上有两个并发事务，更新了同一行数据，那么就会发生资源争用。面对这种情况，Group Replication判定先提交的事务为有效事务，会在整个group里面重放，后提交的事务会直接中断，或者回滚，最后丢弃掉。因此，这也是一个无共享的复制方案，每一个节点都保存了完整的数据副本。

从其工作的原理可以看出，Group Replication基于Paxos协议的一致性算法校验事务执行是否有冲突，然后顺序执行事务，达到最终的数据一致性，也就意味着部分节点可以存在延迟。可以设置多主同时写入和单主写入，通过设置 group_replication_single_primary_mode 来进行控制是多主还是单主，官方推荐单主写入，允许延迟，但延迟过大，则会触发限流规则（可配置的），整个集群会变的很慢，性能大打折扣。

更多组复制: http://www.sohu.com/a/124913450_354963 半同步复制的潜在问题

客户端事务在存储引擎层提交后，在得到从库确认的过程中，主库宕机了，此时，可能的情况有两种：

1. 事务还没发送到从库上

此时，客户端会收到事务提交失败的信息，客户端会重新提交该事务到新的主上，当宕机的主库重新启动后，以从库的身份重新加入到该主从结构中，会发现，该事务在从库中被提交了两次，一次是之前作为主的时候，一次是被新主同步过来的。

2. 事务已经发送到从库上

此时，从库已经收到并应用了该事务，但是客户端仍然会收到事务提交失败的信息，重新提交该事务到新的主上。

无数据丢失的半同步复制

针对上述潜在问题，MySQL 5.7引入了一种新的半同步方案：Loss-Less半同步复制。

针对上面这个图，“Waiting Slave dump”被调整到“Storage Commit”之前。

当然，之前的半同步方案同样支持，MySQL 5.7.2引入了一个新的参数进行控制-rpl_semi_sync_master_wait_point

rpl_semi_sync_master_wait_point有两种取值

AFTER_SYNC

这个即新的半同步方案，Waiting Slave dump在Storage Commit之前。

在kubernetes中，与api server 通讯时一般都需要使用https证书，这些证书文件存在放 /etc/kubernetes/pki 目录中(ubuntu)。主要有以下几种

/etc/kubernetes/pki/ca.{crt,key}

如果你已有现成的证书也可以直接将证书复制到这个目录里即可。这时kubeadm就会跳过证书生成这个步骤。

证书生成后，kubeadm 接下来会为其它组件生成访问api server 所需要的配置文件，这些文件路径为: /etc/kubernetes/xxx.conf:

ls /etc/kubernetes/
admin.conf controller-manager.conf kubelet.conf scheduler.conf

这里可以看到这四个配置文件，分别 为不同的组件之间提供配置。

这些配置文件中存储的是Master节点的ip地址、端口号、证书目录等信息。这样对应的客户端（scheduler，kubelet, controller-manager等）就可以直接加载并读取相应的配置文件来与kube-apiserver 建立安全连接，实现通讯。

附kubernetes架构图

我们平时在使用git的时候，经常会遇到需要撤销上次操作的需求，这时候需要用到git reset的这个命令，他的使用就是 “git-reset – Reset current HEAD to the specified state”, 注意这里主要操作的就是这个 HEAD。

为了方便我们先了解一下 Git 的工作流程

相信大家对这个图已经很熟悉了，其中index也叫stage暂存区或者暂存索引区。git reset 共有三个互斥参数分别为”–soft”、”–mixed(默认参数)” 和 “–hard”，每种参数表示一种恢复模式，下面我们将分别看一下这git reset 三个参数的用法区别。

前提条件 我们仓库中的Git 提交顺序为 “A(a.txt) -> B(b.txt) -> C(c.txt)“，当前分支为master。 当前 HEAD 指向C，即 a47072e9f97eac4ac02c0abac82b26a9719663fc (HEAD -> master)，我们以恢复到B(aad0c91e7b1d3577)点为准。

test1 git:(master) git log
commit a47072e9f97eac4ac02c0abac82b26a9719663fc (HEAD -> master)
Author: 孙兴房 <1293812389@qq.com>
Date: Mon Sep 24 10:37:14 2018 +0800

add c.txt

commit aad0c91e7b1d357729f65dc0bbeb6c9c9dd53844
Author: 孙兴房 <1293812389@qq.com>
Date: Mon Sep 24 10:22:12 2018 +0800

add b.txt

commit 68315608ef8d0cff5d229c2ee5010e59a1475cfe
Author: 孙兴房 <1293812389@qq.com>
Date: Mon Sep 24 10:21:59 2018 +0800

add a.txt

**–soft 模式 ** 执行 git reset –soft aad0c9,恢复到B。然后再执行 git status 看下

一、MVCC简介

MVCC (Multiversion Concurrency Control)，即多版本并发控制技术。InnoDB数据库的事务隔离级别就是通过UNDO和MVCC来实现的(ACID特性)，旧数据存储在UNDO中，再通过DB_ROLL_PTR 回溯查找历史版本。

二、MVCC原理

1、通过DB_ROLL_PT 回溯查找数据历史版本2、通过read view判断行记录是否可见

理解这一块之前，我们必须先了解一下row的内部存储格式

字段说明：

• DB_ROW_ID：长度6个字节。此值由InnoDB自动生成，聚集索引时使用。如果用户未显式指定表主键时，表优先使用第一个非null的唯一索引作为主键.否则使用DB_ROW_ID的值作为主键ID，聚集索引会使用此值。如果指定了表主键的话，则聚集索引使用指定的值。
• DB_TRX_ID：6个字节的事务ID。标记了最后更新此记录的事务ID，每开起一个新事务，其值自动+1
• DB_ROLL_PTR：7字节的回滚指针。指向当前记录项的undo log记录，找之前版本的数据需通过此指针。

MySQL中的MVCC原理

首次 insert 记录的DB_ROLL_PTR指针为NULL。修改新值后，记录的 DB_ROLL_PTR 回滚指针指向原始值在Undo Log 日志的位置，也就是说将原值在Unde Log的物理位置存储到原记录的 DB_POLL_PTR 字段。如果事务回滚的话，则从Undo Log 中把原始值读取出来再放到记录中去。如果直接commit的话，则直接保存即可。记录格式参考：

InnoDB Undo Log的日志类型 MySQL数据库InnoDB存储引擎的undo log采用了逻辑的日志。 InnoDB undo log的格式可以概括为:<操作类型>++<数据>.  A. 从表中删除一行记录 TRX_UNDO_DEL_MARK_REC (将主键记入日志) 在删除一条记录时，并不是真正的将数据从数据库中删除,只是标记为已删除.这样做的好处是Undo Log中不用记录整行的信息.在undo时操作也变得很简单.   B. 向表中插入一行记录 TRX_UNDO_INSERT_REC (仅将主键记入日志) TRX_UNDO_UPD_DEL_REC (将主键记入日志) 当表中有一条被标记为删除的记录和要插入的数据主键相同时， 实际的操作是更新这个被标记为删除的记录。  C. 更新表中的一条记录 TRX_UNDO_UPD_EXIST_REC (将主键和被更新了的字段内容记入日志) TRX_UNDO_DEL_MARK_REC 和 **TRX_UNDO_INSERT_REC ** 当更新主键字段时，实际执行的过程是删除旧的记录然后，再插入一条新的记录。

事务隔离级别的区别：

• RR隔离级别下，在每个事务开始的时候，会将当前系统中的所有的活跃事务拷贝到一个列表中(read view)。

• RC隔离级别下，在事务中的 每个语句开始（select) 时，会将当前系统中的所有的活跃事务拷贝到一个列表中(read view)

Index Condition Pushdown(ICP)

Index Condition Pushdown (ICP)是mysql使用索引从表中检索行数据的一种优化方式。

ICP原理

禁用ICP，存储引擎会通过遍历索引定位基表中的行，然后返回给MySQL Server层，再去为这些数据行进行WHERE后的条件的过滤。

开启ICP，如果部分WHERE条件能使用索引中的字段，MySQL Server 会把这部分下推到存储引擎层，存储引擎通过索引过滤，把满足的行从表中读取出。ICP能减少引擎层访问基表的次数和MySQL Server 访问存储引擎的次数。

ICP的目标是减少从基表中全纪录读取操作的数量，从而降低IO操作

对于InnoDB表，ICP只适用于辅助索引。

ICP标识

当使用ICP优化时，执行计划的Extra列显示 Using index condition提示

相关参数

optimizer_switch="index_condition_pushdown=on”;

可以通过 SET optimizer_switch = ‘index_condition_pushdown=off/on’; 来关闭或开启ICP

适用场景

#辅助索引INDEX (zipcode, lastname, firstname).

SELECT * FROM people WHERE zipcode='95054' AND lastname LIKE '%etrunia%'AND address LIKE '%Main Street%';

People表有个二级索引 INDEX (zipcode, lastname, firstname), 用户只知道某用户的 zipcode 和大概的 lastname、address, 此时想查询相关信息。

若不使用ICP：则是通过二级索引中zipcode的值去基表取出所有 zipcode=’95054′ 的数据，然后server层再对 lastname LIKE ‘%etrunia%’AND address LIKE ‘%Main Street%’;进行过滤

若使用ICP：则 lastname LIKE ‘%etrunia%’AND address LIKE ‘%Main Street%’ 的过滤操作在 二级索引 中完成，然后再去基表取相关数据

服务器端编程经常需要构造高性能的IO模型，常见的IO模型有四种：

（1）同步阻塞IO（Blocking IO）：即传统的IO模型。

（2）同步非阻塞IO（Non-blocking IO）：默认创建的socket都是阻塞的，非阻塞IO要求socket被设置为NONBLOCK。注意这里所说的NIO并非Java的NIO（New IO）库。

（3）IO多路复用（IO Multiplexing）：即经典的 反应器Reactor设计模式，有时也称为异步阻塞IO，Java中的Selector和Linux中的epoll都是这种模型。高性能并发服务程序使用IO多路复用模型+多线程任务处理的架构。

（4）异步IO（Asynchronous IO）：即经典的 Proactor设计模式，也称为异步非阻塞IO。不经常用。

高性能I/O设计模式Reactor和Proactor： https://blog.csdn.net/xiongping_/article/details/45152333

select、poll、epoll之间的区别(搜狗面试)

转自： https://blog.csdn.net/baixiaoshi/article/details/48708347

https://www.jianshu.com/p/0371c9569736

https://segmentfault.com/a/1190000008230146

原文： https://golang.org/ref/mem

https://www.jianshu.com/p/d24dfbb33781

https://www.jianshu.com/p/dd80f6be7969

unsafe包位置: src/unsafe/unsafe.go

指针类型： ***类型：**普通指针，用于传递对象地址，不能进行指针运算。 **unsafe.Pointer：**通用指针，用于转换不同类型的指针，不能进行指针运算。 **uintptr：**用于指针运算，GC 不把 uintptr 当指针，uintptr 无法持有对象。uintptr 类型的目标会被 GC 回收。

unsafe.Pointer 可以和 普通指针 进行相互转换。
unsafe.Pointer 可以和 uintptr 进行相互转换。

也就是说 unsafe.Pointer 是桥梁，可以让任意类型的指针实现相互转换，也可以将任意类型的指针转换为 uintptr 进行指针运算。

一般使用流程： 第一步：将结构体 -> 通用指针unsafe.Pointer(struct) -> uintptr(通用指针)获取内存段的起始位置start_pos，并记录下来，第二步使用。 第二步：使用start_pos + unsafe.Offsetof(s.b) -> 将地址转为能用指针unsafe.Pointer(new_pos)->转为普通指针np = (*byte)(p)->赋值 *np = 20 第三步：打印结构体，发现内容发生了更改。

推荐：unsafe.Sizeof() 针对不同数据类型的情况

首先我们对切片有一个大概的理解，先看一下slice的内部结构，共分三部分，一个是指向底层数组的时候，一个是长度len，另一个就是slice的容量cap了。如cap不足以放在新值的时候，会产生新的内存地址申请。

先看代码

package main

import "fmt"

func main() {

    // 创建一个切片，长度为9，容量为10
    fmt.Println("----- 1.测试切片变量append的影响（未申请新的内存空间）-----")
    a := make([]int, 9,10)
    fmt.Printf( "%p len=%d cap=%d %vn" , a, len(a), cap(a), a)

    // 切片进行append操作，由于原来len(a)长度为9,而cap(a)容量为10，未达到扩展内存的要求，此时新创建的切片变量还指向原来的底层数组，只是数组的后面添加一个新值
    // 此时一共两个切片变量，一个是a，另一个是s4。但共指向的一个内存地址
    s4 := append(a,4)
    fmt.Printf("%p len=%d cap=%d %vnn" , s4, len(s4), cap(s4), s4)

    // 测试上面提到的切片变量a和s4共指向同一个内存地址, 发现切片数组的第一个值都为7，而唯一不同的是len的长度，而cap仍为10
    fmt.Println("----- 2.测试切片变量共用一个底层数组（内存地址一样）-----")

    a[0] =  7
    fmt.Printf("%p len=%d cap=%d %vn" , a, len(a), cap(a), a)
    fmt.Printf("%p len=%d cap=%d %vnn" , s4, len(s4), cap(s4), s4)

    // 切片进行append操作后，发现原来的cap(a)的长度已用完了(因为a和s4共用一个底层数组，你也可以理解为cap(s4))，此时系统需要重新申请原cap*2大小的内存空间,所以cap值为10*2=20，将把原来底层数组的值复制到新的内存地址

    // 此时有两个底层数组，一个是切片变量a和s4指向的数组，另一个就是新的切片变量s4
    fmt.Println("----- 3.测试切片变量append的影响（申请了新的内存空间，内存地址不一样了）-----" )
    s4 = append(s4,  5 )
    fmt.Printf("%p len=%d cap=%d %vnn" , s4, len(s4), cap(s4), s4)

    // 注意：原切片未发生任何变化，(打印a[0]=7是因为上面第3段落代码已把默认的0值改为了7）
    fmt.Println("----- 4.测试原切片变量a未发生变化-----" )
    fmt.Printf("%p len=%d cap=%d %vnn" , a, len(a), cap(a), a)

}

运行结果：

一：innodb_file_format参数

在 innodb 1.0.6版本之前，innodb文件格式innodb_file_format只有 Antelope(Antelope 文件格式支持Redundant，Compact两种格式来存放行记录，Redundant是为了兼容之前版本而保留的。在mysql 5.1版本中，默认设置为Compact，用户可以通过 show table status like 'table_name'来查看表使用的行格式row_format)

从innodb 1.0.6开始引入了新的文件格式 Barracuda 在原来的基础上(Antelope)新增了Dynamic和Compressed两种行格式。

二：innodb_file_format如何使用

  一般， innodb_file_format 在配置文件中指定；row_format则在创建数据表时指定：

CREATE TABLE test2 (column1 INT PRIMARY KEY)
ENGINE=InnoDB ROW_FORMAT=Compressed KEY_BLOCK_SIZE=4;

三：innodb_file_format = Barracuda

在指定innodb_file_format = Barracuda时，建议配合如下参数一起使用

innodb_file_format_max = Barracuda
innodb_strict_mode = 1
innodb_file_per_table = 1

因为system tablespace使用的是Antelope文件格式，如果不指定innodb_file_per_table = 1(5.6.6是默认开启的)，那么innodb表被存储在system tablespace,这时在建表的时候无法使用Dynamic和Compressed两种行格式(如果设置了innodb_strict_mode = 1，那么建表的时候指定Dynamic和Compressed会直接报错。如果没有指定innodb_strict_mode = 1，建表的时候指定Dynamic和Compressed会被忽略，默认设置为Compact)

关于innodb_strict_mode参数介绍：

innodb_strict_mode

Command-Line Format –innodb_strict_mode=# System Variable Name innodb_strict_mode Variable Scope Global, Session Dynamic Variable Yes Permitted Values Type boolean Default OFF When innodb_strict_mode is ON, InnoDB returns errors rather than warnings for certain conditions. The default value is OFF.

推荐阅读： https://www.cnblogs.com/zishengY/p/6892345.html

**一、什么是MRR **

MMR全称是Multi-Range Read，是MYSQL5.6优化器的一个新特性，在MariaDB5.5也有这个特性。优化的功能在使用二级索引做范围扫描的过程中减少磁盘随机IO和减少主键索引的访问次数。是优化器将随机 IO 转化为顺序 IO 以降低查询过程中 IO 开销的一种手段。（参考： https://blog.csdn.net/caomiao2006/article/details/52205177）

**二、MRR和没有MRR的区别 **

给出一个简单的例子，在innodb表执行下面的查询：

SELECT non_key_column FROM tbl WHERE key_column=x

在没有MRR的情况下，它是这样得到结果的：

1.  select key_column, pk_column from tb where key_column=x order  by key_column —> 假设这个结果集是t

2.  for each row in t ; select non_key_column from tb where pk_column = pk_column_value。(回表)

在有MRR的情况下，它是这样执行的： 1.  select key_column, pk_column from tb where key_column = x  order by key_column —> 假设这个结果集是t 2.  将结果集t放在buffer里面(直到read_rnd_buffer_size这个buffer满了)，然后对结果集t按照 pk_column 排序      —> 假设排序好的结果集是t_sort 3.  select non_key_column from tb where pk_column in (select pk_column from t_sort)