go语言多线程面试题 golang 多线程使用

go面试题整理（附带部分自己的解答）

原文：【 】

如果有解答的不对的，麻烦各位在评论写出来~

go的调度原理是基于GMP模型，G代表一个goroutine，不限制数量；M=machine，代表一个线程，最大1万，所有G任务还是在M上执行；P=processor代表一个处理器，每一个允许的M都会绑定一个G，默认与逻辑CPU数量相等（通过runtime.GOMAXPROCS(runtime.NumCPU())设置）。

go调用过程：

可以能，也可以不能。

因为go存在不能使用==判断类型：map、slice，如果struct包含这些类型的字段，则不能比较。

这两种类型也不能作为map的key。

类似栈操作，后进先出。

因为go的return是一个非原子性操作，比如语句 return i ，实际上分两步进行，即将i值存入栈中作为返回值，然后执行跳转，而defer的执行时机正是跳转前，所以说defer执行时还是有机会操作返回值的。

select的case的表达式必须是一个channel类型，所有case都会被求值，求值顺序自上而下，从左至右。如果多个case可以完成，则会随机执行一个case，如果有default分支，则执行default分支语句。如果连default都没有，则select语句会一直阻塞，直到至少有一个IO操作可以进行。

break关键字可跳出select的执行。

goroutine管理、信息传递。context的意思是上下文，在线程、协程中都有这个概念，它指的是程序单元的一个运行状态、现场、快照，包含。context在多个goroutine中是并发安全的。

应用场景：

例子参考：

waitgroup

channel

len：切片的长度，访问时间复杂度为O(1)，go的slice底层是对数组的引用。

cap：切片的容量，扩容是以这个值为标准。默认扩容是2倍，当达到1024的长度后，按1.25倍。

扩容：每次扩容slice底层都将先分配新的容量的内存空间，再将老的数组拷贝到新的内存空间，因为这个操作不是并发安全的。所以并发进行append操作，读到内存中的老数组可能为同一个，最终导致append的数据丢失。

共享：slice的底层是对数组的引用，因此如果两个切片引用了同一个数组片段，就会形成共享底层数组。当sliec发生内存的重新分配（如扩容）时，会对共享进行隔断。详细见下面例子：

make([]Type,len,cap)

map的底层是hash table(hmap类型)，对key值进行了hash，并将结果的低八位用于确定key/value存在于哪个bucket（bmap类型）。再将高八位与bucket的tophash进行依次比较，确定是否存在。出现hash冲撞时，会通过bucket的overflow指向另一个bucket，形成一个单向链表。每个bucket存储8个键值对。

如果要实现map的顺序读取，需要使用一个slice来存储map的key并按照顺序进行排序。

利用map，如果要求并发安全，就用sync.map

要注意下set中的delete函数需要使用 delete(map) 来实现，但是这个并不会释放内存，除非value也是一个子map。当进行多次delete后，可以使用make来重建map。

使用sync.Map来管理topic，用channel来做队列。

参考：

多路归并法:

pre class="vditor-reset" placeholder="" contenteditable="true" spellcheck="false"p data-block="0"(1)假设有K路a href=""数据流/a，流内部是有序的，且流间同为升序或降序；

/pp data-block="0"(2)首先读取每个流的第一个数，如果已经EOF，pass；

/pp data-block="0"(3)将有效的k(k可能小于K)个数比较，选出最小的那路mink，输出，读取mink的下一个；

/pp data-block="0"(4)直到所有K路都EOF。

/p/pre

假设文件又1个G，内存只有256M，无法将1个G的文件全部读到内存进行排序。

第一步：

可以分为10段读取，每段读取100M的数据并排序好写入硬盘。

假设写入后的文件为A,B，C...10

第二步:

将A，B,C...10的第一个字符拿出来，对这10个字符进行排序，并将结果写入硬盘，同时记录被写入的字符的文件指针P。

第三步：

将刚刚排序好的9个字符再加上从指针P读取到的P+1位数据进行排序，并写入硬盘。

重复二、三步骤。

go文件读写参考：

保证排序前两个相等的数其在序列的前后位置顺序和排序后它们两个的前后位置顺序相同的排序叫稳定排序。

快速排序、希尔排序、堆排序、直接选择排序不是稳定的排序算法。

基数排序、冒泡排序、直接插入排序、折半插入排序、归并排序是稳定的排序算法。

参考：

head只请求页面的首部。多用来判断网页是否被修改和超链接的有效性。

get请求页面信息，并返回实例的主体。

参考:

401：未授权的访问。

403: 拒绝访问。

普通的http连接是客户端连接上服务端，然后结束请求后，由客户端或者服务端进行http连接的关闭。下次再发送请求的时候，客户端再发起一个连接，传送数据，关闭连接。这么个流程反复。但是一旦客户端发送connection:keep-alive头给服务端，且服务端也接受这个keep-alive的话，两边对上暗号，这个连接就可以复用了，一个http处理完之后，另外一个http数据直接从这个连接走了。减少新建和断开TCP连接的消耗。这个可以在Nginx设置，

