公衆號後臺回覆“面試”，獲取精品學習資料
掃描下方海報瞭解專欄詳情
https://juejin.im/post/5d0a298bf265da1b827aa06f
《Java工程師面試突擊（第3季）》重磅升級，由原來的70講增至160講，內容擴充一倍多，升級部分內容請參見文末
前言：多賬戶登陸
1. 創業初期
用戶名密碼註冊登陸
手機號註冊登陸
2. 數據庫設計
3. 引入第三方賬戶方案
4. 數據庫設計
5. 總結
前言：多賬戶登陸
互聯網應用當中，我們的應用會使用多個第三方賬號進行登錄，比如：網易、微信、QQ等，我們把此稱爲多賬戶統一登陸。
通過這篇文章， 我想闡釋多賬戶登陸的技術方案細節，以及相應的表設計，流程設計。我這裏不會有具體代碼實現細節，只要方案做的對，有思路，代碼咋寫都不會太爛。
1. 創業初期
歸結爲創業初期是因爲這個時候用戶量比較少，甚至還沒有接入上面所說的其他第三方的賬戶系統，只是自建的體系就可以滿足，自建體系的話，目前常用的有如下解決方案:
用戶名密碼註冊登陸
這種方式在很多初期網站建設會使用，先註冊，再進行登錄，在老一點的cms中都能找到這個影子。流程圖如下：
流程說明：
前端將用戶名、密碼發送到服務器，服務器進行常規的判斷，判斷用戶名、密碼長度是否滿足，用戶名是否重複等條件，條件不通過直接返回對應錯誤碼給到前端，這裏密碼字段，爲了防止傳輸過程中被截胡，建議加密再上傳，我們的傳輸密碼默認都是會進行一個md5加密，然後記錄到數據庫再進行一層加密，就算是脫庫也沒事，密碼不要明文存儲。
校驗通過後，就將用戶名密碼寫入數據庫，並進行後面積分發放等操作，這裏不展開。
現在進行登錄，前端將用戶名，密碼發送給到服務端，服務端首先會校驗登錄次數是否超過設置的閾值，如果超過只能繼續等待被關小黑屋。
如果未超過繼續登錄邏輯，判斷用戶名、密碼是否正確，不正確密碼則進行閾值的判斷，如果超過則關小黑屋，記住小黑屋必須設置過期時間，要不然就會永久關上了，這個可以用redis的過期來做。
登錄成功後進行後續的一切後置邏輯，比如加積分等操作。
手機號註冊登陸
短信業務非常成熟，使用手機號註冊方便快捷。其流程如下：
流程說明：
首先輸入手機號，然後發送到服務端，服務端將手機號記錄在我們數據庫中，然後生成隨機驗證碼，並將手機號和驗證碼綁定到一個redis裏面，然後記錄過期時間，這個過期時間一般是10分鐘左右，這就是我們一般手機驗證碼的有效期。
手機接收到手機短信後，那麼就在界面填寫驗證碼發送服務端，服務端收到驗證碼後就會在redis裏面查詢到這個手機號對應的驗證碼，失敗就返回錯誤碼。
成功後就進行登錄操作。
這裏看起來沒有明確的註冊登錄操作，其實在發送手機號碼就可以認爲是一個常規的註冊，然後後面的驗證碼輸入就是一個登陸操作
問： 那我要密碼咋辦？
答： 在後續產品裏面增加一個手機號碼密碼補錄的功能即可，這也是現在很常規的手法，但是現在移動互聯網大爆炸時代，密碼已經顯得不是那麼重要了，反正我從來記不住密碼，如果手機號碼能操作的app，絕對不用密碼來操作。
2. 數據庫設計
表結構
說明: 這裏只是單純說明需要用到的數據，沒有擴展具體場景,這個表結構能夠滿足上面兩個方案的設計。
3. 引入第三方賬戶方案
這裏是以QQ-SDK的登錄邏輯， 我們先來一波時序圖:
實現思路：
客戶端自己調起登錄的界面，進行輸入用戶名、密碼，這裏的是第三方的用戶名，密碼，登錄成功後，會返回access_token openid expire_in,這過程會使用到oauth2.0，不過在sdk裏面進行內置回調獲取了，後面我們會說明我們自身實現的oauth2.0
客戶端拿到access_token、openid、login_type（qq、wechat…）請求應用服務器，應用服務器拿到這些數據後就會根據對應的login_type去對應的用戶中心進行access_token和openid進行校驗。
校驗不通過則返回對應錯誤碼
校驗通過後就會判斷本地是否有這個login_type和openid是否存在，不存在則進行獲取遠程的用戶名、頭像等基礎信息來作爲本地基礎數據，並且返回code值
如果已經存在，那就是進行登錄操作，返回code值。
客戶端拿到code值後進行token值的換取，這個完全遵照oauth2.0的協議來走的，後續每次請求必須帶上token，token值在服務端的時間比較久，因爲我們想要做的是那種永不下線的操作，所以每次請求我們都將token過期時間進行累加。
4. 數據庫設計
表結構
數據庫的整理 用戶基礎表（users）:
用戶驗證關聯表（user_auth_rel）
本地用戶表（user_local_auth）
第三方用戶表（user_third_auth）
說明
users表只是單純針對我們業務側的登錄，主要是做自身業務的oauth2.0業務，
user_local_auth是做自己用戶名、密碼登錄，手機號碼登錄信息記錄，
user_third_auth是我們第三方用戶體系的數據記錄，
user_auth_rel是用來關聯我們users表與user_local_auth、user_third_auth。
整個設計理念就是將自建用戶與第三方在存儲上區分，這在架構演進上也是合乎情理的，開始用戶體系大多自建，而後纔是對外接入。
5. 總結
總的來講，第三方用戶的接入技術上來講是比較簡單的，這裏設計多一個user_thirds是可以支持足夠多的第三方接入，當然一般我們也就兩三個登錄就好，太多登錄方不僅自身維護成本，界面擺盤也不好看不是。
希望大家能夠通過以上學習，能夠對於我們多賬戶登錄有一個比較好的認知，這裏設計方案不包含分表分庫、沒有服務化，就是簡單直接的設計，當然用戶量和需要的不一樣，在這個基礎上還要加很多東西
END
《Java工程師面試突擊第三季》加餐部分大綱：（注：1-66講的大綱請掃描文末二維碼，在課程詳情頁獲取）
詳細的課程內容，大家可以掃描下方二維碼瞭解：
