golang进阶之路

朱雀 2022-09-06 04:55 417阅读 0赞

**目录**

1、go 的调度

2、 golang中 map的底层实现

3、go 的垃圾回收机制

4、数组与切片的区别

5、go struct能不能比较

6、select

7、golang中除了加Mutex锁以外，还有哪些方式安全读写共享变量：

8、golang中的并发模型

9、map如何顺序读取

10、json标准库对nil slice和空slice的处理一致吗

11、进程、线程、协程的区别

12、什么是channel，为什么它可以做到线程安全

13、go中的锁有哪些？

14、读写锁或者互斥锁读的时候能写吗

15、怎么限制goroutine的数量

16、select关键字

17、在go语言中，Printf()，Sprintf()，Fprintf()函数的区别用法是什么

18、new() 和make()的区别

19、slice的浅拷贝和深拷贝

20、对已经关闭的channel进行读写，会发生什么

21、对未初始化的channel进行读写，会发生什么

22、reflect（反射包）如何获取字段tag

23、为什么json包不能导出私有变量的tag

24、json包变量不加tag会怎么样

25、什么是内存逃逸，如何避免

26、字符串转成byte数组，会发生内存拷贝吗

27、uintptr与unsafe.Pointer的区别

28、for select时，如果其中一个case通道已经关闭会怎样？如何select中只有一个case呢？

29、beego和gin的比较

30、讲讲gin的router、中间件以及Context包的Next

31、讲讲channel的运行机制

32、什么是微服务

33、什么是原子锁

34、gin的参数验证

35、Mutex锁的底层原理

36、读写锁的底层原理

37、for range 返回索引与不返回索引的区别

网络：

1、gRPC和restful相比，有什么优势

2、protobuf与json有什么区别和联系

3、session与cookie的区别

4、http五层协议：

5、tcp四次挥手为什么要等待2MSL

6、http400状态码

7、time\_wait的作用

8、http2与http1的区别

9、http报文是如何封装的

10、http请求为什么是三次握手和四次挥手

11、url从输入浏览器到返回结果的请求过程

12、protobuf的压缩类型

数据库

1、mysql的四种隔离级别，mvcc的实现方法

2、数据库设计三大范式

3、什么是聚簇索引和二级索引

4、mysql底层原理

5、mysql慢查询的优化

6、redis的五种数据类型

7、redis的watch机制

8、如何使用redis实现分布式锁

9、redis的两个持久化方式

10、redis的List底层是如何实现的

11、mysql的索引、索引优化、b+tree索引原理

12、mysql如何实现分布式锁

13、mysql的高可用方案有哪些

14、mysql的级联查询

15、mysql一个表字段很多的情况下如何优化查询

16、gorm与beego orm的对比

17、mysql的引擎有哪些

18、mysql的联合查询

20、mysql的连表查询

21、mysql的B+Tree索引原理

22、mysql的索引优化

23、mysql中的string类型有哪些

中间件

1、说一下你熟悉的 MQ,比如 MQTT等

2、消息队列kafka原理

docker，k8s、etcd、promethus

1、dockerFile 的命令

2、k8s中rc与rs的区别

3、docker的运行机制（运行原理）

4、k8s的整个运行流程

5、讲解一下k8s的各个组件

6、ETCD中的raft原理

7、etcd如何实现分布式锁

8、promethus是如何访问的、访问流程是什么

Linux：

1、查看进程打开哪些文件

2、如何查看Linux系统的状态，如CPU、内存使用、负载情况等

3、如何查看一个进程的状态

算法与数据结构

1、红黑树

2、布隆过滤器

--------------------

### 1、go 的调度 ###

前导：并发与并行

并发：逻辑上同时处理多个任务；

并行：物理上同时处理多个任务；

go语言的并发处理参考了CSP（communicationg sequential process）模型，CSP并发模型不同于传统的多线程通过共享内存来通信，CSP讲究的是“以通信的方式来共享内存”；

golang的CSP模型实现与原始的CSP模型有点差别：原始的CSP中channel里的任务都是立即执行的，而go语言为其增加了一个缓存，即任务可以先暂存起来，等待执行线程准备好再顺序执行。

GO调度器：

go语言运行时环境提供了非常强大的管理goroutine和系统内核线程的调度器，内部提供了三种对象：Goroutine、Machine、Processor。

*  Goroutine：它有自己的栈，instruction pointer和其他信息，用于调度；
 *  Machine：指系统内核线程；
 *  Processor：承载多个goroutine的运行器，所以它维护了一个goroutine队列，里面存储了所有需要执行的goroutine。

一个Machine会对应一个内核线程（K），同时会有一个Processor与它绑定。一个processor连接一个或多个goroutine。processor有一个运行时的goroutine，其他的goroutine处于等待状态；processor的数量是可以并发任务的数量，可通过GOMAXPROCS限制，GOMAXPROCS值默认是CPU的可用核心数，但其数量是可以指定的，使用runtime.GOMAXPROCS(MaxProcs)来指定process数量。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODY2NDIzMg_size_16_color_FFFFFF_t_70][]

GO调度器调度过程：

当一个goroutine被创建时，goroutine对象被压入processor的本地队列或者go运行时全局goroutine队列。processor唤醒一个Machine，如果machine的waiting队列没有等待被唤醒的Machine，则创建一个（一般不超过Machine的最大值，10000），processor获取到machine后，与此machine绑定，并执行此machine。machine执行过程中，随时会发生上下文切换，当发生上下文切换时，需要对执行现场进行保护，以便下次被调度执行时进行现场恢复。go调度器中machine的栈保存在goroutine对象上。如果此时goroutine任务还没有执行完，machine可以将goroutine重新压入processor的队列，等待下一次被调度执行。如果执行过程遇到阻塞并阻塞超时，machine会与processor分离，并等待阻塞结束。此时processor可以继续唤醒machine执行其他的goroutine，当阻塞结束时，machine会尝试“偷取”一个processor，如果失败，这个goroutine会被加入到全局队列中，然后machine将自己转入waiting队列，等待被再次唤醒。

在各个processor运行完本地队列的任务时，会从全局队列中获取任务，调度器也会定期检查全局队列，否则在并发较高的情况下，全局队列的goroutine会因为得不到调度而“饿死”。如果全局队列也为空的时候，会去分担其他processor的任务，一次分一半任务。比如processorA任务完成了，processorB还有10个任务待运行，processorA在获取任务的时候，会一次拿走5个。

P的数量：由runtime.GOMAXPROCS()设定

M的数量：最大值是10000

### 2、 golang中 map的底层实现 ###

总的来说，go的map底层是一个hash表，通过键值对进行映射，键通过哈希函数生成哈希值，然后go底层的map数据结构就存储相应的hash值，进行索引，最终是在底层使用的数组存储key和value。

1）、hash函数

哈希函数有加密型和非加密型。加密型的一般用于加密数据，典型代表有**md5、sha1、sha256、aes256**；非加密型的一般就是查找，如**aes hash、memhash**。在map的应用场景中，用的是查找

哈希函数会将传入的key值进行哈希计算，得到一个唯一的值。go语言把生成的哈希值一分为二，前半部分叫做**高位哈希值**，后半部分叫做**低位哈希值**。

高位哈希值：**用来确定当前的bucket（桶）有没有所存储的数据**；

低位哈希值：**用来确定当前的数据存在了哪个bucket；**

2）、map源码

golang中map的底层实现是一个散列表，因此实现map的过程中就是实现散列表的过程，在这个散列表中，主要的结构体有两个，hmap（a header of map）和bmap（a bucket of map）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODY2NDIzMg_size_16_color_FFFFFF_t_70 1][]

hmap：

