現在有什麼賽道可以幹到退休？

最近，一則“90後無論男女都得65歲以後退休”的訊息在多個網路平臺流傳，也不知道是真是假，好巧不巧今天刷熱點的時候又看到一條這樣的熱點：現在有什麼賽道可以幹到退休？

點進去看了幾條熱評，第一條熱評說的就是：

“除了體制內，哪裡可以幹到65歲退休？”

結果後面就有兩個人發了兩張截圖截圖，內容分別是“入職阿里巴巴15週年的祝福”和“入職騰訊14週年的祝福”，真的是讓人羨慕嫉妒恨吶，他們穩定幹到退休肯定是沒問題...

那你呢？你現在的“賽道”可以幹到退休嗎？

想聽聽大家對這件事的看法，歡迎大家在評論區討論！

當然看這些東西就圖一樂哈，最重要的還是學習，下面就分享一下粉絲投稿的萬興實習面經。

萬興實習面試

一面（Hr）

1. 自我介紹
2. 你認為你的個人優勢是什麼
3. 談談你的工作經歷或實習經驗
4. 說說你個人的優點
5. 你對這個行業未來的看法
6. 瞭解Ai嗎，對ai的看法

二面（技術）

1. go defer順序

類似於棧，先進後出

2. mysql如何儲存大量資料，分庫存分表的建議和看法（沒答出來）

在 MySQL 中處理大量資料時，分庫分表是一種常見的策略：

一、分庫

1. 垂直分庫

• 按照業務模組將不同的資料表儲存在不同的資料庫中。例如，將使用者相關的資料表放在一個庫，訂單相關的資料表放在另一個庫。
• 優點：可以降低單個資料庫的複雜度，提高特定業務模組的效能和可用性。
• 缺點：跨庫關聯查詢變得複雜，需要透過應用層來處理。

2. 水平分庫

• 將資料按照某種規則（如使用者 ID 取模）分佈到多個資料庫中。
• 優點：可以有效應對資料量的增長，實現分散式儲存和負載均衡。
• 缺點：資料的分佈規則需要精心設計，資料遷移和擴容相對複雜。

二、分表

1. 垂直分表

• 將一個表中不常用的欄位、大欄位或者長度較長的欄位拆分到另一個表中。例如，將商品表中的詳細描述欄位拆分到單獨的表中。
• 優點：減少表的寬度，提高查詢效能，便於維護。
• 缺點：增加了表關聯的操作。

2. 水平分表

• 按照一定的規則（如主鍵值取模、按時間範圍等）將一個表的資料拆分到多個表中。
• 優點：可以解決單表資料量過大的問題，提高查詢效率。
• 缺點：同樣存在資料分佈規則設計和跨表查詢的複雜性。

2. 談談你對docker的理解（參考中陽哥docker那篇文章）

Docker 是一種重要的技術，理解如下：

1. 隔離應用

• 把應用和其依賴打包在獨立容器中，彼此隔離不干擾。
• 像 Web 應用和資料庫應用能在同一主機上互不影響。

2. 便於部署遷移

• 容器包含應用所需一切，能在不同環境快速部署，無視環境差異。

3. 最佳化資源利用

• 能更精細分配資源，多個容器可共享主機資源。

4. 支援版本控制與回滾

• 對容器映象能版本控制，出問題可回滾。

5. 促進開發運維協作

• 開發環境與生產一致，減少問題。

6. 適合微服務架構

• 每個微服務可打包成容器，方便獨立操作。

7. 助力 CI/CD

• 與相關工具鏈整合，實現自動化流程。

2. Grpc和http的區別

1. 效能
   • Grpc 通常在效能方面表現更優，因為它使用二進位制協議，資料傳輸效率高。
   • Http 一般使用文字格式，資料量相對較大。
2. 連線方式
   • Grpc 支援長連線，能減少連線建立的開銷。
   • Http 常見的是短連線，每次請求都要重新建立連線。
3. 資料格式
   • Grpc 基於 Protocol Buffers 定義資料格式，具有高效的序列化和反序列化能力。
   • Http 可以使用多種資料格式，如 JSON、XML 等。