这个keepalive_timout时间值意味着：一个http产生的tcp连接在传送完最后一个响应后，还需要hold住keepalive_timeout秒后，才开始关闭这个连接。

特别注意TCP层的keep alive和http不是一个意思。TCP的是指：tcp连接建立后，如果客户端很长一段时间不发送消息，当连接很久没有收到报文，tcp会主动发送一个为空的报文（侦测包）给对方，如果对方收到了并且回复了，证明对方还在。如果对方没有报文返回，重试多次之后则确认连接丢失，断开连接。

tcp的keep alive可通过

net.ipv4.tcp_keepalive_intvl = 75 // 当探测没有确认时，重新发送探测的频度。缺省是75秒。

net.ipv4.tcp_keepalive_probes = 9 //在认定连接失效之前，发送多少个TCP的keepalive探测包。缺省值是9。这个值乘以tcp_keepalive_intvl之后决定了，一个连接发送了keepalive之后可以有多少时间没有回应

net.ipv4.tcp_keepalive_time = 7200 //当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时。一般设置为30分钟1800

修改：

可以

tcp是面向连接的，upd是无连接状态的。

udp相比tcp没有建立连接的过程，所以更快，同时也更安全，不容易被攻击。upd没有阻塞控制，因此出现网络阻塞不会使源主机的发送效率降低。upd支持一对多，多对多等，tcp是点对点传输。tcp首部开销20字节，udp8字节。

udp使用场景：视频通话、im聊天等。

time-wait表示客户端等待服务端返回关闭信息的状态，closed_wait表示服务端得知客户端想要关闭连接，进入半关闭状态并返回一段TCP报文。

time-wait作用：

解决办法：

close_wait:

被动关闭，通常是由于客户端忘记关闭tcp连接导致。

根据业务来啊~

重要指标是cardinality（不重复数量），这个数量/总行数如果过小（趋近于0）代表索引基本没意义，比如sex性别这种。

另外查询不要使用select *，根据select的条件+where条件做组合索引，尽量实现覆盖索引，避免回表。

僵尸进程：

即子进程先于父进程退出后，子进程的PCB需要其父进程释放，但是父进程并没有释放子进程的PCB，这样的子进程就称为僵尸进程，僵尸进程实际上是一个已经死掉的进程。

孤儿进程：

一个父进程退出，而它的一个或多个子进程还在运行，那么那些子进程将成为孤儿进程。孤儿进程将被init进程(进程号为1)所收养，并由init进程对它们完成状态收集工作。

子进程死亡需要父进程来处理，那么意味着正常的进程应该是子进程先于父进程死亡。当父进程先于子进程死亡时，子进程死亡时没父进程处理，这个死亡的子进程就是孤儿进程。

但孤儿进程与僵尸进程不同的是，由于父进程已经死亡，系统会帮助父进程回收处理孤儿进程。所以孤儿进程实际上是不占用资源的，因为它终究是被系统回收了。不会像僵尸进程那样占用ID,损害运行系统。

原文链接：

产生死锁的四个必要条件：

（1） 互斥条件：一个资源每次只能被一个进程使用。

（2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。

（3） 不剥夺条件：进程已获得的资源，在末使用完之前，不能强行剥夺。

（4） 循环等待条件：若干进程之间形成一种头尾相接的循环等待资源关系。

避免方法：

端口占用：lsof -i:端口号 或者 nestat

cpu、内存占用：top

发送信号：kill -l 列出所有信号，然后用 kill [信号变化] [进程号]来执行。如kill -9 453。强制杀死453进程

git log:查看提交记录

git diff ：查看变更记录

git merge：目标分支改变，而源分支保持原样。优点：保留提交历史，保留分支结构。但会有大量的merge记录

git rebase：将修改拼接到最新，复杂的记录变得优雅，单个操作变得(revert)很简单；缺点：

git revert:反做指定版本，会新生成一个版本

git reset:重置到某个版本，中间版本全部丢失

etcd、Consul

pprof

节省空间（非叶子节点不存储数据，相对b tree的优势），减少I/O次数（节省的空间全部存指针地址，让树变的矮胖），范围查找方便（相对hash的优势）。

explain

其他的见：

runtime2.go 中关于 p 的定义： 其中 runnext 指针决定了下一个要运行的 g，根据英文的注释大致意思是说：

所以当设置 runtime.GOMAXPROCS(1) 时，此时只有一个 P，创建的 g 依次加入 P， 当最后一个即 i==9 时，加入的最后 一个 g 将会继承当前主 goroutinue 的剩余时间片继续执行，所以会先输出 9， 之后再依次执行 P 队列中其它的 g。

方法一：

方法二：

[图片上传失败...(image-4ef445-1594976286098)]

方法1：to_days，返回给的日期从0开始算的天数。

方法2：data_add。向日期添加指定时间间隔

[图片上传失败...(image-b67b10-1594976286098)]