// Go map的一个header结构
    type hmap struct {
        count     int // map的大小.  len()函数就取的这个值
        flags     uint8 //map状态标识
        B         uint8  // 可以最多容纳 6.5 * 2 ^ B 个元素，6.5为装载因子即:map长度=6.5*2^B
                        //B可以理解为buckets已扩容的次数
        noverflow uint16 // 溢出buckets的数量
        hash0     uint32 // hash 种子
    
        buckets    unsafe.Pointer //指向最大2^B个Buckets数组的指针. count==0时为nil.
        oldbuckets unsafe.Pointer //指向扩容之前的buckets数组，并且容量是现在一半.不增长就为nil
        nevacuate  uintptr  // 搬迁进度，小于nevacuate的已经搬迁
        extra *mapextra // 可选字段，额外信息
    }

hmap是map的最外层的一个数据结构，包括了map的各种基础信息，如大小、bucket。hmap存储了一个指向底层bucket数组的指针。

其中buckets这个参数，它存储的是指向buckets数组的一个指针。

// Go map 的 buckets结构
    type bmap struct {
        // 每个元素hash值的高8位，如果tophash[0] < minTopHash，表示这个桶的搬迁状态
        tophash [bucketCnt]uint8
      // 第二个是8个key、8个value，但是我们不能直接看到；为了优化对齐，go采用了key放在一起，value放在一起的存储方式，
       // 第三个是溢出时，下一个溢出桶的地址
    }

每一个bucket最多放8个key和value，最后由一个overflow字段指向下一个bmp。bucket的三部分如下：

![20210827015916576.png][]

bucket三部分工作流程：

*  它的topHash存储的是哈希函数算出的**哈希值的高八位**，用来加快索引。因为把高八位存储起来，这样不用完整比较key就能过滤掉不符合的key，加快查询速度；当一个哈希值的高八位和存储的高八位相符合，再去比较完整的key值，进而取出value。
 *  第二部分，存储的是key和value，就是我们传入的key和value，注意它底层的排列方式是**key全部放在一起，value全部放在一起**。当**key大于128字节**时，bucket的key字段存储的会是指针，**指向key的实际内容**；value也是一样；这样排列的好处是key和value的长度不同的时候，可以消除**padding带来的空间浪费**，并且每个bucket最多存放**8个键值对**；如果超过就重新创建一个bucket挂载元bucket上，持续挂接形成**链表；**
 *  第三部分，存储的是当bucket溢出时，指向的是**下一个bucket的指针**；

工作流程：

当查找或操作map时，首先key经过哈希函数生成hash值，通过**哈希值的低八位**判断当前数据属于哪个bucket，找到bucket以后，通过**哈希值的高八位**与bucket存储的高八位哈希值循环对比，如果相同就比较刚才找到的底层数组的key值，如果key相同，取出value。如果高八位hash值在此bucket没有，或者有，但是key不相同，就去链表中**下一个溢出bucket中查找**，**直到找到链表的末尾。**

碰撞冲突：如果不同的key定位到了同一个bucket或者生成了同一hash，就会产生冲突。go是通过链表法来解决冲突的，比如一个高八位的hash值和已经存入的hash值相同，并且此bucket存的8个键值对已经满了，或者后面已经挂了好几个bucket了，这个时候就会先对比key，key不相同就一直沿着链表往后找，找到一个空位置，存入它。所以这种情况，两个相同的hash值高8位是存在不同bucket中的。如果此bucket未存满8个键值对，这个时候再比较完key不相同的时候，同样是沿着当前bucket数组中的内存空间往后找，找到第一个空位，再插入。这个就是用寻址法来解决冲突，查找的时候先比较hash值，再比较key，然后再沿着当前内存地址往后找。

查的时候也是对比hash值和key沿着链表把它查出来。

3）map的扩容

*  当链表越来越长，bucket的扩容次数达到一定值，bmap的扩容加载因数达到6.5，bmap就会进行扩容，将原来的bucket数组数量扩充一倍，产生一个新的bucket数组，也就是bmap的buckets属性指向的数组。这样bmap中的oldbuckets属性指向的是旧bucket数组。
 *  加载因子LoadFactor是一个阈值，计算方式为（map长度/2^B），如果超过6.5将会进行扩容；
 *  map的扩容不会立马全部复制，而是渐进式扩容，即先开辟2倍的内存空间，创建一个新的bucket数组。只有当访问原来旧的bucket数组时，才会将新的bucket拷贝到新的bucket数组，进行渐进式的扩容。旧的数据不会删除，而是去掉引用，等到gc回收。

### 3、go 的垃圾回收机制 ###

golang中的垃圾回收算法是**三色标记法**。

三色集合：

*  黑色集合，黑色集合中确保没有任何指针指向白色集合中的对象；
 *  白色集合，白色集合中允许有指针指向黑色集合对象，不会对垃圾回收造成影响；白色集合中的对象就是垃圾回收的对象；
 *  灰色集合，灰色集合可能会有指针指向白色集合对象

三色标记垃圾收集器的原理：

*  从灰色对象的集合中选择一个灰色对象并将其标记成黑色；
 *  将黑色对象所指向的所有对象都标记为灰色，保证该对象和被该对象引用的对象都不会被回收；
 *  重复上述两个步骤直到对象图中不存在灰色对象；

当三色标记清除的标记阶段结束之后，应用程序的堆中就不存在任何的灰色对象，只能看到黑色的存活对象以及白色的垃圾对象，垃圾收集器可以回收这些白色的垃圾。

混合写屏障：

如果在并发或者增量的标记算法中保证正确性，需要达成以下两种三色不变性的一种：

*  强三色不变性：黑色对象不会指向白色对象，只会指向灰色对象或者黑色对象；
 *  弱三色不变性：黑色对象指向的白色对象，必须包含一条从灰色对象经由多个白色对象的可达路径。

为了移除栈的重扫描过程，除了引入混合屏障之外，在垃圾收集的标记阶段，还需要将创建的所有新对象都标记成黑色，防止新分配的栈内存和堆内存中的对象被错误地回收，因为栈内存在标记阶段最终都会变成黑色，所以不再需要重新扫描栈空间。

增量和并发：

触发垃圾回收时，垃圾回收器会抢占CPU资源以完成标记和清除工作，进而导致较长时间的STW。

增量垃圾收集和并发垃圾收集能减少应用程序暂停的最长时间和总暂停时间：

增量收集：

增量式垃圾收集是减少程序最长暂停时间的一种方案，它可以将原本时间较长的暂停时间切分成多个更小的GC片段，虽然从垃圾收集开始到结束的时间更长了，但是这也减少了应用程序暂停的最大时间。

并发收集：

并发的垃圾收集不仅能够减少程序的最长暂停时间，还能减少整个垃圾收集阶段的时间，通过开启读写屏障、利用多核优势与用户程序并行执行，并发垃圾收集器确实能够减少垃圾收集对应用程序的影响。

### 4、数组与切片的区别 ###

1.  数组是值类型，切片是指针类型；
2.  数组的长度是固定的，切片不是，切片是动态的数组；
3.  切片比数组多一个属性：容量
4.  切片的底层是数组；

### 5、go struct能不能比较 ###

go是强类型语言，所以不同类型的结构体不能比较，但是同一类型的实例值是可以比较的、

### 6、select ###

select常用于goroutine的退出，golang的select就是监听IO操作，当IO操作发生时，触发相应的动作，每个case语句力必须是一个IO操作。

### 7、golang中除了加Mutex锁以外，还有哪些方式安全读写共享变量： ###

goroutine可以通过channel安全读写共享变量。

### 8、golang中的并发模型 ###

golang中常用的并发模型有三种：

*  通过channel通知实现并发控制

无缓冲的channel要求goroutine的发送和接收必须同时准备好，如果没有同时准备好的话，先执行的操作就会阻塞等待，直到另一个相对应的操作准备好为止。通过使用无缓冲的通道，可以实现goroutine的并发控制。

