Q：context作用，原理，超時(shí)控制

A: golang context的理解，context主要用于父子任務(wù)之間的同步取消信號(hào)，本質(zhì)上是一種協(xié)程調(diào)度的方式。另外在使用context時(shí)有兩點(diǎn)值得注意：上游任務(wù)僅僅使用context通知下游任務(wù)不再需要，但不會(huì)直接干涉和中斷下游任務(wù)的執(zhí)行，由下游任務(wù)自行決定后續(xù)的處理操作，也就是說(shuō)context的取消操作是無(wú)侵入的；context是線程安全的，因?yàn)閏ontext本身是不可變的（immutable），因此可以放心地在多個(gè)協(xié)程中傳遞使用。

Q:切片和數(shù)組區(qū)別

A: 數(shù)組是內(nèi)置(build-in)類型,是一組同類型數(shù)據(jù)的集合，它是值類型，通過(guò)從0開(kāi)始的下標(biāo)索引訪問(wèn)元素值。在初始化后長(zhǎng)度是固定的，無(wú)法修改其長(zhǎng)度。當(dāng)作為方法的參數(shù)傳入時(shí)將復(fù)制一份數(shù)組而不是引用同一指針。數(shù)組的長(zhǎng)度也是其類型的一部分，通過(guò)內(nèi)置函數(shù)len(array)獲取其長(zhǎng)度。
注意：和C中的數(shù)組相比，又是有一些不同的
1. Go中的數(shù)組是值類型，換句話說(shuō)，如果你將一個(gè)數(shù)組賦值給另外一個(gè)數(shù)組，那么，實(shí)際上就是將整個(gè)數(shù)組拷貝一份
2. 如果Go中的數(shù)組作為函數(shù)的參數(shù)，那么實(shí)際傳遞的參數(shù)是一份數(shù)組的拷貝，而不是數(shù)組的指針。這個(gè)和C要區(qū)分開(kāi)。因此，在Go中如果將數(shù)組作為函數(shù)的參數(shù)傳遞的話，那效率就肯定沒(méi)有傳遞指針高了。
3. array的長(zhǎng)度也是Type的一部分，這樣就說(shuō)明[10]int和[20]int是不一樣的。array的結(jié)構(gòu)用圖示表示是這樣的：

?[ len|...]?

len表示數(shù)組的長(zhǎng)度，后面的int儲(chǔ)存的是實(shí)際數(shù)據(jù)?

與數(shù)組相比切片的長(zhǎng)度是不固定的，可以追加元素，在追加時(shí)可能使切片的容量增大。切片中有兩個(gè)概念：一是len長(zhǎng)度，二是cap容量，長(zhǎng)度是指已經(jīng)被賦過(guò)值的最大下標(biāo)+1，可通過(guò)內(nèi)置函數(shù)len()獲得。容量是指切片目前可容納的最多元素個(gè)數(shù)，可通過(guò)內(nèi)置函數(shù)cap()獲得。切片是引用類型，因此在當(dāng)傳遞切片時(shí)將引用同一指針，修改值將會(huì)影響其他的對(duì)象。?

切片可以通過(guò)數(shù)組來(lái)初始化，也可以通過(guò)內(nèi)置函數(shù)make()初始化 .初始化時(shí)len=cap,在追加元素時(shí)如果容量cap不足時(shí)將按len的2倍擴(kuò)容。

Q：channel關(guān)閉阻塞問(wèn)題，goroutine如何調(diào)度，gopark是怎么回事？

channel關(guān)閉阻塞問(wèn)題：https://blog.csdn.net/sgsgy5/article/details/82054902

goroutine如何調(diào)度參考：https://www.cnblogs.com/wdliu/p/9272220.html

https://jingwei.link/2019/05/26/golang-routine-scheduler.html

gopark參考：https://blog.csdn.net/u010853261/article/details/85887948

PMG模型描述，誰(shuí)創(chuàng)建的PMG,runtime是怎么個(gè)東西，怎么啟動(dòng)第一個(gè)goroutine