面试问题总结（一）Golang

使用go语言的好处: go语言的设计是务实的, go在针对并发上进行了优化, 并且支持大规模高并发, 又由于单一的码格式, 相比于其他语言更具有可读性, 在垃圾回收上比java和Python更有效, 因为他是和程序同时执行的.

1. 进程, 线程, 协程的区别, 协程的优势

2. 讲一下GMP模型(重点)

3. Go的GC, 混合写屏障(重点)

4. go的Slice和数组的区别, slice的扩容原理(重点)

5. 讲一下channel,实现原理(重点)

6. 讲一下Go的Map的实现原理, 是否线程安全, 如何实现安全(重点)

7. new 和 make 的区别

8. 说一下内存逃逸

9. 函数传指针和传值有什么区别

10. goroutine之间的通信方式

11. 测试是怎么做的(单元测试, 压力测试)

12. 堆和栈的区别

天翼云golang面试几轮

天翼云Golang面试一般会分为以下几轮go语言多线程面试题：

第一轮：简历筛选go语言多线程面试题，在这一轮对简历进行筛选，看看是否满足面试要求，准备进入下一轮。

第二轮：简单go语言多线程面试题的编程测试，这一轮主要考察面试者go语言多线程面试题的基本编程技能，面试者需要准备一些简单的编程问题作为测试。

第三轮：技术面谈，这一轮主要是考察面试者的技术能力，可以涉及Golang相关的基础知识和常见的技术问题。

第四轮：计算机知识测试，这一轮是考察面试者的计算机基础知识，比如数据结构、网络协议等。

第五轮：综合能力测试，这一轮主要考察面试者的综合能力，比如项目经验、团队合作能力等。

彻底理解Golang Map

本文目录如下，阅读本文后，将一网打尽下面Golang Map相关面试题

Go中的map是一个指针，占用8个字节，指向hmap结构体; 源码 src/runtime/map.go 中可以看到map的底层结构

每个map的底层结构是hmap，hmap包含若干个结构为bmap的bucket数组。每个bucket底层都采用链表结构。接下来，我们来详细看下map的结构

bmap 就是我们常说的“桶”，一个桶里面会最多装 8 个 key，这些 key 之所以会落入同一个桶，是因为它们经过哈希计算后，哈希结果是“一类”的，关于key的定位我们在map的查询和插入中详细说明。在桶内，又会根据 key 计算出来的 hash 值的高 8 位来决定 key 到底落入桶内的哪个位置（一个桶内最多有8个位置)。

bucket内存数据结构可视化如下：

注意到 key 和 value 是各自放在一起的，并不是 key/value/key/value/... 这样的形式。源码里说明这样的好处是在某些情况下可以省略掉 padding字段，节省内存空间。

当 map 的 key 和 value 都不是指针，并且 size 都小于 128 字节的情况下，会把 bmap 标记为不含指针，这样可以避免 gc 时扫描整个 hmap。但是，我们看 bmap 其实有一个 overflow 的字段，是指针类型的，破坏了 bmap 不含指针的设想，这时会把 overflow 移动到 extra 字段来。

map是个指针，底层指向hmap，所以是个引用类型

golang 有三个常用的高级类型 slice 、map、channel, 它们都是 引用类型 ，当引用类型作为函数参数时，可能会修改原内容数据。

golang 中没有引用传递，只有值和指针传递。所以 map 作为函数实参传递时本质上也是值传递，只不过因为 map 底层数据结构是通过指针指向实际的元素存储空间，在被调函数中修改 map，对调用者同样可见，所以 map 作为函数实参传递时表现出了引用传递的效果。

因此，传递 map 时，如果想修改map的内容而不是map本身，函数形参无需使用指针

map 底层数据结构是通过指针指向实际的元素 存储空间 ，这种情况下，对其中一个map的更改，会影响到其他map

map 在没有被修改的情况下，使用 range 多次遍历 map 时输出的 key 和 value 的顺序可能不同。这是 Go 语言的设计者们有意为之，在每次 range 时的顺序被随机化，旨在提示开发者们，Go 底层实现并不保证 map 遍历顺序稳定，请大家不要依赖 range 遍历结果顺序。

map 本身是无序的，且遍历时顺序还会被随机化，如果想顺序遍历 map，需要对 map key 先排序，再按照 key 的顺序遍历 map。

map默认是并发不安全的，原因如下：

Go 官方在经过了长时间的讨论后，认为 Go map 更应适配典型使用场景（不需要从多个 goroutine 中进行安全访问），而不是为了小部分情况（并发访问），导致大部分程序付出加锁代价（性能），决定了不支持。

场景: 2个协程同时读和写，以下程序会出现致命错误：fatal error: concurrent map writes

如果想实现map线程安全，有两种方式：

方式一：使用读写锁 map + sync.RWMutex

方式二：使用golang提供的 sync.Map

