2023 go崗位-跳槽-學習規劃（求補充）

進度

2023-05-04 完成基礎，base項，文章整理，連結整理。話術整理。
2023-05-05 完成kafka roccketMQ，以及 知識庫es的知識點整理與面試話術總結。
未完成 docker，k8s
未完成，微服務，領域驅動
未完成 雲原生
2023-05-06 完成 專案疑難問題如何解決。
2023-05-06 增加三次握手 四次揮手 理解，增加b*樹，b+樹區別

基礎面試題

請先完成此文章的題目。再看下面的題。這個題是現在很基礎的，很常問的題。
這個人寫的很正經，不是打廣告，我反正就記錄一下。各位也可以找到其他的相關題。然後可以評論，求補充。
www.kancloud.cn/martist/phper-will...

0. laravel 為phper 轉go的準備下

laravel 基礎面試題 我感覺可以不看，不就那點東西。用了兩三年laravel 自然都會。
翻譯：91 個常見的 Laravel 面試題和答案

laravel生命週期 一圖搞定（講清楚這個就行）

laravel 服務容器：註冊基礎服務；管理所需建立的類及其依賴。

依賴 依賴注入，控制反轉淺顯解釋:部落格：依賴、依賴注入與控制反轉 筆記

1. 面試題

topgo講的細。
www.topgoer.cn/docs/gomianshiti/go...

面試技術點詳解拆分

部落格：go-面試技術點-帶解析

redis部分

包含了redis，但是redis 我認為有更細節的部分（更加易於背誦），請看下文。

部落格：[面試題]跳槽面試必背-自己最近5年的整理，歡迎大家補充。

mysql最佳化，從該文章的 16開始，如下圖
部落格：[面試題]跳槽面試必背-自己最近5年的整理，歡迎大家補充。

2. go 底層

看幼麟實驗室
www.bilibili.com/video/BV1hv411x7w...

3. gin框架（求補充）

實際上，我覺得沒啥好問的。一般也不至於問你gin咋用吧。工作用用行了。

4. Docker（求補充）

5. GRPC（求補充）

6. 微服務（求補充）

7. k8s（求補充）

8. 雲原生 kafka rocketMQ（求補充）

面試題（很多很精要）：來自於某知識星球。我就掛個連結。
wx.zsxq.com/dweb2/index/columns/51...

kafuka 面試彙總

8.1 kafka 使用場景

1）⽇志收集⽅向：可以⽤ Kafka 來收集各種服務的 log，然後統⼀輸出，⽐如⽇志系統 elk，⽤ Kafka 進⾏資料中轉。
2）訊息系統⽅向：Kafka 具備系統解耦、副本冗餘、流量削峰、訊息緩衝、可伸縮性、容錯性等功能，同時還提供了訊息順序性保障以及訊息回溯功能 等。
3）⼤資料實時計算⽅向：Kafka 提供了⼀套完整的流式處理框架， 被⼴泛應⽤到⼤資料處理，如與 flink、spark、storm 等整合 。

來自於華哥的口頭解釋：
現在都是微服務，服務之間通訊都可以用啊，比如你要做一套中介軟體服務或者開放平臺，肯定需要做監控/服務質量相關，就可以透過kafka來接收而不影響業務使用，後面起消費者可以做不同的定製化操作（比如傳送到Prometheus做監控、報警等等）。
還有就是針對高併發業務場景，可以直接脫離資料庫直接用kafka或者rocketmq來抗併發，消峰，然後後臺服務慢慢消費做其他處理
不過大資料用kafka比較多，業務用rocketmq多，我們之前公司基本都是kafka，基礎架構部搭建了kafka訊息管理平臺，做個回撥配置地址就可以了，剩下的就是自己寫生產者和消費者業務程式碼，相對比較簡單。

8.2 kafka 基礎命令

articles.zsxq.com/id_qfjnjwafdxsv....

8.3 rocketMQ 使用場景

跟kafka 差不多。

8.4 rocketMQ 基礎命令

articles.zsxq.com/id_o92x7jv3p0tu....