A: golang CPS并發(fā)模型和PMG模型的理解。

參考：https://www.jianshu.com/p/36e246c6153d

Q:Golang 探索對(duì)Goroutine的控制方法

A:參考：https://www.cnblogs.com/tr3e/p/7995689.html

Q：go逃逸分析怎么回事，內(nèi)存什么時(shí)候棧分配什么時(shí)候堆分配

A:?為什么要逃逸分析

C/C++中動(dòng)態(tài)分配的內(nèi)存需要我們手動(dòng)釋放，導(dǎo)致猿們平時(shí)在寫(xiě)程序時(shí)，如履薄冰。這樣做有他的好處：程序員可以完全掌控內(nèi)存。但是缺點(diǎn)也是很多的：經(jīng)常出現(xiàn)忘記釋放內(nèi)存，導(dǎo)致內(nèi)存泄露。所以，很多現(xiàn)代語(yǔ)言都加上了垃圾回收機(jī)制。
Go的垃圾回收，讓堆和棧對(duì)程序員保持透明。真正解放了程序員的雙手，讓他們可以專注于業(yè)務(wù)，“高效”地完成代碼編寫(xiě)。把那些內(nèi)存管理的復(fù)雜機(jī)制交給編譯器，而程序員可以去享受生活。
逃逸分析這種“騷操作”把變量合理地分配到它該去的地方，“找準(zhǔn)自己的位置”。即使你是用new申請(qǐng)到的內(nèi)存，如果我發(fā)現(xiàn)你竟然在退出函數(shù)后沒(méi)有用了，那么就把你丟到棧上，畢竟棧上的內(nèi)存分配比堆上快很多；反之，即使你表面上只是一個(gè)普通的變量，但是經(jīng)過(guò)逃逸分析后發(fā)現(xiàn)在退出函數(shù)之后還有其他地方在引用，那我就把你分配到堆上。
如果變量都分配到堆上，堆不像棧可以自動(dòng)清理。它會(huì)引起Go頻繁地進(jìn)行垃圾回收，而垃圾回收會(huì)占用比較大的系統(tǒng)開(kāi)銷（占用CPU容量的25%）。
堆適合不可預(yù)知大小的內(nèi)存分配。但是為此付出的代價(jià)是分配速度較慢，而且會(huì)形成內(nèi)存碎片。棧內(nèi)存分配則會(huì)非常快。棧分配內(nèi)存只需要兩個(gè)CPU指令：“PUSH”和“RELEASE”，分配和釋放；而堆分配內(nèi)存首先需要去找到一塊大小合適的內(nèi)存塊，之后要通過(guò)垃圾回收才能釋放。
通過(guò)逃逸分析，可以盡量把那些不需要分配到堆上的變量直接分配到棧上，堆上的變量少了，會(huì)減輕分配堆內(nèi)存的開(kāi)銷，同時(shí)也會(huì)減少gc的壓力，提高程序的運(yùn)行速度。

逃逸分析如何完成

Go逃逸分析最基本的原則是：如果一個(gè)函數(shù)返回對(duì)一個(gè)變量的引用，那么它就會(huì)發(fā)生逃逸。
簡(jiǎn)單來(lái)說(shuō)，編譯器會(huì)分析代碼的特征和代碼生命周期，Go中的變量只有在編譯器可以證明在函數(shù)返回后不會(huì)再被引用的，才分配到棧上，其他情況下都是分配到堆上。
Go語(yǔ)言里沒(méi)有一個(gè)關(guān)鍵字或者函數(shù)可以直接讓變量被編譯器分配到堆上，相反，編譯器通過(guò)分析代碼來(lái)決定將變量分配到何處。
對(duì)一個(gè)變量取地址，可能會(huì)被分配到堆上。但是編譯器進(jìn)行逃逸分析后，如果考察到在函數(shù)返回后，此變量不會(huì)被引用，那么還是會(huì)被分配到棧上。
簡(jiǎn)單來(lái)說(shuō)，編譯器會(huì)根據(jù)變量是否被外部引用來(lái)決定是否逃逸：
1）如果函數(shù)外部沒(méi)有引用，則優(yōu)先放到棧中；
2） 如果函數(shù)外部存在引用，則必定放到堆中；
針對(duì)第一條，可能放到堆上的情形：定義了一個(gè)很大的數(shù)組，需要申請(qǐng)的內(nèi)存過(guò)大，超過(guò)了棧的存儲(chǔ)能力。