sync.map是用读写分离实现的，其思想是空间换时间。和map+RWLock的实现方式相比，它做了一些优化：可以无锁访问read map，而且会优先操作read map，倘若只操作read map就可以满足要求(增删改查遍历)，那就不用去操作write map(它的读写都要加锁)，所以在某些特定场景中它发生锁竞争的频率会远远小于map+RWLock的实现方式。

golang中map是一个kv对集合。底层使用hash table，用链表来解决冲突 ，出现冲突时，不是每一个key都申请一个结构通过链表串起来，而是以bmap为最小粒度挂载，一个bmap可以放8个kv。在哈希函数的选择上，会在程序启动时，检测 cpu 是否支持 aes，如果支持，则使用 aes hash，否则使用 memhash。

map有3钟初始化方式，一般通过make方式创建

map的创建通过生成汇编码可以知道，make创建map时调用的底层函数是 runtime.makemap 。如果你的map初始容量小于等于8会发现走的是 runtime.fastrand 是因为容量小于8时不需要生成多个桶，一个桶的容量就可以满足

makemap函数会通过 fastrand 创建一个随机的哈希种子，然后根据传入的 hint 计算出需要的最小需要的桶的数量，最后再使用 makeBucketArray 创建用于保存桶的数组，这个方法其实就是根据传入的 B 计算出的需要创建的桶数量在内存中分配一片连续的空间用于存储数据，在创建桶的过程中还会额外创建一些用于保存溢出数据的桶，数量是 2^(B-4) 个。初始化完成返回hmap指针。

找到一个 B，使得 map 的装载因子在正常范围内

Go 语言中读取 map 有两种语法：带 comma 和 不带 comma。当要查询的 key 不在 map 里，带 comma 的用法会返回一个 bool 型变量提示 key 是否在 map 中；而不带 comma 的语句则会返回一个 value 类型的零值。如果 value 是 int 型就会返回 0，如果 value 是 string 类型，就会返回空字符串。

map的查找通过生成汇编码可以知道，根据 key 的不同类型，编译器会将查找函数用更具体的函数替换，以优化效率：

函数首先会检查 map 的标志位 flags。如果 flags 的写标志位此时被置 1 了，说明有其他协程在执行“写”操作，进而导致程序 panic。这也说明了 map 对协程是不安全的。

key经过哈希函数计算后，得到的哈希值如下（主流64位机下共 64 个 bit 位）：

m: 桶的个数

从buckets 通过 hash m 得到对应的bucket，如果bucket正在扩容，并且没有扩容完成，则从oldbuckets得到对应的bucket

计算hash所在桶编号：

用上一步哈希值最后的 5 个 bit 位，也就是 01010 ，值为 10，也就是 10 号桶（范围是0~31号桶）

计算hash所在的槽位:

用上一步哈希值哈希值的高8个bit 位，也就是 10010111 ，转化为十进制，也就是151，在 10 号 bucket 中寻找** tophash 值（HOB hash）为 151* 的 槽位**，即为key所在位置，找到了 2 号槽位，这样整个查找过程就结束了。

如果在 bucket 中没找到，并且 overflow 不为空，还要继续去 overflow bucket 中寻找，直到找到或是所有的 key 槽位都找遍了，包括所有的 overflow bucket。

通过上面找到了对应的槽位，这里我们再详细分析下key/value值是如何获取的：

bucket 里 key 的起始地址就是 unsafe.Pointer(b)+dataOffset。第 i 个 key 的地址就要在此基础上跨过 i 个 key 的大小；而我们又知道，value 的地址是在所有 key 之后，因此第 i 个 value 的地址还需要加上所有 key 的偏移。

通过汇编语言可以看到，向 map 中插入或者修改 key，最终调用的是 mapassign 函数。

实际上插入或修改 key 的语法是一样的，只不过前者操作的 key 在 map 中不存在，而后者操作的 key 存在 map 中。

mapassign 有一个系列的函数，根据 key 类型的不同，编译器会将其优化为相应的“快速函数”。

我们只用研究最一般的赋值函数 mapassign 。

map的赋值会附带着map的扩容和迁移，map的扩容只是将底层数组扩大了一倍，并没有进行数据的转移，数据的转移是在扩容后逐步进行的，在迁移的过程中每进行一次赋值（access或者delete）会至少做一次迁移工作。

1.判断map是否为nil

每一次进行赋值/删除操作时，只要oldbuckets != nil 则认为正在扩容，会做一次迁移工作，下面会详细说下迁移过程

根据上面查找过程，查找key所在位置，如果找到则更新，没找到则找空位插入即可

经过前面迭代寻找动作，若没有找到可插入的位置，意味着需要扩容进行插入，下面会详细说下扩容过程

通过汇编语言可以看到，向 map 中删除 key，最终调用的是 mapdelete 函数

删除的逻辑相对比较简单，大多函数在赋值操作中已经用到过，核心还是找到 key 的具体位置。寻找过程都是类似的，在 bucket 中挨个 cell 寻找。找到对应位置后，对 key 或者 value 进行“清零”操作，将 count 值减 1，将对应位置的 tophash 值置成 Empty