8.5 kafka rocketMQ 等區別 優缺點

rocketMQ 最後一頁。
優勢：
1 java原始碼，2支援高階特性多（普通訊息」、「順序訊息」、「事務訊息」、「訊息過濾」、「定時/延時訊息」、「訊息重試」），3阿里已經在用。

articles.zsxq.com/id_6xttsqfhw9v5....

9. 爬蟲

爬蟲base面試題1（簡單版）： blog.csdn.net/AudiA6LV6/article/de...

爬蟲base面試題2（專業版）：blog.csdn.net/wanlitengfei/article...

10. websocket

部落格：websocket 面試題

11. JWT 與 OAuth2.0

請看博文。這個也要自己整理一段話術。或者全背下來
blog.csdn.net/sssssooo/article/det...

12. Elasticsearch面試題 與 應用場景

基礎面試題

blog.csdn.net/QLCZ0809/article/det...

應用場景-知識庫 全文檢索 todo

13. MogoDB 常用操作 與 應用場景

13.1 應用場景，網站使用者來源日誌

1. 存日誌

先提取出各個欄位的值，然後存入，就是一個包含很多個欄位的文件。

也支援批次寫 db.events.insert([doc1, doc2, ...])

2. 日誌分析

可以find 模糊搜尋
可以按照time 時間段搜尋

3. 日誌過大怎麼處理。

第一： 設定TTL 索引，過期自動刪除
之前網站設定的是3個月過期，同時查詢資料存入mysql
MongoDB的TTL索引可以支援文件在一定時間之後自動過期刪除。例如上述日誌time欄位代表了請求產生的時間，針對該欄位建立一個TTL索引，則文件會在30小時後自動被刪除。
db.events.createIndex( { time: 1 }, { expireAfterSeconds: 108000 } )
第二：
定期按集合或DB歸檔，按照月份 對集合命名。 缺點就是，跨月份查詢需要聯合查詢

詳情如下：
比如每到月底就將events集合進行重新命名，名字裡帶上當前的月份，然後建立新的events集合用於寫入。比如2016年的日誌最終會被儲存在如下12個集合裡：

1. events-201601
2. events-201602
3. events-201603
4. events-201604
5. ....
6. events-201612

當需要清理歷史資料時，直接將對應的集合刪除掉：

1. db["events-201601"].drop()
2. db["events-201602"].drop()

不足之處，在於到時候，如果要查詢多個月份的資料，查詢的語句會稍微複雜些，需要從多個集合裡查詢結果來合併。

13.2 基礎命令

1. MongoDB 建立資料庫的語法格式如下：

use DATABASE_NAME

MongoDB 刪除資料庫的語法格式如下：

db.dropDatabase()

2.集合操作

MongoDB 中使用 createCollection() 方法來建立集合

檢視已有集合，可以使用 show collections 或 show tables 命令：

如何將資料插入到 MongoDB 的集合中。

文件的資料結構和 JSON 基本一樣。

所有儲存在集合中的資料都是 BSON 格式。

BSON 是一種類似 JSON 的二進位制形式的儲存格式，是 Binary JSON 的簡稱。

3. 文件

文件的資料結構和 JSON 基本一樣。

所有儲存在集合中的資料都是 BSON 格式。

BSON 是一種類似 JSON 的二進位制形式的儲存格式，是 Binary JSON 的簡稱。

MongoDB 使用 insert() 或 save() 方法向集合中插入文件，語法如下：

db.COLLECTION_NAME.insert(document)  或 db.COLLECTION_NAME.save(document)

update() 更新

remove 刪除

find 查詢

排序 sort

索引 createIndex

14. rbac 原理與 casbin 以及應用場景

rbac原理

1. 五個表，完成許可權控制

2. 升級版本增加角色組表. 使用者組和角色組進行管理.
   

3. 使用者組的優點 應用場景。

除了減少工作量，還有更便於理解。

比如按部門建立使用者組的例子。一位使用者從A部門異動到了B部門，這是實際發生的情況。如果沒有使用者組，那麼我們要拿掉A部門的所有角色，換上B部門的所有角色。
加上使用者組之後，只需要操作使用者離開A組而加入B組就行了。這與實際情況很貼近。