Q：sync.Map實(shí)現(xiàn)原理，適用的場(chǎng)景

A:go 1.9 官方提供sync.Map 來(lái)優(yōu)化線程安全的并發(fā)讀寫(xiě)的map。該實(shí)現(xiàn)也是基于內(nèi)置map關(guān)鍵字來(lái)實(shí)現(xiàn)的。

這個(gè)實(shí)現(xiàn)類似于一個(gè)線程安全的 map[interface{}]interface{} . 這個(gè)map的優(yōu)化主要適用了以下場(chǎng)景：

（1）給定key的鍵值對(duì)只寫(xiě)了一次，但是讀了很多次，比如在只增長(zhǎng)的緩存中；

（2）當(dāng)多個(gè)goroutine讀取、寫(xiě)入和覆蓋的key值不相交時(shí)。

參考：https://blog.csdn.net/u010853261/article/details/103848666

Q：go語(yǔ)言有什么優(yōu)點(diǎn)和缺點(diǎn)

A: 優(yōu)勢(shì)：容易學(xué)習(xí)，生產(chǎn)力，并發(fā)，動(dòng)態(tài)語(yǔ)法。劣勢(shì)：包管理，錯(cuò)誤處理，缺乏框架。

Q：Go框架用過(guò)哪些，有看源碼嗎

A: 優(yōu)勢(shì)：beego，go-micro，gin等

Q：Go GC算法，三色標(biāo)記法描述

A: 參考：https://www.jianshu.com/p/12544c0ad5c1

Q：Go內(nèi)存模型(tcmalloc)

A：tcmalloc是線程緩存的malloc，實(shí)現(xiàn)了高效的多線程內(nèi)存管理，用于替代系統(tǒng)的內(nèi)存分配相關(guān)的函數(shù)

參考：https://blog.csdn.net/zhghost/article/details/104096921

Q：行列都是有序的二維數(shù)組，查找k是否存在,時(shí)間復(fù)雜度

1 3 5 7 9

3 5 7 9 11

4 6 8 10 12

A：二分查找：O(log2（max(m,n)))

Q：有序數(shù)組，有2N+1個(gè)數(shù)，其中N個(gè)數(shù)成對(duì)出現(xiàn)，僅1個(gè)數(shù)單獨(dú)出現(xiàn)，找出那個(gè)單獨(dú)出現(xiàn)的數(shù).,時(shí)間復(fù)雜度

1，1，2，2，3，4，4，5，5，6，6，7，7

答案為3

A: O(log2（2N))二分查找，查找中間位置的數(shù)相等值是在左邊還是右邊？左邊則再左子數(shù)組繼續(xù)查找，右邊則在右子數(shù)組繼續(xù)查找。

Q：100億個(gè)數(shù)求top100,時(shí)間復(fù)雜度

A:分組查找或bitmap，參考：https://blog.csdn.net/zyq522376829/article/details/47686867

Q：100億個(gè)數(shù)和100億個(gè)數(shù)求交集，時(shí)間復(fù)雜度

A: 全排列問(wèn)題，自己找去

2、linux，操作系統(tǒng)

Q：Select/epoll，IO多路復(fù)用，底層數(shù)據(jù)結(jié)構(gòu)，epoll的幾個(gè)函數(shù)，兩種模式

A: Select/epoll 問(wèn)題，網(wǎng)上很多