*  通过sync包中的WaitGroup实现并发控制
 *  使用context上下文，实现并发控制

context包主要用来处理多个goroutine之间共享数据，以及多个goroutine的管理。context对象是线程安全的，可以把一个context对象传递给任意个数的goroutine，对它执行取消操作时，所有goroutine都会接受到取消信号。

### 9、map如何顺序读取 ###

map不能顺序读取，因为map是无序的，想要顺序读取首先要解决的问题是把key变为有序的，所以可以把key放入切片中对切片进行排序。

### 10、json标准库对nil slice和空slice的处理一致吗 ###

处理是不一致的：

nil slice：只是声明了slice，却没有实例化的对象，会报数组越界的错误；

空slice是指slice不为nil，但是slice没有值，slice的底层空间是空的。

### 11、进程、线程、协程的区别 ###

进程：

进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动，进行是进行资源分配和调度的一个独立单位。每个进程都有自己的独立内存空间，所以上下文进程间的切换开销比较大（栈、寄存器、虚拟内存、文件句柄等），但相对比较稳定安全。

线程：

线程是进程的一个实体，是CPU调度和分派的基本单位，它是比进程更小的能独立运行的基本单位。线程自己不拥有系统资源，只拥有一点在运行中必不可少的资源（如程序计数器，一组寄存器和栈），但是它可与同属一个进程的其他线程共享进程所拥有的全部资源。线程间通信主要通过共享内存，上下文切换很快，资源开销小，但相比进程不够稳定容易丢失数据。

协程：

协程是一种用户态的轻量级线程，协程的调度完全由用户控制。协程拥有自己的寄存器上下文和栈。协程调度时，将寄存器上下文和栈保存到其他地方，在切回来的时候，恢复先前保存的寄存器上下文和栈，直接操作栈基本没有内核切换的开销，可以不加锁的访问全局变量，所以上下文切换非常快。

### 12、什么是channel，为什么它可以做到线程安全 ###

channel是go中的一个核心类型，可以把它看成一个管道，通过它并发核心单元就可以发送或者接收数据进行通讯，channel也可以理解为一个先进先出的队列，通过管道进行通信。

golang的channel发送数据和接收数据都是原子性的，而且golang的设计思想就是不要通过共享内存来通信而是通过通信来共享内存，前者通过共享内存来通信会存在资源竞争需要加锁，后者就是channel，channel的主要目的是在多任务间传递数据，当然是线程安全的。

### 13、go中的锁有哪些？ ###

三种锁：互斥锁、读写锁、sync.Map的安全的锁

*  互斥锁，go并发程序对共享资源进行控制的主要手段，由sync包中的Mutex接头体实现；由两个公开的指针方法Lock和UnLock。
 *  读写锁，是针对读写操作的互斥锁，可以分别针对读操作和写操作进行锁定和解锁操作；

读写锁的访问控制规则如下：

多个写操作之间是互斥的；写操作和读操作之间也是互斥的；多个读之间不是互斥的；

*  sync.Map安全锁，golang中的sync.Map是并发安全的，其实也是sync包中golang自定义的一个名为Map的结构体；

### 14、读写锁或者互斥锁读的时候能写吗 ###

go中读写锁包括读锁和写锁，多个读线程可以访问共享数据；写线程必须等所有读线程结束以后，才能获得锁；同样的读线程必须等待写线程释放锁，才能获得锁，也就是说读写锁可以同时读，但是读-写，写-写是互斥的。

### 15、怎么限制goroutine的数量 ###

使用channel+sync.WaitGroup，通过限制channel的容量，在每次新增goroutine的往channel发送数据的时候，就需要先判断channel中的数量，如果channel满了，那么这个goroutine就会阻塞；同时使用waitGroup使主线程等待子线程都执行完。

### 16、select关键字 ###

select是用来监听channel有关的IO操作，当IO操作发生时，触发相应的动作。

在一个select语句中，go会按照从头到尾评估每一个发送和接收的语句，如果其中任意一个语句可以继续执行（没有被阻塞），那么就从那些可以执行的语句中任意选择一条来使用；如果没有任意一条语句可以执行（即所有通道都被阻塞），有两种情况：

1）如果给出了default语句，那么就会执行default的流程，同时程序的执行会从select语句后的语句中回复；

2）如果没有给出default，那么select语句将会被阻塞，直到至少有一个case可以进行下去；

### 17、在go语言中，Printf()，Sprintf()，Fprintf()函数的区别用法是什么 ###

*  Printf()：把格式字符串输出到标准输出；
 *  Sprintf()：把格式字符串输出到指定字符串中，所以参数比printf多个char\*，那就是目标字符串地址
 *  Fprintf()：把格式字符串输出到指定文件设备中，主要用于文件操作；

### 18、new() 和make()的区别 ###

1.  new：用来初始化一个对象，并返回该对象的首地址，其自身是一个指针（指向新分配的类型T的零值），可用于初始化任何类型并分配内存；
2.  make：返回一个初始化的实例（有初始值，不是零值），而不是指针，只能用来初始化map、slice、channel三种内建类型，进行内存分配；

### 19、slice的浅拷贝和深拷贝 ###

*  浅拷贝是只拷贝指针的值，指针指向的内容只有一份；这里slice的浅拷贝是指slice的赋值操作；
 *  深拷贝是指把指针指向的值拷贝一份；append()和copy()函数都能实现深拷贝；

### 20、对已经关闭的channel进行读写，会发生什么 ###

读取已经关闭的channel会一直读到东西，但是读到的内容会根据通道内关闭前是否有元素而不同：

*  如果channel关闭前，buffer内有元素未读取，会读到channel内的值，且返回的第二个bool值为true；
 *  如果channel关闭前，buffer内的元素已经读完，channel内无值，接下来所有接收的值都会非阻塞直接成功，返回channel内结构体的零值，但是第二个bool值一直为false；

对已经关闭的channel进行写，会直接panic。

### 21、对未初始化的channel进行读写，会发生什么 ###

对未初始化的channel进行读写，都会阻塞。（原因是channel为nil）

### 22、reflect（反射包）如何获取字段tag ###

t := reflect.TypeOf(struuu).Elem()
    for i:=0;i<t.NumField();i++{
        fmt.Print(t.Field(i).Tag.Get("json"))
    }

### 23、为什么json包不能导出私有变量的tag ###

因为json包里认为私有变量是不可导出的(Unexported)，所以跳过获取名为json的tag的内容。

### 24、json包变量不加tag会怎么样 ###

1.  如果变量首字母小写，则为private。是获取不到反射信息的；
2.  如果成员变量首字母大写，则为public；
3.  不加tag，可以正常转为json中的字段，json内的字段名跟结构体内的字段名一样；
4.  加了tag，从struct转json的时候，json内的字段名就tag内里面的字段名，原字段名已经没用了；

### 25、什么是内存逃逸，如何避免 ###

1、什么是内存逃逸

在程序中，每个函数块都会有自己的内存区域用来存储自己的局部变量、返回地址、返回值之类的数据，这一块内存区域有特定的结构和寻址方式，寻址起来十分迅速，开销很少。这一块内存地址称为栈，栈是线程级别的，大小在创建的时候已经确定，当变量太大的时候，会“逃逸”到堆上，这种现象称为内存逃逸。简单的说，局部变量通过堆分配和回收，就叫内存逃逸。

堆是一块没有特定结构，也没有固定大小的内存区域，可以根据需要进行调整。全局变量、内存占用较大的局部变量，函数调用结束后不能立刻回收的局部变量都会存在堆里面。变量在堆上的分配和回收都比在栈上开销大的多。增加了gc回收时的压力，同时也容易造成内存碎片。

