
[TOC]

疑问：

1. 为什么append要返回一个切片？

```go
var a = make([]int, 1, 2)
fmt.Printf("%v\t\t%v\n", a, (*reflect.SliceHeader)(unsafe.Pointer(&a)))
a = append(a, 2)
fmt.Printf("%v\t\t%v\n", a, (*reflect.SliceHeader)(unsafe.Pointer(&a)))
a = append(a, 3, 4, 5)
fmt.Printf("%v\t%v\n", a, (*reflect.SliceHeader)(unsafe.Pointer(&a)))
// [0]             &{824634327040 1 2}
// [0 2]           &{824634327040 2 2}
// [0 2 3 4 5]     &{824634368000 5 6}
```

- 如果切片容量不足的话，go扩容切片需要重新申请内存，内存地址会发生变化

- 如果切片容量充足,go不需要扩容，底层数组data内存地址也不会发生变化，`func append(slice []Type, elems ...Type) []Type` 传入的切片也是复制(切片数据结构), 函数的参数是传值, 底层数组部分是通过隐式指针传递(指针本身依然是传值的，但是指针指向的却是同一份的数据)，所以被调用函数是可以通过指针修改掉调用参数切片中的数据。除了数据之外，切片结构还包含了切片长度和切片容量信息，这2个信息也是传值的。如果被调用函数中修改了`Len`或`Cap`信息的话，就无法反映到调用参数的切片中，这时候一般会通过返回修改后的切片来更新之前的切片。

2. 这里注意一下切片a的容量是6，按照我们之前的说法，newcap > 2倍容量时, 取newcap为最终容量，但这里5 > 2 * 2，为什么这里是6呢？内存对齐，最后会解释一下这里的原因

# Go语言程序的初始化

执行从main.main开始，如果main导入了其他的包，会按照顺序将他们包含进mian包里

- 如果某个包被多次导入的话，只会导入的时候只会执行一次
- 当一个包被导入的时候如果还导入了其他的包，则会将其他的包先导入进来，创建和初始化常量和变量，再调用包里的init函数
- 如果一个包里的有多个init函数，调用顺序未定义，同一个文件内的init函数则是以顺序依次调用
- 最后，当main包的所有包级变量、常量创建初始化完成，init函数执行之后才会进入main.main

![](/images/blog/1/golang/assert/数组切片引用.png)

# 函数

```go
// 具名函数
func Add(a, b int) int {
    return a+b
}

// 匿名函数
var Add = func(a, b int) int {
    return a+b
}

func Inc() (v int) {
  // 闭包，什么是闭包
  defer func() {v++}()
  return 42
}
// 43，这里为什么是43而不是42

func main() {
    for i := 0; i < 3; i++ {
        defer func(){ println(i) } ()
    }
}
// Output:
// 3
// 3
// 3
```

- 函数有具名函数和匿名函数之分，包级一般都是具名函数，具名函数是匿名函数的一种特例。
- 当匿名函数引用了外部作用域中的变量时就成了闭包函数，闭包函数是函数式编程语言的核心。
- 函数可以有多个参数和返回值，参数和返回值都是以传值的方式和被调用者交换数据，支持可变参数传值，可变参数必须是最后一个参数，可变数量的参数其实是一个切片类型的参数。
- 函数不仅参数可以有名字，也可以给返回值命名。
- 闭包函数对外部捕获的变量不是以传值方式而是以引用方式传参
- 不建议for循环内部使用defer语句
- 任何可以通过函数参数修改调用参数的情形，是因为函数参数中显式或隐式的传入指针参数

# 方法

```go
// 关闭文件
func (f *File) Close() error {
    // ...
}
// 读文件数据
func (f *File) Read(offset int64, data []byte) int {
    // ...
}
```

- Go语言中，将第一个函数参数移动到函数前面 - 方法
- Go语言中，通过在结构体内置匿名的成员来实现继承
- Go语言中，方法是编译时静态绑定的

# 接口

Go语言在提供严格的类型检查的同时，通过接口类型实现了对鸭子类型的支持，使得安全动态的编程变得相对容易。

> 鸭子类型 -  当看到一只鸟走起来像鸭子、游泳起来像鸭子、叫起来也像鸭子，那么这只鸟就可以被称为鸭子。
>
> 在鸭子类型中，关注点在于对象的行为，能作什么；而不是关注对象所属的类型。例如，在不使用鸭子类型的语言中，我们可以编写一个函数，它接受一个类型为"鸭子"的对象，并调用它的"走"和"叫"方法。在使用鸭子类型的语言中，这样的一个函数可以接受一个任意类型的对象，并调用它的"走"和"叫"方法。如果这些需要被调用的方法不存在，那么将引发一个运行时错误。任何拥有这样的正确的"走"和"叫"方法的对象都可被函数接受的这种行为引出了以上表述，这种决定类型的方式因此得名。- 维基百科



