是的，諸位沒有看錯，這篇文章的要講述的并不是我吊打面試官，而是一段我被面試官吊打的陳年往事，這段痛苦的記憶在我腦海中長久不衰，也是一個我內心曾多次不愿面對的事實，各位看官可以準備好一小把瓜子，聽我將這則舊事緩緩道來~

一、“被吊打事件”的前因后果

在正式談及這次“被吊打事件”之前，首先來聊一聊此次事件的前因后果，事情的起因源自于我太過自信，剛畢業的那段時間，本故事的主人公，也就是我，經過一些特殊手段，成功入職了一家從事教育軟件開發的小企業。當然，你要問我什么樣的特殊手段能讓剛畢業的我，無需面試就進入了一家軟件企業，那就是大名鼎鼎的面試秘法——走后門。

因為我的一位親戚，在這家企業擔任級別不算低的“高管”，因此我靠常人不能及的手段成功入職，沒錯！俺是一個妥妥的關系戶，也正式由于這個原因，所以入職后的工作任務并不算重，飯點前、下班前，沖在第一個的永遠是我，畢竟實力擺在這，不囂張點簡直對不住我的身份，哈哈哈~

總之在入職第一份工作的時光中，我大致算整個研發部門中最輕松的那個，因為工作輕松，所以給了我不少摸魚學習時間，也正是通過這些時間，我在忙完工作之余的時間內，自身也額外學習了不少 Java 技術。

當時我的技術大致是什么水平呢？這里我從招聘軟件上將我當初的簡歷信息摘過來了，如下：

2019 年的時候，我當時的簡歷是這樣的，但凡我當初聽到過的主流技術，基本上都去做了相關學習，并且一半以上在開發中都用過，因為當時的研發模式屬于低代碼定制開發，因此核心平臺的功能代碼中，涉及到的新技術也蠻多，所以當初我有著迷之自信，自認為技術達到了很牛逼的程度。

正是由于當時這份簡歷，給予了自己莫大的自信，再加上成也蕭何敗也蕭何，因為關系戶的原因，我入職額外輕松，但也正因為是關系戶，所以極大程度上限制了自己的成長空間，也就是抹不開面子去提漲薪，因此最終我做出了一個決定：“大丈夫生于天地之間，豈能郁郁久居人下”！

沒錯，當時的我毅然決然的“提桶跑路”了！提出辭職之后，在諸多的勸阻中，頭也不回的卷鋪蓋走人，沒有別的原因，完全歸咎于個人對自己技術的自信！當時跑回了老家玩了一段時間后，想著男子漢大丈夫，是時候該有一番作為了！接著我去到了距離老家最近的省會城市，從此踏上了額外自信的面試之旅（上份工作不在老家的省份，這也是離職原因之一，玩心重，朋友都不在身邊~）

從這段回憶中，大家應該能夠感受出我當時的心態，用一個詞去形容特別恰當，也就是“年少輕狂”，沉浸在自己的認知中，換當時的心理，如果非要找一個字來形容的話，那就是“我技術很屌”！哈哈哈，現在想起來感覺有些許幼稚，但當初的我確實就是這個心態，因自認為的技術飛速提升，造就了當時內心十分膨脹的我。

二、“被吊打事件”的正戲開場

2019 年國慶后的某個下午，陽光明媚，抬頭望去，天空萬里無云，也正是在這個時間點上，一位身著白色T恤的帥小伙，正在賣力的蹬動雙腿：

別看了，蹬車的不是這雙腿，而是我那長達一米四的大長腿~！

當時流行騎共享單車，在我約好面試后，就按約定的時間騎車趕往面試現場，經過近半小時的不懈努力，我成功在約定時間前趕到了，首先接待我的是一位人事小姐姐，在走完面試前的一些流程后，隨即就喊來了一個技術老哥。

負責第一輪面試我的老哥，在簡單看完我的簡歷后表現的很有興趣，大概同我聊了有四五十分鐘的時間，當然，這并不是本次的主題內容，所以按下快進鍵：

• 先簡單問了一些關于 Java 基礎的內容，如面向對象、集合、多線程、特性....

• 接著問了最近做的兩個項目，整體的業務內容、核心技術、個人負責的技術工作....

• 然后又問了一些 JVM 相關的知識，如內存區域、垃圾回收、類加載機制、即時編譯.....

• 接著又聊了一些常用開源框架，如 Spring 事務原理、MVC 工作流程、AOP 的應用場景...

• 然后又談了一些關于分布式系統的技術，如分布式系統的一些解決方案、常用的中間件技術....

• 最后探討了一下 MySQL 的知識，也就是索引、事務、鎖的原理，以及 SQL 優化、性能優化....

第一輪技術面試中，在我的記憶中回答的還算不錯，包括當時負責一面的技術老哥似乎也挺滿意，在聊完技術過了一會兒之后，他就帶著我的簡歷去了人事部，緊接著又是最初的那位人事小姐姐，出來領著我往一個房間走去......

由于當時房間內還在談話，所以我在門口稍等了一小會兒，但沒過多久，我就被喊了進去，進門后映入我眼簾的，是一位梳著成功人士發型、穿著黑襯衫、打著小領帶、并且面容較為英俊的男人，從面相上看應該在27、28歲左右，當時給我的第一印象并不是油膩，而是一位很注重形象、并且風采氣度不凡的老哥，他！就是本文的主角人物！

后來我從人事經理口中得知，他就是這個分公司的技術總負責人，也可以被稱之為CTO、技術總監啥的，當然，在這里我印象最深刻的并非是他的長相和氣質，而是那張超大規模的真皮沙發！畢竟我進門聽到的第一句，就是他朝我說：“別緊張，過來這里坐”！我當時坐在真皮沙發上的第一感覺就是：真軟！

三、“被吊打事件”的來龍去脈

前奏：先是簡單的交談，經過一番寒暄之后，終于正戲上演了！

技術總監：看了一下你的簡歷還不錯呀，跟我聊聊你最近做過的這個項目吧。

我：叭啦叭啦叭.....一頓介紹。

技術總監：說說你在這個項目中，主要負責哪塊開發呢？

我：個人參與了該項目的不少核心功能開發，如整個平臺的用戶模塊，管理、身份、權限等.....

技術總監：OK，那咱們聊一聊登錄注冊吧，這個是你負責的對嘛？

我：是的。

3.1、第一問：登錄、注冊的業務設計

技術總監：你先跟我說說，你們這個項目的注冊、登錄界面是怎么樣的呢？

注冊、登錄界面都大同小異，與一些主流網站類似，注冊界面會要求用戶輸入「手機號/郵箱、昵稱、密碼、二次確認密碼、驗證碼」等基本信息，等這些基礎信息填寫完成后，用戶就可以點擊按鈕注冊賬號了。

而對于登錄流程的設計，相較來說就更為簡單，只需要用戶輸入「郵箱/昵稱/手機號」中的任一信息，然后填寫密碼點擊登錄即可。

技術總監：那如果用戶登錄時，忘記了密碼怎么辦呢？

對于這點是無需擔心的，因為在登錄頁面上，提供了找回密碼的入口，前面注冊時必須要填寫郵箱或手機號的，用戶可以通過「手機驗證碼或郵箱驗證碼」的方式找回密碼。

技術總監：嗯呢，那用戶登錄一次之后，第二次登錄時還需要重新輸入密碼嗎？

這個要看具體情況來區分，因為在登錄的時候，提供了一個「記住密碼」的選項，如果用戶登錄時勾選了該選項，這時在瀏覽器發出的「登錄請求」中，除開基本的用戶登錄信息外，還會額外傳遞一個標識。