2、如何避免发生内存逃逸

*  对于小型的数据，使用传值而不是传指针；
 *  避免使用长度不固定的slice切片，在编译期无法确定切片长度，只能将切片使用堆分配；
 *  interface调用方法会发生内存逃逸，在热点代码片段，谨慎使用；

### 26、字符串转成byte数组，会发生内存拷贝吗 ###

字符串转换成切片，会发生拷贝。严格来说，只要是强类型转换都会发生内存拷贝。

### 27、uintptr与unsafe.Pointer的区别 ###

*  unsafe.Pointer 只是单纯的通用型指针，用于转换不同类型指针，它可以不参与指针运算；
 *  uintptr指针是用于指针运算的，gc不把uintptr当指针，也就是说uintptr无法持有对象，uintptr类型的目标会被回收；
 *  unsafe.Pointer可以和普通指针进行相互转换；也可以可uintptr相互转换；

### 28、for select时，如果其中一个case通道已经关闭会怎样？如何select中只有一个case呢？ ###

for循环select时，如果其中一个case通道已经关闭了，则每次都会执行到这个case；

如果select中只有一个case，而这个case通道被关闭，则会出现死循环。

### 29、beego和gin的比较 ###

*  beego是典型的mvc框架；gin不支持mvc，需要开发者自己实现mvc；
 *  beego支持session，gin不支持session，需要安装另外的包；
 *  beego在业务方面比gin支持的多，但是gin在性能方面比beego好；

### 30、讲讲gin的router、中间件以及Context包的Next ###

**路由**：gin采用httprouter进行路由匹配,每一个注册的url都会通过 / 切分为n个树节点，然后挂到相应的method树上去，所以业务中有几种不同的method接口，就会产生对应的前缀树。

在 httprouter中，节点被分为4种类型：

1）static ，静态节点，/user/api 这种；

2）root，根节点；

3）param，参数节点，/user/\{id\} 这种；

4）catchAll，通配符

它通过对应的method拿到前缀树，然后开始进行一个广度优先的匹配。httprouter对下级节点的查找进行了优化，就是把当前节点的下级节点的首字母维护在本身，匹配时先进行索引的查找。

gin的router需要传入两个参数，一个为路径，另一个为路由执行的方法，称为处理器handler。可以传入多个**handler**，形成一条**handler chain**。handler函数需要传入一个**Gin.Context**指针。

gin的中间件函数是use()，即router := gin.Default() router.Use(func(c \*gin.Context)\{c.Next()\} )

使用Next函数，内部会去执行该路由前的已注册的中间件，它是一个洋葱模型。

洋葱模型：

每一次调用Next都会调用当前index的下一个索引位的方法，开始自增循环，直到index已经比所有的中间件数量还要大了，就会开始执行业务代码。当业务代码执行完后，就会一层一层的往外执行每个中间件未执行完的代码。

### 31、讲讲channel的运行机制 ###

channel的关键结构体是hchan，它记录了channel实现的关键信息，在src/runtime/chan.go里面。

type hchan struct{
    
        qcount              uint         // total data in the queue
        dataqsiz            uint         // size of the circular queue
        buf                 unsafe.Pointer // points to an array of dataqsize elements
        elemsize            uint16     
        closed              uint32
        elemtype            *_type        // element type
        sendx               uint          // send index
        recvx               uint          // receive index
        recevq              waitq         // list of rece waiters
        sendq               waitq         // list of send waiters
        lock                mutex         
    }

channel的整体结构图：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZmx5X1hpYW9tYQ_size_20_color_FFFFFF_t_70_g_se_x_16][]

*  buf是有缓冲的channel所特有的结构，用来存储缓冲数据，是一个循环链表；
 *  sendx和recvx用于记录buf这个循环链表中发送或接收的index；
 *  recvq和sendq分别是接收和发送goroutine的队列，是个双向链表；
 *  lock是个互斥锁；

简单来说，channel的数据结构如下：

1.  一个数组实现的环形队列，数组有两个下标分别表示读写的索引，用于保存channel缓冲区数据；
2.  channel的send和recv队列，队列里面都是持有goroutine和sudog元素，队列都是双链表实现的；
3.  channel的全局锁；

### 32、什么是微服务 ###

采用一组服务的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻量级交互机制来通信，例如RPC、HTTP等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现。

微服务架构设计包括：

*  服务熔断降级限流机制
 *  框架调用解耦（RPC）
 *  链路监控(prometheus)
 *  多级缓存
 *  网关
 *  docker部署管理、k8s
 *  自动扩容机制
 *  logging日志

### 33、什么是原子锁 ###

是针对cpu的锁，不允许两个cpu同时写一个存储单元。

### 34、gin的参数验证 ###

将自定义的校验方法注册到validator验证器里面：

package main
     
    import (
    	"github.com/gin-gonic/gin"
    	"github.com/gin-gonic/gin/binding"
    	"gopkg.in/go-playground/validator.v8"
    	"net/http"
    	"reflect"
    	"time"
    )
     
    //binding 绑定一些验证请求参数,自定义标签bookabledate表示可预约的时期
    type Booking struct {
    	CheckIn  time.Time `form:"check_in" binding:"required,bookabledate" time_format:"2006-01-02"`
    	CheckOut time.Time `form:"check_out" binding:"required,gtfield=CheckOut,bookabledate" time_format:"2006-01-02"`
    }
     
     
    //定义bookabledate标签对应的验证方法
    func bookableDate(
    	v *validator.Validate, topStruct reflect.Value, currentStructOrField reflect.Value,
    	field reflect.Value, fieldType reflect.Type, fieldKind reflect.Kind, param string,
    ) bool {
    	if date, ok := field.Interface().(time.Time); ok {
    		today := time.Now()
     
    		if  date.Unix() > today.Unix() {
    			return true
    		}
    	}
    	return false
    }
     
     
    func main() {
    	route := gin.Default()
     
            //将验证方法注册到验证器中
    	if v, ok := binding.Validator.Engine().(*validator.Validate); ok {
    		v.RegisterValidation("bookabledate", bookableDate)
    	}
     
    	route.GET("/bookable", getBookable)
    	route.Run(":8080")
    }
     
    func getBookable(c *gin.Context) {
    	var b Booking
    	if err := c.ShouldBindWith(&b, binding.Query); err == nil {
    		c.JSON(http.StatusOK, gin.H{"message": "Booking dates are valid!"})
    	} else {
    		c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
    	}
    }

### 35、Mutex锁的底层原理 ###

sync.Mutex由两个字段**state**和**sema**组成。其中，state表示当前互斥锁的状态，而sema是用于控制锁状态的信号量。

type Mutex struct{
        state int32
        sema  uint32    // 信号量，向处于Gwaitting的G发送信号
    }

state：

const (
    	mutexLocked = 1 << iota // mutex is locked
    	mutexWoken  //2
    	mutexStarving //4
    	mutexWaiterShift = iota //3
    )
                                                                                                 
    32                                               3             2             1             0 
     |                                               |             |             |             | 
     |                                               |             |             |             | 
     v-----------------------------------------------v-------------v-------------v-------------+ 
     |                                               |             |             |             v 
     |                 waitersCount                  |mutexStarving| mutexWoken  | mutexLocked | 
     |                                               |             |             |             | 
     +-----------------------------------------------+-------------+-------------+-------------+

最低三位表示mutexLocked、mutexWoken、mutexStarving，剩下的位置用来表示当前有多少个goroutine等待互斥锁的释放；

在默认情况下，互斥锁的所有状态位都是0，int32中的不同位分别表示了不同的状态：

*  mutexLocked——表示互斥锁的锁定状态；
 *  mutexWoken——表示从正常模式被唤醒；
 *  mutexStarving——当前的互斥锁进入饥饿状态；
 *  waitersCount——当前互斥锁上等待的goroutine个数；

