
[TOC]

# 	时间格式常量

## 标准

```go
const (
    ANSIC       = "Mon Jan _2 15:04:05 2006"
    UnixDate    = "Mon Jan _2 15:04:05 MST 2006"
    RubyDate    = "Mon Jan 02 15:04:05 -0700 2006"
    RFC822      = "02 Jan 06 15:04 MST"
    RFC822Z     = "02 Jan 06 15:04 -0700" // RFC822 with numeric zone
    RFC850      = "Monday, 02-Jan-06 15:04:05 MST"
    RFC1123     = "Mon, 02 Jan 2006 15:04:05 MST"
    RFC1123Z    = "Mon, 02 Jan 2006 15:04:05 -0700" // RFC1123 with numeric zone
    RFC3339     = "2006-01-02T15:04:05Z07:00"
    RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"
    Kitchen     = "3:04PM"
    // Handy time stamps.
    Stamp      = "Jan _2 15:04:05"
    StampMilli = "Jan _2 15:04:05.000"
    StampMicro = "Jan _2 15:04:05.000000"
    StampNano  = "Jan _2 15:04:05.000000000"
)
```

## 时/分/秒/毫秒/微妙/纳秒

```go
const (
    Nanosecond  Duration = 1
    Microsecond          = 1000 * Nanosecond
    Millisecond          = 1000 * Microsecond
    Second               = 1000 * Millisecond
    Minute               = 60 * Second
    Hour                 = 60 * Minute
)
```

## 月份

```go
const (
	January Month = 1 + iota
	February
	March
	April
	May
	June
	July
	August
	September
	October
	November
	December
)
```

## 星期几

```go
const (
	Sunday Weekday = iota
	Monday
	Tuesday
	Wednesday
	Thursday
	Friday
	Saturday
)
```

# 超时控制 After

```go
var c chan int

func handle(int) {}

func main() {
	select {
	case m := <-c:
		handle(m)
	case <-time.After(10 * time.Second):
		fmt.Println("timed out")gg
	}
}
```

# 时间间隔 Duration

time.Add(t Duration)传参需要使用Durtaion 

## time.Sub

计算两个时间差，返回duration

```go
func expensiveCall() {}

func main() {
	t0 := time.Now()
	expensiveCall()
	t1 := time.Now()
	fmt.Printf("The call took %v to run.\n", t1.Sub(t0))
}
```

## ParseDuration

有效符号："ns", "us" (or "µs"), "ms", "s", "m", "h".

```go
func main() {
	hours, _ := time.ParseDuration("10h")
	complex, _ := time.ParseDuration("1h10m10s")
	micro, _ := time.ParseDuration("1µs")
	// The package also accepts the incorrect but common prefix u for micro.
	micro2, _ := time.ParseDuration("1us")

	fmt.Println(hours)
	fmt.Println(complex)
	fmt.Printf("There are %.0f seconds in %v.\n", complex.Seconds(), complex)
	fmt.Printf("There are %d nanoseconds in %v.\n", micro.Nanoseconds(), micro)
	fmt.Printf("There are %6.2e seconds in %v.\n", micro2.Seconds(), micro)
}
```

# 时间 Time

基础结构体:

```go
type Time struct {
	wall uint64
	ext  int64
	loc *Location
}
```

## Date

返回指定日期的time

```go
func main() {
	t := time.Date(2009, time.November, 10, 23, 0, 0, 0, time.UTC)
	fmt.Printf("Go launched at %s\n", t.Local())
}
// Go launched at 2009-11-11 07:00:00 +0800 CST
```

## 当前时间 Now

返回当前时间,这个用的最多

## 时间解析 Parse & ParseInLocation

```go
func Parse(layout, value string) (Time, error)
```

Layout 时间格式，value时间值，解析时间返回time

```go
func main() {
	t, _ := time.Parse("2006-01-02", "2020-12-05")
	fmt.Println(t)
  m, _ := time.Parse("2006-01-02 15:04:05", "2020-12-05 11:23:08")
	fmt.Println(m)
}
// 2020-12-05 00:00:00 +0000 UTC
// 2020-12-05 11:23:00 +0000 UTC
```

上面的用法其实是错误的，没有时区，正确的做法是：

```go
func main() {
	t, _ := time.ParseInLocation("2006-01-02", "2020-12-05")
	fmt.Println(t)
  m, _ := time.ParseInLocation("2006-01-02 15:04:05", "2020-12-05 11:23:08")
	fmt.Println(m)
}
// 2020-12-05 00:00:00 +0800 CST
// 2020-12-05 11:23:00 +0800 CST
```

## 时间戳 Unix

解析时间戳为time

```go
func main() {
	t := time.Unix(1576053402, 100000000)
	fmt.Print(t)
}
// 2019-12-11 16:36:42.01 +0800 CST
```

## 格式化 Format

时间格式化

默认输出格式：`2006-01-02 15:04:05.999999999 -0700 MST`

```go
func main() {
	fmt.Printf("当前时间: %s\n", time.Now())
	fmt.Printf("RFC1123Z: %s\n", time.Now().Format(time.RFC1123Z))
	fmt.Printf("RFC3339: %s\n", time.Now().Format(time.RFC3339))
}

// 当前时间: 2019-12-11 16:25:53.987141 +0800 CST m=+0.000513629
// RFC1123Z: Wed, 11 Dec 2019 16:25:53 +0800
// RFC3339: 2019-12-11T16:25:53+08:00
```

## 时间加减 Add

当前时间加上 ？

```go
func main() {
	start := time.Date(2009, 1, 1, 12, 0, 0, 0, time.UTC)
	afterTenSeconds := start.Add(time.Second * 10)
	afterTenMinutes := start.Add(time.Minute * 10)
	afterTenHours := start.Add(time.Hour * 10)
	afterTenDays := start.Add(time.Hour * 24 * 10)

	fmt.Printf("start = %v\n", start)
	fmt.Printf("start.Add(time.Second * 10) = %v\n", afterTenSeconds)
	fmt.Printf("start.Add(time.Minute * 10) = %v\n", afterTenMinutes)
	fmt.Printf("start.Add(time.Hour * 10) = %v\n", afterTenHours)
	fmt.Printf("start.Add(time.Hour * 24 * 10) = %v\n", afterTenDays)
}
```

## 判断时间是否相等 Equal

判断两个时间是否一致

```go
func main() {
	secondsEastOfUTC := int((8 * time.Hour).Seconds())
	beijing := time.FixedZone("Beijing Time", secondsEastOfUTC)

	// Unlike the equal operator, Equal is aware that d1 and d2 are the
	// same instant but in different time zones.
	d1 := time.Date(2000, 2, 1, 12, 30, 0, 0, time.UTC)
	d2 := time.Date(2000, 2, 1, 20, 30, 0, 0, beijing)

	datesEqualUsingEqualOperator := d1 == d2
	datesEqualUsingFunction := d1.Equal(d2)

	fmt.Printf("datesEqualUsingEqualOperator = %v\n", datesEqualUsingEqualOperator)
	fmt.Printf("datesEqualUsingFunction = %v\n", datesEqualUsingFunction)
}
```

## Before/After

判断时间A是否在时间B之前还是之后，返回bool

```go
func main() {
	a := time.Now()
	b := time.Now()

	fmt.Printf("a 在 b 之前: %v\n", a.Before(b))
	fmt.Printf("a 在 b 之后: %v\n", a.After(b))
}

// a 在 b 之前: true
// a 在 b 之后: false
```

## 时间四舍五入 Round

时间4舍5入

```go
func main() {
	t := time.Date(0, 0, 0, 12, 15, 30, 918273645, time.UTC)
	round := []time.Duration{
		time.Nanosecond,
		time.Microsecond,
		time.Millisecond,
		time.Second,
		2 * time.Second,
		time.Minute,
		10 * time.Minute,
		time.Hour,
	}

	for _, d := range round {
		fmt.Printf("t.Round(%6s) = %s\n", d, t.Round(d).Format("15:04:05.999999999"))
	}
}
```

## 舍去 Truncate

```go
func main() {
	t, _ := time.Parse("2006 Jan 02 15:04:05", "2012 Dec 07 12:15:30.918273645")
	trunc := []time.Duration{
		time.Nanosecond,
		time.Microsecond,
		time.Millisecond,
		time.Second,
		2 * time.Second,
		time.Minute,
		10 * time.Minute,
	}

	for _, d := range trunc {
		fmt.Printf("t.Truncate(%5s) = %s\n", d, t.Truncate(d).Format("15:04:05.999999999"))
	}
	// To round to the last midnight in the local timezone, create a new Date.
	midnight := time.Date(t.Year(), t.Month(), t.Day(), 0, 0, 0, 0, time.Local)
	_ = midnight
}
```

# 定时器 Tick 

```go
func statusUpdate() string { return "" }

func main() {
	c := time.Tick(5 * time.Second)
	for now := range c {
		fmt.Printf("%v %s\n", now, statusUpdate())
	}
}
```



go time常用方法


Etcd几个关键特征：

**raft算法**：Leader选举/操作同步，无论访问任意节点，都将获得最终一致性数据，高度可靠。