再来说触发 map 扩容的时机：在向 map 插入新 key 的时候，会进行条件检测，符合下面这 2 个条件，就会触发扩容：

1、装载因子超过阈值

源码里定义的阈值是 6.5 (loadFactorNum/loadFactorDen)，是经过测试后取出的一个比较合理的因子

我们知道，每个 bucket 有 8 个空位，在没有溢出，且所有的桶都装满了的情况下，装载因子算出来的结果是 8。因此当装载因子超过 6.5 时，表明很多 bucket 都快要装满了，查找效率和插入效率都变低了。在这个时候进行扩容是有必要的。

对于条件 1，元素太多，而 bucket 数量太少，很简单：将 B 加 1，bucket 最大数量( 2^B )直接变成原来 bucket 数量的 2 倍。于是，就有新老 bucket 了。注意，这时候元素都在老 bucket 里，还没迁移到新的 bucket 来。新 bucket 只是最大数量变为原来最大数量的 2 倍( 2^B * 2 ) 。

2、overflow 的 bucket 数量过多

在装载因子比较小的情况下，这时候 map 的查找和插入效率也很低，而第 1 点识别不出来这种情况。表面现象就是计算装载因子的分子比较小，即 map 里元素总数少，但是 bucket 数量多（真实分配的 bucket 数量多，包括大量的 overflow bucket）

不难想像造成这种情况的原因：不停地插入、删除元素。先插入很多元素，导致创建了很多 bucket，但是装载因子达不到第 1 点的临界值，未触发扩容来缓解这种情况。之后，删除元素降低元素总数量，再插入很多元素，导致创建很多的 overflow bucket，但就是不会触发第 1 点的规定，你能拿我怎么办？overflow bucket 数量太多，导致 key 会很分散，查找插入效率低得吓人，因此出台第 2 点规定。这就像是一座空城，房子很多，但是住户很少，都分散了，找起人来很困难

对于条件 2，其实元素没那么多，但是 overflow bucket 数特别多，说明很多 bucket 都没装满。解决办法就是开辟一个新 bucket 空间，将老 bucket 中的元素移动到新 bucket，使得同一个 bucket 中的 key 排列地更紧密。这样，原来，在 overflow bucket 中的 key 可以移动到 bucket 中来。结果是节省空间，提高 bucket 利用率，map 的查找和插入效率自然就会提升。

由于 map 扩容需要将原有的 key/value 重新搬迁到新的内存地址，如果有大量的 key/value 需要搬迁，会非常影响性能。因此 Go map 的扩容采取了一种称为“渐进式”的方式，原有的 key 并不会一次性搬迁完毕，每次最多只会搬迁 2 个 bucket。

上面说的 hashGrow() 函数实际上并没有真正地“搬迁”，它只是分配好了新的 buckets，并将老的 buckets 挂到了 oldbuckets 字段上。真正搬迁 buckets 的动作在 growWork() 函数中，而调用 growWork() 函数的动作是在 mapassign 和 mapdelete 函数中。也就是插入或修改、删除 key 的时候，都会尝试进行搬迁 buckets 的工作。先检查 oldbuckets 是否搬迁完毕，具体来说就是检查 oldbuckets 是否为 nil。

如果未迁移完毕，赋值/删除的时候，扩容完毕后（预分配内存），不会马上就进行迁移。而是采取 增量扩容 的方式，当有访问到具体 bukcet 时，才会逐渐的进行迁移（将 oldbucket 迁移到 bucket）

nevacuate 标识的是当前的进度，如果都搬迁完，应该和2^B的长度是一样的

在evacuate 方法实现是把这个位置对应的bucket，以及其冲突链上的数据都转移到新的buckets上。

转移的判断直接通过tophash 就可以，判断tophash中第一个hash值即可

遍历的过程，就是按顺序遍历 bucket，同时按顺序遍历 bucket 中的 key。

map遍历是无序的，如果想实现有序遍历，可以先对key进行排序

为什么遍历 map 是无序的？

如果发生过迁移，key 的位置发生了重大的变化，有些 key 飞上高枝，有些 key 则原地不动。这样，遍历 map 的结果就不可能按原来的顺序了。

如果就一个写死的 map，不会向 map 进行插入删除的操作，按理说每次遍历这样的 map 都会返回一个固定顺序的 key/value 序列吧。但是 Go 杜绝了这种做法，因为这样会给新手程序员带来误解，以为这是一定会发生的事情，在某些情况下，可能会酿成大错。

Go 做得更绝，当我们在遍历 map 时，并不是固定地从 0 号 bucket 开始遍历，每次都是从一个**随机值序号的 bucket 开始遍历，并且是从这个 bucket 的一个 随机序号的 cell **开始遍历。这样，即使你是一个写死的 map，仅仅只是遍历它，也不太可能会返回一个固定序列的 key/value 对了。

Kubernetes 面试题干货集锦

简述 etcd 及其特点？