Q：搶占式調(diào)度是什么回事

A: 進(jìn)程優(yōu)先級(jí)和時(shí)間分片等方面理解

參考：https://tiancaiamao.gitbooks.io/go-internals/content/zh/05.5.html

https://gocn.vip/topics/9884?locale=zh-CN

Q：用戶態(tài)和內(nèi)核態(tài)

A: 系統(tǒng)態(tài)(內(nèi)核態(tài))，操作系統(tǒng)在系統(tǒng)態(tài)運(yùn)行——運(yùn)行操作系統(tǒng)程序

用戶態(tài)(也稱為目態(tài))，應(yīng)用程序只能在用戶態(tài)運(yùn)行——運(yùn)行用戶程序

Q：B+樹(shù)和B樹(shù)區(qū)別，優(yōu)缺點(diǎn)

A：B樹(shù)每個(gè)節(jié)點(diǎn)都存儲(chǔ)key和data，所有節(jié)點(diǎn)組成這棵樹(shù)，并且葉子節(jié)點(diǎn)指針為null。只有葉子節(jié)點(diǎn)存儲(chǔ)data，葉子節(jié)點(diǎn)包含了這棵樹(shù)的所有鍵值，葉子節(jié)點(diǎn)不存儲(chǔ)指針，順序訪問(wèn)指針，也就是每個(gè)葉子節(jié)點(diǎn)增加一個(gè)指向相鄰葉子節(jié)點(diǎn)的指針。

Q：B樹(shù)和二叉查找樹(shù)或者紅黑色區(qū)別

A：基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)問(wèn)題

Q：聚簇索引什么特點(diǎn)，為什么這樣，順序查詢的實(shí)現(xiàn)，回表查詢，聯(lián)合索引特性

A：

• 聚簇索引：將數(shù)據(jù)存儲(chǔ)與索引放到了一塊，找到索引也就找到了數(shù)據(jù)
• 非聚簇索引：將數(shù)據(jù)存儲(chǔ)于索引分開(kāi)結(jié)構(gòu)，索引結(jié)構(gòu)的葉子節(jié)點(diǎn)指向了數(shù)據(jù)的對(duì)應(yīng)行，myisam通過(guò)key_buffer把索引先緩存到內(nèi)存中，當(dāng)需要訪問(wèn)數(shù)據(jù)時(shí)（通過(guò)索引訪問(wèn)數(shù)據(jù)），在內(nèi)存中直接搜索索引，然后通過(guò)索引找到磁盤相應(yīng)數(shù)據(jù)，這也就是為什么索引不在key buffer命中時(shí)，速度慢的原因

Q：大表分頁(yè)查詢,10億行數(shù)據(jù)，查找第N頁(yè)數(shù)據(jù)，怎么優(yōu)化

A: 根據(jù)查詢的頁(yè)數(shù)和查詢的記錄數(shù)可以算出查詢的id的范圍，可以使用 id between and 來(lái)查詢。

Q：悲觀鎖和樂(lè)觀鎖，mysql相關(guān)鎖說(shuō)一下

A:

樂(lè)觀鎖（ Optimistic Locking）：對(duì)加鎖持有一種樂(lè)觀的態(tài)度，即先進(jìn)行業(yè)務(wù)操作，不到最后一步不進(jìn)行加鎖，"樂(lè)觀"的認(rèn)為加鎖一定會(huì)成功的，在最后一步更新數(shù)據(jù)的時(shí)候再進(jìn)行加鎖。

悲觀鎖（Pessimistic Lock）：悲觀鎖對(duì)數(shù)據(jù)加鎖持有一種悲觀的態(tài)度。因此，在整個(gè)數(shù)據(jù)處理過(guò)程中，將數(shù)據(jù)處于鎖定狀態(tài)。悲觀鎖的實(shí)現(xiàn)，往往依靠數(shù)據(jù)庫(kù)提供的鎖機(jī)制（也只有數(shù)據(jù)庫(kù)層提供的鎖機(jī)制才能真正保證數(shù)據(jù)訪問(wèn)的排他性，否則，即使在本系統(tǒng)中實(shí)現(xiàn)了加鎖機(jī)制，也無(wú)法保證外部系統(tǒng)不會(huì)修改數(shù)據(jù)）。