在后端判斷用戶輸入的「用戶名、密碼」正確后，如果請求中存在該標識，則會生成一個 Cookie 信息，將「用戶名、密碼」保存在 Cookie 中返回，客戶端在收到該信息后，會自動把 Cookie 存儲在瀏覽器的本地緩存中，所以當用戶第二次登錄時，避免了再次重復輸入「用戶名、密碼」的工作。

技術總監：那你認為這種方式存在什么問題么？

有兩個隱患，一方面由于保存的「用戶名、密碼」存在瀏覽器的本地記錄中，所以如果在本地找到了對應的 Cookie 記錄，用戶密碼是有被盜取的風險。

同時，如果并非用戶本人操作電腦時，其他人通過「開發者工具」把 input 元素的類型從 password 類型修改成 text 這種，依舊有可能造成用戶密碼泄露。

技術總監：可以的，邏輯思維能力還不錯。

哈哈哈，沒有的，主要是對于這塊業務比較熟悉，而且登錄注冊的業務不算太復雜（這個時候我還沒有意識到問題的嚴重性）。

技術總監：再問問你登錄的設計哈。

技術總監：用戶注冊時填好了一部分信息，但因為有事走開了，最后電腦沒電關機，用戶重啟電腦后，再次打開注冊界面，需要重填信息嗎？

在我們當時的項目中，如果出現這種情況，由于電腦已經重啟了，因此用戶上次填寫的信息會丟失，需要用戶重新從頭填寫注冊信息。

技術總監：嗯呢，那你有沒有好的辦法解決這個問題呢？

「埋頭苦思：不對勁，這小子很不對勁，這種問題怎么也問？讓我想想該怎么回答。」 ? ?? ? ?在用戶填寫數據的時候，前端可以通過「光標移出事件」來獲取用戶當前填寫的數據，接著將其保存在本地的 Cookie 中，如果用戶點擊了「注冊」按鈕后，則主動去刪除 Cookie 中的信息，畢竟提交注冊后這些保存的信息就失去了作用。

但如果用戶寫到一半，電腦突然沒電關機了，重啟后再次打開注冊頁面，那這里又可以在「頁面加載事件」中，從本地 Cookie 中將原本保存的數據讀出來，然后賦值給對應的文本框即可，從而避免用戶重復填寫數據。

技術總監：很棒呀，這個想法很不錯！

技術總監：那假設有兩個用戶在同時注冊，并且輸入的用戶名相同，同時提交注冊會出現什么情況呢？

首先這種情況出現的幾率比中彩票都小，同時就算出現了也沒關系，因為不同地段的網速肯定有差距，所以兩個注冊請求到達服務器的時機也不同，同時在設計數據庫的用戶表時，對用戶名加了唯一索引，所以兩個用戶同時注冊時，就算輸入的用戶名相同，也只會有一個注冊成功，并不會出現用戶名重復的情況。

技術總監：你們項目除開通過注冊賬號登錄外，還有沒有什么其他方式呢？

還有第三方聯合登錄的實現，主要就是QQ、微信這兩種社交賬號的聯合登錄，是通過騰訊本身提供的 API 來實現的，如果用戶選擇這種第三方登錄，會直接去調用騰訊的登錄 API。用戶掃碼登錄成功后，會觸發我們平臺登錄成功的回調接口，為其自動在平臺注冊一個賬號，最終實現第三方賬號的聯合登錄。

技術總監：好的，那咱們再聊點其他的。

3.2、第二問：注冊時的敏感詞檢測

技術總監：你在做注冊業務的時候，有沒有考慮過，如若用戶填寫的「昵稱/用戶名」涵蓋敏感信息怎么辦呢？比如填寫的昵稱存在傳播色情、違反政策規定、存在侮辱性含義等情況。

「沉默下來思考了幾十秒，內心OS：WC，我還真沒想過這塊問題」

對于這塊問題，當時在開發時并未考慮完全，因為這個平臺屬于定制化開發的，所以用戶注冊量也不算太大，因此在設計時也沒往這塊多想。

技術總監：沒關系，那假設現在我讓你去解決這個問題，你會如何下手呢？

「當時的我，因為做的都是一些簡單的CRUD/增刪改查項目，所以被問的時候，腦袋有些斷線，心理想的是：明明我都說沒做過了，你偏偏還得往這塊問，這純屬是在存心刁難我胖虎啊！」

但沒辦法，畢竟人家都問了，所以當時硬著頭皮隨便扯，當時的回答大致是這樣的：首先我會在數據庫里設計一張表，或者在后端里面創建一個Map、Set這類的容器，專門用來存儲「違規敏感詞」，當用戶注冊時，在填寫好「昵稱」后，前端采用Ajax異步請求的方式，將用戶輸入的「昵稱」發給后端進行敏感詞檢測。? ? ? ?后端收到前端發送的 Ajax 請求后，拿著用戶的昵稱去和「違規敏感詞」進行匹配，如果用戶輸入的昵稱中包含敏感詞，那就讓前端顯示一下「昵稱違規，請重新輸入」，反之則通過驗證，允許用戶正常注冊。

技術總監：思路不錯嘛，那如果用戶的昵稱有七個字，但其中有兩個字組成的詞語屬于敏感詞，請問如何檢測出來呢？

首先肯定需要先把用戶輸入的昵稱分開，然后再進行敏感詞檢測，但由于個人未處理過該問題，所以目前不清楚具體的做法（其實具體方案是可以借助 ElasticSearch 對用戶輸入的昵稱做分詞處理，然后再對分詞后的結果進行敏感詞檢測，或者可以通過 DFA 算法的方式進行敏感詞檢測）。

技術總監：沒關系，既然你沒具體做過，那咱們先跳過這個話題。

「我心中長呼一口氣，終于跳過這個該死的問題了，再問下去都遭不住了！但沒想到，我以為的結束卻僅僅只是開始！」

技術總監：如果有人通過機器手段，如爬蟲技術對平臺進行賬號的批量注冊怎么辦？? ? ?這點不必擔心啊，因為前面說過的，在注冊時用戶必須要填寫「手機號、或郵箱地址」，然后后端會先向對應的手機號或郵箱發送「驗證碼」，用戶必須要輸入正確的「驗證碼」之后，才能繼續注冊的，而手機號也好、郵箱也罷，基本上同一個人不會有太多個，所以通過「驗證碼」的方式，能夠有效阻止機器批量注冊。

也包括這個平臺其實還支持第三方賬號注冊，也就是通過QQ、微信的方式快捷注冊，這種賬號和「手機號、郵箱」類似，都具備一定的稀缺性，同一個人不會有太多的賬號，所以基于這類稀缺性賬號實現注冊功能，都能有效的避免機器批量注冊。技術總監：好的，那一個手機號或者郵箱允許注冊多個賬號么？

這個是不行的，因為在后端有做唯一性判斷，一個「手機號、郵箱」注冊一次之后，就無法再利用它進行二次注冊了。技術總監：嗯呢，好的。

3.3、第三問：爬蟲惡意調用短信接口做轟炸

技術總監：你有接觸過、或者聽說過短信轟炸嘛？

這個之前接觸過，比如當你在網上和一個人起了爭執，并且對方通過一些手段得到了你的手機號，他就可以拿著你的手機號，放到一些轟炸平臺上去，然后這個平臺就會頻繁的給你發送一些垃圾短信，以此來實現轟炸、騷擾的效果。

技術總監：你說的很對，所謂的短信轟炸就是這么回事，但我想問你個事啊。

技術總監：你前面說過：用戶在注冊時不是可以選擇手機號注冊么？

技術總監：假設有人通過逆向分析，調試出了你們「發送短信驗證碼」的接口，接著用爬蟲技術批量調用該接口轟炸別人怎么辦？

「內心OS：早知道說沒聽過短信轟炸了，我是真嘴欠啊，但后面仔細一想，好像不用擔心這個問題！」