为了保证锁的公平性，设计上互斥锁有两种状态：正常状态和饥饿状态。

正常状态：所有等待锁的goroutine按照FIFO顺序等待。唤醒的goroutine不会直接拥有锁，而是会和新请求锁的goroutine竞争锁的拥有。新请求锁的goroutine具有优势：它正在CPU上执行，而且可能有好几个，所以刚刚唤醒的goroutine有很大可能在锁竞争中失败。在这种情况下，这个被唤醒的goroutine会加入到等待队列的前面。如果一个等待的goroutine超过1ms没有获取锁，那么它将会把锁变为饥饿状态；

饥饿状态：锁的所有权将从unlock的goroutine直接交给等待队列中的第一个。新来的goroutine将不会尝试去获得锁，即使锁看起来是unlock状态，也不会去尝试自旋操作，而是放在等待队列的尾部。

### 36、读写锁的底层原理 ###

### 37、for range 返回索引与不返回索引的区别 ###

## 网络： ##

### 1、gRPC和restful相比，有什么优势 ###

gRPC和restful API都提供了一套通信机制，用于server/client模型通信，而且它们都使用http作为底层的传输协议（严格地说gRPC使用的是http2.0，而restful API则不一定）

*  gRPC可以使用protobuf来定义接口，可以有更加严格的接口约束条件，支持多种语言；
 *  protobuf可以将数据序列化为二进制编码，这会大幅减少需要传输的数据量，从而大幅提高传输速度；
 *  gRPC可以支持streaming流式通信（http2.0），提高传输速度；

扩展：

Protobuf: 实际是一套类似json或者xml的数据传输格式和规范，用于不同应用或进程之间进行通信时使用。

Protobu优点：

*  序列化后体积很小，消息大小只有xml的1/10~1/3
 *  解析速度快，解析速度比xml快20~100倍
 *  多语言支持
 *  兼容性好，能够很好的向上或向下兼容

http2.0：理论上http2.0就可以使用steaming模式，但是通常web服务的restful api很少使用，通常的流式应用如视频流，一般都会使用专门的协议如HLS，RTMP等，这些就不是我们通常web服务了，而是有专门的服务器应用。

### 2、protobuf与json有什么区别和联系 ###

protobuf和json都可以用来存储结构化数据，但是protobuf表示的数据能更加高效，并且将数据压缩得更小

原理：protobuf通过protobuf编译器将与编程语言无关的特有的 .proto 后缀的数据结构文件编译成各个编程语言（java、c/c++、python）专用的类文件，然后通过Google提供的各个编程语言的支持库lib即可调用API。

总结：

在编解码性能方面：

*  次数在1千一下，protobuf与json的编码与解码性能不相上下，甚至有比json差的趋势；
 *  次数在2千以上，protobuf的编码与解码性能比json高很多；
 *  次数在10万以上，protobuf的编码与解码性能优势就很明显了，远远高于json；

在内存占用方面：

*  protobuf的内存34，而json达到106，protobuf的内存占用只有json的1/3.

### 3、session与cookie的区别 ###

*  cookie数据存放在客户的浏览器上，session数据放在服务器上；
 *  cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session；
 *  session会在一定时间内保存在服务器上，当访问增多，会比较占用服务器的性能，考虑到减轻服务器性能方面，应当使用cookie；
 *  单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie；

### 4、http五层协议： ###

1）物理层：物理层的任务是透明地传送比特流（单位是比特）。

2）数据链路层：

3）网络层：负责为分组交换网上的不同主机提供通信服务；通过网络中的路由器找到目的主机；

4）传输层：传输控制协议（TCP），面向连接的，提供可靠的交付；用户数据包协议（UDP），无连接的，数据传输的单位的用户数据报，不保证提供可靠的交付。

5）应用层：直接为用户的应用进程提供服务。

### 5、tcp四次挥手为什么要等待2MSL ###

msl：maximum segment lifetime即报文最大生存时间。

1）防止客户端最后一次发给服务器的确认在网络中丢失以至于客户端关闭，而服务端未关闭，导致资源的浪费；

2）等待最大的2msl可以让本次连接的所有的网络包在链路上消失，以造成不必要的干扰。

### 6、http400状态码 ###

*  400 bad request 请求报文存在语法错误
 *  401 unauthorized 请求未授权通过
 *  403 forbidden表示请求资源的访问被服务器拒绝
 *  404 not found 在服务器上未找到请求的资源

### 7、time\_wait的作用 ###

time\_wait为主动关闭的那端最后经历的状态，持续时间为2MSL（maximum segment lifetime，最长生存时间）。

实现time\_wait的原因有以下两点：

1.  保证客户端发送的最后一个ACK报文段能够到达服务器，因为最后一个ACK报文可能会丢失，然后服务器就会超时重传第三次挥手的FIN信息报，然后客户端再重传一次第四次挥手的ACK报文。如果没有这2MSL，客户端发送完最后一个ACK报文后就直接关闭连接，就接收不到服务器超时重传的FIN信息报，服务器就不能按正常步骤进入close状态，就会耗费服务器的资源；
2.  在第四次挥手后，经过2MSL的时间 让本次连接所产生的所有报文段都从网络中消失。如果不等待2MSL的时间再关闭连接的话，就会有迷失在网络中的数据包出现在下次连接中，就会出现问题。

### 8、http2与http1的区别 ###

1）二进制传输

http2采用二进制传输，相对于http1的文本传输安全性要高；

2）多路复用

http1一个链接只能提交一个请求，而http2能同时处理无数个请求，可以降低连接的数量，提高网络的吞吐量；

3）头部压缩

http2通过gzip与compress对头部进行压缩，并且在客户端与服务端各维护了一份头部索引表，只需要根据索引id就可以进行头部信息的传输，缩小了头部容量，间接提升了传输效率；

4）服务端推送

http2可以主动推送资源到客户端，避免客户端花过多时间逐个请求，降低响应时间；

### 9、http报文是如何封装的 ###

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZmx5X1hpYW9tYQ_size_15_color_FFFFFF_t_70_g_se_x_16][]

http请求报文包括请求行、请求头、请求数据。

请求行：HTTP请求报文的第一行，由请求方法、URL字段和HTTP协议版本字段；其中方法字段严格区分大小写；

请求头部：位于请求行的下面；请求报文中常见的标头有Connection标头、Host、Range、User-Agent、Accept-Language

**HTTP的响应报文**：

响应报文也包括起始行、头部和消息，响应报文和请求报文不同的地方在于起始行：

1）协议类型及版本字段；

2）状态码；

3）状态码的文字描述；

### 10、http请求为什么是三次握手和四次挥手 ###

### 11、url从输入浏览器到返回结果的请求过程 ###

### 12、protobuf的压缩类型 ###

底部数据是二进制，基于128bits的数值存储方式（Base 128 Varints）

## 数据库 ##

### 1、mysql的四种隔离级别，mvcc的实现方法 ###

1）READ UNCOMMITED 读未提交

事务中修改了数据，即便是未提交，也被其他事务可见，这样就造成了脏读。脏读会带来很多问题，所以很少使用它。

2）READ COMMITED 读已提交

这是大多数数据库的默认隔离级别，一个事务修改数据但未提交，对其他任何事务都是不可见的。也就是不可重复读。

3）REAPATABLE READ 可重复读

解决了脏读的问题，但是不能解决另外一个问题，幻读。所谓幻读就是当某个事务读取某个范围内的记录时，另外一个事务又在该范围内插入了新纪录，当之前的新事物再次来读取该范围的数据时，返现还有新数据未被更新，就像产生了幻觉一样，即产生幻行。InnoDB采取了（MVCC,Multiversion Concurrency Control）解决了幻读的问题。 可重复读是mysql的默认事务隔离级别。

