本人國內(nèi)某211地理信息專業(yè)（GIS）畢業(yè)，畢業(yè)之后考了日本某舊帝大的CS研究生，現(xiàn)在在網(wǎng)安方向研究室研一就讀，4月剛開學(xué)。當(dāng)時(shí)留日想法就是想要個(gè)cs方向的研究生學(xué)歷，以后就業(yè)面大一點(diǎn)，目前是想要回國工作。目前計(jì)劃是暑假如果可以的話找日本公司短期實(shí)習(xí)，明年暑假找國內(nèi)實(shí)習(xí)，然后秋招春招。想問國內(nèi)網(wǎng)安方向現(xiàn)在前途如何，還是說直接轉(zhuǎn)開發(fā)比較好，想的是保底可以干gis方向的開發(fā)，有相關(guān)經(jīng)驗(yàn)。希望?？痛罄薪o小弟指點(diǎn)迷津，感謝各位。

#你會選擇考研還是直接就業(yè)# #如果能重來，就業(yè)or讀研你選哪個(gè)？# #如果再來一次，你還會選擇這個(gè)工作嗎？# 各位牛友們，我有個(gè)哥們保研去了果殼大非頂所cs，但是實(shí)驗(yàn)室就業(yè)情況很差，基本都是自學(xué)后去搞開發(fā)的，而且實(shí)驗(yàn)室對學(xué)生強(qiáng)度大有論文發(fā)表要求，但實(shí)驗(yàn)室學(xué)術(shù)氛圍也很差。他現(xiàn)在拿了一個(gè)小企業(yè)五六十萬的offer，自動化相關(guān)的工作。他是c9本自動化專業(yè)，然后他現(xiàn)在就特糾結(jié)，不過我是一直在勸他去就業(yè)的，各位????覺得應(yīng)該就業(yè)還是讀研呢？

兄弟們有什么建議嗎，騰訊云元寶py的后臺開發(fā)和滴滴的golang后臺開發(fā)，有點(diǎn)糾結(jié)了，期望大佬給個(gè)建議#offer幫選##騰訊2025實(shí)習(xí)生招聘##?？虯I配圖神器#

一面后1小時(shí)通知二面——————————#面試問題記錄#整整一個(gè)小時(shí)的拷打，場景題+項(xiàng)目拷打 幾乎無八股文?? 個(gè)人背景與項(xiàng)目經(jīng)歷1.你自我介紹一下？2.你做的兩個(gè)項(xiàng)目中，哪個(gè)是實(shí)習(xí)？哪個(gè)是練手項(xiàng)目？3.實(shí)習(xí)項(xiàng)目主要做了什么？用到了哪些技術(shù)和框架？4.練手項(xiàng)目是獨(dú)立做的嗎？用了哪些模塊和功能？    5.你對這個(gè)練手項(xiàng)目熟悉嗎？可以詳細(xì)介紹一下它的功能模塊？?? 技術(shù)能力 - 后端開發(fā)1.你項(xiàng)目的XX流程是怎么實(shí)現(xiàn)的？Redis + Lua 在其中起到什么作用？2.你項(xiàng)目的Redis 緩存預(yù)熱結(jié)構(gòu)是怎樣的？怎么判斷用戶狀態(tài)？3.你用 MQ 的目的是什么？為什么不是直接操作數(shù)據(jù)庫？4.MQ 消費(fèi)失敗的情況下你是怎么處理的？有重試機(jī)制嗎？5.死信隊(duì)列和超時(shí)取消使用的是同一個(gè)嗎隊(duì)列？怎么區(qū)分消息類型？6.redis成功執(zhí)行寫入了但 MQ 落庫消費(fèi)失敗怎么辦？Redis 寫成功就代表成功嗎？7.JWT 是怎么生成和校驗(yàn)的？用了什么加密算法？8.用戶主動登出是怎么實(shí)現(xiàn)的？?? 多線程與分布式9.Redis 的原子性是怎么保證的？10.項(xiàng)目中你有沒有考慮冪等性？怎么防止重復(fù)請求的冪等性？11.XX場景中是否能做到最終一致性？如何通知用戶成功？? MQ & 延遲任務(wù)12.延遲隊(duì)列的作用是什么？項(xiàng)目中用來處理哪類業(yè)務(wù)？13.死信隊(duì)列是如何配置的？超時(shí)和消費(fèi)者消費(fèi)失敗如何分別處理？14.如果 MQ 消息失敗進(jìn)入死信隊(duì)列，你是如何排查和處理的？15.MQ 消息失敗重試到上限后該怎么辦？16.使用 RabbitMQ 是為了提高性能還是為了消息可靠性？17.項(xiàng)目中有沒有處理 MQ 消息重復(fù)消費(fèi)問題？?? MySQL & 數(shù)據(jù)庫能力18.MySQL 的 B+樹結(jié)構(gòu)你了解嗎？聚簇索引和非聚簇索引有什么區(qū)別？19.建立索引有什么原則？如何判斷字段是否適合建索引？20.用“性別”字段建索引合適嗎？為啥說選擇性低不適合？21.全表掃描和使用區(qū)分度低的索引掃描哪種情況下更快？22.大分頁 offset 性能差怎么優(yōu)化？23.在實(shí)習(xí)中是怎么優(yōu)化SQL的？ ??場景題：高并發(fā)請求失敗后處理方式?? 題目背景描述：你接入了一個(gè)第三方服務(wù)，該服務(wù)每天發(fā)送約 300 萬次請求給你們系統(tǒng)。其中，每個(gè)請求都包含一個(gè)全局唯一的 requestId（一個(gè) 40 字節(jié)的 UUID 字符串）。如果因?yàn)榫W(wǎng)絡(luò)中斷、超時(shí)等原因?qū)е碌谌經(jīng)]有收到響應(yīng)，它會重新發(fā)起完全相同的請求（帶相同的 requestId），業(yè)務(wù)上有幾個(gè)關(guān)鍵限制：    1、每個(gè) requestId 表示一次業(yè)務(wù)處理，例如支付通知、回調(diào)、交易同步等。    2、你方必須保證對于每個(gè) requestId，只能處理一次（典型的冪等性要求）。    3、不能重復(fù)請求第三方服務(wù)（第三方服務(wù)不具備冪等性）    4、由于網(wǎng)絡(luò)波動或響應(yīng)失敗，同一個(gè) requestId 有可能會在不同時(shí)間再次被發(fā)送過來，甚至有以下復(fù)雜時(shí)間分布：        4.1、絕大部分重復(fù)請求會在20 分鐘內(nèi)重發(fā)；        4.2、一小部分會在1 天內(nèi)重發(fā)；        4.3、極個(gè)別（例如接口掛起重試）會在一年后突然重發(fā)。?? 關(guān)鍵技術(shù)難點(diǎn)：    如何快速識別“是否已處理過某 requestId”？    如何既不誤判（重復(fù)處理）又不濫用資源（存一年）？    如何兼顧吞吐量、IO壓力、成本？