在Go语言中，对于基础类型（非接口类型）不支持隐式转换，无法将一个int类型的值直接赋值给int64类型的变量，也无法将int的值赋值给底层是int类型新定义命名类型的变量，go语言对类型的一致性要求非常严格，但是对接口转化则是非常的灵活，对象和接口之间的转换、接口和接口之间的转换都可能是隐式的转换。

有时候对象和接口之间太灵活了，导致我们需要人为地限制这种无意之间的适配。常见的做法是定义一个含特殊方法来区分接口。比如`runtime`包中的`Error`接口就定义了一个特有的`RuntimeError`方法，用于避免其它类型无意中适配了该接口：

```go
type runtime.Error interface {
    error
    // RuntimeError is a no-op function but
    // serves to distinguish types that are run time
    // errors from ordinary errors: a type is a
    // run time error if it has a RuntimeError method.
    RuntimeError()
}

type testing.TB interface {
    Error(args ...interface{})
    Errorf(format string, args ...interface{})
    ...

    // A private method to prevent users implementing the
    // interface and so future additions to it will not
    // violate Go 1 compatibility.
    private()
}
```

扩容和内存对齐

```go
// 这个例子 讲讲扩容或内存
var a = make([]int, 1, 1)
fmt.Printf("%v\t%v\n", a, (*reflect.SliceHeader)(unsafe.Pointer(&a)))
a = append(a, 2, 3, 4, 5)
fmt.Printf("%v\t%v\n", a, (*reflect.SliceHeader)(unsafe.Pointer(&a)))
// [0]             &{824634335232 1 1}
// [0 2 3 4 5]     &{824634368000 5 6}
```

按照扩容的第二条，大于两倍旧容量，按理说应该是5但这里是6，那就是接下来的内存对齐了

- capmem = roundupsize(uintptr(newcap) * sys.PtrSize)
- newcap 我们计算出来是5, uintptr(newcap) * sys.PtrSize -> 5 * 8 = 40; roundupsize(40)
- (size+smallSizeDiv-1)/smallSizeDiv] -> (40 + 8 - 1)/8 = 5（这里是因为int存储的，后面小数都是截取）class_to_size[size_to_class8[5]] -> 48 
- 48 / 8 = 6 所以最终cap为6

记一下学习心得，写写来的踏实

go 函数方法接口


[TOC]

# 什么是rpc，rpc和http的区别，为什么要用rpc

访问量加大以后，为了解决用户访问卡顿的问题，我们就上集群架设nginx部署多个服务，由nginx负载均衡把请求转发到其他服务上。过一段时间发现发现数据库扛不住了，应用服务完好，这时候我们就上数据库读写分离，再架设几台数据库服务器，做主从，分库分表。服务访问量越来越高，项目功能也越来越多，整个项目也愈发庞大。修改一个类就需要全盘上传，切换nginx重启，分布流程越来越长，也越来越复杂。我们开始把模块拆分，用户系统、订单系统、评论系统...，这样就达到用户模块代码修改的时候只需要修改用户信息服务。但是还是需要切换顶层的nginx，把需要重启的服务的流量切到可用服务上。这个时候rpc登场了，所有服务启动的时候注册到一个注册机里面，然后顶层处理在接收到nginx请求后，去注册机里找一个可用的服务并调用接口。

用户和订单肯定是分不开的，分离成为两个系统不同的主机不同的进程以后如何进行交互，可以通过http或者rpc，http的优点是：简单、通用、开发方便。相较http rpc的优点是：长连接（不必像http 3次握手）、rpc一般都有注册中心，有丰富的监控管理；

一般来说，RPC服务主要是针对大型企业的，而HTTP服务主要是针对小企业的，因为RPC效率更高，而HTTP服务开发迭代会更快。

# 前期准备