4）SERIALIZABLE 串行化

它是最高的隔离级别。它通过强制事务串行化，避免了前面所说的幻读问题。简单的说，就是SERIALIZABLE 会在读取的每一行数据上都加锁，这样会导致大量的超时和锁竞争的问题。实际上也很少用它。

补充：mysql的事务实现方式——mvcc

什么是mvcc：

MVCC，全称Multi-Version concurrency controller，即多版本并发控制。MVCC是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的访问，在编程语言中实现事务内存。mysql的innoDB引擎支持MVCC，在事务级别为RR（可重复读）和RC（读提交）生效。

工作原理：

实现原理借助3个隐藏字段、undo log和read view实现。

1）3个隐藏字段：

数据库表的引擎为innoDB时，都会为每行数据添加3个隐藏字段：

DB\_ROW\_ID：包含一个行ID，该行ID随着插入新行而增加，如果有唯一键，这个隐藏字段不会被创建；

DATA\_TRX\_ID：插入或更新该行的最后一个事务的事务标识符。删除在内部被视为更新，在该更新中，行中的特殊位被设置为将其标记为删除。

DATA\_ROLL\_PTR：滚动指针。innoDB通过这个指针找到之前版本的数据，该行版本的数据在undo log中是以链表形式存在的。

2）undo log

undo log主要分为两种:

insert undo log：代表事务在insert新纪录时产生的undo log，只在事务回滚时需要，并且在事务提交后可以被立即丢弃；

update undo log：事务在进行update或delete时产生的undo log，不仅在事务回滚时需要，在读快照时也需要；所以不能随便删除，只有在速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除。

3) read view

consistent read view：一致性视图，为某一时刻事务系统（trx\_sys）的快照，之后的读操作根据当前事务id与快照中事务系统状态做比较，判断数据对事务的可见性。

### 2、数据库设计三大范式 ###

1）确保每列保持原子性；

2）确保表中的每列都和主键相关；

3）确保每列都和主键直接相关，而不是间接相关；

### 3、什么是聚簇索引和二级索引 ###

聚簇索引：索引和数据存储在一块（都存储在同一个B\*tree中）。一般主键索引都是聚簇索引。

二级索引（辅助索引）：二级索引存储的是记录的主键，而不是数据存储的地址。

主键索引（聚簇索引）查询效率高于非主键索引；主键定义的长度越小，二级索引的大小就越小。

### 4、mysql底层原理 ###

引擎：InnoDB

InnoDB的存储文件有两个，后缀名分别是 .frm和 .db，其中 .frm是表的定义文件，而idb是数据文件。

InnoDB中存在表锁和行锁，行锁是在命中索引的情况下才会起作用；

InnoDB支持事务，且支持四种隔离级别（读未提交、读已提交、可重复读、串行化），默认的是可重复读。

存储结构：采用B+Tree来存储数据的。

### 5、mysql慢查询的优化 ###

1）索引没引起作用的情况：

*  使用LIKE关键字的查询语句

在使用LIKE关键字进行查询的查询语句中，如果匹配字符串的第一个字符为“%”，索引不会起作用。只有“%”不在第一个位置索引才会起作用。

*  使用多列索引的查询语句

MySQL可以为多个字段创建索引。一个索引最多可以包含16个字段，对于多列索引，只有查询条件使用了这些字段中的第一个字段时，索引才会被使用。

2）优化数据库结构

合理的数据库结构不仅可以使数据库占用更小的磁盘空间，而且能够使查询速度更快。数据库结构的设计，需要考虑数据冗余、查询和更新的速度、字段的数据类型是否合理等多方面的内容。

*  将字段很多的表分解为多个表

对于字段比较多的表，如果有些字段的使用频率很低，可以将这些字段分离出来形成新表。因为当一个表的数据量很大时，会由于使用频率低的字段的存在而变慢。

*  增加中间表

对于需要经常联合查询的表，可以建立中间表以提高查询效率。通过建立中间表，把需要经常查询的数据插入到中间表中，然后将原来的联合查询改为对中间表的查询，以此来提高查询效率。

3）分解关联查询

将一个大的查询分解为多个小查询是很有必要的。很多高性能的应用都会对关联查询进行分解，就是可以对每一个表进行一次单表查询，然后将查询结果在应用程序中进行关联，很多场景下这样会更高效。

4）优化LIMIT分页

查询时需要分页的操作通常会使用limit加上偏移量的方法实现，同时加上合适的order by 子句。如果有对应的索引，通常效率会不错。

但是当偏移量非常大的时候，例如可能是limit 10000,20这样的查询，这时mysql需要查询10020条然后只返回最后20条，前面的10000条记录都将被舍弃，这样的代价很高。

优化此类查询的方法就是使用索引覆盖扫描，而不是查询所有的列，然后根据需要做一次关联操作再返回所需的列，对于偏移量很大的时候效率会得到很大的提升。

### 6、redis的五种数据类型 ###

*  string 字符串，string数据结构是简单的key-value类型，value不仅可以是string，也可以是数字。
 *  list 列表，说白了就是列表，使用双端链表实现的list。
 *  set 集合，一堆不重复值的组合。
 *  sorted set 有序集合，和set集合相比，增加了一个权重参数score，使得集合中的元素能够按score进行有序排序。比如存储全班同学成绩的sorted sets，其集合value可以是同学的学号，score可以是其考试得分，这样数据插入集合的时候，就已经进行了排序。
 *  hash 字典（hash的key必须唯一）

### 7、redis的watch机制 ###

redis watch 命令用于监视一个（或多个）key，如果在事务执行之前这个key被其他命令所改动，那么事务将被打断

### 8、如何使用redis实现分布式锁 ###

借助于redis的setnx命令来操作，setnx针对key赋值的时候会判断redis中是否存在这个key，如果有返回-1，如果没有的话，直接set键值。setnx是原子操作，而set不能保证原子性。

为了防止锁被长久锁定，可以用expire加入过期时间。

### 9、redis的两个持久化方式 ###

redis提供两种方式进行持久化：RDB和AOF。

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，即fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

RDB存在哪些优势呢？

1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。

2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB又存在哪些劣势呢？

1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF的优势有哪些呢？

1). 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。

2). 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

3). 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

AOF的劣势有哪些呢？

1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

###  ###

### 10、redis的List底层是如何实现的 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODY2NDIzMg_size_16_color_FFFFFF_t_70 2][]

redis列表list使用两种数据结构作为底层实现：

*  压缩列表ziplist
 *  双向链表linkedlist

双向链表占用内存比压缩列表多，所以当创建新的列表时会优先使用压缩列表，并且在有需要的时候才从压缩列表转换到双向链表。在redis3.2版本之前是ziplist，3.2之后ziplist被quicklist替代。

### 11、mysql的索引、索引优化、b+tree索引原理 ###

1）索引

索引类型：

*  B+TREE索引，这是innoDB的默认索引类型；时间复杂度是 O(logN)
 *  HASH索引；时间复杂度是O(1)
 *  全文索引；

索引种类：

*  主键索引（PRIMARY KEY），是一种特殊的唯一索引，不允许有空值；一个表只能有一个主键索引；
 *  唯一索引（UNIQUE），唯一索引列的值必须唯一，但允许有空值；如果是组合索引，则列值的组合必须唯一；
 *  普通索引（INDEX），这是最基本的索引，没有任何限制；
 *  组合索引（INDEX），即一个索引包含多个列，多用于避免回表查询；
 *  全文索引（FULLTEXT），也称全文检索，是目前搜索引擎使用的一种关键技术。

**普通索引：**

创建索引：CREATE INDEX \[indexName\] ON \[tableName\] (\[columnName\])

添加索引：ALTER TABLE \[tableName\] ADD INDEX indexName