咳咳，對于這個問題嘛，其實也不必擔心，因為當用戶點擊了「發送驗證碼」的按鈕之后，首先會彈出來一個「滑塊驗證碼」，只有當用戶通過「滑塊驗證」之后，才會頒發一個調用接口的「數字簽名」，如果不具備這個簽名，直接調用「發短信驗證碼」的接口時就會返回「權限不足」的提示。

而作為一個正常人，通過「滑塊驗證」自然不成問題，所以當一個“人類用戶”注冊時，肯定是先拿到簽名再調用「發短信」接口，如果出現未攜帶「數字簽名」的請求，自然無法通過調用前的校驗，因此通過這種滑塊驗證碼的方式，就能有效防止爬蟲的暴力調用問題。

其實當初身為一個 CRUD 仔的我，在被問到這個問題之前，一直并不理解為什么要在發送短信之前，增加「滑塊驗證碼」這步反人類操作，畢竟一個簡單的滑塊，就連三歲小孩都能通過，因此當初在開發程序時，思來想去都不能理解這步操作！

技術總監：嗯呢，那如果對方通過 Selenium 這種自動化技術，通過了你們平臺的「滑塊驗證」，又或者說對方又調試出了「數字簽名」的生成接口，從而得到了簽名，依舊可以正常調用「短信」接口怎么辦？

當我聽到這個提問的時候，我很想回答一句：我！不！知！道！我只是一個天天摸魚的螺絲仔，這不是純屬刁難人么！但不懂兩個字決不能從我口中說出，因此當時隨意間就扯了起來！

這個當時沒有考慮到，畢竟前面跟您說過的，這個平臺屬于定制化程序，上線后面對的用戶量并不算大，因此也沒有考慮設計反爬蟲機制，但您所說的這個問題也很好解決，對于一些較為“珍貴”的接口資源，比如目前所說到的短信接口，因為每條發出的短信都需要付費，所以通常情況下都會做調用限制，比如限制十分鐘內只允許調用三次這類的。

技術總監：拿你所說的十分鐘調用三次為例，如果一個人在第九分鐘調用了三次，接著又在第十一分鐘調用了三次，這樣做是不是打破了調用限制呢？你認為是否有更好的方案代替呢？? ? ?當時回答的是：聽您這么說，的確是存在一定的漏洞，從而讓調用限制被打破，但這塊沒有去詳細了解和接觸過，所以并不清楚是否有更好的方案解決此問題。

對于這個問題，當時的確沒有接觸過，現在想來，他想聽到的答案應該是“高并發情況下的限流方案”，而我回答的限流算法，屬于最基本的計數器限流方案，除此之外還有時間窗口限流、令牌桶限流、漏桶限流這三種方案，下面對這幾種常見的限流方案展開聊聊。

同時，對于「發短信」這類“珍貴性”接口，也應該做好接口的安全性設計，比如做好接口的防篡改、防重放，以及通過數字簽名實現接口調用的高鑒權等措施。

3.3.1、計數器限流方案

計數器方案屬于限流算法中最簡單、并且實現難度最低的算法，比如以前面的案例來說，規定了「短信」接口的調用頻率，不允許在十分鐘內超出三次。

這時實現起來就很簡單，在「短信」接口的類中，創建一個Map<String,AtomicInteger>類型的容器即可，其中Key存儲用戶ID，而Value則存儲一個原子計數器，每當一個用戶調用一次短信接口后，就將容器中對應的計數器加一，同時開啟一個定時任務，每十分鐘對計數器做歸零重置。

當然，上述這種做法在用戶量較大的情況下，顯然會對程序造成較大的性能損耗，假設有 100W 用戶，那就需要維護 100W 個計數器，這會使得內存占用率直線飆升，同時還需要創建 100W個 定時器，來分別維護每個用戶的調用計數器。

更好一些的做法是借助中間件實現，比如基于 Redis 緩存中間件來完成，將用戶 ID 設計成 Key，而 Value 則是計數器，并且創建每個 Key 時將過期時間指定為10s，這樣就能充分利用資源，不會造成太大的資源與性能開銷，偽邏輯如下：