Q：如何分庫(kù)分表

A:

1）垂直分表

也就是“大表拆小表”，基于列字段進(jìn)行的。一般是表中的字段較多，將不常用的， 數(shù)據(jù)較大，長(zhǎng)度較長(zhǎng)（比如text類型字段）的拆分到“擴(kuò)展表“。一般是針對(duì)那種幾百列的大表，也避免查詢時(shí)，數(shù)據(jù)量太大造成的“跨頁(yè)”問(wèn)題。

2）垂直分庫(kù)

垂直分庫(kù)針對(duì)的是一個(gè)系統(tǒng)中的不同業(yè)務(wù)進(jìn)行拆分，比如用戶User一個(gè)庫(kù)，商品Producet一個(gè)庫(kù)，訂單Order一個(gè)庫(kù)。切分后，要放在多個(gè)服務(wù)器上，提高性能。

3）水平分庫(kù)分表

將單張表的數(shù)據(jù)切分到多個(gè)服務(wù)器上去，每個(gè)服務(wù)器具有相應(yīng)的庫(kù)與表，只是表中數(shù)據(jù)集合不同。水平分庫(kù)分表能夠有效的緩解單機(jī)和單庫(kù)的性能瓶頸和壓力，突破IO、連接數(shù)、硬件資源等的瓶頸。

4、redis

Q：幾種數(shù)據(jù)結(jié)構(gòu)(list,set,zset,geohash,bitmap)實(shí)現(xiàn)原理

A:參考：https://www.cnblogs.com/MouseDong/p/11134039.html

Q：pipline用來(lái)干嘛

A：pipeline的作用是將一批命令進(jìn)行打包，然后發(fā)送給服務(wù)器，服務(wù)器執(zhí)行完按順序打包返回。

Q：事務(wù)

A: redis事務(wù)就是一次性、順序性、排他性的執(zhí)行一個(gè)隊(duì)列中的一系列命令。　

Q：備份(aof/rdb)原理，哪些參數(shù)可調(diào)

A:RDB是根據(jù)指定的規(guī)則定時(shí)將內(nèi)存中的數(shù)據(jù)備份到硬盤上，AOF是在每次執(zhí)行命令后命令本身記錄下來(lái)，所以RDB的備份文件是一個(gè)二進(jìn)制文件，而AOF的備份文件是一個(gè)文本文件。

after 900 sec (15 min) if at least 1 key changed 900秒（15分鐘）內(nèi)至少1個(gè)key值改變（則進(jìn)行數(shù)據(jù)庫(kù)保存--持久化）after 300 sec (5 min) if at least 10 keys changed 300秒（5分鐘）內(nèi)至少10個(gè)key值改變（則進(jìn)行數(shù)據(jù)庫(kù)保存--持久化）after 60 sec if at least 10000 keys changed 60秒（1分鐘）內(nèi)至少10000個(gè)key值改變（則進(jìn)行數(shù)據(jù)庫(kù)保存--持久化） save 900 1 save 300 10 save 60 10000

AOF有3種方式將操作命令存入AOF文件

1. appendfsync no 不保存

只執(zhí)行WHRITE操作，SAVE操作會(huì)被略過(guò)，只有在Redis被關(guān)閉、AOF功能被關(guān)閉、系統(tǒng)的寫(xiě)緩存被刷新（如緩存已被寫(xiě)滿）這三種情況，SAVE操作會(huì)被執(zhí)行，但是這三種情況都會(huì)引起Redis主進(jìn)程阻塞

2. appendfsync everysec 每秒鐘保存一次