创建表时指定索引：

create table \[tableName\] (ID int not null, username varchar(16) not null , index \[indexName\] (username(length)))

**唯一索引**：

创建索引： CREATE UNIQUE INDEX \[tableName\] ON \[tableName\]

添加索引：ALTER TABLE \[tableName\] ADD UNIQUE \[indexName\] (userName(length))

**组合索引**：

ALTER TABLE table\_name ADD INDEX index\_name(column1,column2,column3)

创建表时指定索引：

create table \[tableName\]( ID int not null ,userName varchar(16) not null ,unique \[indexName\] (userName (length) ) )

**全文索引**：

ALTER TABLE table\_name ADD FULLTEXT (column)

备注：索引一经创建不能修改，如果要修改索引，只能删除重建。

2）索引优化

*  使用LIKE关键字的查询语句，在使用LIKE关键字进行查询的查询语句中，如果匹配字符串的第一个字符为“%”，索引不会起作用；
 *  一个索引最多可以包含16个字段，对于多列索引，只有查询条件使用了这些字段中的第一个字段时，索引才会被使用；
 *  一个表的索引尽量不要超过5个；
 *  尽量使用覆盖索引；
 *  尽量不要再重复数据多的列上建索引；

3）b+tree索引原理

### 12、mysql如何实现分布式锁 ###

在数据库中创建一个表，表中包含方法名等字段，并在方法名字段中创建唯一索引，想要执行某个方法，就使用这个方法名向表中插入数据，成功则获取锁，执行完成后删除对应的行数据释放锁。

### 13、mysql的高可用方案有哪些 ###

*  主从或主主半同步复制
 *  半同步复制优化；
 *  高可用架构优化；
 *  共享存储，SAN共享存储、DRBD磁盘复制；
 *  分布式协议；

### 14、mysql的级联查询 ###

使用的beego的mysql的orm：

先定义一个ormer对象——>调用QueryTable获得一个query seter——>执行RelatedSel()——>执行Filter()——>执行All()

### 15、mysql一个表字段很多的情况下如何优化查询 ###

1）主从同步复制+读写分离；

2）纵向分表

根据原则，每个表最多不要超过5个索引，纵向拆分字段，将部分字段拆到一个新表

3）横向分表

4）利用表分区

在同一个磁盘上，表的数据存在不同的文件夹内，能够极大的提高查询速度。

### 16、gorm与beego orm的对比 ###

gorm是基于go语言实现的orm库，类似于java实现的mybatis、SpringData等。

### 17、mysql的引擎有哪些 ###

1.  InnoDB，mysql的默认引擎，事务型数据库的首选，支持行锁定和外键；
2.  MyISAM；
3.  MEMORY;
4.  MERGE；

### 18、mysql的联合查询 ###

### 20、mysql的连表查询 ###

### 21、mysql的B+Tree索引原理 ###

### 22、mysql的索引优化 ###

### 23、mysql中的string类型有哪些 ###

## 中间件 ##

### 1、说一下你熟悉的 MQ,比如 MQTT等 ###

MQTT协议实现方式：

实现MQTT需要客户端和服务器端通讯完成，在通讯过程中，MQTT协议中有三种身份：发布者（publish）、代理（broker）、订阅者（subscribe）。其中消息的发布者和订阅者都是客户端，消息代理是服务器，消息发布者可以同时是订阅者。

MQTT传输的消息分为：主题（topic）和负载（payload）两部分：

1）topic，可以理解为消息的类型，订阅者订阅后（subscribe），就会收到该主题的消息内容（payload）

2）payload，消息的内容，是指订阅者具体要使用的内容。

网络传输与应用消息：

MQTT会构建底层网络传输：它将建立客户端到服务器的连接，提供两者之间的一个有序的、无损的、基于字节流的双向传输。当应用数据通过MQTT网络发送时，MQTT会把与之前的服务质量（QoS）和主题名（Topic）相关联。

MQTT客户端：

一个使用MQTT协议的应用程序或者设备，它总是建立到服务器的网络连接，客户端可以：

1）发布与其他客户端可能会订阅的消息；

2）订阅其他客户端发布的消息；

3）退出或删除应用程序的消息；

4）断开与服务器连接；

MQTT服务器：

MQTT服务器又称为“消息代理”（broker），可以是一个应用程序或设备。它是位于消息发布者和订阅者之间，它可以：

1）接受来自客户的网络连接；

2）接受客户发布的应用消息；

3）处理来自客户端的订阅和退订请求；

4）向订阅的客户转发应用程序消息；

MQTT协议中的订阅、主题、会话：

一、订阅（subscription）

订阅主要包括主题筛选器（Topic Filter）和最大服务器质量（QoS）。订阅会与一个会话（Session）关联。一个会话可以包含多个订阅。每一个会话中的订阅都有一个不同的主题筛选器。

二、会话（Session）

每个客户端与服务器建立连接后就是一个会话，客户端和服务器之间有状态交互。会话存在于一个网络之间，也可能在客户端和服务器之间跨越多个连续的网络连接。

三、主题名（Tpoic Name）

连接到一个应用程序消息的标签，该标签与服务器的订阅相匹配。服务器会将消息发送给订阅所匹配标签的每个客户端。

四、主题筛选器（Topic Filter）

一个队主题名通配符筛选器，在订阅表达式中使用，表示订阅所匹配到的多个主题。

五、负载（payload）

消息订阅者所具体接收的内容。、

MQTT协议中的方法：

MQTT协议中定义了一些方法（也被称为动作），来表示对确定资源所进行操作。这个资源可以代表预先存在的数据或动态生成数据，这取决于服务器的实现。通常来说，资源指服务器上的文件或输出，主要方法有：

1）connect。等待与服务器建立连接；

2）disconnect。等待MQTT客户端完成所做的工作，并与服务器断开TCP/IP会话；

3）subscribe。等待完成订阅；

4）unsubscribe。等待服务器取消客户端的一个或多个topic订阅。

5）publish。MQTT客户端发送消息请求，发送完成后返回应用程序线程。

MQTT协议数据包结构：

在MQTT协议中，一个MQTT数据包由：固定头（Fixed header）、可变头（Variable header）、消息体（payload）三部分组成。MQTT数据结构如下：

1）固定头（Fixed header）：存在于所有的MQTT数据包中，表示数据包类型及数据包的分组类标识；

2）可变头（Variable header）：存在于部分MQTT数据包中，数据包类型决定了可变头是否存在及其具体内容；

3）消息体（payload）：存在部分MQTT数据包中，表示客户端收到的具体内容。包含CONNECT、SUBSCRIBE、SUBACK 、UNSCRIBE四种类型的消息。

### 2、消息队列kafka原理 ###

## docker，k8s、etcd、promethus ##

### 1、dockerFile 的命令 ###

*  FROM 指定哪种镜像作为新镜像的基础镜像，如

FROM ubuntu:14.04

*  MAINTAINER 指明该镜像的作者和其电子邮件，如

MAINTAINER vector4wang "xxxx@qq.com"

*  RUN 在新镜像内部执行的命令，比如安装一些软件、配置一些基础环境，可以使用 \\ 来换行，如：

RUN echo "hello docker!" \
        > /usr/local/file.txt

也可以使用exec格式 RUN \["executable","param1","param2"\]的命令，如：

RUN ["apt-get","install","-y","nginx"]

注意：executable是命令，后面的param是参数。

*  COPY 将主机的文件复制到镜像内，如果目的位置不存在，Docker会自动创建所需要的目录结构，但是它只是单纯的复制，并不会去做文件提取和解压工作，如：

COPY applicaiton.yml /etc/src/resources

注意：需要复制的目录需要放在Dockerfile文件的同级目录下。