使用者組的理解：

使用者組對標的是使用者而不是角色，使用者組的作用是對使用者做一個歸類，可以更加方便地授權而已。
譬如你要對多個角色授權，並且這些角色成員存在交集。那麼先把這些共同的使用者新增到一個使用者組，再在角色成員裡面新增使用者組，總的新增操作次數是x+y，而直接新增使用者則是x*y次。這就是使用者組的作用。

casbin 應用場景

casbin 支援acl rbac RESTful等。 我們系統中用的是 rbac 與restful（RESTful: ⽀持路徑, 如 /res/*, /res/:id 和 HTTP ⽅法, 如 GET, POST, PUT, DELETE）

目前的系統裡，構建了一個 rbac服務。
採用互斥角色。
使用者-單角色，單角色對對許可權節點。
許可權節點分為了，選單，按鈕，api。

二開了許可權節點，新增了api分類與api表。增加了公共api分類。
把選單或者按鈕與多個api進行關聯。一對多。
因為可能某個按鈕，有多個api。
在中介軟體中增加相關的許可權判斷。

15. 專案中的問題，你是如何解決的

15.1 事務問題例子：

突然的網站訪問慢。但是cpu 記憶體 磁碟資源正常。
這時候經過排查，發現是有兩種情況。一是資料庫事務佔用，二是資料庫連線耗盡。

原因大致是： 程式碼問題，沒有回滾，就return。 二是事務執行時間過長，造成資料庫連結無法釋放。
解決方案是：

1. review 減少程式碼bug。 有err return，則所有地方都加回滾。
2. 事務執行過長。要麼邏輯移出事務，要麼最佳化這塊程式碼。
3. 合理配置超時時間。比如，實在是一次處理幾千條資料。那就超時給1分鐘。

後面考慮做的，是 kafka 日誌，監控。但是還沒做。

15.2 安全問題

1. 簡訊盜刷。
   透過驗證，傳送簡訊 url，來源標誌。判斷使用者是否合法。
   如：url來源、渠道。如百度 360 手機端 pc 端等等。
   結合同ip傳送簡訊頻率，來進行判斷。

2. 惡意併發請求。

有的競爭對手，會去網咖。瘋狂併發請求網站。消耗資源。
寫了個py指令碼。如果檢視到同ip發起大量請求，則直接禁止訪問。

3. 資料庫漏洞

場景1：之前遇到一個把我們mysql5.6 資料庫給乾死的。
恢復資料，資料庫升級到8.0，改埠，限制ip訪問
系統打補丁。
這個是真沒太多辦法。
場景2：資料丟失，資料誤刪。
取自動備份前一天的資料，+binlog 恢復。

15.3 爬蟲問題

爬蟲還是禁不了。
因為你總要有頁面輸出吧。哪怕程式碼不能爬，火車頭也能爬，谷歌瀏覽器外掛Data Scraper也能爬。
人工也能爬。。。只要別讓人家把網站爬的資源不夠最好。

後來
開放 api，api資料全是快取過的。讓外人去爬。

16 三次握手 四次揮手

16.1 簡單話術

三次握手
我對你 嗨
你對我 嗨
我發出握手邀請。
你收到了，跟我握手。
我，看握住了，我加點力。
你也看，握住了，也加點力

四次揮手
職員問主管，我要下班了。
主管，說，還有事。你得做。或者沒事，你收拾東西走吧。
職員，收拾一下或者接著做事。
主管 看職員收拾好走了，主管也準備走了。

16.2 專業術語

簡述 TCP 三次握手？

• 伺服器程式先建立傳輸控制塊 TCB，並處於監聽狀態，等待客戶端的連線請求
• 客戶端建立傳輸控制塊 TCB，並向伺服器發出連線請求報文段
• 伺服器收到連線請求報文段後，如同意建立連線，則傳送確認報文段
• 客戶端程式收到伺服器的確認報文段後，立即回覆確認報文段，並進入已建立連線狀態
• 伺服器收到確認報文段之後，也進入已建立連線狀態

簡述TCP 四次揮手？

• 客戶端應用程式發出連線釋放報文段，並停止再傳送資料，進入 FIN-WAIT-1(終止等待1)狀態，等待伺服器確認
• 伺服器收到連線釋放報文段後即發出確認，進入 CLOSE-WAIT(關閉等待)狀態，伺服器若傳送資料，客戶端扔要接收
• 客戶端收到來自伺服器的確認後，進入 FIN-WAIT-2(終止等待2)狀態，等待伺服器發出連線釋放報文段
• 伺服器沒有要傳送的資料，發出連線釋放報文段，進入 LAST-ACK(最後確認)狀態，等待客戶端確認
• 客戶端收到連線釋放報文段後，發出確認，進入 TIME-WAIT(時間等待)狀態，經過時間等待計時器設定的時間 2MSL 後，進入 CLOSED(關閉) 狀態
• 伺服器收到客戶端報文段後，進入 CLOSED 狀態

17. mysql b*樹 與 b+樹，為什麼選擇b+樹索引呢？

17.1 B*樹又在B+樹的基礎上產生了一系列的變化，如下：

B*樹定義了非葉子結點關鍵字個數至少為(2/3)*M，即塊的最低使用率為2/3，代替B+樹的1/2；
B+樹的分裂：當一個結點滿時，分配一個新的結點，並將原結點中1/2的資料複製到新結點，最後在父結點中增加新結點的指標；B+樹的分裂隻影響原結點和父結點，而不會影響兄弟結點，所以它不需要指向兄弟的指標；
*樹的分裂：當一個結點滿時，如果它的下一個兄弟結點未滿，那麼將一部分資料移到兄弟結點中，再在原結點插入關鍵字，最後修改父結點中兄弟結點的關鍵字（因為兄弟結點的關鍵字範圍改變了）；如果兄弟也滿了，則在原結點與兄弟結點之間增加新結點，並各複製1/3的資料到新結點，最後在父結點增加新結點的指標；
所以B*樹相對於B+樹，空間利用率上有所提高，查詢速率也有所提高。

17.2 為什麼MySQL選擇B+樹做索引

首先 Mysql索引主要有兩種結構：B+Tree索引和Hash索引
(a) Inodb儲存引擎 預設是 B+Tree索引
(b) MyISAM 儲存引擎 預設是Fulltext索引(全文索引)；
(c)Memory 儲存引擎 預設 Hash索引；

1、 B+樹的磁碟讀寫代價更低：B+樹的內部節點並沒有指向關鍵字具體資訊的指標，因此其內部節點相對B樹更小，如果把所有同一內部節點的關鍵字存放在同一盤塊中，那麼盤塊所能容納的關鍵字數量也越多，一次性讀入記憶體的需要查詢的關鍵字也就越多，相對IO讀寫次數就降低了。

2、B+樹的查詢效率更加穩定：由於非終結點並不是最終指向檔案內容的結點，而只是葉子結點中關鍵字的索引。所以任何關鍵字的查詢必須走一條從根結點到葉子結點的路。所有關鍵字查詢的路徑長度相同，導致每一個資料的查詢效率相當。

3、B+樹更便於遍歷：由於B+樹的資料都儲存在葉子結點中，分支結點均為索引，方便掃庫，只需要掃一遍葉子結點即可，但是B樹因為其分支結點同樣儲存著資料，我們要找到具體的資料，需要進行一次中序遍歷按序來掃，所以B+樹更加適合在區間查詢的情況，所以通常B+樹用於資料庫索引。

4、B+樹更適合基於範圍的查詢：B樹在提高了IO效能的同時並沒有解決元素遍歷的我效率低下的問題，正是為了解決這個問題，B+樹應用而生。B+樹只需要去遍歷葉子節點就可以實現整棵樹的遍歷。而且在資料庫中基於範圍的查詢是非常頻繁的，而B樹不支援這樣的操作或者說效率太低。

本作品採用《CC 協議》，轉載必須註明作者和本文連結