這種模式中，SAVE原則上每隔一秒鐘就會(huì)執(zhí)行一次，具體的執(zhí)行周期和文件寫(xiě)入、保存時(shí)，Redis所處的狀態(tài)有關(guān)，此模式下SAVE操作由后臺(tái)子線程調(diào)用，不會(huì)引起服務(wù)器主進(jìn)程的阻塞

3. appendfsync always 每執(zhí)行一個(gè)命令保存一次
在這種模式下，每執(zhí)行一個(gè)命令，WRITE和SAVE都會(huì)被執(zhí)行，且SAVE操作會(huì)阻塞主進(jìn)程

Q：網(wǎng)絡(luò)模型，為什么單線程能hold住10萬(wàn)QPS

A:網(wǎng)絡(luò)模型，I/O復(fù)用，Reactor 設(shè)計(jì)模式，參考：https://blog.csdn.net/ligupeng7929/article/details/90742578。

Q：熱點(diǎn)key怎么處理

A：1、熱key加載到系統(tǒng)內(nèi)存中，直接從系統(tǒng)內(nèi)存中取，而不走到redis層。

2、redis集群，熱點(diǎn)備份分布到集群中，避免單臺(tái)redis集中訪問(wèn)。

Q：一致性hash解決什么問(wèn)題

A:redis集群和負(fù)載均衡

Q：redis集群(主從，高可用，擴(kuò)展節(jié)點(diǎn))

A：參考：https://www.jianshu.com/p/7d5fbf90bcd7

5、kafka相關(guān)

Q：消息是否按照時(shí)間有序，kafka分區(qū)的數(shù)據(jù)是否有序，如何保證有序

A:不保證按時(shí)間有序，主題在單個(gè)分區(qū)是有序的。

如何保證有序？kafka topic 只設(shè)置一個(gè)分區(qū)，或者producer將消息發(fā)送到指定分區(qū)

Q：Kafka為什么吞吐量高

A：

1）順序讀寫(xiě)

kafka的消息是不斷追加到文件中的，這個(gè)特性使kafka可以充分利用磁盤的順序讀寫(xiě)性能，順序讀寫(xiě)不需要硬盤磁頭的尋道時(shí)間，只需很少的扇區(qū)旋轉(zhuǎn)時(shí)間，所以速度遠(yuǎn)快于隨機(jī)讀寫(xiě)。

2）零拷貝

利用Linux kernel"零拷貝(zero-copy)"系統(tǒng)調(diào)用機(jī)制，就是跳過(guò)“用戶緩沖區(qū)”的拷貝，建立一個(gè)磁盤空間和內(nèi)存的直接映射，數(shù)據(jù)不再?gòu)?fù)制到“用戶態(tài)緩沖區(qū)”。

3）分區(qū)

kafka中的topic中的內(nèi)容可以被分為多分區(qū)存在，每個(gè)分區(qū)又分為多個(gè)段，所以每次操作都是針對(duì)一小部分做操作，很輕便，并且增加并行操作的能力。

4）批量發(fā)送

kafka允許進(jìn)行批量發(fā)送消息，producter發(fā)送消息的時(shí)候，可以將消息緩存在本地,等到了固定條件發(fā)送到kafka

等消息條數(shù)到固定條數(shù)，一段時(shí)間發(fā)送一次。

5）數(shù)據(jù)壓縮

Kafka還支持對(duì)消息集合進(jìn)行壓縮，Producer可以通過(guò)GZIP或Snappy格式對(duì)消息集合進(jìn)行壓縮

壓縮的好處就是減少傳輸?shù)臄?shù)據(jù)量，減輕對(duì)網(wǎng)絡(luò)傳輸?shù)膲毫?/strong>

Q：kafka的存儲(chǔ)模型

A：Kafka一個(gè)Topic可以有多個(gè)Partition,多個(gè)線程，每個(gè)線程負(fù)責(zé)一個(gè)Partition進(jìn)行讀寫(xiě)