*  ADD 将主机的文件复制到镜像中，跟COPY一样，但是ADD会对压缩文件做提取和解压操作。

ADD application.yml /etc/src/resources

*  EXPOSE 暴露镜像的端口供主机做映射，启动镜像时，使用 -P 参数来将镜像端口与宿主机的随机端口做映射。可以指定多个：

EXPOSE 8080
    EXPOSE 8088

*  WORKDIR 在构建镜像时，指定镜像的工作目录，之后的命令都是基于此工作目录，如果不存在，则会创建目录：

WORKDIR /usr/local
    WORKDIR webservice
    RUN echo 'hello docker' >  a.txt

最终会在/user/local/webservice/目录下生成 a.txt文件。

*  ONBUILD 当一个包含ONBUILD命令的镜像被用作其他镜像的基础镜像时（比如用户的镜像需要从某个准备好的位置添加源代码，或者用户需要执行特定于构建镜像的环境构建脚本），该命令就会去执行：

如创建镜像 image-A

FROM ubuntu
    ...
    ONBUILD ADD . /var/www
    ...

然后创建镜像 image-B，指定image-A为基础镜像，如

FROM image-A
    ...

然后在构建image-B的时候，日志上显示为

Step 0: FROM image-A
    # Execting 1 build triggers
    Step onbuild-0 : ADD . /var/www
    ...

*  USER

指定该镜像以什么样的用户去执行，如：

USER mongo

*  VOLUME

用来向基于镜像创建的容器添加卷。比如你可以将mogodb镜像中存储数据的data文件指定为主机的某个文件，如：

VOLUME /data/db  /data/configdb

*  CMD

容器启动的命令：

CMD /bin/bash
    # 或
    CMD ["/bin/bash"]

注意：当有多个CMD的时候，只有最后一个生效。

*  ENTRYPOINT

作用和用法跟CMD一样。

*  CMD和ENTRYPOINT的区别：

CMD的命令会被docker run 相同的命令覆盖，而ENTRYPOINT不会。

如，使用CMD \["/bin/bash"\] 或 ENTRYPOINT \["/bin/bash"\]后，再使用 docker run -it image启动容器，它会自动进入容器内部的交互终端，如同使用 docker run -it image /bin/bash。

但是如果启动的命令为 docker run -it image /bin/ps，使用CMD后面的命令就会被覆盖转而执行 /bin/ps命令，而ENTRYPOINT的则不会，而是会把docker run后面的命令当做ENTRYPOINT执行命令的参数。

如：

ENTRYPOINT ["/usr/sbin/nginx"]

然后通过build之后的容器输入命令：

docker run -it image -g "daemon off"

此时 -g "daemo off"会被当成参数传递给ECTRYPOINT，最终的命令变成了：

/usr/sbin/nginx -g "daemon off"

当CMD和ENTRYPOINT都存在时，CMD的指令会变成ENTRYPOINT的参数，并且此CMD提供的参数会被docker run后面的命令覆盖。

### 2、k8s中rc与rs的区别 ###

rs是rc的升级版本，在旧版本中只有rc（replication controller，复制控制器），它的作用是确保pod以用户指定的副本数运行，即如果有容器异常退出，replication controller会自动创建新的pod来替代。

在新版本中，建议使用ReplicaSet来取代replication controller。rs和rc没有本质的不同，rs支持集合式的选择器，而rc只支持等式选择器。

### 3、docker的运行机制（运行原理） ###

docker是一个client-server结构的系统，docker守护进程运行在主机上，然后通过socket连接从客户端访问，守护进程从客户端接受命令并管理运行在主机上的容器。容器是一个运行时环境。

docker为什么比jvm运行快？

1.  docker用的是宿主物理机上的硬件，不用Hypervisor实现硬件虚拟化，所以CPU、内存利用率在效率上有优势；
2.  docker利用的是宿主机的内核，不需要guest os，因此docker不需要和虚拟机一样要加载操作系统的内核，利用的是宿主机的操作系统，因此过程是非常快的，是秒级的（而新建一个虚拟机时，需要加载guest os，这个过程是分钟级的）

### 4、k8s的整个运行流程 ###

### 5、讲解一下k8s的各个组件 ###

### 6、ETCD中的raft原理 ###

etcd使用raft协议来保证整个分布式的节点网络能正常的运转，并且能正确的将数据复制到每个节点上面去。

选举状态：

*  leader 表示选举最终产生的领导人
 *  candidate 候选状态，表示当前正在参与选举
 *  follower 表示从属节点

选举过程：

1.  所有节点一开始都是follower状态；
2.  当节点处于follower状态时，每个节点随机经过一段时间，如果没有收到leader的消息就会进入candidate状态（证明当前没有leader节点需要重新进行选举），如果收到信息就会继续保持follower状态；
3.  当节点处于candidate就会要求别人给自己投票，收到大多数的节点的投票就转变为leader状态，否则 要么是别的节点成为了leader，要么就是因为特殊情况导致这次选举失败重新进行选举；
4.  每次选举举办的时候有一个term，在每一个term中，每个节点只能投票一次；
5.  投票的时候必须投给当前数据至少和自己一样的节点，并且term大的优先；

日志复制规则：

etcd是通过日志复制来实现数据同步的。leader选出后接受客户端请求，leader把请求日志作为日志条目加入到日志中，然后向其他follower节点复制日志，如果超过半数的日志复制成功，则leader将日志应用到状态机并向客户端返回执行结果，同时follower也将结果提交。如果存在follower没有成功复制日志，则leader会无限重试。

日志同步的关键点：

*  日志由有序编号的日志条目组成，每条日志包含创建的任期和用于执行的命令，日志是保证所有节点数据一致的关键；
 *  leader负责一致性检查，同时让所有的follower都和自己保持一致；
 *  在leader发生切换时，如何保证各节点日志一致：leader为每一个follower维护一个nextIndex，将index和termid信息发送至follower，从缺失的termid和index为follower补齐数据，直至和leader完全一致；
 *  只允许主节点提交包含当前term的日志，否则会出现已经commit的日志出现更改的情况；

### 7、etcd如何实现分布式锁 ###

1.  在etcd系统里创建一个key；
2.  如果创建失败，key存在，则监听该key的变化事件，直到该key被删除，回到1；
3.  如果创建成功，则认为获得了锁；

### 8、promethus是如何访问的、访问流程是什么 ###

## Linux： ##

### 1、查看进程打开哪些文件 ###

lsof /filepath/file

### 2、如何查看Linux系统的状态，如CPU、内存使用、负载情况等 ###

*  w 查看服务器性能
 *  free 只能查看内存的使用信息
 *  df -h 查看磁盘情况

### 3、如何查看一个进程的状态 ###

ps -aux 或者ps -aux|grep \[port|pid|关键词\]

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZmx5X1hpYW9tYQ_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

## 算法与数据结构 ##

### 1、红黑树 ###

### 2、布隆过滤器 ###

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODY2NDIzMg_size_16_color_FFFFFF_t_70]: /images/20220829/44e47a857948469c8fb5578ca58f3ebb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODY2NDIzMg_size_16_color_FFFFFF_t_70 1]: /images/20220829/d5465d1bacb64076a799392f8788ffbf.png
[20210827015916576.png]: /images/20220829/bc233f10cb734b7b979ab8b8c5aa0620.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZmx5X1hpYW9tYQ_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/0a321e3e6cea496aab9f27add8450d72.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZmx5X1hpYW9tYQ_size_15_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/d7189a68c3cc445fb366b6b283a856db.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODY2NDIzMg_size_16_color_FFFFFF_t_70 2]: /images/20220829/e0de14c5fbac433b96eaa932bbdea80e.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZmx5X1hpYW9tYQ_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220829/d3f9ef749f694af685fb8ce7e63971c7.png