• 前言：多賬戶登陸
• 1. 創業初期
• 使用者名稱密碼註冊登陸
• 手機號註冊登陸
• 2. 資料庫設計
• 3. 引入第三方賬戶方案
• 4. 資料庫設計
• 5. 總結

前言：多賬戶登陸

1. 創業初期

使用者名稱密碼註冊登陸

1. 前端將使用者名稱、密碼傳送到伺服器，伺服器進行常規的判斷，判斷使用者名稱、密碼長度是否滿足，使用者名稱是否重複等條件，條件不透過直接返回對應錯誤碼給到前端，這裡密碼欄位，為了防止傳輸過程中被截胡，建議加密再上傳，我們的傳輸密碼預設都是會進行一個md5加密，然後記錄到資料庫再進行一層加密，就算是脫庫也沒事，密碼不要明文儲存。
2. 校驗透過後，就將使用者名稱密碼寫入資料庫，並進行後面積分發放等操作，這裡不展開。
3. 現在進行登入，前端將使用者名稱，密碼傳送給到服務端，服務端首先會校驗登入次數是否超過設定的閾值，如果超過只能繼續等待被關小黑屋。
4. 如果未超過繼續登入邏輯，判斷使用者名稱、密碼是否正確，不正確密碼則進行閾值的判斷，如果超過則關小黑屋，記住小黑屋必須設定過期時間，要不然就會永久關上了，這個可以用redis的過期來做。
5. 登入成功後進行後續的一切後置邏輯，比如加積分等操作。

手機號註冊登陸

1. 首先輸入手機號，然後傳送到服務端，服務端將手機號記錄在我們資料庫中，然後生成隨機驗證碼，並將手機號和驗證碼繫結到一個redis裡面，然後記錄過期時間，這個過期時間一般是10分鐘左右，這就是我們一般手機驗證碼的有效期。
2. 手機接收到手機簡訊後，那麼就在介面填寫驗證碼傳送服務端，服務端收到驗證碼後就會在redis裡面查詢到這個手機號對應的驗證碼，失敗就返回錯誤碼。
3. 成功後就進行登入操作。

2. 資料庫設計

3. 引入第三方賬戶方案

1. 客戶端自己調起登入的介面，進行輸入使用者名稱、密碼，這裡的是第三方的使用者名稱，密碼，登入成功後，會返回access_token openid expire_in,這過程會使用到oauth2.0，不過在sdk裡面進行內建回撥獲取了，後面我們會說明我們自身實現的oauth2.0
2. 客戶端拿到access_token、openid、login_type（qq、wechat…）請求應用伺服器，應用伺服器拿到這些資料後就會根據對應的login_type去對應的使用者中心進行access_token和openid進行校驗。

1. 校驗透過後就會判斷本地是否有這個login_type和openid是否存在，不存在則進行獲取遠端的使用者名稱、頭像等基礎資訊來作為本地基礎資料，並且返回code值
2. 如果已經存在，那就是進行登入操作，返回code值。
3. 客戶端拿到code值後進行token值的換取，這個完全遵照oauth2.0的協議來走的，後續每次請求必須帶上token，token值在服務端的時間比較久，因為我們想要做的是那種永不下線的操作，所以每次請求我們都將token過期時間進行累加。

4. 資料庫設計

1. users表只是單純針對我們業務側的登入，主要是做自身業務的oauth2.0業務，
2. user_local_auth是做自己使用者名稱、密碼登入，手機號碼登入資訊記錄，
3. user_third_auth是我們第三方使用者體系的資料記錄，
4. user_auth_rel是用來關聯我們users表與user_local_auth、user_third_auth。
5. 整個設計理念就是將自建使用者與第三方在儲存上區分，這在架構演進上也是合乎情理的，開始使用者體系大多自建，而後才是對外接入。

5. 總結

希望大家能夠透過以上學習，能夠對於我們多賬戶登入有一個比較好的認知，這裡設計方案不包含分表分庫、沒有服務化，就是簡單直接的設計，當然使用者量和需要的不一樣，在這個基礎上還要加很多東西，謝謝大家閱讀，喜歡文章歡迎轉發，點贊。

作者丨低調的碼農;來源：