答：etcd 是 CoreOS 团队发起的开源项目，是一个管理配置信息和服务发现

（service discovery）的项目，它的目标是构建一个高可用的分布式键值（key-value）

数据库，基于 Go 语言实现。

特点：

l 简单：支持 REST 风格的 HTTP+JSON API

l 安全：支持 HTTPS 方式的访问

l 快速：支持并发 1k/s 的写操作

l 可靠：支持分布式结构，基于 Raft 的一致性算法，Raft 是一套通过选举主节点来

实现分布式系统一致性的算法。

简述 etcd 适应的场景？

答：etcd 基于其优秀的特点，可广泛的应用于以下场景：

l 服务发现(Service Discovery)：服务发现主要解决在同一个分布式集群中的进程

或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解

集群中是否有进程在监听 udp 或 tcp 端口，并且通过名字就可以查找和连接。

一些配置信息放到 etcd 上进行集中管理。

l 负载均衡：在分布式系统中，为了保证服务的高可用以及数据的一致性，通常都

会把数据和服务部署多份，以此达到对等服务，即使其中的某一个服务失效了，

也不影响使用。etcd 本身分布式架构存储的信息访问支持负载均衡。etcd 集群化

以后，每个 etcd 的核心节点都可以处理用户的请求。所以，把数据量小但是访问

频繁的消息数据直接存储到 etcd 中也可以实现负载均衡的效果。

通过注册与异步通知机制，实现分布式环境下不同系统之间的通知与协调，从而

对数据变更做到实时处理。

l 分布式锁：因为 etcd 使用 Raft 算法保持了数据的强一致性，某次操作存储到集

群中的值必然是全局一致的，所以很容易实现分布式锁。锁服务有两种使用方式，

一是保持独占，二是控制时序。

l 集群监控与 Leader 竞选：通过 etcd 来进行监控实现起来非常简单并且实时性强。

简述 Kubernetes 和 Docker 的关系？

答：Docker 提供容器的生命周期管理和，Docker 镜像构建运行时容器。它的主要优

点是将将软件/应用程序运行所需的设置和依赖项打包到一个容器中，从而实现了可移

植性等优点。

Kubernetes 用于关联和编排在多个主机上运行的容器。

简述 Kubernetes 中什么是 Minikube、Kubectl、Kubelet？

答：Minikube 是一种可以在本地轻松运行一个单节点 Kubernetes 群集的工具。

Kubectl 是一个命令行工具，可以使用该工具控制 Kubernetes 集群管理器，如检查

群集资源，创建、删除和更新组件，查看应用程序。

Kubelet 是一个代理服务，它在每个节点上运行，并使从服务器与主服务器通信。

简述 Kubernetes 常见的部署方式？

答：常见的 Kubernetes 部署方式有：

l kubeadm：也是推荐的一种部署方式；

l 二进制：

l minikube：在本地轻松运行一个单节点 Kubernetes 群集的工具。

简述 Kubernetes 如何实现集群管理？

答：在集群管理方面，Kubernetes 将集群中的机器划分为一个 Master 节点和一群工

作节点 Node。其中，在 Master 节点运行着集群管理相关的一组进程 kube

apiserver、kube-controller-manager 和 kube-scheduler，这些进程实现了整个集

群的资源管理、Pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且

都是全自动完成的。

简述 Kubernetes 相关基础概念？

答：

l master：k8s 集群的管理节点，负责管理集群，提供集群的资源数据访问入口。

拥有 Etcd 存储服务（可选），运行 Api Server 进程，Controller Manager 服务

进程及 Scheduler 服务进程。

l node（worker）：Node（worker）是 Kubernetes 集群架构中运行 Pod 的服

务节点，是 Kubernetes 集群操作的单元，用来承载被分配 Pod 的运行，是 Pod

运行的宿主机。运行 docker eninge 服务，守护进程 kunelet 及负载均衡器

kube-proxy。

l pod：运行于 Node 节点上，若干相关容器的组合。Pod 内包含的容器运行在同

一宿主机上，使用相同的网络命名空间、IP 地址和端口，能够通过 localhost 进行通信。Pod 是 Kurbernetes 进行创建、调度和管理的最小单位，它提供了比容

器更高层次的抽象，使得部署和管理更加灵活。一个 Pod 可以包含一个容器或者

多个相关容器。

l label：Kubernetes 中的 Label 实质是一系列的 Key/Value 键值对，其中 key 与

value 可自定义。Label 可以附加到各种资源对象上，如 Node、Pod、Service、

RC 等。一个资源对象可以定义任意数量的 Label，同一个 Label 也可以被添加到

任意数量的资源对象上去。Kubernetes 通过 Label Selector（标签选择器）查询

和筛选资源对象。

l Replication Controller：Replication Controller 用来管理 Pod 的副本，保证集

群中存在指定数量的 Pod 副本。集群中副本的数量大于指定数量，则会停止指定

数量之外的多余容器数量。反之，则会启动少于指定数量个数的容器，保证数量

