
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]

# 疑惑

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/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/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]  // 从切片删除最后一个元素
```





[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/fca55d90c9642938104b4e363c93763c)

这边使用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语言以后开发一套聊天功能，一起参观一下

golang开发的聊天室



[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