**mvcc**:  etcd有2级存储结构 [B树内存索引](https://github.com/google/btree)  / [bbolt B+树](https://github.com/etcd-io/bbolt) ，内存中使用btree维护key/value索引，节点中存的是bbolt中键值K，通过这个k在bbolt查找，得到的才是用户传进去的value值

- 每个事务有唯一事务id，就是下面的main id int64
- 一个事务可以包含多个修改操作（put/delete），每一个操作就是一个revision, 共享同一个main id
- 一个事务内多个连续修改操作会从0开始递增，编号 sub id int64

```
type revision struct {
	// main is the main revision of a set of changes that happen atomically.
	main int64

	// sub is the sub revision of a change in a set of changes that happen
	// atomically. Each change has different increasing sub revision in that
	// set.
	sub int64
}

type keyIndex struct {
	key         []byte
	modified    revision // the main rev of the last modification
	generations []generation
}
```

内存索引中，每个原始key会关联一个key_index，里面维护了多版本信息

**事务**: 

- 只读事务
- 读写事务



# 概要

- etcd集群

- 配置UI管理界面

- 监控与维护

- 容灾

#### 应用场景

- 服务发现
- 配置中心
- 分布式锁
- 监控机器活动

#### 基础功能

- 监控 watch
- 租约 lease
- 全局锁 lock
- 选举 elect
- 集群状态 
  - `etcdctl --write-out=table endpoint status`
  - `etcdctl endpoint health`
- 快照 snapshot
  - `etcdctl --endpoints=127.0.0.1:2379 snapshot save my.db`
  - `etcdctl --endpoints=127.0.0.1:2379 --write-out=table snapshot status my.db`
- 迁移 migrate
- 成员管理 member
  - `etcdctl --endpoints=127.0.0.1:2379 member list`

- 授权 auth



# 集群配置

`docker-compose.yml`

```yaml
services:
  etcd1:
    image: 'bitnami/etcd:latest'
    environment:
      - ALLOW_NONE_AUTHENTICATION=yes
      - ETCD_NAME=etcd1
      - ETCD_INITIAL_ADVERTISE_PEER_URLS=http://etcd1:2380
      - ETCD_LISTEN_PEER_URLS=http://0.0.0.0:2380
      - ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379
      - ETCD_ADVERTISE_CLIENT_URLS=http://etcd1:2379
      - ETCD_INITIAL_CLUSTER_TOKEN=etcd-cluster
      - ETCD_INITIAL_CLUSTER=etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
      - ETCD_INITIAL_CLUSTER_STATE=new
    networks:
      - app-tier
  etcd2:
    image: 'bitnami/etcd:latest'
    environment:
      - ALLOW_NONE_AUTHENTICATION=yes
      - ETCD_NAME=etcd2
      - ETCD_INITIAL_ADVERTISE_PEER_URLS=http://etcd2:2380
      - ETCD_LISTEN_PEER_URLS=http://0.0.0.0:2380
      - ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379
      - ETCD_ADVERTISE_CLIENT_URLS=http://etcd1:2379
      - ETCD_INITIAL_CLUSTER_TOKEN=etcd-cluster
      - ETCD_INITIAL_CLUSTER=etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
      - ETCD_INITIAL_CLUSTER_STATE=new
    networks:
      - app-tier
  etcd3:
    image: 'bitnami/etcd:latest'
    environment:
      - ALLOW_NONE_AUTHENTICATION=yes
      - ETCD_NAME=etcd3
      - ETCD_INITIAL_ADVERTISE_PEER_URLS=http://etcd3:2380
      - ETCD_LISTEN_PEER_URLS=http://0.0.0.0:2380
      - ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379
      - ETCD_ADVERTISE_CLIENT_URLS=http://etcd1:2379
      - ETCD_INITIAL_CLUSTER_TOKEN=etcd-cluster
      - ETCD_INITIAL_CLUSTER=etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
      - ETCD_INITIAL_CLUSTER_STATE=new
    networks:
      - app-tier
  etcdkeeper:
    image: deltaprojects/etcdkeeper:latest
    ports:
      - 8080:8080
    networks:
      - app-tier
```

etcdkeeper 连接etcd: `etcd1:2379` ，它们处在同一个network中直接使用服务名就可以

# 服务注册与服务发现

**服务注册：**

1. 申请lease租约，设置服务生存周期ttl，让key自动过期
2. 服务正常状态下，通过keep-alive定期去租约，避免过期
3. key有统一前缀，比如：`etcdctl --endpoints=127.0.0.1:2379 put /sdmaster-service/192.168.31.110   192.168.31.110`

**服务发现：**

1. 服务`watch /sdmaster-service --prefix`
2. `sdmaster-service` 下发生变化都会发生通知

相关代码已经发到github [discovery](https://github.com/douyacun/discovery)

**版本兼容:**

1. 正常安装`github.com/coreos/etcd/clientv3`会存在 `module declares its path as: go.etcd.io/bbolt`

```
go: discovery/discovery-service-protocol/client imports
        github.com/coreos/etcd/clientv3 tested by
        github.com/coreos/etcd/clientv3.test imports
        github.com/coreos/etcd/auth imports
        github.com/coreos/etcd/mvcc/backend imports
        github.com/coreos/bbolt: github.com/coreos/bbolt@v1.3.5: parsing go.mod:
        module declares its path as: go.etcd.io/bbolt
                but was required as: github.com/coreos/bbolt
```

解决方法：

`replace github.com/coreos/bbolt latest => go.etcd.io/bbolt latest`

2. 如果使用grpc的话，会存在grpc版本和etcd不兼容的问题

使用最先版本grpc, 会报`google.golang.org/grpc/naming`缺失

`module google.golang.org/grpc@latest found (v1.33.1), but does not contain package google.golang.org/grpc/naming`

如果降低到1.29.0可以解决这个问题，如果运行代码会报

`undefined: resolver.BuildOption` 

`undefined: resolver.ResolveNowOption`

这是因为grpc版本和etcd不兼容的问题，需要降低版本到 `1.26.0` 以下

解决方法:

```
replace google.golang.org/grpc latest => google.golang.org/grpc v1.26.0
```

3. 目前 protobuf grpc 生成的go代码, 会报错 `undefined grpc.ClientConnInterface` `undefined: grpc.SupportPackageIsVersion6`

```
go get -d -u github.com/golang/protobuf/protoc-gen-go
git -C "$(go env GOPATH)"/src/github.com/golang/protobuf checkout $GIT_TAG
go install github.com/golang/protobuf/protoc-gen-go
```

# go-grpc 负载均衡

正常http负载均衡策略，client -> proxy gateway load balance -> service

grpc提供负载均衡策略，client  load balance -> service 

grpc关键点是负载均衡在客户端

1. 服务端启动时，首先将服务地址注册到服务注册表，定期keepalive健康检测
2. 客户端访问某个服务，watch订阅服务注册表，然后以某种负载均衡策略选择一个目标地址

![](/images/blog/1/architecture/assert/grpc-load-balancing.png)

相关代码已发到github: [go-grpc 负载均衡](https://github.com/douyacun/discovery)

# etcd 配置中心

- 动态加载配置（watch）
- 历史版本（revision）
- 权限控制
- 命名空间

思路:

1. 加载配置文件 put etcd
2. watch prefix 配置变更可以及时变更配置

相关代码已经发到 github : [etcd配置中心](https://github.com/douyacun/etcd/)

# etcd 分布式锁

原理:

1. 租约创建一个key
2. key不存在，创建key，成功获取到锁
3. key存在，无法创建key，获取锁失败

etcd分布式锁的实现在`go.etcd.io/etcd/clientv3/concurrency`包中

1. 初始化sessions

```go
func NewSession(client *v3.Client, opts ...SessionOption) (*Session, error) {
	ops := &sessionOptions{ttl: defaultSessionTTL, ctx: client.Ctx()}
	for _, opt := range opts {
		opt(ops)
	}
	// 初始化租约
	id := ops.leaseID
	if id == v3.NoLease {
		resp, err := client.Grant(ops.ctx, int64(ops.ttl))
		if err != nil {
			return nil, err
		}
		id = v3.LeaseID(resp.ID)
	}
	// 由上层调用控制是否中断
	ctx, cancel := context.WithCancel(ops.ctx)
	keepAlive, err := client.KeepAlive(ctx, id)
	if err != nil || keepAlive == nil {
		cancel()
		return nil, err
	}
	donec := make(chan struct{})
	s := &Session{client: client, opts: ops, id: id, cancel: cancel, donec: donec}
	go func() {
		defer close(donec)
		for range keepAlive {
			// eat messages until keep alive channel closes
		}
	}()
	return s, nil
}
```

2. `func NewMutex(s *Session, pfx string) *Mutex `

初始化`Mutex`

3. `func (m *Mutex) Lock(ctx context.Context) error`

这里类似redis的分布式锁: `set key value NX EX 60`  如果key存在就返回，否则就设置

```go
func (m *Mutex) Lock(ctx context.Context) error {
	s := m.s
	client := m.s.Client()
  // 伪代码
  // if !m.myKey {
  //	client.Put(m.myKey, value)
  // } else {
  // 	client.Get(m.myKey)
	// }
	m.myKey = fmt.Sprintf("%s%x", m.pfx, s.Lease())
	cmp := v3.Compare(v3.CreateRevision(m.myKey), "=", 0)
	put := v3.OpPut(m.myKey, "", v3.WithLease(s.Lease()))
	get := v3.OpGet(m.myKey)
	getOwner := v3.OpGet(m.pfx, v3.WithFirstCreate()...)
	resp, err := client.Txn(ctx).If(cmp).Then(put, getOwner).Else(get, getOwner).Commit()
	if err != nil {
		return err
	}
 	// 此锁是否为自己获得
	m.myRev = resp.Header.Revision
	if !resp.Succeeded {
		m.myRev = resp.Responses[0].GetResponseRange().Kvs[0].CreateRevision
	}
	ownerKey := resp.Responses[1].GetResponseRange().Kvs
	if len(ownerKey) == 0 || ownerKey[0].CreateRevision == m.myRev {
		m.hdr = resp.Header
		return nil
	}
	// 阻塞直到获取到该锁
	hdr, werr := waitDeletes(ctx, client, m.pfx, m.myRev-1)
	if werr != nil {
		m.Unlock(client.Ctx())
	} else {
		m.hdr = hdr
	}
	return werr
}
```

4. `func (m *Mutex) Unlock(ctx context.Context) error` 删除 key

# 推荐阅读

- [高可用分布式存储 etcd 的实现原理](https://draveness.me/etcd-introduction/)
- [etcd使用经验总结](https://alexstocks.github.io/html/etcd.html)





已实现 grpc负载均衡、服务发现、分布式锁、配置中心、

etcd应用场景


[toc]

# CPU高的原因

负载首先看的是top(htop也可以)，可以定位到是哪个进程（线上服务也不会运行多个服务的）

但是进程是因为什么导致的进程负载高？

- **CPU密集型进程**: 使用大量CPU会导致平均负载高，与平均负载一致
- **I/O密集型**: 等待I/O也会导致平均负载升高，但是CPU使用率不一定很高
- **上下文切换**: 大量的上下文切换也会导致CPU负载变高，此时CPU 使用率也会比较高
  - 进程上下文切换
    - 内核调度（优先级/时间片）
    - 系统资源不足
    - sleep
    - 硬件中断
  - 线程上下文切换
  - 中断上下文切换

# 负载

**单核处理器**

"load average"的值越低，比如等于0.2或0.3，就说明电脑的工作量越小，系统负荷比较轻。

系统负荷为1.0，意味着大桥的所有路段都有车，也就是说大桥已经"满"了。但是必须注意的是，直到此时大桥还是能顺畅通行的

系统负荷为1.7，意味着车辆太多了，大桥已经被占满了（100%），后面等着上桥的车辆为桥面车辆的70%。

CPU的系统负荷，基本上等同于上面的类比。大桥的通行能力，就是CPU的最大工作量；桥梁上的车辆，就是一个个等待CPU处理的进程（process）。

**经验法则**

当系统负荷持续大于0.7，你必须开始调查了，问题出在哪里，防止情况恶化。

当系统负荷持续大于1.0，你必须动手寻找解决办法，把这个值降下来。

当系统负荷达到5.0，就表明你的系统有很严重的问题，长时间没有响应，或者接近死机了。你不应该让系统达到这个值。

**多处理器**

2个CPU表明系统负荷可以达到2.0，此时每个CPU都达到100%的工作量。推广开来，n个CPU的电脑，可接受的系统负荷最大为n.0

## 工具

其他工具用法: [高负载定位的常用工具以及用法分析](./负载高定位工具.md)

### Stress:  (模拟负载高的场景) 

> 详细用法来自： [sparkdev](https://www.cnblogs.com/sparkdev/p/10354947.html)

 - `-v`: verbose 详情

 - `-q`: quiet  程序在运行的过程中不输出信息

 - `-n`: dry-run 演练，并不实际执行

 - `-t`: timeout 超时

 - `-c`: 多少进程计算sqrt(平方根)

 - `-i`: 多少进程调用sync(脏页同步到磁盘)

 - `-m`: 多少进程调用内存malloc/free(内存申请释放)

- `--vm-bytes B`  每个进程总计申请多少字节内存

- `--vm-stride B`  内存赋值时间隔多少字节

  不断的给部分内存赋值，让 COW(Copy On Write)发生。只要指定了内存相关的选项，这个操作就会执行，只是大小为默认的 4096。赋值内存的比例由参数决定：

```
for (i = 0; i < bytes; i += stride)
ptr[i] = 'Z';           /* Ensure that COW happens.  */
```
bytes 为消耗的总内存大小，stride 为间隔。
该参数会影响 CPU 状态 us 和 sy：

- us: 用户空间占用CPU百分比
- sy: 内核空间占用CPU百分比

```
$ stress --vm 2 --vm-bytes 500M --vm-stride 64
$ top
%Cpu(s): 21.3 us, 32.1 sy
```

```
$ stress --vm 2 --vm-bytes 500M --vm-stride 1M
$ top
%Cpu(s):  0.7 us, 36.3 sy
```

- `--vm-stride` 值增大就意味着减少赋值，用户空间占用CPU的比率就小了
- `--vm-hang N`: 每个消耗内存的进程在分配到内存后转入睡眠状态 N 秒，然后释放内存，一直重复执行这个过程, CPU空闲出来了，US就会降低了
- `--vm-keep`: 一直占用内存，区别于不断的释放和重新分配(默认是不断释放并重新分配内存)

```
$ stress --vm 2 --vm-bytes 500M --vm-keep
%Cpu(s): 50.4 us,  0.3 sy

$ stress --vm 2 --vm-bytes 500M --vm-hang 5
%Cpu(s):  1.8 us,  7.8 sy
```

- `-d`: （`--hadd`） 产生 N 个不断执行 write 和 unlink 函数的进程(创建文件，写入内容，删除文件)

  - `--hadd-bytes B`  指定文件大小
  
  ```
  $ stress -d 3 --hdd-bytes 10M
  $ pidstat -d 3
  11时34分30秒   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
  11时34分33秒  1000     20879      0.00      1.33      0.00  java
  11时34分33秒     0     23086      0.00 308237.87 309581.40  stress
  11时34分33秒     0     23087      0.00 346640.53 347003.32  stress
  11时34分33秒     0     23088      0.00 329619.93 326591.36  stress
  ```

## 场景一：CPU密集型

```
$ stress -c 1 time 600
$ watch -d uptime

Every 2.0s: uptime
23:39:14 up 10 days, 15:03,  3 users,  load average: 1.17, 0.82, 0.40

$ mpstat -P ALL 5
23时35分39秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
23时35分44秒  all   26.35    0.00    1.00    0.00    0.00    0.05    0.00    0.00    0.00   72.60
23时35分44秒    0    0.60    0.00    1.00    0.00    0.00    0.00    0.00    0.00    0.00   98.40
23时35分44秒    1  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
23时35分44秒    2    3.41    0.00    1.41    0.00    0.00    0.00    0.00    0.00    0.00   95.18
23时35分44秒    3    1.21    0.00    1.61    0.00    0.00    0.00    0.00    0.00    0.00   97.18
```

CPU密集型是因为进程进行了大量的运算工作的导致的，通过`mpstat`可以轻松判断出来、

> todo: 如何对代码定位问题

特点:

- `usr` 高，进程一直处于用户态运行
- `sys` 低
- `iowait` 低

## 场景二：I/O 密集型

```
$ stress -i 5 --timeout 600
$ watch -d uptime
Every 2.0s: uptime                                                                                  Sat Aug  8 00:18:56 2020
 00:18:56 up 10 days, 15:43,  3 users,  load average: 0.95, 0.75, 0.43
$ mpstat -P ALL 3
13时42分04秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
13时42分07秒  all    2.04    0.00   43.20    1.02    0.00    0.09    0.00    0.00    0.00   53.66
13时42分07秒    0    4.10    0.00   42.66    0.00    0.00    0.00    0.00    0.00    0.00   53.24
13时42分07秒    1    0.68    0.00   43.69    0.34    0.00    0.00    0.00    0.00    0.00   55.29
13时42分07秒    2    2.03    0.00   42.23    0.34    0.00    0.00    0.00    0.00    0.00   55.41
13时42分07秒    3    1.70    0.00   44.22    3.06    0.00    0.00    0.00    0.00    0.00   51.02
$ top
top - 13:49:30 up 12 days,  5:13,  5 users,  load average: 2.07, 1.08, 1.44
Tasks: 169 total,   1 running, 168 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.9 us, 41.4 sy,  0.0 ni, 55.0 id,  0.5 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem :  7924044 total,  1278284 free,  5345032 used,  1300728 buff/cache
KiB Swap:  2097148 total,  2095868 free,     1280 used.  2109988 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 3092 root      20   0    7308     96      0 D  28.2  0.0   0:09.30 stress
 3094 root      20   0    7308     96      0 D  27.9  0.0   0:09.37 stress
 3091 root      20   0    7308     96      0 D  27.6  0.0   0:09.36 stress
 3093 root      20   0    7308     96      0 D  27.6  0.0   0:09.31 stress
 3095 root      20   0    7308     96      0 D  26.9  0.0   0:09.35 stress
```

I/O密集型是因为进行了大量的磁盘读写导致的负载高，其实磁盘和内存之间是有 [**页缓存**](./页缓存.md) 来缓冲磁盘和内存速度差异的，

- 低频的读写文件是不会引起`iowait`偏高的，`iowait`高的原因是因为调用 `sync` / `fsync` 频繁的刷新脏页导致iowait过高，此时是处于内核态运行的所以 `sys`也会偏高
- 高频的大量读写文件会直接触发 脏页刷新，`iowait`/`sys`会较高

而上面`sys`较高，`iowait`低的原因，只是因为高频的调用了`sync`，没有脏页（没有高频的写文件）

## 场景三：大量进程的场景

```
$ stress -c 8 
$ watch -d uptime
Every 2.0s: uptime                                                                                                                Sun Aug  9 13:19:04 2020

 13:19:05 up 12 days,  4:43,  5 users,  load average: 7.44, 3.23, 1.30
$ mpstat -P ALL 3
14时32分28秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
14时32分31秒  all   99.42    0.00    0.58    0.00    0.00    0.00    0.00    0.00    0.00    0.00
14时32分31秒    0   99.67    0.00    0.33    0.00    0.00    0.00    0.00    0.00    0.00    0.00
14时32分31秒    1   98.00    0.00    2.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
14时32分31秒    2   99.67    0.00    0.33    0.00    0.00    0.00    0.00    0.00    0.00    0.00
14时32分31秒    3  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
$ pidstat -u 3
14时32分56秒   UID       PID    %usr %system  %guest    %CPU   CPU  Command
14时32分59秒     0     19290    0.00    0.33    0.00    0.33     3  mpstat
14时32分59秒     0     19450    0.33    1.33    0.00    1.67     0  pidstat
14时32分59秒     0     19491   48.67    0.00    0.00   48.67     3  stress
14时32分59秒     0     19492   49.33    0.00    0.00   49.33     1  stress
14时32分59秒     0     19493   48.67    0.00    0.00   48.67     3  stress
14时32分59秒     0     19494   48.67    0.00    0.00   48.67     0  stress
14时32分59秒     0     19495   50.33    0.00    0.00   50.33     2  stress
14时32分59秒     0     19496   48.67    0.00    0.00   48.67     0  stress
14时32分59秒     0     19497   49.33    0.00    0.00   49.33     2  stress
14时32分59秒     0     19498   49.33    0.33    0.00   49.67     1  stress
$ vmstat 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 8  0   1280 1271004    148 1301392    0    0     0     1    5    1  2  1 97  0  0
 8  0   1280 1271000    148 1301380    0    0     0     3 4414 1760 98  2  0  0  0
 8  0   1280 1267432    148 1301368    0    0     0     0 4370 1636 98  2  0  0  0
```

系统是4H8G

- mpstat的4个CPU `usr` 一直是100%
- pidstat的8个stress进程，各占用每个CPU的50%
- vmstat的 `r` 正在运行的进程队列是 8



## 场景四：大量的上下文切换

使用sysbench模拟大量的线程

```
$ sysbench --threads=10 --time=10 threads run
```

```
top - 09:18:26 up 14 days, 42 min,  2 users,  load average: 2.58, 0.66, 1.30
Tasks: 161 total,   1 running, 160 sleeping,   0 stopped,   0 zombie
%Cpu(s): 16.2 us, 76.0 sy,  0.0 ni,  7.8 id,  0.0 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem :  7924044 total,  1689024 free,  5740484 used,   494536 buff/cache
KiB Swap:  2097148 total,  1800444 free,   296704 used.  1734212 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 7640 root      20   0   95116   3972   2824 S 351.5  0.1   1:41.20 sysbench
```

- 负载高
- sy 内核态CPU高
- sysbench 进程

```
$ vmstat -S M 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  0    289   1649      0    482    0    0     1     3    8    1  2  1 97  0  0
 7  0    289   1649      0    482    0    0     0     1 23407 347642 14 76  9  0  0
 7  0    289   1648      0    482    0    0     0     0 21909 339189 16 76  8  0  0
 7  0    289   1649      0    482    0    0     0     0 23330 344468 16 75  9  0  0
```

- r: 运行队列高
- in：中断高
- cs：上下文切换次数高

```
$ pidstat -p 7640 -wt 3
09时21分22秒   UID      TGID       TID   cswch/s nvcswch/s  Command
09时21分25秒     0      7640         -      0.00      0.00  sysbench
09时21分25秒     0         -      7640      0.00      0.00  |__sysbench
09时21分25秒     0         -      7641   8870.00  23660.33  |__sysbench
09时21分25秒     0         -      7642  10428.00  20367.67  |__sysbench
09时21分25秒     0         -      7643  10766.67  19406.67  |__sysbench
09时21分25秒     0         -      7644  10391.67  18603.00  |__sysbench
09时21分25秒     0         -      7645  10480.00  21960.33  |__sysbench
09时21分25秒     0         -      7646  10012.67  18224.00  |__sysbench
09时21分25秒     0         -      7647   9655.00  18724.33  |__sysbench
09时21分25秒     0         -      7648  10216.33  20583.00  |__sysbench
09时21分25秒     0         -      7649  10317.67  20421.00  |__sysbench
09时21分25秒     0         -      7650  10450.67  20246.67  |__sysbench
```

通过top知道负载高的原因

- 内核态的运行导致

vmstat定位负载高的原因：

- 上下文切换高导致
- 中断导致
- 运行队列有等待运行进程

pidstat定位负载高的原因：

- 可以看到sysbench 出来很多的子线程

# 负载与参数

分析

- CPU使用率高，如何定位进程和是进程的哪个函数导致的？

## CPU使用率高，如何定位进程和是进程的哪个函数导致的？

CPU使用率高定位是哪个进程，我们可以使用的工具有：

- top/htop
- pidstat
- ps

如何定位是进程的哪个函数导致的？







借助stress、iostat、mpstat、pidstat定位负载高的进程

服务器CPU高问题排查思路


[toc]

# top(系统正在执行的进程的相关信息)

top是我定位问题的想到的第一个命令，用的最多的命令

```
top - 13:49:30 up 12 days,  5:13,  5 users,  load average: 2.07, 1.08, 1.44
Tasks: 169 total,   1 running, 168 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.9 us, 41.4 sy,  0.0 ni, 55.0 id,  0.5 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem :  7924044 total,  1278284 free,  5345032 used,  1300728 buff/cache
KiB Swap:  2097148 total,  2095868 free,     1280 used.  2109988 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 3092 root      20   0    7308     96      0 D  28.2  0.0   0:09.30 stress
 3094 root      20   0    7308     96      0 D  27.9  0.0   0:09.37 stress
 3091 root      20   0    7308     96      0 D  27.6  0.0   0:09.36 stress
 3093 root      20   0    7308     96      0 D  27.6  0.0   0:09.31 stress
 3095 root      20   0    7308     96      0 D  26.9  0.0   0:09.35 stress
```

第一行：(同uptime显示的信息) 系统时间、当前登录用户数，负载均衡：1分钟 5分钟 15分钟

第二行：进程统计数据

- total: 进程数
- running：运行进程数
- slepping：处于休眠状态的进程数
- stopped：停止的进程数
- zombie：僵尸进程数

第三行: CPU统计数据，百分比

- us：用户态占比
- sy：内核态占比
- ni：改变过优先级的进程占用CPU的百分比
- id：空闲占比
- wa：io等待占比
- hi：软中断
- si：硬中断

> 显示每个CPU的运行情况，按 1

第四行/第五行：内存的统计数据

- total：总内存
- free：空闲内存
- used：使用中的内存
- buff：用作内核缓冲区的内存

表格各字段含义：

| PID    | USER     | PR                 | NI  |VIRT| RES |SHR|
| ------ | -------- | ------------------ | ---- |---| ---|---|
| 进程号 | 运行用户 | 优先级，越小越优先 |      |虚拟内存| 物理内存 |共享内存|

---

| SHR      | S        | %CPU |%MEM|TIME+|COMMAND|
| -------- | -------- | ---- |---|---|---|
| 共享内存 | 进程状态 | CPU使用百分比 |内存使用百分比|占用CPU使用时间的累加值|运行命令|

进程状态:

- R:(Running) 运行状态
- D:(uninterruptible slepp) 不可中断睡眠状态，等待IO资源时会出现
- S:(Sleep) 睡眠状态
- T:(Stop) 终止状态，调试会进入终止状态
- Z:(Zombie) 僵尸进程

top命令操作指令:

- c: 显示完全命令
- P: CPU使用率排序
- M: 内存使用率排序
- T: 按占用CPU的总时间排序
- R: 高亮正在运行的程序
- q: 退出


# mpstat: (单个CPU维度的统计数据)

- `-P`: 指定CPU编号
  - `ALL`: 全部CPU

```
$ mpstat -P ALL 2 5
```

显示所有的进程，每2秒显示一次

# pidstat: (进程线程级别的统计数据)

sysstat工具的一个命令, 监控全部或指定进程的CPU、内存、线程、设备IO等系统资源的占用情况,`pidstat`首次运行时显示自系统启动开始的各项统计信息，之后运行`pidstat`将显示自上次运行该命令以后的统计信息

- `-C`: 正则匹配 启动命令 关键字

- `-l`: 显示 命令详情，包括启动参数

- `-p`: 指定进程号
  - `SELF`: 直显示pidstat的统计数据
  - `ALL`: 显示所有进程的统计数据

- `-r`: 内存统计数据

  ```
  $ pidstat -r -l 3
  平均时间:   UID       PID  minflt/s  majflt/s     VSZ    RSS   %MEM  Command
  平均时间:     0         1      4.07      0.00  191024   4068   0.05  /usr/lib/systemd/systemd --switched-root --system --deserialize 22
  平均时间:     0       780      1.44      0.00   21656   1224   0.02  /usr/sbin/irqbalance --foreground
  平均时间:     0       913      0.07      0.00  714272  18072   0.23  /data/frp/frp_0.33.0_linux_amd64/frpc -c /data/frp/frp_0.33.0_linux_amd64/frpc.ini
  平均时间:     0      1784      0.00      0.00 1621172  48480   0.61  /usr/bin/dockerd-current --add-runtime docker-runc=/usr/libexec/docker/docker-runc-current --default-runtime=docker-runc --exec
  平均时间:  1000     20879      5.96      0.00 8038196 4665088  58.87  /usr/share/elasticsearch/jdk/bin/java -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPre
  平均时间:  1000     21111    111.54      0.00 1735056 361671   4.56  /usr/share/kibana/bin/../node/bin/node /usr/share/kibana/bin/../src/cli --cpu.cgroup.path.override=/ --cpuacct.cgroup.path.over
  平均时间:     0     26952     69.29      0.00  108356   1223   0.02  pidstat -r -l 3
  平均时间:     0     28871      0.04      0.00  160888   5812   0.07  sshd: root@pts/0,pts/1,pts/2,pts/4
  ```

- `-s`: 堆栈利用率

  - `StkSize`: 预留内存，但是未使用
  - `StkRef`: 已经使用的内存

- `-d`:  I/O 的统计数据

  ```
  $ pidstat -d 3
  11时34分30秒   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
  11时34分33秒  1000     20879      0.00      1.33      0.00  java
  11时34分33秒     0     23086      0.00 308237.87 309581.40  stress
  11时34分33秒     0     23087      0.00 346640.53 347003.32  stress
  11时34分33秒     0     23088      0.00 329619.93 326591.36  stress
  ```

  - `kB_rd/s` : 每秒读磁盘
  - `KB_wr/s`:  每秒写磁盘
  - `KB_ccwr/s`: 脏页刷新数

- `-T`: 是否显示子进程/子线程

  - `TASK`: 不显示子进程/子线程
  - `CHILD`: 显示指定进程和其子进程/子线程
  - `ALL`: 显示所有进程和其子进程/子线程

- `-w`: 上下文切换统计数据

  - `cswch/s` : 每秒自愿上下文切换次数
  - `nvcswch/s`: 每秒非自愿上下文切换次数

- `-t`: 显示子线程

  - 显示进程号(TGID)和线程号(TID)

- `-u`: CPU统计数据

- `-U`: 指定用户

# vmstat: (虚拟内存状态)

`-S` :  k, K, m or M 显示单位，默认kb

```
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   1280 1247128    148 1326668    0    0     0     1    1    7  2  1 97  0  0
 0  0   1280 1247440    148 1326664    0    0     0     0  821 1592  2  1 97  0  0
 0  0   1280 1247316    148 1326664    0    0     0     7  342  396  2  0 98  0  0
 0  0   1280 1248076    148 1326660    0    0     0     0  869 1462  3  1 96  0  0
```

procs (进程)

- r：运行队列中进程数量
- b: 等待IO的进程数量

memory(内存)

- swpd: 虚拟内存大小
- free：空闲物理内存大小
- buffer 缓冲区的内存大小
- cache 缓存的内存大小

swap

- si：从磁盘写入内存的大小
- so：从内存到磁盘的大小

io（每块1KB）

- bi：每秒读取的块数
- bo：每秒写入的块数

system

- in：每秒中断次数
- cs：没秒上下文切换的次数

CPU：

- us：用户态百分比
- sy：内核态百分比
- id：空闲百分比
- wa：等待io的百分比

# sysbench 基础测试工具

1. cpu性能
2. 磁盘IO性能
3. 调度程序性能
4. 内存分配及传输速度
5. POSIX线程性能
6. 数据库性能

使用姿势：

```
sysbench [options]... [testname] [command]
```

options：

- --threads: 线程数
- --time： 运行时间 秒
- --thread-stack-size： 每个线程堆栈大小

testname:

- fileio: 磁盘io性能
- cpu： cpu性能
- memory:  内存分配及传输速度
- threads：posix线程性能
- mutex： 互斥锁性能测试

commands:

- prepare: 准备阶段
- run： 运行
- cleanup：清理
- help： 帮助

**线程性能压测**

> 线程无需prepare和cleanup 直接run即可

```shell
$ sysbench --threads=10 threads run
General statistics:
    total time:                          10.0208s
    total number of events:              5342

Latency (ms):
         min:                                    2.36
         avg:                                   18.73
         max:                                  152.47
         95th percentile:                       70.55
         sum:                               100069.68

Threads fairness:
    events (avg/stddev):           534.2000/22.05
    execution time (avg/stddev):   10.0070/0.01
```

**数据库性能压测**

社区提供的脚本：

```
/usr/share/sysbench/bulk_insert.lua
/usr/share/sysbench/oltp_common.lua
/usr/share/sysbench/oltp_delete.lua
/usr/share/sysbench/oltp_insert.lua
/usr/share/sysbench/oltp_point_select.lua
/usr/share/sysbench/oltp_read_only.lua
/usr/share/sysbench/oltp_read_write.lua
/usr/share/sysbench/oltp_update_index.lua
/usr/share/sysbench/oltp_update_non_index.lua
/usr/share/sysbench/oltp_write_only.lua
/usr/share/sysbench/select_random_points.lua
/usr/share/sysbench/select_random_ranges.lua
```

>  On-Line Transaction Processing联机事务处理过程(*OLTP*)

准备数据（prepare）：

```shell
$ sysbench /usr/share/sysbench/oltp_read_only.lua --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password='' --mysql-db=sbtest --db-driver=mysql --tables=10 --table-size=1000000 --report-interval=10 --threads=128 --time=120 prepare
```

压测 (run):

```shell
$ sysbench /usr/share/sysbench/oltp_read_only.lua --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password='' --mysql-db=sbtest --db-driver=mysql --tables=10 --table-size=1000000 --report-interval=10 --threads=128 --time=120 run
```

```
[ 10s ] thds: 128 tps: 83.61 qps: 1460.28 (r/w/o: 1280.37/0.00/179.91) lat (ms,95%): 3151.62 err/s: 0.00 reconn/s: 0.00
[ 20s ] thds: 128 tps: 114.82 qps: 1829.74 (r/w/o: 1600.00/0.00/229.74) lat (ms,95%): 3267.19 err/s: 0.00 reconn/s: 0.00
[ 30s ] thds: 128 tps: 116.70 qps: 1862.06 (r/w/o: 1628.67/0.00/233.40) lat (ms,95%): 3208.88 err/s: 0.00 reconn/s: 0.00
[ 40s ] thds: 128 tps: 125.20 qps: 2015.85 (r/w/o: 1765.55/0.00/250.29) lat (ms,95%): 1803.47 err/s: 0.00 reconn/s: 0.00
[ 50s ] thds: 128 tps: 123.80 qps: 1954.32 (r/w/o: 1706.71/0.00/247.60) lat (ms,95%): 1618.78 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 128 tps: 119.30 qps: 1925.28 (r/w/o: 1686.69/0.00/238.60) lat (ms,95%): 1771.29 err/s: 0.00 reconn/s: 0.00
[ 70s ] thds: 128 tps: 119.49 qps: 1922.65 (r/w/o: 1683.77/0.00/238.88) lat (ms,95%): 1739.68 err/s: 0.00 reconn/s: 0.00
[ 80s ] thds: 128 tps: 120.21 qps: 1919.50 (r/w/o: 1679.09/0.00/240.41) lat (ms,95%): 1771.29 err/s: 0.00 reconn/s: 0.00
[ 90s ] thds: 128 tps: 121.11 qps: 1931.94 (r/w/o: 1689.52/0.00/242.42) lat (ms,95%): 1739.68 err/s: 0.00 reconn/s: 0.00
[ 100s ] thds: 128 tps: 121.90 qps: 1964.95 (r/w/o: 1721.16/0.00/243.79) lat (ms,95%): 1618.78 err/s: 0.00 reconn/s: 0.00
[ 110s ] thds: 128 tps: 122.40 qps: 1943.02 (r/w/o: 1698.23/0.00/244.79) lat (ms,95%): 1803.47 err/s: 0.00 reconn/s: 0.00
[ 120s ] thds: 128 tps: 120.79 qps: 1928.00 (r/w/o: 1686.71/0.00/241.29) lat (ms,95%): 1648.20 err/s: 0.00 reconn/s: 0.00
SQL statistics:
    queries performed:
        read:                            199108 // 总select数量
        write:                           0
        other:                           28444
        total:                           227552
    transactions:                        14222  (117.57 per sec.) // tps
    queries:                             227552 (1881.20 per sec.) // qps
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          120.9538s
    total number of events:              14222

Latency (ms):
         min:                                   13.84 // 最小响应时间
         avg:                                 1084.70 // 平均响应时间
         max:                                 5281.53 // 最大响应时间
         95th percentile:                     2120.76 // 95分位响应时间
         sum:                             15426627.71 // 总时间

Threads fairness:
    events (avg/stddev):           111.1094/4.84
    execution time (avg/stddev):   120.5205/0.26
```

> 这是早期的联想电脑装的linux，本身不带固态，4H8G配置

清理数据：

```shell
$ sysbench /usr/share/sysbench/oltp_read_only.lua --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password='' --mysql-db=sbtest --db-driver=mysql --tables=10 --table-size=1000000 --report-interval=10 --threads=128 --time=120 cleanup
```

**磁盘IO压测**

options：

- --file-num=N  文件数量 128

- --file-block-size=N 写入块的大小 16K

- --file-total-size=SIZE 每个文件的大小 2G

- --file-test-mode=STRING 

  - seqwr（顺序写）
  - seqrewr（顺序读写）
  - seqrd（顺序读）
  - rndrd（随机读）
  - rndwr（随机写）
  - rndrw（随机读写）

- --file-io-mode=STRING 

  - sync 同步 默认
  - async 异步
  - mmap map映射

- --file-fsync-freq=N 调用fysnc同步磁盘的频率 （0不调用）100

- --file-fsync-all=[off|on] 每次写完文件立即 fsync  off

- --file-fsync-end=[off|on] 测试结束执行 fsync on

- --file-fsync-mode=STRING

  - fsync 默认

  - fdatasync 

  - > sync 只是将修改过的块缓冲区加入同步队列，直接返回，不等待写磁盘操作完成
    >
    > fsync 只对单一文件起作用，等待写磁盘完成，fsync会同步文件属性
    >
    > fdatasync 只同步文件数据部分

- --file-merged-requests=N 合并IO请求 0（不合并）
- --file-rw-ratio=N 读写比例 1.5 （2:1）

# lsof(列出系统打开的工具)

主要用途：查看进程打开的mysql连接，文件，网络连接等

1. 普通文件
2. 目录
3. 网络文件系统的文件
4. 字符或设备文件
5. (函数)共享库
6. 管道，命名管道
7. 符号链接
8. 网络文件（例如：NFS file、网络socket，unix域名socket）
9. 还有其它类型的文件，等等

**命令参数**

- `-c <进程名>` 
  - `losf -c mysqld`： 列出mysql进程打开的文件
- `+d <目录>` 列出目录下被打开的文件
  - `lsof +d /data/mysql` 列出 /data/mysql 目录下被打开的文件
- `+D <目录>` 递归列出目录下被打开的文件
- `-i <条件> ` 列出符合条件的进程 
  - `lsof -i 4` / `lsof -i 6`：列出打开ipv4/ipv6网络的进程
  - `lsof -i @<域名>`：列出与域名建立连接的进程
  - `lsof -i :<端口>`：列出占用端口的进程
  - `losf -i tcop -p 1969`: 列出1969进程建立的所有tcp连接
- `-p <进程号>` 
  - `lsof -p 1969` 列出 1969 进程 打开的文件



高负载定位的常用工具以及用法分析


这篇文章目的

-   熟悉kong的配置
-   线上已经在运行openresty，如何无缝接入kong
-   如何配置一个service
-   路由如何匹配，header/path/method/source/destination/SNI 如何配置
-   多个路由同时匹配优先级如何匹配
-   豆瓣是否如何对匿名用户和授权用户进行不同频率限流访问的
-   kong是如何支持蓝绿部署，金丝雀部署
-   kong的健康检测和熔断机制

[toc]

# 配置



## 注入kong nginx指令

`nginx_http_` 会注入到 `http` 块下面

`nginx_proxy_` 注入到kong 代理端口 `server` 块下面

```nginx
server {
    server_name kong;
    listen 0.0.0.0:8000 reuseport backlog=16384;
    listen 0.0.0.0:8443 ssl http2 reuseport backlog=16384;
	# ...
    # injected nginx_proxy_* directives
    real_ip_header X-Real-IP;
    real_ip_recursive off;
    # ...
}
```

`nginx_admin_` 注入到kong 管理端口 `server` 块下面

```nginx
server {
    server_name kong_admin;
    listen 127.0.0.1:8001 reuseport backlog=16384;
    listen 127.0.0.1:8444 ssl http2 reuseport backlog=16384;
	# ...
    # injected nginx_admin_* directives
    location / {
        default_type application/json;
        content_by_lua_block {
            Kong.admin_content()
        }
        header_filter_by_lua_block {
            Kong.admin_header_filter()
        }
    }
    # ...
}
```

### 配置server块

新增配置文件

```nginx
server {
  listen 2112;
  location / {
    # ...more settings...
    return 200;
  }
}
```

`kong.conf`  `nginx_http_include` 引入此配置文件

```nginx
nginx_http_include = /path/to/your/my-server.kong.conf
```

## 自定义kong nginx模版

极少用到

-   kong.conf 配置命令无法满足
-   线上已经在运行openresty实例，可以使用kong生成配置文件并且引入

### 模版

```
/usr/local/kong
├── nginx-kong.conf
└── nginx.conf
```

重启命令

```
kong start -c kong.conf --nginx-conf custom_nginx.template
```

## 嵌入kong到openresty中

kong下的文件，kong是openresty的插件，索引如果线上已经有openresty在运行的话，可以无缝衔接

```shell
[root@ali conf]# ll /usr/local/kong/
total 292
drwxr-xr-x 2 root   root   4096 May 28 14:31 bin
drwx------ 2 nobody root   4096 May 28 15:30 client_body_temp
-rw-r--r-- 1 root   root 234703 Apr 25 00:45 COPYRIGHT
drwx------ 2 nobody root   4096 May 28 15:30 fastcgi_temp
drwxr-xr-x 3 root   root   4096 May 28 14:31 include
drwxr-xr-x 4 root   root   4096 May 28 14:31 lib
drwxr-xr-x 2 root   root   4096 May 28 15:30 logs
-rw-r--r-- 1 root   root    297 Jun  1 19:18 nginx.conf
-rw-r--r-- 1 root   root   7807 Jun  1 19:18 nginx-kong.conf
-rw-r--r-- 1 root   root   1821 Jun  1 19:18 nginx-kong-stream.conf
drwxr-xr-x 2 root   root   4096 Jun  4 15:25 pids
drwx------ 2 nobody root   4096 May 28 15:30 proxy_temp
drwx------ 2 nobody root   4096 May 28 15:30 scgi_temp
drwxr-xr-x 2 root   root   4096 May 28 15:30 ssl
drwx------ 2 nobody root   4096 May 28 15:30 uwsgi_temp
```

启动方式:

```shell
$ /usr/local/openresty/nginx/sbin/nginx -p /usr/local/kong -c /usr/local/kong/nginx.conf
```

# Proxy

service/route/plugins

## service

可以通过rest api创建一个service，url指向服务

```shell
curl -i -X POST http://localhost:8001/services/ \
    -d 'name=foo-service' \
    -d 'url=http://foo-service.com'
```

url会自动解析:

-   Protocol
-   host
-   port
-   path

重试机制:

-   retries 实现方式是nginx的 [**proxy_next_upstream_tries**](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream_tries) 模块提供的功能，如果service response error，nginx会再次请求upstream

超时时间:

-   Connect timeout
-   Write timeout
-   Read timeout

## route

### 匹配规则

kong支持http/https,tcl/tls,grpc/grpcs协议的代理

-   `http`: `methods`, `hosts`, `headers`, `paths` (and `snis`, if `https`)
-   `tcp`: `sources`, `destinations` (and `snis`, if `tls`)
-   `grpc`: `hosts`, `headers`, `paths` (and `snis`, if `grpcs`)

匹配规则:

-   必须命中所有的字段
-   至少命中字段配置的一个值

```
{
    "hosts": ["example.com", "foo-service.com"],
    "paths": ["/foo", "/bar"],
    "methods": ["GET"]
}
```

以下可以命中路由, host、path、method 均可以匹配到

```
GET /foo/hello/world HTTP/1.1
Host: example.com

GET /bar HTTP/1.1
Host: foo-service.com

GET /foo HTTP/1.1
Host: example.com
```

以下无法命中路由

```
# path没有命中
GET / HTTP/1.1
Host: example.com
# method没有命中
POST /foo HTTP/1.1
Host: example.com
# host没有命中
GET /foo HTTP/1.1
Host: foo.com
```

#### request header

#### host

**指定多个host**

`json`

```shell
curl -i -X POST http://localhost:8001/routes/ \
    -H 'Content-Type: application/json' \
    -d '{"hosts":["example.com", "foo-service.com"]}'
```

`form`

```shell
curl -i -X POST http://localhost:8001/routes/ \
    -d 'hosts[]=example.com' \
    -d 'hosts[]=foo-service.com'
```

**通配符**

只能使用1个*，在左边或最右边

```json
{
    "hosts": ["*.example.com", "service.*"]
}
```

**preserve_host**

kong默认会把请求host替换成upstream的host

upstream target host

```json
{
  "created_at": 1591585408.555,
  "upstream": {
    "id": "6baccef1-2b15-44b8-b1a5-49fce6452487"
  },
  "id": "5b4c2ac4-27c5-42bb-9ec2-41ed6c3c3e75",
  "target": "docker.for.mac.host.internal:9003",
  "weight": 100,
  "health": "HEALTHY"
}
```

打印一下请求头（其他无关请求头忽略）

```json
{
    "code": 0,
    "message": "success",
    "data": {
        "header": {
            "X-Forwarded-For": [
                "172.21.0.1"
            ],
            "X-Forwarded-Host": [
                "douyacun.io"
            ],
            "X-Forwarded-Port": [
                "8000"
            ],
            "X-Forwarded-Proto": [
                "http"
            ],
            "X-Real-Ip": [
                "172.21.0.1"
            ]
        },
        "host": "docker.for.mac.host.internal:9003"
    }
}
```

关闭preserve_host

```json
{
    "code": 0,
    "message": "success",
    "data": {
        "header": {
            "X-Forwarded-For": [
                "172.21.0.1"
            ],
            "X-Forwarded-Host": [
                "douyacun.io"
            ],
            "X-Forwarded-Port": [
                "8000"
            ],
            "X-Forwarded-Proto": [
                "http"
            ],
            "X-Real-Ip": [
                "172.21.0.1"
            ]
        },
        "host": "douyacun.io:8000"
    }
}
```

#### 其他header

kong支持通过header来匹配路由

![](/images/blog/1/architecture/assert/kong-route-header.png)

header中需要添加`version:v1`, 才可以匹配到路由

```shell
GET /api/kong/preserve_host HTTP/1.1
version: v1
```

否则:

```
An invalid response was received from the upstream server
```

#### path

kong url path 匹配必须符合前缀匹配

```json
{
    "paths": ["/api"]
}
```

以下是可以匹配到路由的

```
GET /api/kong/preserve_host HTTP/1.1
Host: douyacun.io
```

默认情况下，kong代理到upstream不会改变url path

**正则路径**

kong支持正则路径和前缀路径匹配

```json
{
    "paths": ["/users/\d+/profile", "/following"]
}
```

```
GET /users/123/profile HTTP/1.1
Host: ...
```

**优先级**

正则匹配可以使用`regex_priority`指定优先级，否则最长前缀路径优先匹配,最多规则有限匹配

```json
[
    {
        "paths": ["/status/\d+"],
        "regex_priority": 0
    },
    {
        "paths": ["/version/\d+/status/\d+"],
        "regex_priority": 6
    },
    {
        "paths": ["/version"],
    },
    {
        "paths": ["/version/any/"],
    }
]
```

1.  `/version/\d+/status/\d+`
2.  `/status/\d+`
3.  `/version/any/`
4.  `/version`

**strip path**

像nginx alias的用法, 去掉前缀路由发送给upstram， 默认是启用状态

`service`

```json
{
  "path": "/",
}
```

path 是 `/api` , 这个path是作为路由前缀的

`route`

```json
{
  "paths": [
    "/api"
  ]
}
```

strip path 开启状态

```
GET /api/articles HTTP/1.1
Host: ...

404 page not found
```

upstream 接收到的请求

```
GET /articles HTTP/1.1
Host: ...
```

**method**

通过请求方法发送过滤路由

`GET`  `POST` `HEAD` `PUT`

**source**

通过请求涞源ip/port过滤路由

`10.1.0.0/16` 



# Authentication

流程：

1. 为service创建一个plugin
2. 创建一个consumer
3. 为consumer创建一个credentials
4. 请求进入时，首先会验证权限

## Consumers

主要用于自定义请求行为，为安卓/iOS创建一个consumer, 或者每个版本、每个平台创建一个consumer。这是一个不透明的概念，所以称为consumer而不是用户

## Anonymous Access

匿名访问和鉴权访问同时存在

对匿名访问进行 低频 限流，对授权用户有 高频限流

流程:

1. 创建service

2. 创建route

3. 创建key-auth plugin

   ```shell
   curl -i -X POST \
      --url http://localhost:8001/services/douyacun/plugins/ \
      --data 'name=key-auth'
   ```

4. 创建anonymous Consumer

   ```shell
   curl -i -X POST \
      --url http://localhost:8001/consumers/ \
      --data "username=anonymous_users"
      
   HTTP/1.1 201 Created
   Content-Type: application/json
   Connection: keep-alive
   
   {
      "username": "anonymous_users",
      "created_at": 1428555626000,
      "id": "bbdf1c48-19dc-4ab7-cae0-ff4f59d87dc9"
   }
   ```

5. 允许anonymous Consumer访问

   ```shell
   curl -i -X PATCH \
      --url http://localhost:8001/plugins/<your-plugin-id> \
      --data "config.anonymous=<上一步anonymous Consumer生成的id>"
   ```

最终结果,原本需要授权的url现在不授权也可以访问了, 授权的consumer也可以正常访问

![](/images/blog/1/architecture/assert/anonymous-consumer.png)

6 . 针对匿名consumer创建rate limit plugin, 针对授权consumer创建rate limit plugin

```shell
curl -i -X POST \
   --url http://localhost:8001/services/douyacun/plugins/ \
   --data 'name=rate-limiting'
   --data 'config.minute=5'
   --data 'consumer.id=<匿名账户id>'
```

7. 验证 如果没有授权访问，每分钟超过5次就会被限流

```shell
{
    "message": "API rate limit exceeded"
}
```

# 负载均衡

DNS-based loadbalancing/ring-balancer

DNS负载均衡，节点不是向kong注册服务，而是向DNS服务器提供注册，kong使用域名就可以了，

DNS各级都有缓存，缓存时间难以把控，不方便做健康检测移除不可用节点 (不推荐使用)

## ring-balancer

使用ring-balancer，需要向kong进行服务注册, 使用http注册以后可以立即获取流量

**upstream**: 虚拟hostname，route可以使用upstream name当作hostname

**target**: ip/port 每个node 都会有weight权重，决定承担多少流量

### upstram

修改target的成本较小，修改upstram的成本较大

slots: 根据最多设置多少个target算出，假设设置10个target，那么slot就是 `10 * 100`,  用于负载均衡算法，(todo:令牌?)

### target

target只支持创建/删除，不支持修改，如果要改权重，删除之前的taget然后新创建一个target

target自动清理，不活跃target比活跃target多10个时会自动清理不活跃target

### 负载算法

`hash_on`

-   **none**： 加权轮询

-   **consumer**: 按照consumer id hash，负载到不同的机器

-   **ip**：按照 ip hash

-   **header**：按照指定header hash
    -   `hash_on_header` 指定header 
    -   `hash_fallback_header` ：`hash_on_header` 缺失时，替补

-   **cookie**: 按cookie hash
    -   `hash_on_cookie`: 指定cookie name
    -   `hash_on_cookie_path`: 指定cookie path

`hash_fallback`

`hash_on` 返回的hash值为空，hash_fallback指定替代品

### 注意事项

-   target尽量不要使用域名，域名解析也是需要一定时间
-   确保hash值有较好的方差平均分布
    -   3个consumer，几十万的用户的 建议按ip hash
    -   如果用户大多集中在统一个地区，使用同一个NAT gateway(因为大家的ip都是同一个)，建议使用cookie hash

## 蓝绿部署

一个是当前运行的生产环境，接收所有的用户流量（称之为蓝）。另一个是它的副本，但是闲置（称之为绿）。两者使用相同的数据库后端和应用配置

应用的新版本部署在绿色版本环境中，进行功能和性能测试。一旦测试通过，应用的流量从蓝色版本路由到绿色版本。然后绿色版本变成新的生产环境。

过程：

1.  创建service
2.  创建route
3.  创建green upstream + target
4.  创建blue upstream + target
5.  发布时 切换service hostname 为green hostname

## 金丝雀部署（灰度发布）

和蓝绿部署很像，区别在于可以阶段性进行，不用一次性全切流量

金丝雀部署可以在生产环境中基础设施小范围部署新的应用代码，一旦应用部署发布，只有少数用户被路由到，最大程度降低影响

-   在允许外部用户访问之前，将内部用户暴露给金丝雀部署；
-   基于源 IP 范围的路由；
-   在特定地理区域发布应用；
-   使用应用程序逻辑为特定用户和群体解锁新特性。当应用为其他用户上线后，移除此逻辑。

kong的实现方式使用通过设置target权重来分配流量

```
# first target at 900
$ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \
    --data "target=192.168.34.17:80"
    --data "weight=900"

# second target at 100
$ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \
    --data "target=192.168.34.18:80"
    --data "weight=100"
```

# 健康检测&熔断机制

kong支持2种健康检测，可以单独使用也可以结合使用：

-   主动监测，定期请求提供的http/https接口，根据响应决定target是否健康状态
-   被动检测，分析正在代理的流量请求，根据响应局定target是否健康状态

## 健康/非健康

每一个target都有独自的健康检测

健康检测的规则

-   响应码 200 Success，增加`Success`计数，重置其他计数
-   connect fail，增加`TCP failures`计数，重置`Success`计数
-   timeout,  增加`timeouts`计数，重置`Success`计数
-   响应码非 200 Success，增加`Http Failures`计数，重置`success`计数

如果`TCP failures` / `timeouts` / `Http Failures` 次数达到配置的阀值，target会被标记为unhealthy

如果`Success ` 次数达到配置阀值后，target会被重新标记为healthy

## 健康检查配置

### 主动检测

`healthchecks.active.http_path`： 设置target 健康检测接, 默认`/`，常用`ping`

`healthchecks.active.healthy.interval`:  健康target间隔多少秒进行一次检测，0不检测

`healthchecks.active.unhealthy.interval`：非健康target间隔多少进行一次检测

`healthchecks.active.type`: 指定协议http/https

`healthchecks.active.timeout`: 连接超时时间，默认1s

`healthchecks.active.concurrency`: 一次请求多少个target

`healthchecks.active.healthy.successes`： 健康检测成功多少次认为是健康

`healthchecks.active.unhealthy.tcp_failures`: 连接失败多少次判定target非健康

`healthchecks.active.unhealthy.timeouts`: 请求超时次数判定target非健康

`healthchecks.active.unhealthy.http_failures`： 非 (`healthchecks.active.unhealthy.http_statuses` 定义的状态码) 响应多少次判定target非健康

### 被动检测

`healthchecks.passive.healthy.successes`: 非健康节点检测

`healthchecks.active.unhealthy.tcp_failures`: 连接失败多少次判定target非健康

`healthchecks.active.unhealthy.timeouts`: 请求超时次数判定target非健康

`healthchecks.active.unhealthy.http_failures`： 非 (`healthchecks.active.unhealthy.http_statuses` 定义的状态码) 响应多少次判定target非健康

### 禁用健康检测

设置间隔时间为0就关闭检测`healthchecks.active.healthy.interval`  / `healthchecks.active.unhealthy.interval`

线上已经在运行openresty，如何无缝接入kong

kong进阶

go opentracing 实践与落地


本篇文档目的:

1.  使用docker或centos7部署一套kong的环境
2.  使用kong代理到本地服务
3.  熟悉kong限流和鉴权
4.  负载均衡

# 安装

docker、centos7安装

## docker

[官网](https://docs.konghq.com/install/docker/?_ga=2.181811879.1832554820.1590497490-1678089697.1590497490) 有完整介绍

创建桥接网络，kong和postgres在同一网段中

```shell
$ docker network create kong-net
```

使用postgres存储，这里需要指定密码负责postgres会启动不起来

```shell
$ docker run -d --name kong-database \
--network=kong-net \
-p 5432:5432 \
-e "POSTGRES_USER=kong" \
-e "POSTGRES_DB=kong" \
-e "POSTGRES_PASSWORD=kong" \
postgres:9.6
```

`docker ps -a` 确认一下是否启动了postgres

初始化数据库

```shell
$ docker run --rm \
     --network=kong-net \
     -e "KONG_DATABASE=postgres" \
     -e "KONG_PG_HOST=kong-database" \
     -e "KONG_PG_PASSWORD=kong" \
     -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
     kong:latest kong migrations bootstrap
```

启动kong

```shell
$ docker run -d --name kong \
     --network=kong-net \
     -e "KONG_DATABASE=postgres" \
     -e "KONG_PG_HOST=kong-database" \
     -e "KONG_PG_PASSWORD=kong" \
     -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
     -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
     -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
     -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
     -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
     -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \
     -p 8000:8000 \
     -p 8443:8443 \
     -p 127.0.0.1:8001:8001 \
     -p 127.0.0.1:8444:8444 \
     kong:latest
```

查看空是否启动成功:

```shell
$ curl -i http://localhost:8001/
```

安装kong管理界面：

```shell
$ docker run -d -p 1337:1337 \
             --network kong-net \
             --name konga \
             -e "NODE_ENV=production" \
             -e "TOKEN_SECRET=kong" \
             pantsel/konga
```

配置konga，连接kong，因为在同一个网络可以使用容器name做为host连接容器

![](/images/blog/1/architecture/assert/konga-connection.png)

## centos 7

### 安装PostgreSQL

**yum 安装**

安装步骤官网较全

[https://www.postgresql.org/download/linux/redhat/](https://www.postgresql.org/download/linux/redhat/)

```shell
$ yum install -y postgresql10-server  postgresql10  postgresql10-contrib
```

**初始化数据库**

```shell
$ /usr/pgsql-10/bin/postgresql-10-setup initdb
```

**启动数据库**

```shell
$ systemctl enable postgresql-10.service
```

**允许远程连接**

` /var/lib/pgsql/10/data/postgresql.conf`

```shell
$ listen_addresses = '0.0.0.0'
```

**连接验证**

` /var/lib/pgsql/10/data/pg_hba.conf`

```conf
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    all             all             127.0.0.1/32            trust
# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            ident
# IPv6 local connections:
host    all             all             ::1/128                 ident
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     peer
host    replication     all             127.0.0.1/32            ident
host    replication     all             ::1/128                 ident
host    all             all             0.0.0.0/0               trust
```

注意放在最上面，否则本地连接的话会优先命中

`host    replication     all             127.0.0.1/32            ident`

```shell
Ident authentication failed for user "kong"
```

### 安装kong

**yum安装**

```shell
$ sudo wget -O kong-2.0.4.el7.amd64.rpm https://bintray.com/kong/kong-rpm/download_file?file_path=centos/7/kong-2.0.4.el7.amd64.rpm
$ sudo yum install kong-2.0.4.el7.amd64.rpm
$ kong -h
```

**创建数据库**

```shell
$ sudo -u postgres psql
```

```plsql
 CREATE USER kong; 
 CREATE DATABASE kong OWNER kong;
 \du;
```

常用命令

```
\password           设置密码。
\q                  退出。
\h                  查看SQL命令的解释，比如\h select。
\?                  查看psql命令列表。
\l                  列出所有数据库。
\c [database_name]  连接其他数据库。
\d                  列出当前数据库的所有表格。
\d [table_name]     列出某一张表格的结构。
\du                 列出所有用户。
\e                  打开文本编辑器。
\conninfo           列出当前数据库和连接的信息。
```

**配置文件**

`/etc/kong/kong.conf`

```ini
database = postgres
pg_host = 127.0.0.1
pg_port = 5432
pg_user = kong
pg_database = kong
proxy_listen = 0.0.0.0:80
declarative_config = /etc/kong/kong.yml
```

**迁移数据库**

```
kong migrations bootstrap -c /etc/kong/kong.conf
```

# 概念

架构图

![](/images/blog/1/architecture/assert/Kong-GS-overview.png)

| Concept/Feature | Description                                                  |
| :-------------- | :----------------------------------------------------------- |
| Service         | 多个 Upstream 的集合，是 Route 的转发目标                    |
| Routes          | 求的转发规则，按照 Hostname 和 PATH，将请求转发给 Service    |
| Consumers       | API 的用户，记录用户信息                                     |
| REST API        | 通过 REST API 进行配置管理，从繁琐的配置文件中解放           |
| 插件            | 提供众多开箱即用的插件，且有易于扩展的自定义插件接口，可以使用 Lua 自行开发插件 |
| 限流            | 可以通过插件实现单个服务某些接口的限流，避免服务过载导致不可用 |
| 鉴权            | 权限控制，IP 黑白名单，同样是 OpenResty 的特性               |
| 负载均衡        | Kong Gateway provides two methods for load balancing: straightforward DNS-based or using a ring-balancer. In this guide, you’ll use a ring-balancer, which requires configuring upstream and target entities. With this method, the adding and removing of backend services is handled by Kong Gateway, and no DNS updates are necessary. |

# 为什么用kong?

- 统一入口：服务端微服务框架中，接口权限验证，IP 限制，限流等在各个服务中都单独实现。没有统一入口，不方便统一管理。
- 易用性，扩展性：服务端技术栈主要是LNMP开发，目前在逐步转型到基于golang微服务技术栈上开发。这是一个灰度迁移的过程，我们需要Proxy能操作简单，管理方便。
- 持续集成发布：互联网 2C 产品，用户无时不刻不在使用服务，同时产品还在不断的迭代，服务每时每刻都可以发布，所以必须要热部署能力，并且是自动化的。支持灰度发布，具有故障转移能力

# kong网关提供服务

kong承担的是网关层，可以当作中间件来看待

service: 代表后端api服务

route: 路由到哪个service服务，一个service可以有多个route

![](/images/blog/1/architecture/assert/route-and-service.png)

### 创建service

`rest api`

```shell
$ curl -i -X POST http://localhost:8001/services \
 --data name=douyacun \
 --data url='http://docker.for.mac.host.internal:9003'
```

界面

![](/images/blog/1/architecture/assert/add-service.png)

### 创建route

`rest api`

```shell
$ curl --location --request POST '127.0.0.1:8001/services/douyacun/routes' \
--form 'name=ping' \
--form 'paths[]=/ping'
```

界面

![](/images/blog/1/architecture/assert/add-routes.png)

访问:

```shell
curl --location --request GET '127.0.0.1:8000/ping'
# ok
```

### 限流配置

`rest api` 这样设置，默认是全局配置, 默认是针对consumer,每分钟5次

```shell
$ curl -i -X POST http://localhost:8001/plugins \
--data "name=rate-limiting" \
--data "config.minute=5" \
--data "config.policy=local"
```

界面

![](/images/blog/1/architecture/assert/rate-limit.png)

超过5次以后会返回

```json
{
    "message": "API rate limit exceeded"
}
```

### proxy_cache 缓存请求插件

`rest api`

```shell
$ curl -i -X POST http://127.0.0.1:8001/plugins \
--data name=proxy-cache \
--data config.content_type="application/json" \
--data config.cache_ttl=30 \
--data config.strategy=memory
```

界面

![](/images/blog/1/architecture/assert/proxy-cache.png)

注意： 如果`content-type` 不一致的话，缓存命中状态会是跳过状态`X-Cache-Status: Bypass` ，像我们上面设置的 `config.content_type="application/json"`  但是response content-type是 `application/json; charset=utf-8`

### key-auth 鉴权

添加key-auth插件

```shell
$ curl -X POST http://127.0.0.1:8001/routes/douyacun/plugins \
 --data name=key-auth
```

添加consumer和Credentials

```shell
$ curl -i -X POST -d "username=douyacun&custom_id=douyacun" http://localhost:8001/consumers/
```

为consumer生成apikey

```shell
$ curl -i -X POST http://localhost:8001/consumers/douyacun/key-auth -d 'key=ASF-JIK-0O1'
```

验证

```shell
$ curl -i http://localhost:8000/api/articles -H 'apikey:ASF-JIK-0O1'
```

### 负载均衡

创建Upstream

```shell
curl -X POST http://127.0.0.1:8001/upstreams \
 --data name=upstream
```

修改之前创建的douyacun service

```shell
curl -X PATCH http://127.0.0.1:8001/services/douyacun \
 --data host='upstream'
```

增加两个后端节点

```shell
$ curl -X POST http://127.0.0.1:8001/upstreams/upstream/targets \
 --data target=’docker.for.mac.host.internal:9004’
 
$ curl -X POST http://127.0.0.1:8001/upstreams/upstream/targets \
 --data target=’docker.for.mac.host.internal:9003’
```



kong基础入门


1. `omitempty` 字段为空时( 空指针, 空接口, 空数组, slice, map, or string.)，json encode时不返回该字段

```go
type person struct {
	Name string `json:"name,omitempty"`
	Age  int    `json:"age"`
}

var p = person{
  Name: "",
  Age:  18,
}
if res, err := json.Marshal(&p); err != nil {
  fmt.Println(err)
	return
} else {
  fmt.Println(string(res))
}
// {"age":18}
```

2. `string` 字符串和数字类型转换，对于php和js这类弱类型语言字符串和数字很容易就混

```go
type person struct {
	Name string `json:"name,omitempty"`
	Age  int    `json:"age,string"`
}

var p1 person
str := `{"name":"douyacun", "age": "18"}`
if err := json.Unmarshal([]byte(str), &p1); err != nil {
  fmt.Println(err)
  return
}
fmt.Println(p1)
// {douyacun 18}
```

如果age 没有string tag的话，会报错 `json: cannot unmarshal string into Go struct field person.age of type int`

3. `-` 忽略字段

```go
type person struct {
	Name   string `json:"name,omitempty"`
	Age    int    `json:"age,string"`
	Height int    `json:"-"`
}
var p = person{
  Name: "",
  Age:  18,
  Height: 180,
}
if res, err := json.Marshal(&p); err != nil {
  fmt.Println(err)
  return
} else {
  fmt.Println(string(res))
}
// {"age":"18"}
var p1 person
str := `{"name":"douyacun", "age": "18", "height": 180}`
if err := json.Unmarshal([]byte(str), &p1); err != nil {
  fmt.Println(err)
  return
}
fmt.Println(p1)
// {douyacun 18 0}
```

4. 判断json字符串是否有效

```json
fmt.Println(json.Valid([]byte(`{"name":"douyacun", "age": "18", "height": 180}`)))
// true
```

5. 从数据流读取字符串并解码

```go
var jsonStream = `
	{"Message": "Hello", "Array": [1, 2, 3], "Null": null, "Number": 1.234}
`
des := json.NewDecoder(strings.NewReader(jsonStream))
for{
  t, err := des.Token()
  if err == io.EOF {
    break
  }
  if err != nil {
    fmt.Printf("%v\n", err)
    return
  }
  if _, ok := t.(json.Delim); !ok {
    fmt.Printf("%T: %v\n", t, t)
  }
}
// string: Hello
// string: Array
// float64: 1
// float64: 2
// float64: 3
// string: Null
// <nil>: <nil>
// string: Number
// float64: 1.234
```

6. 对于不确定是int或者float的字段，可以使用json.Number

```go
type person struct {
	Weight json.Number `json:"weight"`
}

var p person
str := `{"weight": 19}`
if err := json.Unmarshal([]byte(str), &p); err != nil {
  fmt.Println(err)
  return
}
fmt.Println(p.Weight.Int64())
// 19 <nil>
```

7. 可以像orm一样写原生sql。像es的查询结果如何定义结构体：

**编码**

```go
type person struct {
	Weight json.Number     `json:"weight"`
	Skill  json.RawMessage `json:"skill"`
}

skill := map[string]interface{}{
  "language": []string{"c", "php", "js", "golang"},
  "js":       []string{"react"},
  "php":      []string{"Laravel", "ThinkPHP"},
  "golang":   []string{"gin"},
}
res, err := json.Marshal(skill)
if err != nil {
  fmt.Println(err)
}
p := person{
  Weight: "89",
  Skill:  json.RawMessage(res),
}
if res, err := json.MarshalIndent(p, "", "\t"); err != nil {
  fmt.Println(err)
  return
} else {
  fmt.Println(string(res))
}
```

输出

```json
{
        "weight": 89,
        "skill": {
                "golang": [
                        "gin"
                ],
                "js": [
                        "react"
                ],
                "language": [
                        "c",
                        "php",
                        "js",
                        "golang"
                ],
                "php": [
                        "Laravel",
                        "ThinkPHP"
                ]
        }
}
```

**解码**

像ES search结果集，外层有公共的数据结构

```json
{
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 12,
      "relation" : "eq"
    },
    "max_score" : 1.0,
    "hits" : []
  }
}
fmt.Println(p1)
// {douyacun 18}
// 如何不加string，会报错: json: cannot unmarshal string into Go struct field person.age of type int
```

结构体

```go
type ESListResponse struct {
	Took    int  `json:"took"`
	Timeout bool `json:"timed_out"`
	Shards  struct {
		Total      int `json:"total"`
		Successful int `json:"successful"`
		Skipped    int `json:"skipped"`
		Failed     int `json:"failed"`
	} `json:"_shards"`
	Hits struct {
		Total struct {
			Value    int    `json:"value"`
			Relation string `json:"relation"`
		} `json:"total"`
		MaxScore float64         `json:"max_score"`
		Hits     []json.RawMessage `json:"hits"`
	} `json:"hits"`
}
type ESItemResponse struct {
	Index  string          `json:"_index"`
	Type   string          `json:"_type"`
	Id     string          `json:"_id"`
	Score  float64         `json:"_score"`
	Source json.RawMessage `json:"_source"`
}
```

这个有点复杂，写个简单的例子：

```go
type person struct {
	Weight json.Number     `json:"weight"`
	Skill  json.RawMessage `json:"skill"`
}


str := `{
	"weight": 180,
	"skill": {
		"language": ["php", "golang", "c", "python"],
		"database": ["elasticsearch", "mysql", "redis"]
	}
}`
var p person
if err := json.Unmarshal([]byte(str), &p); err != nil {
  fmt.Println(err)
  return
}
fmt.Printf("weight: %s\nskill: %s\n", p.Weight, p.Skill)

type _skill struct {
  Language []string `json:"language"`
  Database []string `json:"database"`
}

var skill _skill
if err := json.Unmarshal(p.Skill, &skill); err != nil {
  fmt.Println(err)
  return
}
fmt.Printf("%+v\n", skill)
```

输出：

```
weight: 180
skill: {
                "language": ["php", "golang", "c", "python"],
                "database": ["elasticsearch", "mysql", "redis"]
        }
{Language:[php golang c python] Database:[elasticsearch mysql redis]}
```

其实 p.Skill 还是 []byte,可以再次被 Unmarshal


json包的使用不是像php那样json_encode/json_decode,有更大操作空间

go json 解析小技巧

# 最终一致性

> 建议阅读
> - [分布式事务一致性，3种模式](https://zhuanlan.zhihu.com/p/36153160)
> - [TCC](https://juejin.im/post/5bf201f7f265da610f63528a)

原则还是尽量保持单机事物，只有单库执行才能保证数据库的ACID特性，遇到跨库事物， 通常通过“最终一致”事物保证事物执行的吞吐量，

- 定义
- 原理

# 定义
系统中所有的数据副本经过一段时间后最终能够达到一致的状态

# 原理
保证核心事物的正向执行，然后保存事物中间状态，其他事物异步执行，执行完成后达到最终的事物一致，避免跨库事物时间序列执行阻塞，提升事物吞吐量

# 实现模式
- 可靠事件模式
- 业务补偿模式
- TCC模式


# 可靠事件

关键点在于：**可靠事件投递** 和 **避免事件重复消费**

可靠事件投递：
  - 每个服务原子的业务操作和发布事件
  - 事件代理系统确保事件传递至少一次，避免重复消费，要求事件消费系统实现 **幂等性**，eg. 支付服务不能因为重复收到事件就多次支付

## 本地事件表

1. 在同一个本地事物中记录业务数据和事件
2. 实时发布一个事件 事件系统 立即通知关联的业务服务，事件发布成功立即删除记录的事件
3. 事件恢复服务定时从事件表中恢复未发布成功的事件，重新发布，重新发布成功才删除记录
  

2要求实时性，第三条保证一定发布，额外的事件数据库可能会给数据库带来额外的压力

## 外部事件表

将事件持久化到外部事件系统，事件系统需要提供实时事件服务以接受微服务发布事件，事件系统需要提供事件恢复服务来确认和恢复服务

1. 业务服务 在事物提交前，通过实时事件服务向事件系统请求 *发送事件*, 事件系统只记录事件不会真正发送事件
2. 业务服务 在事物提交后，向事件系统确认发送，事件得到确认后事件系统才真正发送事件
3. 业务服务 在事物回滚后，请求事件系统取消发送
4. 事件系统定时查找未确认发送的事件向业务服务查询状态，根据返回状态决定取消还是发布

需要一次确认操作 并且需要 业务服务提供额外的查询接口， 事件幂等性


### issue

1. 幂等性

    TODO:: 待完善

    幂等事件要考虑执行顺序，
    - 保证事件顺序的一个简单做法就是在添加时间戳，微服务记录最后处理的时间戳，如果事件戳早于记录的时间戳，丢弃
    - 更稳妥的做法是，每个事件有个全局递增的事件id，为每条事件记录处理结果，如果处理过返回上一次的处理结果，否则调度执行事件

2. 事件消费的开销

    需要考虑重复执行一条事件和查询存储结果的开销

    对于重复处理开销很小的事件，或者只有非常少的事件会被重复处理接收，可以重复处理一次事件，在将事件数据持久化时由数据库 **唯一索引** 抛出唯一性约束异常

    对于重复处理一条事件的开销比额外一次查询的开销要高很多， 可以使用过滤服务过滤处理的过的事件， 每个事件执行完成后记录执行结果

3. 过滤服务是在事件处理完成后记录结果，可能处理中间就再次收到重复事件

    可以记录事件的处理过程：
     - 接收
     - 处理中
     - 收到应答
     - 处理完成
    
    可以根据不同的状态，做不同的处理

4. 业务服务的 消息处理状态，发送请求成功但是没有收到处理结果

    选择暂时不一致性，采用对账和人工接入的方式保证一致性



# 业务补偿模式

- 业务异常：业务逻辑异常，eg. 商品库存不足、账户余额不足
- 技术异常：非业务逻辑异常，eg. 网络连接异常、请求超市

补偿模式使用一个额外的协调服务来保证各个需要保证一致性的微服务，协调服务按顺序调用各个微服务，如果某个微服务调用异常（包括业务异常和技术异常）就取消之前已经调用成功的微服务

为了降低开发的复杂度和效率，协调服务需要实现为一个通用补偿框架，提供服务编排和自动完成补偿的能力
    - 确定失败的步骤和状态，从而确定补偿的范围
    - 能提供补偿操作使用到的业务数据
    - 生成全局唯一的业务流水号
    - 关联表，获取各个步骤的业务数据和状态
    - 提供重试策略



## 重试策略

- 失败原因不是暂时性的，由于业务因素导致的，应立即终止重试
- 错误是一些罕见的异常，eg. 网络传输过程中数据丢失，应该立即重试
- 如果错误的是系统繁忙，eg. 500,或者超时 需要等一段时间再次重试
- 重试操作要指定次数，达到上线就不应该再次重试了
- 如果重试时仍然错误，可逐渐增加时间，直到达到上限后
- 如果某个时刻存在大量重试操作，补偿框架要控制请求的流量，防止对工作服务造成过大的压力


# TCC模式

建议阅读
- [TCC](https://juejin.im/post/5bf201f7f265da610f63528a)

3个阶段

## try
预处理阶段

## confirm
事物提交阶段

## cancel
事物回滚阶段


原则还是尽量保持单机事物，只有单库执行才能保证数据库的ACID特性，遇到跨库事物， 通常通过“最终一致”事物保证事物执行的吞吐量，

分布式事务最终一致性


[toc]

高并发通用设计方法

- 分流
- 缓存
- 异步

# 架构分层

**为什么分层**

- 简化系统设计，让不同的人专注某一层
- 分层提高复用性
- 分层更容易横向扩展

**如何分层**
- 客户端显示层
- 网关层 
- web层 一般参数校验 ，validate的封装
- service层 
    - 业务封装
    - 复杂业务验证，依赖数据库存值得验证逻辑
- manager
    - 通用逻辑
    - 第三方接口的封装
- DAO数据存储层

todo:各层功能界限不明确

# 系统设计目标

**高并发设计三大目标**
- 高性能  
    - 响应时间 毫秒级
    - QPS
- 高可用
    - 稳定性
- 可扩展
   -  快速应对峰值流量
   



## 高性能

### 性能优化原则

- 问题导向
- 八二原则：20%精力解决80%的性能问题
- 数据支撑：数据监控，时刻了解性能优化以后响应时间减少了多少，提示了多少吞吐量
- 制定目标，持续优化，业务逻辑复杂的系统，也会有多方面的问题

### 性能度量指标

吞吐量 和 响应时间

99分位值的响应时间控制在200ms以内，不超过1s请求占比控制在99.99以内

平均值  少量的慢请求无法反映

最大值  过于敏感

分位值 能很好反应一段时间的性能状况，例如90分位(100个请求响应时间排序，排在90的就是分位点)，分位值越高，对于慢请求越敏感

### 性能优化

- 增加系统的核数 
- 减少单次请求时间
   - linux性能分析工具
       - cpu
       - memory
       - i/o
   - go pprof
   



## 高可用

系统无故障运行的能力，系统可用行需要从系统设计和系统运维来保证

### 系统设计
系统设计时考虑如何自动化发现故障，出现故障如何解决。具体的优化方法故障转移、超时控制、限流

**故障转移：**
- 检测主备机器是否故障，心跳检测 ping，定时请求，一段时间没有响应，判定机器故障，报警并触发选主操作
- nginx 异常重试
```nignx
proxy_next_upstream
```

**超时控制：** 不让请求一直保持，经过一段时间后让请求失败，释放资源

内网服务 
- 连接超时100 - 300ms
- 读超时 1- 3s

**降级:** 保证核心服务的稳定而牺牲非核心服务的做法

**限流:** 对并发请求进行限速来保护系统

### 系统运维

运维可以从灰度发布，故障演练来考虑提升系统的可用性

**灰度发布：** 业务稳定运行过程，系统是很少发生故障，90%的故障时发生在上线变更阶段，除了提供回滚方案就是灰度发布

**故障演练：** 模拟线上事故,比如：在线上随机关闭节点



## 可扩展

系统扩展会增加系统设计的复杂度，设计思路有：存储层扩展、业务层扩展

### 易扩展得复杂性

-   mysql存储瓶颈
-   带宽的瓶颈
-   第三方依赖的瓶颈


### 存储层扩展

第一步 做业务服务化拆分，减少单一主库压力

第二步 系统运行一段时间后，单一的业务数据库仍然会超过在容量和请求量仍然会超过单机的限制，这次就需要按数据特征做水平拆分，问题时节点不是随意增加的

### 业务纬度拆分

- 按业务纬度拆分，各服务独立部署，拥有独立的数据库
- 按业务重要程度进行分级，流量激增时优先扩容核心业务，保证稳定性


提生系统设计意识，意识很重要