不变。Replication Controller 是实现弹性伸缩、动态扩容和滚动升级的核心。

l Deployment：Deployment 在内部使用了 RS 来实现目的，Deployment 相当

于 RC 的一次升级，其最大的特色为可以随时获知当前 Pod 的部署进度。

l HPA（Horizontal Pod Autoscaler）：Pod 的横向自动扩容，也是 Kubernetes

的一种资源，通过追踪分析 RC 控制的所有 Pod 目标的负载变化情况，来确定是

否需要针对性的调整 Pod 副本数量。

l Service：Service 定义了 Pod 的逻辑集合和访问该集合的策略，是真实服务的抽

象。Service 提供了一个统一的服务访问入口以及服务代理和发现机制，关联多个

相同 Label 的 Pod，用户不需要了解后台 Pod 是如何运行。

l Volume：Volume 是 Pod 中能够被多个容器访问的共享目录，Kubernetes 中的

Volume 是定义在 Pod 上，可以被一个或多个 Pod 中的容器挂载到某个目录下。l Namespace：Namespace 用于实现多租户的资源隔离，可将集群内部的资源对

象分配到不同的 Namespace 中，形成逻辑上的不同项目、小组或用户组，便于

不同的 Namespace 在共享使用整个集群的资源的同时还能被分别管理。

简述 Kubernetes RC 的机制？

答：Replication Controller 用来管理 Pod 的副本，保证集群中存在指定数量的 Pod

副本。当定义了 RC 并提交至 Kubernetes 集群中之后，Master 节点上的 Controller

Manager 组件获悉，并同时巡检系统中当前存活的目标 Pod，并确保目标 Pod 实例的数量刚好等于此 RC 的期望值，若存在过多的 Pod 副本在运行，系统会停止一些

Pod，反之则自动创建一些 Pod。

简述 Kubernetes 中 Pod 的重启策略？

答：Pod 重启策略（RestartPolicy）应用于 Pod 内的所有容器，并且仅在 Pod 所处

的 Node 上由 kubelet 进行判断和重启操作。当某个容器异常退出或者 健康 检查失败

时，kubelet 将根据 RestartPolicy 的设置来进行相应操作。

Pod 的重启策略包括 Always、OnFailure 和 Never，默认值为 Always。

l Always：当容器失效时，由 kubelet 自动重启该容器；

l OnFailure：当容器终止运行且退出码不为 0 时，由 kubelet 自动重启该容器；

l Never：不论容器运行状态如何，kubelet 都不会重启该容器。

同时 Pod 的重启策略与控制方式关联，当前可用于管理 Pod 的控制器包括

ReplicationController、Job、DaemonSet 及直接管理 kubelet 管理（静态 Pod）。

不同控制器的重启策略限制如下：

l RC 和 DaemonSet：必须设置为 Always，需要保证该容器持续运行；

l Job：OnFailure 或 Never，确保容器执行完成后不再重启；

l kubelet：在 Pod 失效时重启，不论将 RestartPolicy 设置为何值，也不会对 Pod

进行 健康 检查。

简述 Kubernetes Pod 的 LivenessProbe 探针的常见方式？

答：kubelet 定期执行 LivenessProbe 探针来诊断容器的 健康 状态，通常有以下三种

方式：

l ExecAction：在容器内执行一个命令，若返回码为 0，则表明容器 健康 。

l TCPSocketAction：通过容器的 IP 地址和端口号执行 TCP 检查，若能建立 TCP

连接，则表明容器 健康 。

l HTTPGetAction：通过容器的 IP 地址、端口号及路径调用 HTTP Get 方法，若响

应的状态码大于等于 200 且小于 400，则表明容器 健康 。

. 简述 Kubernetes Pod 的常见调度方式？

答：Kubernetes 中，Pod 通常是容器的载体，主要有如下常见调度方式：

l Deployment 或 RC：该调度策略主要功能就是自动部署一个容器应用的多份副本，

以及持续监控副本的数量，在集群内始终维持用户指定的副本数量。

l NodeSelector：定向调度，当需要手动指定将 Pod 调度到特定 Node 上，可以

通过 Node 的标签（Label）和 Pod 的 nodeSelector 属性相匹配。

l NodeAffinity 亲和性调度：亲和性调度机制极大的扩展了 Pod 的调度能力，目前

有两种节点亲和力表达：

l requiredDuringSchedulingIgnoredDuringExecution：硬规则，必须满足指定

的规则，调度器才可以调度 Pod 至 Node 上（类似 nodeSelector，语法不同）。

l preferredDuringSchedulingIgnoredDuringExecution：软规则，优先调度至满

足的 Node 的节点，但不强求，多个优先级规则还可以设置权重值。

l Taints 和 Tolerations（污点和容忍）：

l Taint：使 Node 拒绝特定 Pod 运行；

l Toleration：为 Pod 的属性，表示 Pod 能容忍（运行）标注了 Taint 的 Node。

简述 Kubernetes DaemonSet 类型的资源特性？

