
[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存储瓶颈
-   带宽的瓶颈
-   第三方依赖的瓶颈


### 存储层扩展

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

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

### 业务纬度拆分

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


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

高并发系统设计


[toc]

# 疑惑

1. 如何区分变量是数组还是切片
2. 数组复制是否像c语言一样，只复制数组开始的地址
3. 为什么字符串（"hello world"）计算大小unsafe.Sizeof()是16

# 数组

### 定义方式：

```go
var a [3]int                    // 定义长度为3的int型数组, 数组中的每个元素都以零值初始化
var b = [...]int{1, 2, 3}       // 定义长度为3的int型数组, 长度根据初始化元素的数目自动计算
var c = [...]int{2: 3, 1: 2}    // 定义长度为3的int型数组, 索引的方式来初始化数组的元素
var d = [...]int{1, 2, 4: 5, 6} // 定义长度为6的int型数组, 元素为 1, 2, 0, 0, 5, 6
```

### 概念： 数组是一个固定长度的特定类型元素组成的序列，长度/类型

- 不同长度和类型数据组成数组类型是不同的
- 不同长度的数组因为长度不同无法直接赋值

- 不同于切片，数组的长度是明确指定的
- 不同于c语言数组，go语言数组是值语义，并不是隐式指向第一个元素指针，当一个数组被复制和传递是，实际会复制整个数组
- len 和 cap 返回的结果始终是对应数组的长度
- 数组可以用于数值、字符串、结构体、函数、接口、管道数组

### 内存结构：在内存中连续存储

```
| 1 | 2 | 3 | 4 | 5 |
```

```go
var a = [...]int{1, 2, 3, 4, 5}
fmt.Println(unsafe.Sizeof(a))
// 40
```

Sizeof(a)大小是40，我这系统是64位的所以int位64位,8个字节， 8*5 = 40

# 字符串

### 概念： 一个字符串是一个不可改变的字节序列

- 字符串是一个只读的字节数组，长度是固定的
- 字符串长度并不是字符串类型的一部分，不同长度的字符串可以等值比较
- 字符串是一个结构体，因此字符串赋值操作也就是reflect.StringHeader复制操作，不会涉及到底层数组的复制
- 字符串是只读的，相同字符串常量，通常是对应同一个字符串常量
- 字符串和数组类似也可以通过len获取字符串长度，StringHeader也可以获取

```go
var a = "Hello world"
fmt.Println(len(a))
fmt.Println((*reflect.StringHeader)(unsafe.Pointer(&a)).Len)、
fmt.Println(unsafe.Sizeof(a))
// 11
// 11
// 16
```

a内存的数据，使用reflect.StringHeader类型来解释，类型强制转换, unsafe.Sizeof(a)其实计算的是，下面reflect.StringHeader结构的大小，unitptr 8字节 + int 8字节 = 16字节，因此可以称呼go字符串为字符串结构体

### 数据结构在reflect.StringHeader定义：

```go
type StringHeader struct {
    Data uintptr
    Len  int
}
```

字符串的内存结构：

![](/images/blog/1/golang/assert/ch1-8-string-1.ditaa.png)

# 切片

### 概念：切片就是一种简化版的动态数组，动态数组的长度不固定，切片相对于数组更具有灵活性#

- 切片的长度不是类型的组成部分，数组的长度需要计算得出
- 容量必须大于或等于切片的长度
- 在对切片本身赋值或参数传递时，和数组指针的操作方式类似，只是复制切片头信息（`reflect.SliceHeader`）

结构体定义：

```go
type SliceHeader struct {
    Data uintptr
    Len  int
    Cap  int
}
```

 内存布局：x := []int{2,3,5,7,11}

![](/images/blog/1/golang/assert/ch1-10-slice-1.ditaa.png)

切片声明：

```go
var a []int // 这里只是声明类型，结构体还没有初始化，所以为nil
b := []int{} // 结构体已经初始化了
fmt.Println(a == nil, b == nil)
fmt.Println(unsafe.Sizeof(a))// 8 + 8 + 8 = 24
// true false
// 24
g := make([]int, 3) // 有3个元素的切片, len和cap都为3
```

### 切片新增和删除：

增加元素：

```go
var a = []int{1, 2, 3, 4}
fmt.Println(a, len(a), cap(a))
// [1 2 3 4] 4 4

a = append(a, 5)
fmt.Println(a, len(a), cap(a))
// [1 2 3 4 5] 5 8

var b = make([]int, 0, 1)
b = append(b, 1, 2, 3, 4, 5, 6)
fmt.Println(b, len(b), cap(b))
// [1 2 3 4 5 6] 6 6

var c = make([]int, 1023, 1024)
c = append(c, 1, 3)
fmt.Println(c, len(c), cap(c))
// [0 0 0 0 ...] 1025 1280
```

扩容：

在容量不足的情况下，`append`的操作会导致重新分配内存，可能导致巨大的内存分配和复制数据代价，目的是为了减少向操作malloc申请堆内存的次数，重复的申请代价也是昂贵的

- 期望容量大于当前容量的2倍，使用期望容量
- 当前容量小于1024会将容量翻倍
- 当前容量大于1024，每次增加25%直到大于期望容量

```go
// runtime/slice.go/func growslice(et *_type, old slice, cap int) slice {}
newcap := old.cap
doublecap := newcap + newcap
if cap > doublecap {
  newcap = cap
} else {
  if old.len < 1024 {
    newcap = doublecap
  } else {
    // Check 0 < newcap to detect overflow
    // and prevent an infinite loop.
    for 0 < newcap && newcap < cap {
      newcap += newcap / 4
    }
    // Set newcap to the requested cap when
    // the newcap calculation overflowed.
    if newcap <= 0 {
      newcap = cap
    }
  }
}

capmem = roundupsize(uintptr(newcap) * sys.PtrSize)
// uintptr: 能存储指针的整型,也能存储int，官方解释：uintptr is an integer type that is large enough to hold the bit pattern of any pointer.
// sys.PtrSize 64位系统是8

// 内存对齐
// Returns size of the memory block that mallocgc will allocate if you ask for the size.
func roundupsize(size uintptr) uintptr {
  // _MaxSmallSize: 32768
	if size < _MaxSmallSize {
		if size <= smallSizeMax-8 {
			return uintptr(class_to_size[size_to_class8[(size+smallSizeDiv-1)/smallSizeDiv]])
		} else {
			return uintptr(class_to_size[size_to_class128[(size-smallSizeMax+largeSizeDiv-1)/largeSizeDiv]])
		}
	}
	if size+_PageSize < size {
		return size
	}
	return round(size, _PageSize)
}

// size_to_class8: 0, 1, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8, 8, 9, 9......
// class_to_size: 0, 8, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160......
```

扩容和内存对齐

```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
a = []int{1, 2, 3}
a = a[1:] // 删除开头1个元素
a = a[N:] // 删除开头N个元素
a = append(a[:0], a[1:]...) // 删除开头1个元素
a = a[:copy(a, a[1:])] // 删除开头1个元素
a = append(a[:i], a[i+1:]...) // 删除中间1个元素
```

### 切片使用技巧

0长切片特性（长度为0，容量不为0），应用场景：过滤掉字符串中的某些字符， 切片高效操作的要点是要降低内存分配的次数

```go
func Filter(s []byte, f func(x byte) bool) []byte {
	b := s[:0] // 这里b的长度是0，容量是s容量等价于 var b = make([]byte, 0, cap(s))
	for _, x := range s {
		if !f(x) {
			b = append(b, x)
		}
	}
	return b
}
```

切片避免内存泄漏, FindPhoneNumber会加载整个文件到内存中，搜索第一个出现的号码，最终结构以切片方式返回，返回结果指向保存整个文件的数组，因为切片引用了整个原始数组，导致垃圾回收器不能及时释放底层的空间

```go
func FindPhoneNumber(filename string) []byte {
    b, _ := ioutil.ReadFile(filename)
    return regexp.MustCompile("[0-9]+").Find(b)
}
```



类似的问题，在删除切片元素时可能会遇到。假设切片里存放的是指针对象，那么下面删除末尾的元素后，被删除的元素依然被切片底层数组引用，从而导致不能及时被自动垃圾回收器回收

```go
var a []*int{ ... }
a = a[:len(a)-1] // 被删除的最后一个元素依然被引用, 可能导致GC操作被阻碍

var a []*int{ ... }
a[len(a)-1] = nil // GC回收最后一个元素内存
a = a[:len(a)-1]  // 从切片删除最后一个元素
```



go 类型定义,内存布局,底层数据结构,切片扩容规则



[TOC]

# 环境

后端

-   语言golang
-   数据库elastisearch
-   web框架是基于[gin](https://gin-gonic.com/zh-cn/docs/)封装的
-   websocket库用的是[gorilla/websocket](https://github.com/gorilla/websocket)
-   日志: [zap](https://github.com/uber-go/zap)
-   Error: [pkg/errors](https://github.com/pkg/errors)

前端

-   框架: [react](https://zh-hans.reactjs.org/docs/getting-started.html)
-   服务端渲染: [nextjs](https://nextjs.org/docs/api-reference/next.config.js/static-optimization-indicator)
-   UI: [Material UI](https://material-ui.com/zh/components)
-   登录认证:  cookie [nookie](https://github.com/maticzav/nookies)  
-   websocket是浏览器原生支持
-   后续聊天功能模仿：[https://getstream.io/](https://github.com/GetStream/stream-chat-react)

登录

- [github OAuth documentation](https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/)
- [google Sign-In for Websites](https://developers.google.com/identity/sign-in/web)

# 如何建立连接

-   [websocket协议](https://www.cnblogs.com/chyingp/p/websocket-deep-in.html)

websocket复用http的握手通道，客户端通过HTTP请求与WebSocket服务端协商升级协议，协议升级完成后，后续的数据交换则按按照websocket的协议。

**1. 客户端：申请协议升级**

```http
Connection: Upgrade
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Sec-WebSocket-Key: m3xNMIzhueJyd3N66EAK6w==
Sec-WebSocket-Version: 13
Upgrade: websocket
```

-   `Connection: Upgrade` 表示要升级协议
-   `Upgrade: websocket`  升级到websocket协议
-   `Sec-WebSocket-Version: 13` websocket协议版本，如果服务端不支持该版本，需要返回一个`Sec-WebSocket-Version`header，里面包含服务端支持的版本号。

-   `Sec-WebSocket-Key: m3xNMIzhueJyd3N66EAK6w==` 与后面服务端响应首部的`Sec-WebSocket-Accept`是配套的，提供基本的防护，比如恶意的连接，或者无意的连接

**2. 服务端：响应协议升级**

```http
HTTP/1.1 101 Switching Protocols
Connection: upgrade
Sec-WebSocket-Accept: qgWIKoKflyd9H8L/jCNa8XP4CYQ=
Upgrade: websocket
```

状态代码`101`表示协议切换。到此完成协议升级，后续的数据交互都按照新的协议来。

**3. Sec-WebSocket-Accept的计算**

`Sec-WebSocket-Accept`根据客户端请求首

`Sec-WebSocket-Accept`根据客户端请求首部的`Sec-WebSocket-Key`计算出来。

计算公式为：

1.  将`Sec-WebSocket-Key`跟`258EAFA5-E914-47DA-95CA-C5AB0DC85B11`拼接。
2.  通过SHA1计算出摘要，并转成base64字符串。

伪代码如下：

```
>toBase64( sha1( Sec-WebSocket-Key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 )  )
```

验证下前面的返回结果：

```js
const crypto = require('crypto');
const magic = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11';
const secWebSocketKey = 'm3xNMIzhueJyd3N66EAK6w==';

let secWebSocketAccept = crypto.createHash('sha1')
    .update(secWebSocketKey + magic)
    .digest('base64');

console.log(secWebSocketAccept);
// qgWIKoKflyd9H8L/jCNa8XP4CYQ=
```

# 前端难点

**服务端渲染框架如何使用cookie**

nextjs是服务端渲染框架，nextjs会请求是在服务器上初始化一次dom，要获取cookie可以有2种方式

1. 从请求request中获取cookie，返回给组件
2. 客户端请求完成后用hook从浏览器本地加载cookie

cookie 库用的是 [nookies](https://github.com/maticzav/nookies)

```js
React.useEffect(() => {
  const all = parseCookies();
  if (all.douyacun) {
    const douyacun = JSON.parse(all.douyacun);
    setCook(douyacun);
  }
}, []);
```

另一个就是本地开发cookie跨域的问题, 本地域名localhost:3000,服务端域名localhost:9000：

本来是想用[http-proxy-middleware](https://github.com/chimurai/http-proxy-middleware) 来解决跨域的问题，但是websocket代理关于cookie的问题难以搞定，版本是1.0.3

最后还是nginx了，怎么统一一个域名呢？location，后端服务统一以api开头

```nginx
server {
	listen 80;
	server_name douyacun.io;

	location /api/ {
        		if ($request_method = 'OPTIONS') {
      					return 204;
           	}
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host  $http_host;
            proxy_set_header X-Nginx-Proxy true;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';

    				# 不需要考虑到负载的，就无需配置upstream节点。
    				proxy_pass    http://127.0.0.1:9003;
        }
	location / {
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host  $http_host;
            proxy_set_header X-Nginx-Proxy true;
            proxy_set_header Connection "";

            # 不需要考虑到负载的，就无需配置upstream节点。
            proxy_pass    http//127.0.0.1:3000;
  }
}
```

修改本地dns douyacun.io => 127.0.0.1

**如何保证websocket初始化一次**

还是因为框架用的nextjs服务端渲染框架，不能在全局初始化websocket，只能在useEffect中使用

```js
useEffect(() => {
  initWebsocket();
  return () => {
  }
});
const initWebsocket = () => {
  conn = new WebSocket(WS_ADDRESS);
  conn.onmessage = handlerMessage;
  conn.onclose = function () {
    dispatch({ type: "dialog_open", dialogOpen: true })
  };
  conn.onerror = function () {
    console.log("连接失败");
  }
}
```

这样会有一个问题，只要有state变更，useEffect就会被调用，导致webSocket循环初始化

> todo: 后端服务如何识别这种重复性的初始化，如何拒绝？

react hook 文档给出了答案

> the **previous effect is cleaned up before executing the next effect**. In our example, this means a new subscription is created on every update. To avoid firing an effect on every update, refer to the next section. 
>
> 意味着组件的每一次更新都会创建新的订阅
>
> If you pass an empty array (`[]`), the props and state inside the effect will always have their initial values, 
>
> useEffect第二个参数传 []， 就不回每次state变更都调用了。

```js
useEffect(() => {
  initWebsocket();
  return () => {
  }
}, []);
```

**conn.onmessage(() => {setMessages()}) 不会触发state组件的重新渲染？**

这个问题没有弄懂，不过react hook提供另一种状态管理，useReducer(), 就像redux一样。

> state 逻辑较复杂且包含多个子值，或者下一个 state 依赖于之前的 state 等。并且，使用 `useReducer` 还能给那些会触发深更新的组件做性能优化，

**滑动条的位置**

1. 收到新消息时，滑动条回到最底部

hook 提供了useRef可以操作组件, 在收到消息时，控制滑动条到最底部，

```jsx
const scrollToBottom = () => {
  // 保证消息在最下面
  contentRef.current.scrollTop = contentRef.current.scrollHeight
}
const handlerMessage = function (evt) {
  let msg = JSON.parse(evt.data)
  dispatch({ type: "new_message", msg: msg, channel_id: msg['channel_id'] });
  scrollToBottom();
}

<div className="scrollable content" ref={contentRef} onScroll={upScrollLoadMore}>
  ...
</div>
```

2. 上拉加载更多历史消息

滑动条高度 = 加载历史消息完成后文档高度 - 加载前文档高度

```jsx
// 这里是为了在加载完成后，在控制滑动条位置，如果不是hook的话，setState(state, () => {})，第二个参数回掉函数完成，hook使用useEffect的代替了这种方式
useEffect(() => {
  // loadMore 是请求后端的接口
  let t = setTimeout(loadMore, 1000);
  if (!loading) {
    // 滑动条高度 = 加载历史消息完成后文档高度 - 加载前文档高度
    contentRef.current.scrollTop = contentRef.current.scrollHeight - messagesHeight;
  }
  return () => {
    clearTimeout(t);
  }
}, [loading]);

// contentRef.onScroll
const upScrollLoadMore = () => {
  let scrollTop = contentRef.current.scrollTop;
  // 记录加载前文档的高度
  let channelMessages = state.messages[state.currentId];
  if (scrollTop == 0 && !loading && channelMessages && channelMessages.length > 0) {
    let channel = getChannelById(state.currentId);
    if (channel.total > 0) {
      setloading(true);
    }
  }
}
```

3. 正在查看历史消息，如果有新消息来会导致滑动条到最底部

todo::

# nginx如何反向代理websocket?

前端开发环境配置的时候已经展示过一次

- `proxy_http_version 1.1;` : 代理http版本号
- `proxy_set_header Upgrade $http_upgrade;`: http协议升级的请求头Upgrade传给后端
- `proxy_set_header Connection 'upgrade';` http协议升级的请求头Connection传给后端



# 群聊和私聊是如何实现的

不管是私聊还是群聊，都会创建一个channel来包含成员，每次消息发送消息指定channel.id即可，服务器在收到消息后，根据channel.id向channel.members推送消息。

channel分了3中类型：

- global 全局，每个人都会订阅
- public 群聊 聊天人数超过2个
- private 私聊 聊天人群2个



# 一个连接的成本是多少？

这边使用[gorilla/websocket](https://github.com/gorilla/websocket/blob/master/examples/chat/main.go) 1万个连接测试

占用147.93MB RAM, 平均连接每个占用15kb 测试代码见：[github gwebsocket](https://github.com/douyacun/gwebsocket/blob/master/v3_ws_ulimit/wsserver.go)

```shell
(pprof) top
Showing nodes accounting for 137.93MB, 93.24% of 147.93MB total
Dropped 6 nodes (cum <= 0.74MB)
Showing top 10 nodes out of 51
      flat  flat%   sum%        cum   cum%
   73.79MB 49.88% 49.88%    73.79MB 49.88%  bufio.NewWriterSize
   34.63MB 23.41% 73.29%    34.63MB 23.41%  bufio.NewReaderSize
      11MB  7.44% 80.73%       11MB  7.44%  runtime.malg
       4MB  2.70% 83.44%     5.50MB  3.72%  net/textproto.(*Reader).ReadMIMEHeader
       3MB  2.03% 85.46%     3.50MB  2.37%  github.com/gorilla/websocket.newConn
       3MB  2.03% 87.49%    10.50MB  7.10%  net/http.readRequest
    2.50MB  1.69% 89.18%    16.50MB 11.16%  net/http.(*conn).readRequest
    2.50MB  1.69% 90.87%     3.50MB  2.37%  context.propagateCancel
       2MB  1.35% 92.23%        2MB  1.35%  syscall.anyToSockaddr
    1.50MB  1.01% 93.24%     1.50MB  1.01%  net.newFD
(pprof) web
failed to execute dot. Is Graphviz installed? Error: exec: "dot": executable file not found in $PATH
(pprof) list flat
Total: 147.93MB
```

goroutine是10003，每个goroutine占用4kb的内存

```shell
(pprof) top
Showing nodes accounting for 10001, 100% of 10003 total
Dropped 24 nodes (cum <= 50)
Showing top 10 nodes out of 19
      flat  flat%   sum%        cum   cum%
     10001   100%   100%      10001   100%  runtime.gopark
         0     0%   100%       9998   100%  bufio.(*Reader).Peek
         0     0%   100%       9998   100%  bufio.(*Reader).fill
         0     0%   100%       9999   100%  github.com/gorilla/websocket.(*Conn).NextReader
         0     0%   100%       9999   100%  github.com/gorilla/websocket.(*Conn).ReadMessage
         0     0%   100%       9999   100%  github.com/gorilla/websocket.(*Conn).advanceFrame
         0     0%   100%       9998   100%  github.com/gorilla/websocket.(*Conn).read
         0     0%   100%       9999   100%  internal/poll.(*FD).Read
         0     0%   100%      10001   100%  internal/poll.(*pollDesc).wait
         0     0%   100%      10001   100%  internal/poll.(*pollDesc).waitRead (inline)
(pprof) list flat
Total: 10003
(pprof)
```

根据  Eran Yanay 在 Gophercon Israel 分享的讲座 [https://www.youtube.com/watch?reload=9&v=LI1YTFMi8W4](https://www.youtube.com/watch?reload=9&v=LI1YTFMi8W4) 优化,  代码在[github](https://github.com/eranyanay/1m-go-websockets)


- 使用epoll优化, 复用goroutine， goroutine适合cpu密集型，而epoll适合I/O密集型，这里使用epoll来复用goroutine， 如果是1万个链接的话, 4kb *  10000 / 1024 ~= 39M , epoll的原理和用法可以看一下，[了解一下高大上的epoll](/article/4a999859dea85d6d65f34b0fc8c22f25)

这边使用epoll 内存节省了 147.93 - 79.94 = 67.99MB, 

```shell
(pprof) top
Showing nodes accounting for 79.94MB, 100% of 79.94MB total
Showing top 10 nodes out of 37
      flat  flat%   sum%        cum   cum%
   38.65MB 48.35% 48.35%    38.65MB 48.35%  bufio.NewReaderSize (inline)
   30.12MB 37.67% 86.02%    30.12MB 37.67%  bufio.NewWriterSize
    4.50MB  5.63% 91.65%        5MB  6.26%  github.com/gorilla/websocket.newConn
    2.50MB  3.13% 94.78%     2.50MB  3.13%  net.sockaddrToTCP
       2MB  2.50% 97.28%        2MB  2.50%  syscall.anyToSockaddr
    0.67MB  0.84% 98.12%     0.67MB  0.84%  main.(*epoll).Add
    0.50MB  0.63% 98.75%     0.50MB  0.63%  fmt.(*pp).handleMethods
    0.50MB  0.63% 99.37%     0.50MB  0.63%  net.newFD
    0.50MB  0.63%   100%     0.50MB  0.63%  github.com/gorilla/websocket.(*Conn).SetPingHandler
         0     0%   100%    38.65MB 48.35%  bufio.NewReader
(pprof) list flat
Total: 79.94MB
```

运行的goroutine只有5个

```shell
(pprof) top
Showing nodes accounting for 5, 100% of 5 total
Showing top 10 nodes out of 35
      flat  flat%   sum%        cum   cum%
         2 40.00% 40.00%          2 40.00%  runtime.gopark
         1 20.00% 60.00%          1 20.00%  runtime/pprof.writeRuntimeProfile
         1 20.00% 80.00%          1 20.00%  syscall.Syscall
         1 20.00%   100%          1 20.00%  syscall.Syscall6
         0     0%   100%          2 40.00%  internal/poll.(*FD).Accept
         0     0%   100%          1 20.00%  internal/poll.(*FD).Read
         0     0%   100%          2 40.00%  internal/poll.(*pollDesc).wait
         0     0%   100%          2 40.00%  internal/poll.(*pollDesc).waitRead (inline )
         0     0%   100%          2 40.00%  internal/poll.runtime_pollWait
         0     0%   100%          1 20.00%  main.(*epoll).Wait
(pprof) list flat
Total: 5
```

- 从上面内存占用情况来看还是buf占用内存比较多，接下来就考虑优化buf的使用。go websocket库有2个比较推荐，第一个就是上面一直用的另一个是：[gobwas/ws](https://github.com/gobwas/ws)， gobwas有几个特性：
  - Zero-copy upgrade
  - No intermediate allocations during I/O
  - Low-level API which allows to build your own logic of packet handling and buffers reuse
  - High-level wrappers and helpers around API in `wsutil` package, which allow to start fast without digging the protocol internals

1w个链接3M内存,  5个goroutine

```shell
(pprof) top
Showing nodes accounting for 3328.46kB, 100% of 3328.46kB total
Showing top 10 nodes out of 20
      flat  flat%   sum%        cum   cum%
 1024.12kB 30.77% 30.77%  1024.12kB 30.77%  net.newFD (inline)
 1024.05kB 30.77% 61.54%  1024.05kB 30.77%  net.sockaddrToTCP
  768.26kB 23.08% 84.62%   768.26kB 23.08%  main.(*epoll).Add
  512.03kB 15.38%   100%   512.03kB 15.38%  syscall.anyToSockaddr
         0     0%   100%   512.03kB 15.38%  internal/poll.(*FD).Accept
         0     0%   100%   512.03kB 15.38%  internal/poll.accept
         0     0%   100%  2560.20kB 76.92%  main.main
         0     0%   100%   768.26kB 23.08%  main.wsHandle
         0     0%   100%  2560.20kB 76.92%  net.(*TCPListener).Accept
         0     0%   100%  2560.20kB 76.92%  net.(*TCPListener).accept
(pprof) list flat
Total: 3.25MB

(pprof) top
Showing nodes accounting for 5, 100% of 5 total
Showing top 10 nodes out of 35
      flat  flat%   sum%        cum   cum%
         2 40.00% 40.00%          2 40.00%  runtime.gopark
         1 20.00% 60.00%          1 20.00%  runtime/pprof.writeRuntimeProfile
         1 20.00% 80.00%          1 20.00%  syscall.Syscall
         1 20.00%   100%          1 20.00%  syscall.Syscall6
         0     0%   100%          2 40.00%  internal/poll.(*FD).Accept
         0     0%   100%          1 20.00%  internal/poll.(*FD).Read
         0     0%   100%          2 40.00%  internal/poll.(*pollDesc).wait
         0     0%   100%          2 40.00%  internal/poll.(*pollDesc).waitRead (inline)
         0     0%   100%          2 40.00%  internal/poll.runtime_pollWait
         0     0%   100%          1 20.00%  main.(*epoll).Wait
(pprof) list flat
Total: 5
```

# heartbeat？？？

使用gobws重构了一下聊天室，每隔一段时间，如果不发消息连接会自动断开，问题定位在nginx上，代理超时的机制，2次读之间的超时。

```nginx
server {
        listen 80;
        server_name douyacun.io;

        location /api/ {
                if ($request_method = 'OPTIONS') {
                        return 204;
                }
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host  $http_host;
                proxy_set_header X-Nginx-Proxy true;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection 'upgrade';

                # 不需要考虑到负载的，就无需配置upstream节点。
                proxy_pass    http://127.0.0.1:9003;
        }
        location / {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host  $http_host;
                proxy_set_header X-Nginx-Proxy true;
                proxy_set_header Connection "";

                # 不需要考虑到负载的，就无需配置upstream节点。
                proxy_pass    http://127.0.0.1:3000;
        }
}
```

nginx有2个参数是涉及到timeout

- proxy_read_timeout 默认值 60s   该指令设置与代理服务器的读超时时间。它决定了nginx会等待多长时间来获得请求的响应。 这个时间不是获得整个response的时间，而是两次reading操作的时间。
- proxy_send_timeout 默认值 60s  这个指定设置了发送请求给upstream服务器的超时时间。超时设置不是为了整个发送期间，而是在两次write操作期间。 如果超时后，upstream没有收到新的数据，nginx会关闭连接

**如何解决**？

通过定期发送ping帧以保持连接并确认连接是否还在使用

**定时给scoket发送ping消息？**

如果每个connection持有一个goroutine的话，初始化一个ticker定时器每隔N秒发送一次ping就ok了，问题是我们使用epoll来节省goroutine

TODO:: epoll如何实现定时轮询





# 如何限流，防止ddos

https://studygolang.com/articles/13254

# 如何实现分布式?

https://learnku.com/articles/39701

https://cloud.tencent.com/developer/article/1509469

一直以来对websocket保持一颗崇拜的心，php这方面比较弱势，学习go语言以后开发一套聊天功能，一起参观一下