@Autowired private?StringRedisTemplate?redis;@RequestMapping("/sendSmsVerification") public?ResultVO?sendSmsVerification(String?sign,?String?userId){//?用?SMS_?拼接用戶ID作為KeyString?userIdSMS?=?"SMS_"?+?userId;//?先通過前面生成的Key去Redis中進行查詢String?value?=?redis.opsForValue().get(userIdSMS);//?如果目前已經達到了調用次數限制if?("3".equals(value))?{return?new?ResultVO(200,?"短信調用次數已達上限，請在十分鐘后重試...");}//?如果該用戶的Key在Redis中不存在，說明是第一次調用短信接口if?("".equals(value))?{//?首次調用短信接口時，則在Redis中創建一個計數器redis.opsForValue().set(lockKey,?1,?10,?TimeUnit.SECONDS);}?//?如果該用戶的Key在Redis中存在，說明并非第一次調用短信接口else?{//?此時則通過Redis的incr命令，把對應的計數器加一redis.opsForValue().increment(key);}//?省略其他業務代碼...... }

這段限流代碼并不算特別復雜，整體下來無非還是前面說的那幾步：

• ①先通過用戶 ID 拼接得到 Key，然后去 Redis 中進行查詢。

• ②如果查詢出的結果為 3，說明目前已達到了調用限制，則直接返回調用已達上限。

• ③如果查詢出的結果為空，則說明用戶是第一次調用短信接口，此時則在 Redis 中創建計數器。

• ④如果查詢出的 value 和上面兩條都不匹配，則對 Redis 中的計數器加一。

這種計數器限流算法實現起來尤為簡單，但前面也聊過它所存在的問題：臨界問題，如果在兩個時間單位的臨界處調用，比如在第9:59秒調用了三次，接著又在第10:01秒調用了三次，那依舊會發生“超出調用上限”的情況，畢竟以十分鐘作為單位，第9、10分鐘屬于一個時間單位內，這時就超出了調用上限，調用次數達到6次。

3.3.2、時間窗口限流方案

時間窗口限流方案被提出的主要目的，就是為了解決傳統的計數器方案存在的臨界問題，它的演變前身為TCP協議的滑動窗口。

限流方案中的時間窗算法，主要可被分為固定窗口限流、滑動窗口限流兩種方案，而前面聊到的計數器方案，實際上就是一種特殊的固定窗口限流方案，在前面的例子中，時間窗口大小為10min，速率限制為3次，這種方案存在明顯的臨界限制問題。

下面重點聊一聊滑動時間窗口，這種方案是解決臨界問題而被提出的，但對于滑動窗口的概念有些不好理解，所以先上一副邏輯圖，如下：

在上圖中，整個用虛紅線圈出來的代表一個時間窗口，以上述例子來說，一個窗口的大小為600s/10min，并且每個窗口被分為了三個單位，每個單位大小是200s，這也就意味著每過200s，窗口會向后滑動一個單位，這個動作也可以被稱之為向后滑動一格，目前的窗口分布如下：

• 第一格：0~200s

• 第二格：201~400s

• 第三格：401~600s

劃分出來的每個格子，都具備各自獨立的計數器，比如在第138s時發生了一次接口調用，此時第一格的計數器就會+1，還是以之前的例子來說：

第9:59秒調用了三次，接著又在第10:01秒調用了三次。

將這里的分鐘轉換為具體秒數，也就是在第599s調用了三次，第601s調用了三次，此時來看，每當時間過去200s，窗口就會向后滑動一格，這也就意味著整個窗口會變成圖中的下面的樣子，此時的窗口分布為：

• 第一格：201~400s

• 第二格：401~600s

• 第三格：601~800s

當第599s調用了三次「短信」接口后，第二格的計數器會累加到3，此時再當第601s嘗試調用「短信」接口時，就會檢測出已達到調用上限，此時就會拒絕用戶的調用，以此來解決傳統計數器方案的臨界問題。

Why？Why？Why？有些小伙伴可能到這里就有些暈了，第601s是如何檢測出調用超額的吶？因為目前的時間窗口范圍是201~800s，而將整個時間窗口內的計數器求和，就會得到調用總次數為3，因而成功檢測出了第601s的調用上限。

當出現調用達到上限時，必須隨著時間推移、窗口不斷向后滑動，這樣整個窗口的計數器總和才會下降，因此用戶才能繼續調用，通過這種方式就能控制一個時間段的絕對限流。但滑動窗口限流方案就不存在臨界問題嗎？答案是No，依舊存在，Why？來看下圖：

看上圖中給出的案例，因為目前的時間窗口大小是600s，而199s~203s顯然處于同一個時間窗口范圍內，但隨著窗口向后滑動，這里依舊會出現臨界問題，也就是在一個窗口范圍內，同樣會出現打破調用次數上限的情況，那這種情況下又該如何解決呢？其實答案很簡單，把一個窗口的格子單位調小即可。

比如直接將每一格的單位大小從200s調整為1s，此時每過一秒鐘，窗口就會向后滑動一格，等到100s秒過后，窗口會向后滑動100格，此時窗口的區間范圍是101~700s，這就將199~203s這個范圍包含了進去，因此上述情況自然就不會出現！

經過上述分析由此可以得出一條準則：當滑動窗口的格子劃分的單位越小，整個窗口中的格子數量會越多，滑動窗口的向后移動就越平滑，限流的統計就會越精確。

3.3.3、令牌桶限流方案

前面簡單聊完了時間窗口限流方案后，接著再來聊一聊大名鼎鼎的令牌桶限流方案，令牌桶算法是一種類似于“池化”思想的產物，算法的大體過程如下：

①初始化令牌桶并設置最大令牌數，當桶內的令牌達到閾值時，新添加的令牌會被拒絕或丟棄。

②根據限流大小，啟動一條線程，并按照一定速率向令牌桶中不斷添加新的令牌。

③任何處于「限流范圍」內的請求，都需要先獲取到一個可用令牌，然后才會被處理。

④當一個請求獲取到可用令牌后，才會真正執行業務邏輯，執行完成后會將此令牌從桶內移除。

⑤令牌桶除開有最大令牌數外，也會有最小令牌數，當桶內令牌數小于最小閾值時，處理完請求并不會移除令牌，而是會將令牌還給令牌桶。

對于令牌桶限流算法，理解起來并沒有前面的滑動時間窗口復雜，但唯一要注意的是：當桶內的令牌被一個請求獲取后，此時并不會立馬從桶內移除，該令牌會依舊停留在桶內，只不過該令牌的狀態會從可用狀態變為不可用狀態，也就是其他請求無法再獲取該令牌，真正移除令牌的工作，會在業務邏輯執行完成之后才觸發。

3.3.4、漏桶限流方案

漏桶限流和令牌桶限流都屬于桶類型的算法，但漏桶算法更類似于MQ消息隊列，其算法的執行示意圖如下：

想要理解漏桶算法，咱們先來看看日常生活中的漏斗，比如現在我要用漏斗來給摩托車加油：

倒油時，我們可以用瓶子，也可以用桶子，也可以用加油槍.....，這也就意味著：漏斗上方的進油速率并不固定，但不管上方的進油速率如何，下方的漏斗出口，其速率確實固定的，無論上方進油多快，都不能影響下方的出油速率。

理解了日常生活中的漏斗后，接著再來看看前面的漏桶限流算法，請求會從漏桶上方進入，而服務端則只會按照固定速率去處理請求。此時思考一個問題：當請求進入的速率大于請求處理的速率，會發生什么情況呢？

此時依舊回到用漏斗給摩托車加油的例子中，如果漏斗上方的倒油速度比較快，而由于漏斗的結構原因，下方的出口跟不上進油速度，此時漏斗中的油量會直線上升，直到超出漏斗的最大容量時，再進入漏斗的汽油會溢出。

而限流中的漏桶算法同樣如此，請求進入的速率大于請求處理的速率時，多出來的請求會被放入桶中等待，當桶內阻塞等待的請求超過最大限制后，后續進入的請求會被丟棄或拒絕。

從上述的講解中，諸位應該能夠明顯感受到漏桶算法的特點，即：寬進嚴出，該算法中不會限制請求進入的速率，但會限制請求處理的速率，一些對穩定性要求較高的系統，就可以采用該算法對系統進行限流。當然，如果熟悉MQ的小伙伴也能感受出：漏桶算法和MQ的削峰填谷有著異曲同工之妙，當系統峰值流量較高時，會將請求寫入到MQ中，然后再由具體的業務服務，按照固定的速率拉取MQ中的消息進行處理。

3.3.5、高并發限流算法小結

在前面共計提到了計數器、滑動窗口、令牌桶、漏桶這四種常規的限流方案，但要記住：并不存在一種適用于任何場景的限流算法，根據業務的需求不同，系統的關注面不同，應當采用不同的限流方案，沒有所謂的最好！最后簡單說一些成熟的限流實現：

• Guava 中的 RateLimiter 工具類：基于令牌桶實現的限流組件，并且對其進行了預熱拓展。

• Sentinel 中的勻速排隊限流策略：基于漏桶思想的限流策略，內部采用隊列進行實現。

• Nginx 的 limit_req_zone 限流模塊：基于漏桶思想的限流模塊，實現網關層的限流控制。

• ........

3.4、第四問：API接口的冪等性問題

技術總監：接下來我們再聊聊其他方面的可以吧？

技術總監：以目前的技術來說，任何用戶在使用網絡時，難免會存在延遲是不是？

對的，這點我深有體會，尤其是在過年回老家的時候，由于山區的網絡覆蓋并不全面，所以在訪問一個網站時，加載的速度會特別的慢。

技術總監：嗯呢，既然你也說了這個問題，那我再問你一個問題。

技術總監：如果一個用戶在注冊時，網絡比較卡頓，所以提交注冊后遲遲沒有反應，因此他又連續點擊了多次「注冊」按鈕，此時會發生什么情況呢？

「我沉思片刻回答道」：如果沒有做任何限制，理論上會向服務端發出多次請求，如果數據庫的表結構設計不合理，那么還會出現同一用戶的注冊信息，在用戶表中被插入多次。

技術總監：說的不錯，那請問你們當時是怎么處理呢？

我們當時處理方案比較簡單，首先在前端做了一定限制，也就是當用戶首次點擊了「注冊」按鈕后，「注冊」按鈕就會變成灰色，也就是用戶再次點擊時，并不會再次發送Post請求向后端提交表單數據。技術總監：那如果用戶看點擊注冊按鈕后遲遲沒反應，按F5刷新或瀏覽器的后退鍵，接著再次點了「注冊」按鈕怎么辦？

「心里一顫，沒想過啊！硬著頭皮解釋道」：對于此問題，我在做登錄注冊時并未考慮周全，未對這個問題進行思考。

但其實現在想來，解決的思想也比較簡單，除開在原本將按鈕變灰的基礎上，再加上一個「重定向頁面」即可，比如信息提交后就跳轉下述這個界面：

這樣做的好處在于：重定向操作發生后，當用戶再次刷新網頁，或者通過瀏覽器的回退鍵，回到原本的界面時，之前表單中填寫的信息并不會保存。這樣做的好處在于：用戶想要再次點擊注冊按鈕，就只能再次重新輸入信息。

在用戶網絡比較卡頓的情況下，做了上述設計后，就只會出現兩種情況：

①用戶上次點擊「注冊」按鈕提交的Post請求發送失敗，服務端并未處理上次的注冊請求。

②用戶上次點擊「注冊」按鈕提交的Post請求發送成功，在用戶再次填寫信息的過程中，服務端將上次的注冊請求成功處理，用戶再次提交注冊時，系統會直接提示去通過手機號登錄。

總之加入了這個「重定向頁面」后，都能保障在短時間內，用戶無法再次重復提交參數相同的注冊請求。

技術總監：那如果有人通過PostMan之類的工具，模擬注冊參數多次調用注冊接口呢？? ? ?這個實際上也不需要擔心的，因為在數據庫的表設計中，我們對「郵箱/昵稱/手機號」這些特殊字段也加了唯一索引，就算特殊情況下造成重復請求出現，由于表結構中有唯一性字段，所以對于相同注冊參數的請求，在用戶表中依舊只會成功插入一條數據。

技術總監：這種方案也可以，但你還有沒有什么其他更好的方案呢？

當時項目是這么做的，所以并未再去對其他方案進行研究。

技術總監：沒事，你等面試結束之后可以再研究一下。

3.4.1、接口冪等性設計的最佳實現

雖然當時并未回答出更好的方案，但后續自己也去了解過「接口冪等性與防重設計」，這里做簡單總結。

產生冪等問題的根本原因 ? ?總的來說，在軟件系統中出現冪等問題的原因無非四個：

①用戶重復提交：一般是指用戶填寫好表單信息后，由于響應較慢，從而多次點擊提交按鈕。

②非法調用：指第三方通過逆向手段調試到了接口地址，然后通過爬蟲或接口工具多次調用。

③失敗重試：指分布式項目中，被調用方出現超時或異常時，觸發了調用方的重試補償機制。

④重復消息：通常指引入MQ的項目，對于同一個消息，生產者多次發送，或消費者重復消費。

會出現冪等問題的操作

作為開發者的我們都知道，任何一個軟件，不管業務多么復雜，其背后的本質依舊是增刪改查，對于刪、查操作而言，天然具備冪等性，因此需要考慮冪等性設計的就只有增、改這兩種，Why？

因為查詢、刪除操作，就算出現多次也并不影響整體數據的一致性，比如查詢“張三”的年齡，同一時間內無論查多少次，得到的結果都是相同的。而刪操作同樣如此，如刪除姓名為“張三”的用戶數據，就算同一時間內出現了十個這樣的請求，最終結果都是“張三”這條數據不見了。

多個層面解決冪等問題的方案

前端：

①按鈕變灰/或變為Load狀態：防止用戶點擊多次按鈕，造成多個重復請求出現。

②重定向頁面：防止用戶通過刷新/回退的方式，造成多個重復請求出現。

后端：

①唯一Key方案：先根據業務參數，從中選出或計算出一個全局唯一Key：

• 唯一Key的計算方案：

  • 選用請求參數中的某個特殊值，如手機號、訂單號...作為Key。

  • 通過Hash函數來對所有參數進行哈希計算，得到一個Key。

  • 非注冊的場景，可以使用當前用戶ID+目標方法名作為Key。

  • .....（這里只要能得到一個與業務相關的唯一Key即可）。

• 得到唯一Key之后，通過set nx px命令向Redis插入數據：

  • 成功：代表前面沒有重復的請求，當前請求可以執行。

  • 失敗：代表前面有相同請求已經插入過了，當前請求需要被丟棄。

②防重表方案：使用業務的唯一ID，如訂單號作為唯一索引，操作之前先插入防重表。

③狀態機方案：在表上多加一個狀態字段，對于update操作加上狀態判斷，如訂單表：

• 將「待付款」改為「待發貨」：update ...,status = 2 where status = 1;

• 這樣就算出現多個修改請求，因為第一個請求改成功后，狀態變為2，其他請求都會失敗。

④Token 方案：內容較多，后面聊。

數據庫：

• 樂觀鎖方案：額外設計一個 version 版本字段，但這種方案只適用于 update 操作。

• 唯一索引：對于數據的關鍵字段加上唯一索引，如手機號，避免重復數據多次插入。

上面根據不同的層面，給出了多種冪等問題的解決方案，但有些方案只適用于特殊的場景，如狀態機、樂觀鎖、防重表等方案，如果要設計一套解決冪等問題的通用方案，選擇如下：

甲、前端重定向頁面防重 + 后端唯一Key去重 + 數據庫唯一索引兜底。

乙、前端按鈕變灰防重 + 后端Token去重 + 數據庫唯一索引兜底。

通過上述這兩套組合方案，任選其一都能夠打造出一套解決冪等問題的通用策略，但其中唯一沒展開講解的則是Token方案，這種方式到底是如何實現的呢？下面展開聊一聊，示意圖如下：

①當用戶進入一個表單時，前端通過Ajax異步調用后端提供的Token獲取接口。

②后端生成一個全局唯一性的Token放入Redis中，可以是UUID、SnowflakeID....。

③后端將生成的Token返回給前端，前端先將其保存在一個變量或Cookie中。

④用戶填寫好表單數據后，在Post請求的頭部攜帶Token值，接著與表單數據一起發給后端。

⑤后端先獲取頭部的Token值，并嘗試去Redis中刪除該Token，即del [token_value]。

⑥后端根據刪除命令的執行結果，進行下一步判斷：

• 如果成功刪除：表示目前請求是第一次調用接口，允許執行具體的業務邏輯。

• 如果刪除失敗：表示該Token之前已經刪過了，當前請求屬于重復請求，應當被丟棄。

上述即是前面所說的 Token 方案，整個過程會出現兩個請求，第一個請求是異步獲取 Token，第二個請求則是具體的業務請求，最后會基于業務請求上攜帶的 Token值，以此作為重復請求的判斷條件，從而避免同時處理多個重復的請求。

3.5、第五問：用戶賬號的合并問題

技術總監：你之前說過，你們項目注冊時，可以選用「郵箱/手機號/第三方賬號」進行登錄是吧？? ? ?對的，用戶可以通過這三種方式來注冊并登錄平臺。

技術總監：那一個用戶通過手機號注冊后，能否綁定第三方賬號呢？? ? ?這個是支持的，在用戶的個人中心里，用戶可以選擇綁定第三方賬號，綁定第三方賬號后，后續用戶也可以直接通過第三方賬號登錄。

技術總監：那假設用戶先通過微信進行第三方登錄，按你們平臺的規則，會自動為其注冊一個賬號。

技術總監：接著該用戶又用手機號注冊了，此時同一個人在你們平臺，是不是有了兩個賬號？

是的，通過微信登錄時，如果之前這個微信沒有綁定過平臺賬號，會為其自動創建一個賬號。用戶通過手機號進行注冊，同樣又會生成一個賬號。

技術總監：嗯呢，那我想問一下，如果這個用戶有一次通過手機號登錄，接著想要綁定那個微信，這樣可以嗎？

我聽到這個問題，第一反應是想回答：“可以”！但轉念一想發現了端倪，如果能綁定同一個微信，豈不是一個微信對應兩個平臺賬號了？假設該用戶下次選擇通過微信掃碼登錄，掃碼成功之后，到底要登入哪個賬號呢？

「我理清思路回答道」：這是不可以的，因為這樣綁定之后，一個微信號會與兩個平臺賬號產生映射關系，下次用戶選擇用該微信號登錄時，就會出現問題，無法確定要登入哪個賬號。

技術總監：既然你能想明白這個問題，那我想問問你有沒有什么好的解決方案呢？

「我聽到這個問題后，陷入了沉默.....」

3.5.1、站在現在的角度再次看待此問題

其實這個問題本身并不是技術問題，而是一個業務問題，所以想要解決此問題，就無法完全依靠程序自己完成，此時必須介入人工進行處理，而這個問題在如今的各大平臺都有解決方案，大體歸為下述五類：

①選擇第三方登錄時，需要用戶通過手機號先創建一個平臺賬號。

②合并多賬號的權利交給用戶自己。

③當用戶嘗試綁定一個「已綁微信」時，提示用戶找管理員申訴。

④允許同一個第三方賬號對應多個平臺賬號，掃碼登錄時，選擇登錄哪個賬號的權利交給用戶。

⑤用戶想要綁定一個「已綁微信」時，提示用戶先去解除該微信與其他賬號的綁定關系。

第一種做法在各大銀行的手機APP中比較常見，當你選擇通過第三方賬號登錄手機銀行時，如果是第一次登錄，微信登錄成功后會跳轉注冊界面，要求你先通過手機號創建一個賬號，接著銀行APP會自動將當前「手機號、微信」產生綁定關系，后續可以兩者中的任一方式登錄。

第二種做法我在簡書見過，當多個賬號之間存在沖突時，將合并賬號的權利交給用戶自己，當用戶選擇保留某個賬號時，其他賬號都會被銷毀，包括其他賬號在平臺上的所有數據也會徹底丟失。

第三種做法我在一些小的自建站見過，其實這是觸發了平臺的「未知操作」的補償機制，由于用戶在嘗試綁定一個「已綁微信」，這種操作在程序后臺無法識別，所以直接給出統一的提示，即：“請聯系管理員進行申訴”，申訴后會由平臺管理員，介入修改后臺數據庫進行處理。

第四種做法在游戲的用戶管理中比較常見，以廣為人知的「王者榮耀」舉例說明，在登錄界面可以選擇通過微信登錄游戲，而微信登錄成功之后，會出現下述這個界面：

在這類游戲中，玩家可以自行選擇分區，同一個微信賬號支持在多個分區創建賬號，這也就意味著一個第三方賬號，可以與多個平臺賬號存在關聯關系，當用戶下次通過該微信賬號登錄時，用戶可以自行選擇具體的分區（具體要登錄的平臺賬號）。

第五種做法屬于最常見的做法，明確規則一個第三方賬號，只能與一個平臺賬號存在綁定關系，當一個賬號嘗試綁定第三方賬號時，如果檢測到對應的第三方賬號存在其他的綁定關系，就直接提示用戶：“該第三方賬號已被其他賬號綁定，請手動解除綁定后重試”！

3.6、第六問：登錄的奪命五連問

技術總監：用戶登錄成功之后，第二天再次打開網站需要重新登錄嗎？

如果用戶登錄成功之后，第二天再次打開網站無需再次登錄，但「免登錄」存在時效限制，一般情況下為7天，也就是距離用戶上次登錄的時間超出七天后，用戶再次訪問網站就需要再次登錄。

實現的大體原理：通過JWT實現，用戶登錄成功之后，后端往Redis中存儲一個時效七天的refresh Token（Key=userID，value=refreshToken），接著會向前端頒發一個時效較短的access Token，前端會將其存儲瀏覽器本地，在后續每次客戶端訪問當前網站時，都會攜帶這個access Token完成鑒權。

頒發給前端的access Token時效為何比refresh Token要短呢？

有些業務對權限比較敏感，為了Token避免被盜用，access Token自然是有效期越短越安全。

時效較短的access Token過期了怎么辦？當一個客戶端攜帶過期的access Token來請求時，服務端可以通過該Token解析出時間戳和用戶信息，效驗時間戳沒有問題后，接著通過用戶信息中的userID去查Redis，如果能夠查詢到對應的refresh Token，此時就可以重新簽發一個access Token返回給前端，前端將之前的Token替換成新的后，再次請求服務端資源。

這個過程會不斷循環，周而復始之，直至服務端Redis中的refresh Token過期為止（過期后需要用戶重新登錄）。

技術總監：用戶登錄成功之后，其他的子系統如何得知該用戶登錄了？

因為不同的子系統都有權限控制，一個用戶在主站登錄成功之后，服務端會向客戶端頒發Token，客戶端可以通過該Token在主站域名下“活躍”，但當客戶端嘗試訪問其他不同域名的子系統時，由于瀏覽器的本地數據（緩存、Cookies等）是按域名區分存儲的，所以訪問其他子系統時并不會攜帶前面主站頒發的Token，最終客戶端的訪問會遭到拒絕。

現如今業務線愈加復雜，因此都會引入分布式概念拆分出不同的子系統，并且不同的業務子系統會采用不同的域名部署，所以想要保證「用戶一次登錄，全線都能訪問」的功能，就需要實現單點登錄功能。在我們項目中，當時通過OAuth2.0整合JWT實現了SSO認證服務，從而最終實現了單點登錄的功能。

簡單概述OAuth2.0 + JWT + SSO實現單點登錄的原理，如下圖：

前提：

①當用戶在訪問任意子系統沒有攜帶Token（Ticket）時，都會被重定向到獨立部署的SSO認證中心。

②如果對應的用戶在SSO服務中找不到登錄憑證，最終會跳轉登錄頁面，要求用戶進行登錄操作。

一次完整的單點登錄過程：

①用戶未攜帶Ticket訪問A系統的某個頁面，被重定向到SSO服務。

②用戶未攜帶登錄憑證訪問SSO認證中心，被重定向到登錄頁面。

③用戶完成登錄操作，在SSO域的Cookie中植入各種憑證，并再攜帶Code重定向到A系統的回調接口。

④用戶攜帶Code訪問A系統，A向SSO請求驗證Code，有效則為A域頒發Ticket，并重定向到原網頁。

⑤用戶攜帶Ticket訪問A系統的原網頁，A向SSO請求校驗Ticket，有效則執行具體的業務邏輯。

⑥用戶訪問B系統的某個頁面（此時無法攜帶A域的Ticket），被重定向到SSO服務。

⑦用戶攜帶SSO-Cookie訪問SSO，該用戶的登錄憑證校驗成功，攜帶Code重定向到B系統的回調。

⑧用戶攜帶Code訪問B系統，B向SSO請求驗證Code，有效則為B域頒發Ticket，并重定向到原網頁。

⑨用戶攜帶Ticket訪問B系統的原網頁，B向SSO請求校驗Ticket，有效則執行具體的業務邏輯。

為什么可以通過Code換Ticket呢？利用OAuth2.0的四種授權方式之一：授權碼來實現。為什么要用Code換Ticket呢？Code是一次性的，降低Ticket被盜用的風險。

技術總監：用戶復制一個登錄后才能訪問的鏈接，然后粘貼到另一個頁面上會怎樣？

這要分情況，如果用戶復制鏈接之后，粘貼在同一個瀏覽器的其他頁面，此時該用戶是可以正常訪問的。但如果用戶復制鏈接粘貼到其他瀏覽器上，在其他瀏覽器未登錄過的情況下，本次訪問都會遭到拒絕。這是因為后端都對用戶做了權限控制，如果未登錄賬號的客戶端，在我們平臺屬于游客級別，而登錄了賬號的客戶端，則屬于正常用戶的級別，不同的用戶級別對應不同角色，不同角色則又對應不同權限，以此來實現權限的精準控制。

這里背后的實現原理就不過多啰嗦了，當時的項目是采用Shrio權限框架實現的，所有的權限、角色、用戶的映射關系，都存儲在數據庫的五張權限表之中（有興趣的可以自行去了解）。

技術總監：用戶點擊登錄之后把當前頁面關了會發生什么？

「思索片刻后不自信道」：額....，應該會登錄成功吧。

技術總監：確定會登錄成功么？

「陷入沉默.....」（內心：我擦，這純屬刁難人啊，那個吃飽沒事干的人，會點了登錄就關網頁！？！！）

站在現在的角度思考：

結論：是否會登錄成功要分實際情況來決定，看用戶關閉的是當前網頁，還是當前的瀏覽器。

用戶關閉了當前網頁，結果是會登錄成功。用戶關閉了當前瀏覽器，結果是不一定登錄成功。

原理分析：關閉當前網頁：因為用戶點擊登錄按鈕之后，登錄（賬號、密碼）的請求已經發往了服務器，所以服務端處理完登錄請求后，最終會返回一個Token或登錄憑證，此時由于瀏覽器進程還在，這也就意味著瀏覽器自帶的網絡進程并未消失，所以登錄效驗成功之后的操作，如在Cookie中植入Token、各類憑證等操作依舊能正常完成，所以理論上會登錄成功。

關閉當前瀏覽器：這種情況下，用戶點擊登錄按鈕后，依舊會向服務器發出登錄請求，但由于瀏覽器已經被關閉了，所以相應的網絡進程也會消失，最終就會出現一種特殊現象：「當服務端處理完登錄請求后，向客戶端返回響應結果時，由于客戶端的網絡進程已經銷毀，所以瀏覽器無法接收響應結果，也就自然無法在Cookie中植入各種登錄憑證，最終結果就不一定登錄成功」。

疑惑解答：

為什么關閉瀏覽器之后無法接收服務端的響應結果？

因為HTTP/HTTPS協議的底層是TCP協議，TCP是一種雙向通信的網絡協議，當通信的一端出現故障時，兩端之間的網絡數據就無法正常傳輸，期間TCP的發送方會多次重新發送數據包，但由于接收端的網絡進程已銷毀，所以無法收到響應結果。

為什么關閉瀏覽器的結果是不一定登錄成功？因為存在不穩定因素，畢竟大多數進程在退出時，采取的措施都是優雅關閉，也就是會先處理完目前正在執行的任務后，才會真正將所有后臺進程退出（也就是大家關閉一個程序之后，電腦管家都會提醒你XX軟件還有殘留進程可清理的原因）。

如果關閉瀏覽器之后，網絡進程沒有立馬銷毀，在這期間可能會正常收到服務端的響應結果，最終就會登錄成功。

但如果服務端的響應時間比較慢，或者用戶安裝了電腦管家之類的程序，在進程退出后也許會自動清理殘留進程，這種情況下就會徹底銷毀網絡進程，此時結果就是登錄失敗。

技術總監：用戶點擊登錄之后把網線拔了，你認為結果是怎么樣的？

「當時的心情：.....................................」

「當時的內心：我去，你*&#...~-/！，前面的點登錄按鈕后關頁面就夠離譜了，你現在又整一個拔網線...，你怎么不問我用戶點擊登錄之后，地球就爆炸了會怎樣呢？？？」

「我的回答」：不知道！（當時到這里心態都被問出一點問題了）

以現在的知識儲備進行理性思考：

結論：具體要看用戶拔網線的時機，結果依舊可能是登錄成功或登錄失敗。

如果用戶在響應結果回來之后拔了網線，結果是登錄成功。但如若響應回來之前拔了網線，結果是失敗。

原理分析：

這個問題其實和上一個問題類似，但實際情況又存在很大差異，因為不管什么時候拔網線，本質上瀏覽器的網絡進程都不會消失，問題在于網絡傳輸鏈路出了問題。

對于接收到響應結果之后才拔網線的情況，理解起來也比較容易，畢竟響應結果都拿到了，剩下的工作自然也能進行，最終結果就必然是登錄成功。但此時重點要說明的另一種情況，也就是：為什么在響應結果回來之前，拔掉網線的結果是登錄失敗？

想要明白這個問題，本質上與計算機網絡的基礎脫不了干系，眾所周知的一點，現如今的互聯網是由一個個局域網組成的，由于IP屬于珍貴性資源，所以并不是每臺網絡設備都具備公網IP，而恰恰遠距離的網絡通信需要公網IP，此時又該怎么辦呢？那也就是多臺網絡設備共享一個公網IP，這些共享一個公網IP的多臺機器，會組成一個小的局域網（如果理解比較困難，可以這樣理解：插同一個路由器網線、連同一個路由器WiFi的設備，都可以看成是一個局域網內的設備）。

有了上述知識的簡單儲備后，接著再回到問題本身進行探討，當用戶的瀏覽器發出登錄請求，并且服務端將用戶的登錄請求處理完成后，經一系列處理會產生一個數據報文，該報文的目標地址就是發出登錄請求的那臺機器（實際上是那臺機器所在的局域網的公網IP），接著響應報文會先來到機器所在的局域網，但此刻問題來了！

響應報文已經抵達了局域網，不過此刻用戶的電腦網線被拔，也就是對應設備會退出這個局域網，那么局域網的路由器在“派送數據報文”時，就無法找到具體的派送目標，但此時用戶電腦上的瀏覽器網絡進程依舊存在，只是由于傳輸鏈路出現故障，所以無法接收到響應結果，最終導致登錄失敗。

這種情況就相當于買快遞，原本你寫的是收貨地址A，當快遞送到A小區的菜鳥驛站時，結果你搬家搬去了B小區，這時A小區的驛站派送員，就無法根據收貨地址將快遞送貨上門。

當然，還有一種特殊情況，也就是用戶把網線拔了之后，又立馬插上去了，這時理論上還是會登錄成功的，因為HTTP底層的TCP協議，是一種可靠性傳輸協議，在傳輸失敗的情況下會有重發機制。

3.7、第七問：令人窒息的多IP并發操作

技術總監：一個賬號在多臺電腦上同時點擊登錄按鈕，最后會出現什么情況呢？

「吸收前面的教訓，聽到這個問題的我，第一反應就是這里面絕對有詐！」

「經過一番思考后，回答道」：應該都會登錄成功。

技術總監：哦？也就是你們的項目中，并未限制多IP登錄，或者做同端互斥對嗎？

「我仔細想了想，好像確實沒做，于是回答道」：在我們的項目中確實沒做這些。

技術總監：那假設一個賬號在兩個IP上登錄了，同時修改昵稱會發生什么變化？

有一個IP上修改的昵稱，會被另外一個IP上的昵稱替代掉。因為就算兩個IP同時修改、同時提交，最終到數據庫執行update語句時，都會被串行化，因為兩個事務并發修改同一行數據時，需要先獲取行鎖資源，這也就意味著這兩個修改操作最終都有前后之分，前一個IP修改的昵稱總會被后一個IP修改的昵稱覆蓋掉。

技術總監：嗯呢，那在不限制多IP登錄的情況下，你有什么好的辦法結果這個問題嗎？

「仔細推導一番后，回答道」：可以加入一個中間狀態，也就是在用戶表中多設計一個狀態字段，0代表正常狀態，1代表審核狀態，當用戶的信息發生變化后，對應的用戶記錄都會被改成「審核中狀態」，而執行語句時只允許修改正常狀態的用戶記錄，偽SQL如下：

--?之前的SQL語句 update?zz_user?set?user_name?=?"888",?...?where?user_id?=?888;--?優化后的SQL語句 update?zz_user? set?user_name?=?"888",?status?=?1,?...? where?user_id?=?888?and?status?=?0;

通過這樣的手段，在第一個IP修改成功之后，第二個IP就無法滿足SQL語句的執行條件，最終就無法真正修改用戶數據。

技術總監：很不錯的思路，的確能夠解決我所提出的問題。

技術總監：如果現在有一個簽到領積分的功能，兩個不同IP的同一賬號同時簽到，會不會領到雙倍積分？

如果沒有做任何限制措施，這種情況下應該會領到雙倍積分，但前提是兩個IP是以絕對手段進行同時操作的才行，也就是服務端中同一時間內，兩條線程并行處理兩個IP的簽到請求。

技術總監：嗯呢，那如果你項目中有訂單功能，一個IP刪除訂單，一個IP結算訂單，兩個操作同一時刻內進行，結果是什么呢？

會出現問題，導致一個賬號上的訂單數據錯亂。

技術總監：那你認為該怎么解決此問題呢？

當時的我聽到這個問題，心里的第一想法：得加鎖，但又轉念一想，似乎發現了不對勁，因為加鎖只能讓并行操作串行化，但最終兩個業務操作總會執行的，這里加鎖之后只會出現兩種情況：

①刪除訂單的請求先獲取鎖，先刪掉了訂單，結算訂單的請求無法執行結算業務（因為訂單都沒了）。

②結算訂單的請求先拿到鎖，用戶付錢結算了訂單之后，刪除訂單的請求獲取到了鎖，然后把用戶已經付錢的訂單刪了（這顯然更不合理，用戶估計能舉起四十米的大刀...）。

「由于當時的我沒做過并發處理，就只懂一些簡單的多線程理論，于是又陷入了沉默.....」

站在如今的角度出發，再次看待此問題，解決方案為：狀態機！啥意思呢？其實和之前「并發修改昵稱」的方案差不多，單獨的靠加鎖無法解決此問題，問題并不在這上面，這同樣是個業務邏輯的問題，應該在訂單表上面也設計一個status狀態字段。

訂單表的狀態字段，可選狀態如下：

• 0：待結算（待支付）。

• 1：待發貨。

• 2：待收貨。

• 3：已簽收。

• .....

• 9：已銷毀。

有了上述這個狀態機字段后，再回過頭來看「刪除訂單、結算訂單」這兩個業務操作，本質上都是執行update操作，刪除是將狀態改為9，結算是將狀態改為1，所以SQL語句只需要新增一個條件即可：-- 刪除訂單（只允許刪除待結算、已簽收的訂單）

update?zz_order?set?status?=?9,...?where?status?=?0?or?status?=?3; --?結算訂單（只允許結算待支付的訂單） update?zz_order?set?status?=?1,...?where?status?=?0;

也就是直接通過狀態字段限制其他并發操作，無論「刪除訂單、結算訂單」誰先執行，另一個操作都無法繼續執行。有人也許會疑惑：有了狀態機之后，就不需要加鎖了嗎？

其實這種情況下，加不加鎖就無所謂了，因為MySQL-InnoDB本身有行鎖機制，多個事務并發修改同一條數據，都會被串行化執行，因此在后端加鎖，只是將請求串行化的工作提前罷了，這反而會影響整體的性能。

「其實到這里還并未結束，后來這位面試官還與我聊了許多，但由于時間較為久遠，就只能回憶起一些印象比較深刻的提問了~」

四、這段難忘經歷給我帶來的感悟

可能看到這里，大家很感興趣的一點是：后來的我怎么樣了？其實這次面試之后，當時的我不氣餒是不可能的，甚至那時的我被打擊的有些嚴重，自以為不可一世的我，結果死在了“最簡單的登錄注冊”上....

結束了這次面試后，我并未再繼續投遞簡歷，但人總得吃飯是不？于是乎，我又使出了另一種赫赫有名的面試秘法 —— 朋友內推，在第二天以滿意的薪酬，成功入職了另一家公司~

當然，其實后來這家外企的人事也在后面一周的周一，給我打來了入職邀約的電話，但由于我已經入職了朋友公司，所以用「臨時有事，不方便過去入職」的理由拒絕了（我原本以為自己肯定涼了，畢竟三四天都沒有給我通知，但后面轉念一想，畢竟這是外企的分公司，可能是入職審批流程比較長）。

不過令人出乎意料的是：在當天的下午，該外企的人事總監又打來了一個電話邀請我入職，說他們技術總監比較看好我，感覺我很具備培養價值....，而且這回的入職邀約中，可能以為我上次拒絕是薪資不滿意，還額外在我報價的基礎上加了1.5K的工資（這對當時的我來說，雖然不算特別多，但每個月多出1.5K也是一筆不菲的收入），不過最終還是因為多方面的原因拒絕了，哈哈（其實早兩天打給我說不定真的會過去~）。

雖然這次面試帶給我的打擊很大，但從中我的收獲也不小，其實總的來說也算咎由自取，畢竟當時的我的確很驕傲，而這位 CTO 則用我當時認為“最簡單的業務”，將我虐的體無完膚，從這段經歷中我想明白了一個道理：謙虛戒驕才是真正的大佬應有的美德。

當然，說了這么多的過程，最后也來聊聊這段經歷帶給我的感悟，捫心自問，其實這位面試官也是人生中的一位“貴人”，從他身上我看到了很多之前并不知曉的道理。

4.1、千萬不要抱怨自己只是個CRUD的螺絲仔

在現在的開發環境中，很多人都會抱怨工作：“天天都是負責業務的增刪改查，這種日子什么時候是個頭啊，不想一直再做CRUD的螺絲仔了”！擁有這種心態的人不在少數，誰的心里都有個夢，起初的我也并不例外，「架構師、CTO、技術總監、技術專家.....」，面對這一個個高大上的職位，曾經的我也憧憬過，時常幻想著什么時候我也能成為這樣的人啊，這頭銜說出去就倍有面子.....

但等到了這些職位的時候，你會發現每天的工作還是和業務打交道，泡泡茶暢談未來技術？用技術在項目中指點江山？沉淪在技術中做架構選型？其實這些都不存在，每天其實依舊在圍繞著業務兜兜轉轉，「高職技術人」和「普通開發者」之間，唯一區別就是把敲簡單的業務代碼這項工作，換成了其他更為艱難的任務。

當然，話再說回主題，既然目前無法在項目中用到各種新技術，目前的CRUD無法給自己帶來技術成長，那我們要做的就是：在有限的空間內做到“無限”的發展，其實就算最普通的業務也能玩出不同花樣，業務的增刪改查想要做好也并不容易，比如怎樣才能讓代碼更整潔、能否讓程序拓展性更好？如何才能讓代碼跑的更快.....，動才能改變，抱怨再多也改變不了自身。

4.2、牢記謙虛戒驕，人外有人天外有天

這個道理應該是本次經歷中，帶給我感悟最深的一條，作為技術人覺得自己牛可以，但千萬不要驕傲，也不要在面試中、同事交談中、群聊討論中.....表露出來，因為永遠會有人比你更厲害，不要為了虛榮心去刻意“攀比”，否則最終倒霉的還是自己，舉個很常見的案例：

如果當過面試官的小伙伴應該都遇到過一種情況，也就是候選者在面試時有些刻意裝逼，這樣的候選者在面試時，往往都會遭到面試官的無情打壓，最簡單的做法就是連環炮問法，從基礎入門問源碼原理，從API調用問到操作系統實現.....直到最后被問到啞口無言。

擁有自信是好事，但千萬不要自信過頭，牢記謙虛戒驕，因為人外有人天外有天。比如我，原以為自己的技術已達巔峰造極，但經過這次面試后，發現自己理解的一些東西都是浮于表面的假象，看似駕輕就熟，實際上只是上層特性的搬磚工，學習和學會，壓根是兩碼事！

4.3、再牛的技術也永遠是為業務所服務

在IT開發行業，其實有不少人抱著做純技術開發的念想，至少我遇到過的不在少數，不想去重復做單純的業務開發，但也請牢記：技術驅動業務，但技術也永遠是為業務提供服務。

當然，想做純技術開發也并非不行，但國內這樣的人很少，或者說國內這樣的崗位比較少，除開少數中間件開發、開源技術研發、基礎平臺開發等工作外，大多數崗位都需要和業務打交道，所以在學習新技術時也萬萬不要忘了業務，等你吃透某一行業的業務時，也許給你帶來的好處會勝過技術的收益。

總結

以上是生活随笔為你收集整理的过于自信，面试普通Java岗被面试官吊打了。。。的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。