答：DaemonSet 资源对象会在每个 Kubernetes 集群中的节点上运行，并且每个节

点只能运行一个 pod，这是它和 deployment 资源对象的最大也是唯一的区别。因此，

在定义 yaml 文件中，不支持定义 replicas。

它的一般使用场景如下：

l 在去做每个节点的日志收集工作。

l 监控每个节点的的运行状态。

简述 Kubernetes Service 分发后端的策略？

答：Service 负载分发的策略有：RoundRobin 和 SessionAffinity

l RoundRobin：默认为轮询模式，即轮询将请求转发到后端的各个 Pod 上。

l SessionAffinity：基于客户端 IP 地址进行会话保持的模式，即第 1 次将某个客户

端发起的请求转发到后端的某个 Pod 上，之后从相同的客户端发起的请求都将被

转发到后端相同的 Pod 上。

简述 Kubernetes Scheduler 使用哪两种算法将 Pod 绑定到 worker 节点？

答：Kubernetes Scheduler 根据如下两种调度算法将 Pod 绑定到最合适的工作节点：

l 预选（Predicates）：输入是所有节点，输出是满足预选条件的节点。kube

scheduler 根据预选策略过滤掉不满足策略的 Nodes。如果某节点的资源不足或

者不满足预选策略的条件则无法通过预选。如“Node 的 label 必须与 Pod 的

Selector 一致”。

l 优选（Priorities）：输入是预选阶段筛选出的节点，优选会根据优先策略为通过

预选的 Nodes 进行打分排名，选择得分最高的 Node。例如，资源越富裕、负载

越小的 Node 可能具有越高的排名。

简述 Kubernetes Secret 有哪些使用方式？

答：创建完 secret 之后，可通过如下三种方式使用：

l 在创建 Pod 时，通过为 Pod 指定 Service Account 来自动使用该 Secret。

l 通过挂载该 Secret 到 Pod 来使用它。

l 在 Docker 镜像下载时使用，通过指定 Pod 的 spc.ImagePullSecrets 来引用它。

简述 Kubernetes 网络策略原理？

答：Network Policy 的工作原理主要为：policy controller 需要实现一个 API

Listener，监听用户设置的 Network Policy 定义，并将网络访问规则通过各 Node 的

Agent 进行实际设置（Agent 则需要通过 CNI 网络插件实现）。

简述 Kubernetes 集群联邦？

答：Kubernetes 集群联邦可以将多个 Kubernetes 集群作为一个集群进行管理。因此，

可以在一个数据中心/云中创建多个 Kubernetes 集群，并使用集群联邦在一个地方控

制/管理所有集群。

简述 Kubernetes 如何进行优雅的节点关机维护？

答：由于 Kubernetes 节点运行大量 Pod，因此在进行关机维护之前，建议先使用

kubectl drain 将该节点的 Pod 进行驱逐，然后进行关机维护。

. 简述 Kubernetes 中，如何使用 EFK 实现日志的统一管理？

答：在 Kubernetes 集群环境中，通常一个完整的应用或服务涉及组件过多，建议对

日志系统进行集中化管理，通常采用 EFK 实现。

EFK 是 Elasticsearch、Fluentd 和 Kibana 的组合，其各组件功能如下：

l Elasticsearch：是一个搜索引擎，负责存储日志并提供查询接口；

l Fluentd：负责从 Kubernetes 搜集日志，每个 node 节点上面的 fluentd 监控并

收集该节点上面的系统日志，并将处理过后的日志信息发送给 Elasticsearch；

l Kibana：提供了一个 Web GUI，用户可以浏览和搜索存储在 Elasticsearch 中的

日志。通过在每台 node 上部署一个以 DaemonSet 方式运行的 fluentd 来收集每台 node

上的日志。Fluentd 将 docker 日志目录/var/lib/docker/containers 和/var/log 目录

挂载到 Pod 中，然后 Pod 会在 node 节点的/var/log/pods 目录中创建新的目录，可

以区别不同的容器日志输出，该目录下有一个日志文件链接到

/var/lib/docker/contianers 目录下的容器日志输出。

「第三十七期」小米 golang服务端开发 校招 一面二面

由于没有golang基础，又没什么项目经验，所以上来先代码题：

……后面记不清了

面试官很和蔼，有的问题没回答出来，也一一给我进行了讲解。一度以为自己凉了。过了一个星期后联系我进行二面。

面试官很年轻，大概二十七八，感觉非常亲切。

把我的所有项目都问了一遍，针对一些点对我进行了提问，指出了项目的不足，我虚心受教。

他在找题，顺便问了问我有没有什么疑问？（问面试官旁边的同事们在讨论什么。感觉公司的氛围很活跃，我很喜欢。我讨厌死气沉沉的环境。他表示认同。）

调试了两次，ac。

两次的面试官都非常nice，虽然有些紧张，但是体验很好，聊的非常投机。

go语言多线程面试题的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于golang 多线程使用、go语言多线程面试题的信息别忘了在本站进行查找喔。