## 安装 Protocol Buffers v3 工具
从 [https://github.com/google/protobuf/releases](https://github.com/google/protobuf/releases) 下载工具
1. 解压
2. bin/protoc 添加环境变量

## 安装 protoc 插件 protoc-gen-go
```shell
go get -u github.com/golang/protobuf/protoc-gen-go
```

# c & s 基本服务与请求

[【源代码】](https://github.com/douyacun/foo_go/tree/master/cmd/rpc/cs)

protoc 是 [Protocol Buffers](https://developers.google.com/protocol-buffers/docs/overview) 的一个工具，负责生成协议的序列化、反序列化相应语言的代码，看个例子:

首先定义proto协议文件：
```protobuf
// 这里声明协议版本，默认是proto2, 不向下兼容
syntax = "proto3";

// 这里指定 go 包名
package greeter;

// 定义要序列化的信息的结构
message HelloRequest {
    // string 字段类型， 也可以自定义字段类型
    string name = 1; // 注意这里1是唯一的， 1-15 占用1个字节， 16 - 2047 占用2个字节
    // 预留字段
    reserved "foo", "bar";
}
// 同一个proto文件中可以定义多个message type
message HelloReply {
    string message = 1;
}
// 定义接口
service Greeter {
    rpc SayHello (HelloRequest) returns (HelloReply);
}
```
具体的字段类型个语言对照可以查看[https://developers.google.com/protocol-buffers/docs/proto3#scalar](https://developers.google.com/protocol-buffers/docs/proto3#scalar)


编译grpc生成序列化和反序列化代码
```shell
protoc --go_out=plugins=grpc:. hello.proto
```

gRPC插件会为服务端和客户端生成不同的接口：
```go
//client api
type GreeterClient interface {
	SayHello(ctx context.Context, in *HelloRequest, opts ...grpc.CallOption) (*HelloReply, error)
}

// server API
type GreeterServer interface {
	SayHello(context.Context, *HelloRequest) (*HelloReply, error)
}
```

## server

1. 定义结构体，实现服务端接口
2. 注册rpc 服务
3. 启用tcp服务，接受一个链接启用一个goroutine，完成http/2握手，接收gRPC请求，调用注册函数

```go
const Port = ":4000"
// 定义结构体
type server struct{}
// 实现 service greeter 定义的接口
func (p *server) SayHello(ctx context.Context, req *greeter.HelloRequest) (*greeter.HelloReply, error) {
	reply := &greeter.HelloReply{
		Message:              "hello " + req.GetName(),
	}
	return reply, nil
}
func main() {
  // 注册rpc server
	greeter.RegisterGreeterServer(s, new(server))
	lis, err := net.Listen("tcp", Port)
	if err != nil {
		log.Fatal(err)
	}
	if err := grpc.NewServer().Serve(lis); err != nil {
		log.Fatalf("failed to serve: %v", err)
	}
}
```

## client

1. 连接服务器，`grpc.WithInsecure` 不需要权限验证
2. 初始化客户端，gRPC自动生成的客户端
3. 调用api

```go
func main() {
	conn, err := grpc.Dial("localhost:4000", grpc.WithInsecure())
	if err != nil {
		log.Fatal(err)
	}
	defer conn.Close()
	client := greeter.NewGreeterClient(conn)
	if err != nil {
		log.Fatal(err)
	}
	reply, err := client.SayHello(context.Background(), &greeter.HelloRequest{Name: "world"})
	if err != nil {
		log.Fatal(err)
	}
	fmt.Println(reply.GetMessage())
}
```

# stream 简单聊天室

[【源代码】](https://github.com/douyacun/foo_go/tree/master/cmd/rpc/stream)

定义protobuf

```protobuf
// 定义接口
service Greeter {
		...
    // 声明关键字stream，这里可以只有参数使用或者返回值使用stream
    rpc RouteChat (stream HelloRequest) returns (stream HelloReply);
}
```

## server

```go
type Greeter_RouteChatServer interface {
	Send(*HelloReply) error
	Recv() (*HelloRequest, error)
	grpc.ServerStream
}
```

greeter.Greeter_RouteChatServer 接口,有Send/Recv两个方法相当于write/read，当前stream要当作单个connection，接下来的操作就是对stream的读写操作了

```go
func (p *server) RouteChat(stream greeter.Greeter_RouteChatServer) error {
	for {
    // Recv 返回前面定义 HelloRequest 结构体
		request, err := stream.Recv()
		if err != nil {
      // EOF 表示客户端结束了连接
			if err == io.EOF {
				return nil
			}
			return err
		}
		err = stream.Send(&greeter.HelloReply{Message: "hello " + request.GetName()})
		if err != nil {
			return err
		}
	}
}

```

## client

同服务端建立长连接，间隔1秒发送一次请求

```go
func main() {
	conn, err := grpc.Dial("localhost:4000", grpc.WithInsecure())
	if err != nil {
		log.Fatal(err)
	}
	defer conn.Close()
	client := greeter.NewGreeterClient(conn)
	stream, err := client.RouteChat(context.Background())
	if err != nil {
		log.Fatal(stream)
	}
	go func() {
		for{
			if err := stream.Send(&greeter.HelloRequest{Name: "world"}); err != nil {
				log.Fatal(err)
			}
			time.Sleep(time.Second)
		}
	}()
	for {
		reply, err := stream.Recv()
		if err != nil {
			if err == io.EOF {
				break
			}
			log.Fatal(err)
		}
		fmt.Println(reply.GetMessage())
	}
}
```

# 发布订阅模式

[【源码阅读】](https://github.com/douyacun/foo_go/tree/master/cmd/rpc/pubsub)

找个优秀的包，godoc搜索 pubsub https://godoc.org/?q=pubsub 看到docker的pubsub引用最多，而且和第二名差距甚大，决定使用docker提供的pubsub

本地使用发布订阅：

```go
p := pubsub.NewPublisher(100*time.Millisecond, 10)
c := p.Subscribe()

p.Publish("hi")

msg := <-c
fmt.Println(msg)
```

使用grpc 实现 发布订阅模式， 创建protobuf文件

```protobuf
syntax = "proto3";

package douyacun;

message Topic {
    string name = 1;
}
message PubsubMessage {
    bytes data = 1;
}
message PublishRequest {
    Topic topic = 1;
    PubsubMessage messages = 2;
}
message PublishResponse {
    uint64 message_id = 1;
}
service Publisher {
    rpc Publish (PublishRequest) returns (PublishResponse);
    rpc Subscribe (Topic) returns (stream PubsubMessage);
}
```

## server

```go
type server struct {
	Pub *pubsub.Publisher
}

func (s *server) Publish(c context.Context, pub *douyacun.PublishRequest) (*douyacun.PublishResponse, error) {
	s.Pub.Publish(pub)
	return &douyacun.PublishResponse{MessageId: 1}, nil
}

func (s *server) Subscribe(req *douyacun.Topic, stream douyacun.Publisher_SubscribeServer) error {
	ch := s.Pub.SubscribeTopic(func(v interface{}) bool {
    // 订阅全部消息
		if req.GetName() == "" {
			return true
		}
		if it, ok := v.(*douyacun.PublishRequest); ok {
			if it.Topic.GetName() == req.GetName() {
				return true
			}
		}
		return false
	})
	for v := range ch {
		if pub, ok := v.(*douyacun.PublishRequest); ok {
			if err := stream.Send(pub.GetMessages()); err != nil {
				return err
			}
		}
	}
	return nil
}
```

## client

### 订阅

这样就可以多启动几个订阅进程

```go
cc, err := grpc.Dial(":12345", grpc.WithInsecure())
if err != nil {
  log.Fatalf("grpc.Dial 错误：%v", err)
}
client := douyacun.NewPublisherClient(cc)
stream, err := client.Subscribe(context.Background(), &douyacun.Topic{Name: "golang"})
if err != nil {
  log.Fatalf("client.Subscribe 错误: %v", err)
}
for {
  msg, err := stream.Recv()
  if err != nil {
    if err == io.EOF {
      return
    }
    log.Fatal(err)
  }
  fmt.Printf("新消息：%s\n", msg.String())
}
```

### 发布

```go
cc, err := grpc.Dial(":12345", grpc.WithInsecure())
if err != nil {
  log.Fatal(err)
}
client := douyacun.NewPublisherClient(cc)
for {
  resp, err := client.Publish(context.Background(), &douyacun.PublishRequest{
    Topic: &douyacun.Topic{
      Name: "golang",
    },
    Messages: &douyacun.PubsubMessage{
      Data: []byte("welcome!"),
    },
  })
  if err != nil {
    log.Fatal(err)
  }
  fmt.Println(resp.MessageId)
  time.Sleep(time.Second)
}
```



什么是rpc，rpc和http的区别，为什么要用rpc

gRPC入门

innodb关键特性包括：
- 插入缓冲 (insert buffer)
- 两次写(double write)
- 自适应hash索引(adaptive hash index)
- 异步I/O (async i/o)
- 刷新临界页 (flush neighbor page)

# 插入缓冲
## insert buffer

每张表都有一个主键索引(没有明确指明，会默认生成一个不可见的主键索引)，主键索引(聚集索引)的插入顺序是非常快的，但是不可能每张表只有一个聚集索引，更多情况下一张表会有很多辅助索引，对于主键索引的插入式顺序存放的，但是对于辅助索引的叶子节点的插入就不是顺序的了。

innodb 对于非聚集索引的插入和更新操作，不是每一次直接插入到索引页，而是先判断索引页是否在缓冲池中,若有直接插入，否则，先放入到insert buffer中。再以一定频率合并insert buffer和索引子节点。通常能将多个插入操作合并到一个操作中，因为在一个索引页中。使用insert buffer需要同时满足两个条件：
- 索引是辅助索引
- 索引不是唯一索引

`show engine innodb status\G;`可以查看insert buffer的使用情况

- seg_size 代表insert buffer大小为 n*16k
- free list len代表空闲列表的长度
- inserts代表插入记录数
- merged recs代表了合并后的插入记录数
- merges 代表合并的次数，实际读取页的次数

> 缓冲池: 是为了通过内存速度来弥补磁盘速度较慢对于性能的影响，包括insert buffer、data pag、index page、lock info、adaptive hash index

**IBUF_POOL_SIZE_PER_MAX_SIZE**可以调整insert_buffer_pool可以占用缓冲池的大小

## change buffer
change buffer可以对DML操作(insert,delete,update)进行缓冲操作,适用对象仍然是非唯一的辅助索引， 对一条记录update的步骤：
- 将记录标记为已删除
- 真正将记录删除

**innodb_change_buffer_max_size**控制change buffer最大使用内存的数量，25表示最多使用1/4缓冲池空间

# double write
插入缓冲给innodb存储引擎带来的是性能上的提升，double write提高了innodb存储引擎的数据页的可靠性

那么double write做了什么？\
数据库宕机时，可能对数据页只写入部分，这种情况称为部分写失效。可以通过redo log来恢复，在写入失效时，先通过页的副本还原该页，在进行重做，这就是double write

double write有一段2m的内存空间，在磁盘上还有2m*的共享表空间，数据先从内存空间写入到共享空间，立即调用fsync同步，此时是顺序写入速度快，在完成写入后，再将共享空间的数据写入到各个表空间文件中。此时写入是离散的。double write写入时会合并写入操作，消耗要小于两次io的消耗

```shell
mysql> show global status like 'innodb_dblwr%\G'
```

- innodb_dblwr_pages_writen: inndob一共写了多少页
- innodb_dblwr_writes: 实际写入次数

`skip_innodb_doublewrite`可以禁止使用doublewrite功能

# 自适应hash索引
hash索引的查找复杂度O(1),B+树的查找取决于B+树的高度，生产环境一般是3～4,需要3～4次

innodb会监控对表上各索引的查询，如果二级索引被频繁访问，成为热点数据，建立hash索引可以带来，速度的提升

hash索引有一个要求，查询模式必须是一样的，必须是等值查询

**`innodb_adaptive_hash_index`**: 是否开启自适应hash索引

# 异步I/O - AIO
AIO优势:
1. 多个I/O异步执行
2. 合并多个I/O为同步操作

mysql read、脏页刷新，磁盘写入都是通过AIO来实现的

# 刷新邻接页
原理是：innodb刷新脏页时，会检测该页所在区的所有页，如果有脏页AIO就会将多个I/O操作合并为一个操作。
**innodb_flush_neighbors** 可以控制是否启用，传统机械键盘建议启用，固态硬盘建议关闭

innodb说这些特性，相信比说支持事务要更有说服力

innodb关键特性

mysql中常见的日志文件：
- 错误日志(error log)
- 二进制日志(binlog)
- 慢查询日志(slow log)
- 查询日志(log)

# 错误日志
查看错误日志的位置
```shell
mysql> show variables like 'log_error'\G;
```

# 慢查询日志

开启慢查询日志`log_slow_queries`
```shell
mysql> show variables like 'log_slowqueries'\G;
```
慢查询时间`long_query_time`
```shell
mysql> show variables like 'long_query_time'\G
```

sql没有用到索引也会记录到慢查询日志
```shell
mysql> show variables like 'long_throttle_queries_not_using_indexes'\G;
```

mysqldumpslow查看执行时间最长的10条sql
```shell
$ mysqldumpslow -s -al -n 10 mysqlslow.log
```

mysql支持将慢查询日志写入到slow_log表，**log_output**指定慢查询输出格式，默认为file，设置为table会写入到slow_log表

```shell
mysql> show create table mysql.slow_log;
```

# rds执行日志记录sls
阿里云关系数据库RDS（MySQL版本）的SQL执行日志已经与日志服务打通，提供准实时的SQL执行分析功能，并提供内置可深钻的报表、支持自定义审计规则、异常报警、报表订阅与生态对接能力等。
- 据库的登录、退出。
- DDL（Data Definition Language）：对数据库结构定义的SQL，例如CREATE、ALTER DROP、TRUNCATE、COMMENT等。
- DML（Data Manipulation Language）：SQL操作语句，包括SELECT、INSERT、UPDATE、DELETE等。
- 其他SQL执行，包括任何其他通过SQL执行的控制，例如回滚、控制等。
- 失败的SQL执行也会被记录。
- 对SQL执行的延迟、执行结果、影响的行数等信息的提取。

https://help.aliyun.com/document_detail/118266.html

# 二进制日志
- max_binlog_size: 二进制文件最大值，超过该值产生新的文件，后缀加1
- binlog_cache_size: innodb所有未提交的事物都会被记录缓存中去，事物提交时，在写二进制日志中。当一个session开启一个事物时，会自动初始化一个大小为binlog_cache_size大小的缓存，当事物的记录大于binlog_cache_size的时候，会把缓冲的日志写入一个临时文件
    - binlog_cache_use 缓冲写二进制日志次数 
    - binlog_cache_disk_use 临时文件写二进制日志次数

查看binlog文件的内容：
```shell
mysql> mysqlbinlog --start-position=203 douyacun.00007
```

# 套接字文件
本地mysql可以使用套接字文件来连接
```shell
mysql> show variables like 'socket';
```

# pid文件
进程pid，可以用pid文件来重启进程
```shell
mysql> show variables like "";
```



错误日志,慢查询日志,查询日志,二进制日志

mysql日志文件


```
vmstat 5

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 966440 215852 1476524    0    0     0    30    1    1 16  5 79  0  0
 0  0      0 964680 215852 1476520    0    0     0    86 1869 1031  7  2 91  0  0
 0  0      0 964184 215852 1476560    0    0     0   266 1399  914  5  1 94  0  0
 5  0      0 963440 215852 1476496    0    0     0   105 2439 1284 12  3 85  0  0
 0  0      0 965920 215852 1476528    0    0     0    69 2468 1322 15  6 79  0  0
 0  0      0 964904 215852 1476620    0    0     0    64 2121 1169  9  1 90  0  0
 0  0      0 965176 215852 1476656    0    0     0   117 4030 1761 23  6 71  0  0
 2  0      0 965424 215852 1476700    0    0     0    94 3611 1679 22  8 70  0  0
```

procs: 
- `r` 代表多少进程正在等待cpu*, 
- `b`显示多少进程在不可中断的休眠(通常意味在等待系统io eg. 磁盘，网络，用户输入等)

memory: 
- swapd: 显示多少块被换出到了磁盘(页面交换)
- free: 多少块是空闲，未被使用
- buffer: 多少被用作缓冲
- cache: 多少被用作操作系统的缓存

swap:显示页面交换活动，每秒有多少块正在被换入(从磁盘)和换出(到磁盘)
- si
- so

io: 显示有多少块从磁盘读取(io)和写出(bo),反映了磁盘io

system: 显示了每秒中断(in)和上下文切换(cs)的数量

cpu: 显示cpu时间花费在各类操作的百分比，包括执行用户代码(非内核)，执行系统代码(内核)，空闲，以及等待I/O

> linux块的大小是1024字节

vmstat.md



# redis 持久化策略
- master关闭持久化
- slave 开启rdb，必要时开启aof和rdb

# aof和rdb配置
- `save` rdb出发记录条件
    - `save 900 1`     # 服务器在900秒内，修改了1次
    - `save 300 10`     # 服务器在300秒内，修改了10次
    - `save 60 10000`   # 服务器在60秒内，修改了10000次 
    - `save ""` 关闭rdb持久化
- `rdbchecksum yes` 压缩rdb文件
- `rdbcompression yes` 压缩rdb文件
- `dbfilename dump.rdb` rdb文件

- `appendonly yes` 启用aof增量持久化
- `appendfilename "appendonly.aof"` aof文件
- `appendfsync` `fsync`脏页同步策略
    - `always` 每次修改
    - `everysec` 每秒记录一次
    - `no` 取决于系统
- `no-appendfsync-on-rewrite yes` # 如果是开启状态的，并且有bgsave或bgrewriteaof正在进行的话不调用系统函数`fsync()`(同步脏页到磁盘中)
```c
/* Don't fsync if no-appendfsync-on-rewrite is set to yes and there are
    * children doing I/O in the background. 
    *
    * 如果 no-appendfsync-on-rewrite 选项为开启状态，
    * 并且有 BGSAVE 或者 BGREWRITEAOF 正在进行的话，
    * 那么不执行 fsync 
    */
if (server.aof_no_fsync_on_rewrite &&
    (server.aof_child_pid != -1 || server.rdb_child_pid != -1))
        return;
```

# aof 实现原理
aof重写并不读取分析现有aof文件，是通过读取当前数据库状态来实现，然后用一条命令代替之前记录这个键值对的多条命令,aof重写函数，因为这个函数会进行大量的写入操作，这个线程会被长时间阻塞，no-appendfsync-on-rewrite 是为了避免在此期间与aof重写进程占用文件描述符

- fork一个子进程处理
- 父进程将新输入的写命令追加到server.aof_rewrite_buffer

aof.c/rewriteAppendOnlyFileBackground
```c
/* This is how rewriting of the append only file in background works:
 * 1) The user calls BGREWRITEAOF
 * 2) Redis calls this function, that forks():
 *    2a) the child rewrite the append only file in a temp file.
 *    2b) the parent accumulates differences in server.aof_rewrite_buf.
 * 3) When the child finished '2a' exists.
 * 4) The parent will trap the exit code, if it's OK, will append the
 *    data accumulated into server.aof_rewrite_buf into the temp file, and
 *    finally will rename(2) the temp file in the actual file name.
 *    The the new file is reopened as the new append only file. Profit!
 */
int rewriteAppendOnlyFileBackground(void) {
    pid_t childpid;
    long long start;

    // 已经有进程在进行 AOF 重写了
    if (server.aof_child_pid != -1) return REDIS_ERR;

    // 记录 fork 开始前的时间，计算 fork 耗时用
    start = ustime();

    if ((childpid = fork()) == 0) {
        char tmpfile[256];

        /* Child */

        // 关闭网络连接 fd
        closeListeningSockets(0);

        // 为进程设置名字，方便记认
        redisSetProcTitle("redis-aof-rewrite");

        // 创建临时文件，并进行 AOF 重写
        snprintf(tmpfile,256,"temp-rewriteaof-bg-%d.aof", (int) getpid());
        if (rewriteAppendOnlyFile(tmpfile) == REDIS_OK) {
            size_t private_dirty = zmalloc_get_private_dirty();

            if (private_dirty) {
                redisLog(REDIS_NOTICE,
                    "AOF rewrite: %zu MB of memory used by copy-on-write",
                    private_dirty/(1024*1024));
            }
            // 发送重写成功信号
            exitFromChild(0);
        } else {
            // 发送重写失败信号
            exitFromChild(1);
        }
    } else {
        /* Parent */
        // 记录执行 fork 所消耗的时间
        server.stat_fork_time = ustime()-start;

        if (childpid == -1) {
            redisLog(REDIS_WARNING,
                "Can't rewrite append only file in background: fork: %s",
                strerror(errno));
            return REDIS_ERR;
        }

        redisLog(REDIS_NOTICE,
            "Background append only file rewriting started by pid %d",childpid);

        // 记录 AOF 重写的信息
        server.aof_rewrite_scheduled = 0;
        server.aof_rewrite_time_start = time(NULL);
        server.aof_child_pid = childpid;

        // 关闭字典自动 rehash
        updateDictResizePolicy();

        /* We set appendseldb to -1 in order to force the next call to the
         * feedAppendOnlyFile() to issue a SELECT command, so the differences
         * accumulated by the parent into server.aof_rewrite_buf will start
         * with a SELECT statement and it will be safe to merge. 
         *
         * 将 aof_selected_db 设为 -1 ，
         * 强制让 feedAppendOnlyFile() 下次执行时引发一个 SELECT 命令，
         * 从而确保之后新添加的命令会设置到正确的数据库中
         */
        server.aof_selected_db = -1;
        replicationScriptCacheFlush();
        return REDIS_OK;
    }
    return REDIS_OK; /* unreached */
}
```

# 残酷的事实
1. redis 是单线程的数据库，导致单核cpu的最大处理能力就是redis单实例处理能力的天花板了, 举个例子:

新功能上线又有点不放心，于是做了个开关放在 Redis，所有应用可以很方便的共享。通过读取 Redis 中的开关 key 来判断是否启用某个功能，对每个请求做判断。这里的问题是什么？

这个key只能放在一个实例上，而所有的流量都要去这个实例去get，导致该分片实例亚历山大，他的极限在我们的实例上不过4w QPS

- 根据数据性质把 Redis 集群分类；我的经验是分三类：cache、buffer 和 db
   - cache：临时缓存数据，加分片扩容容易，一般无持久化需要。
   - buffer：用作缓冲区，平滑后端数据库的写操作，根据数据重要性可能有持久化需求。
   - db：替代数据库的用法，有持久化需求。

[redis实践](http://www.ittidy.com/it/479.html)

redis持计划_rdb_aof_持久化


# fsync,  fdatasync 同步内核的页缓存到磁盘
```c
#include <unistd.h>

int fsync(int fd);
int fdatasync(int fd);
```

- fsync： 文件描述符(fd)在内核中所有的[脏页](/linux/页缓存.md#dirty_page)同步到的磁盘，调用会被阻塞直到磁盘写入完成，能确保被修改过的块立即写入到磁盘
- fdatasync：类似于fysnc，文件属性(st_atime,st_mtime等)不会同步到磁盘，目的是为了减少磁盘交互

# 与fdatasync相比fsync的性能问题#性能
fysnc 除了同步文件的修改内容(脏页)，还会同步文件的描述信息(metadata、包括size、访问时间st_atime、st_mtime等)，因为文件数据和metadata通常存在磁盘不同的地方，所以fsync至少需要两次I/O操作

多余的一次IO操作，有多么昂贵呢？根据Wikipedia的数据，当前硬盘驱动的平均寻道时间（Average seek time）大约是3~15ms，7200RPM硬盘的平均旋转延迟（Average rotational latency）大约为4ms，因此一次IO操作的耗时大约为10ms左右。

文件的尺寸(st_size)如果发生变化，是需要立即同步的否则OS一旦崩溃，即使文件的数据部分已同步，由于metadata没有同步，依然读不到修改的内容，最后的饿访问时间和修改时间是不需要每次同步的

读redis源码-AOF和磁盘I/O造成的延迟

sync_fsync_fdatasync_linux

# 参数
- -c 统计每一系统调用的所执行的时间,次数和出错的次数等.
- -d 输出strace关于标准错误的调试信息.
- -f 跟踪由fork调用所产生的子进程.
- -ff 如果提供-o filename,则所有进程的跟踪结果输出到相应的filename.pid中,pid是各进程的进程号.
- -F 尝试跟踪vfork调用.在-f时,vfork不被跟踪.
- -h 输出简要的帮助信息.
- -i 输出系统调用的入口指针.
- -q 禁止输出关于脱离的消息.
- -r 打印出相对时间关于,,每一个系统调用.
- -t 在输出中的每一行前加上时间信息.
- -tt 在输出中的每一行前加上时间信息,微秒级.
- -ttt 微秒级输出,以秒了表示时间.
- -T 显示每一调用所耗的时间.
- -v 输出所有的系统调用.一些调用关于环境变量,状态,输入输出等调用由于使用频繁,默认不输出.
- -V 输出strace的版本信息.
- -x 以十六进制形式输出非标准字符串
- -xx 所有字符串以十六进制形式输出.
- -a column 设置返回值的输出位置.默认 为40.
- -e expr 指定一个表达式,用来控制如何跟踪.格式：[qualifier=][!]value1[,value2]...
qualifier只能是 trace,abbrev,verbose,raw,signal,read,write其中之一.value是用来限定的符号或数字.默认的 qualifier是 trace.感叹号是否定符号.例如:-eopen等价于 -e trace=open,表示只跟踪open调用.而-etrace!=open 表示跟踪除了open以外的其他调用.有两个特殊的符号 all 和 none. 注意有些shell使用!来执行历史记录里的命令,所以要使用\\.
- -e trace=set 只跟踪指定的系统 调用.例如:-e trace=open,close,rean,write表示只跟踪这四个系统调用.默认的为set=all.
- -e trace=file 只跟踪有关文件操作的系统调用.
- -e trace=process 只跟踪有关进程控制的系统调用.
- -e trace=network 跟踪与网络有关的所有系统调用.
- -e strace=signal 跟踪所有与系统信号有关的 系统调用
- -e trace=ipc 跟踪所有与进程通讯有关的系统调用
- -e abbrev=set 设定strace输出的系统调用的结果集.-v 等与 abbrev=none.默认为abbrev=all.
- -e raw=set 将指定的系统调用的参数以十六进制显示.
- -e signal=set 指定跟踪的系统信号.默认为all.如 signal=!SIGIO(或者signal=!io),表示不跟踪SIGIO信号.
- -e read=set 输出从指定文件中读出 的数据.例如: -e read=3,5
- -e write=set 输出写入到指定文件中的数据.
- -o filename 将strace的输出写入文件filename
- -p pid 跟踪指定的进程pid.
- -s strsize 指定输出的字符串的最大长度.默认为32.文件名一直全部输出.
- -u username 以username的UID和GID执行被跟踪的命令

# 查看php-fpm master进程的系统调用
```shell
[root@cpc-dev01 work]# strace -p 175664
strace: Process 175664 attached
epoll_wait(11, [], 1, 322)              = 0
epoll_wait(11, [], 1, 333)              = 0
epoll_wait(11, [], 1, 94)               = 0
getsockopt(10, SOL_TCP, TCP_INFO, "\n\0\0\0\0\0\0\0@B\17\0\0\0\0\0\30\2\0\0\0\0\0\0\0\0\0\0\200\0\0\0"..., [104]) = 0
epoll_wait(11, [], 1, 239)              = 0
epoll_wait(11, [], 1, 333)              = 0
epoll_wait(11, [], 1, 333)              = 0
epoll_wait(11, [], 1, 94)               = 0
getsockopt(10, SOL_TCP, TCP_INFO, "\n\0\0\0\0\0\0\0@B\17\0\0\0\0\0\30\2\0\0\0\0\0\0\0\0\0\0\200\0\0\0"..., [104]) = 0
epoll_wait(11, [], 1, 239)              = 0
epoll_wait(11, [], 1, 333)              = 0
epoll_wait(11, [], 1, 269)              = 0
epoll_wait(11, [], 1, 64)               = 0
epoll_wait(11, [], 1, 94)               = 0
getsockopt(10, SOL_TCP, TCP_INFO, "\n\0\0\0\0\0\0\0@B\17\0\0\0\0\0\30\2\0\0\0\0\0\0\0\0\0\0\200\0\0\0"..., [104]) = 0
```

# 统计一下mysql系统调用
```
[root@00h ~]# strace -p 2940 -c
strace: Process 2940 attached
^Cstrace: Process 2940 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 75.28    0.001836        1836         1           poll
 18.00    0.000439         439         1           restart_syscall
  6.40    0.000156          39         4           futex
  0.33    0.000008           4         2           accept
------ ----------- ----------- --------- --------- ----------------
100.00    0.002439                     8           total
```

可以使用strace对应用的系统调用和信号传递的跟踪结果来对应用进行分析