每個(gè)Paratition可以有多個(gè)LogSegment，每個(gè)LogSegment文件包括一個(gè)日志數(shù)據(jù)文件和兩個(gè)索引文件（偏移量索引文件和消息時(shí)間戳索引文件）。

以上紅字部分就是他的存儲(chǔ)模型

其中，每個(gè)LogSegment中的日志數(shù)據(jù)文件大小均相等（該日志數(shù)據(jù)文件的大小可以通過(guò)在Kafka Broker的config/server.properties配置文件的中的“l(fā)og.segment.bytes”進(jìn)行設(shè)置，默認(rèn)為1G大小（1073741824字節(jié)），在順序?qū)懭胂r(shí)如果超出該設(shè)定的閾值，將會(huì)創(chuàng)建一組新的日志數(shù)據(jù)和索引文件

Kafka的索引文件是采用稀疏索引的方式，每隔一定的字節(jié)數(shù)建立了一條索引

所以在添加數(shù)據(jù)時(shí)，如果還沒(méi)有LogSegment,就會(huì)建第一個(gè)LogSegment，然后把數(shù)據(jù)順序?qū)懺谠揕ogSegment的日志數(shù)據(jù)文件里，然后再把索引加到偏移量索引文件里去

偏移量索引文件的每條索引由offset和position組成，每個(gè)索引條目可以唯一確定在各個(gè)分區(qū)數(shù)據(jù)文件的一條消息

在查找數(shù)據(jù)時(shí)

先根據(jù)Position定位到LogSegment，再根據(jù)Position和offset在logSegment找到日志數(shù)據(jù)文件中對(duì)應(yīng)數(shù)據(jù)的位置

原理就是這樣。

Q：Kafka消費(fèi)者多個(gè)group消費(fèi)同一個(gè)topic,會(huì)重復(fù)消費(fèi)嗎？

A：不會(huì)。

8、項(xiàng)目問(wèn)題

Q：遇到過(guò)內(nèi)存溢出嗎？怎么解決

A：主要了解有沒(méi)有處理過(guò)內(nèi)存泄漏導(dǎo)致的問(wèn)題，C/C++定位內(nèi)存泄漏問(wèn)題；Golang和JAVA主要與GC的工作機(jī)制有關(guān)，堆內(nèi)存一直增長(zhǎng)，導(dǎo)致應(yīng)用內(nèi)存溢出等。

Q：布隆過(guò)濾器怎么設(shè)置m,n,k的值，怎么合理安排key(用戶和item越來(lái)越多，怎么保證內(nèi)存不會(huì)爆)

A：m,n,k 網(wǎng)上有實(shí)踐經(jīng)驗(yàn)，可參考。item越來(lái)越多的話，進(jìn)行item的拆分，拆分本質(zhì)是不要將 Hash(Key) 之后的請(qǐng)求分散在多個(gè)節(jié)點(diǎn)的多個(gè)小 bitmap 上，而是應(yīng)該拆分成多個(gè)小 bitmap 之后，對(duì)一個(gè) Key 的所有哈希函數(shù)都落在這一個(gè)小 bitmap 上。

Q：服務(wù)雪崩怎么處理，怎么解決保證不影響線上

A：限流，降級(jí)，熔斷方面措施，結(jié)合后端系統(tǒng)架構(gòu)闡述，如網(wǎng)關(guān)的限流和快速失敗。

Q：redis和mysql數(shù)據(jù)一致性怎么保證

A：重點(diǎn)考慮業(yè)務(wù)邏輯上寫(xiě)和數(shù)據(jù)的流程（異常和錯(cuò)誤處理等），結(jié)合MQ做異步重試處理。

Q：分布式鎖應(yīng)用場(chǎng)景，哪些坑

A：鎖過(guò)期了，業(yè)務(wù)還沒(méi)執(zhí)行完；分布式鎖，redis主從同步的坑；獲取到鎖后，線程異常。

總結(jié)

以上是生活随笔為你收集整理的go语言总结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。