4. 流處理
   • Grpc 對雙向流和伺服器流的支援較好。
   • Http 在流處理方面相對較弱。

2. 協作開發時，不同人員的go版本不同如何解決

1. 統一版本
   • 確定一個共同的 Go 版本，要求所有開發人員安裝和使用該版本。
   • 可以透過專案規範和文件明確指定。
2. 使用工具管理
   • 利用版本管理工具，如 go.mod 和 go.sum 。
   • 這些檔案可以指定專案所依賴的特定 Go 版本和模組版本，確保不同開發者在拉取程式碼時能夠獲取到一致的依賴環境。
3. 容器化開發環境
   • 使用 Docker 等容器技術建立統一的開發環境。
   • 在容器中配置好指定的 Go 版本和相關依賴，開發人員在容器中進行開發，避免本地環境差異。

2. Prtobuf檔案過多過長時候該如何管理

1. 分包與分組
   • 將相關功能或模組的訊息定義分組到不同的 Protobuf 檔案中。
   • 例如，將使用者相關的訊息定義放在 user.proto ，訂單相關的放在 order.proto 。
2. 目錄結構規劃
   • 建立清晰的目錄結構來組織 Protobuf 檔案。
   • 可以按照業務模組、功能型別等劃分不同的目錄。
3. 提取公共部分
   • 如果有多個檔案中存在重複或相似的定義，提取這些公共部分到單獨的 Protobuf 檔案中，然後其他檔案進行引用。
4. 版本控制
   • 利用版本控制系統（如 Git）來管理 Protobuf 檔案的變更歷史。
5. 文件註釋
   • 在 Protobuf 檔案中新增詳細的註釋，說明每個訊息的用途、欄位含義等，方便理解和維護。
6. 定期審查與重構
   • 定期對 Protobuf 檔案進行審查，刪除不再使用的定義，最佳化複雜的結構。

例如，一個大型電商專案可以將商品相關的 Protobuf 檔案放在 goods/ 目錄下，包括 goods_info.proto 、 goods_comment.proto 等。對於一些通用的錯誤碼定義，可以提取到 common/error_code.proto 中供其他檔案引用。

2. GMP模型

https://juejin.cn/post/7384303275376230411
可以看看這個，我自己總結的

2. 為什麼選擇go,go語言優勢，打算做哪方面的開發

Go 語言有諸多優勢，如語法簡潔高效，便於學習和編寫；併發支援強大，goroutine 和 channel 讓併發程式設計輕鬆；編譯速度快，利於快速開發；記憶體管理有自動垃圾回收；跨平臺性好；效能出色，能滿足高效能需求；標準庫豐富，涵蓋眾多領域。這些優勢使其在雲端計算、後端開發、網路程式設計等領域廣泛應用。

2. 如何進行版本管理（git）

3. Map是否安全

在 Go 語言中，內建的 map 不是併發安全的。

如果在多個 goroutine 中同時對一個 map 進行讀寫操作，可能會導致不可預測的結果，例如資料競爭、程式崩潰等。

例如，如果一個 goroutine 正在對 map 進行寫入操作，而另一個 goroutine 同時在讀取或刪除元素，就可能出現問題。

為了在併發環境中安全地使用 map ，可以使用一些併發安全的替代方案，比如使用 sync.RWMutex 來加鎖保護對 map 的操作，或者使用第三方庫提供的併發安全的 map 實現。

2. 個人專案相關（較多較細）
3. Kafka

三面（綜合面）

1. 是否使用過ai,對大模型的看法，大模型對程式設計師有什麼幫助？
2. 如果你要進行一個專案開發的話，流程該怎麼樣
3. 對於Go的介面化不夠友好，該怎麼解決
4. 在專案開發時候，前後端開發有分歧該如何解決
5. 對於go未來的發展你怎麼看，使用哪個版本的go,各個版本間你是怎麼看的
6. 個人愛好，職業發展

歡迎關注 ❤

我們搞了一個免費的面試真題共享群，互通有無，一起刷題進步。

沒準能讓你能刷到自己意向公司的最新面試題呢。

感興趣的朋友們可以加我微信：wangzhongyang1993，備註：部落格園面試群。