可以學到：多用戶下面的技術方案細節(jié)，以及相應的表設計，流程設計。

不可以學到：與其他文章一樣，我這里不會有具體代碼實現(xiàn)細節(jié)，方案做的對，代碼咋寫都不會太爛。

前端將用戶名、密碼發(fā)送到服務器，服務器進行常規(guī)的判斷，判斷用戶名、密碼長度是否滿足，用戶名是否重復等條件，條件不通過直接返回對應錯誤碼給到前端，這里密碼字段，為了防止傳輸過程中被截胡，建議加密再上傳，我們的傳輸密碼默認都是會進行一個md5加密，然后記錄到數(shù)據(jù)庫再進行一層加密，就算是脫庫也沒事，密碼不要明文存儲。

校驗通過后，就將用戶名密碼寫入數(shù)據(jù)庫，并進行后面積分發(fā)放等操作，這里不展開。

現(xiàn)在進行登錄，前端將用戶名，密碼發(fā)送給到服務端，服務端首先會校驗登錄次數(shù)是否超過設置的閾值，如果超過只能繼續(xù)等待被關小黑屋。

如果未超過繼續(xù)登錄邏輯，判斷用戶名、密碼是否正確，不正確密碼則進行閾值的判斷，如果超過則關小黑屋，記住小黑屋必須設置過期時間，要不然就會永久關上了，這個可以用redis的過期來做。

登錄成功后進行后續(xù)的一切后置邏輯，比如加積分。。。等操作。

首先輸入手機號，然后發(fā)送到服務端，服務端將手機號記錄在我們數(shù)據(jù)庫中，然后生成隨機驗證碼，并將手機號和驗證碼綁定到一個redis里面，然后記錄過期時間，這個過期時間一般是10分鐘左右，這就是我們一般手機驗證碼的有效期。

手機接收到手機短信后，那么就在界面填寫驗證碼發(fā)送服務端，服務端收到驗證碼后就會在redis里面查詢到這個手機號對應的驗證碼，失敗就返回錯誤碼。

成功后就進行登錄操作。

客戶端自己調(diào)起登錄的界面，進行輸入用戶名、密碼，這里的是第三方的用戶名，密碼，登錄成功后，會返回access_token openid expire_in,這過程會使用到oauth2.0，不過在sdk里面進行內(nèi)置回調(diào)獲取了，后面我們會說明我們自身實現(xiàn)的oauth2.0

客戶端拿到access_token、openid、login_type（qq、wechat...）請求應用服務器，應用服務器拿到這些數(shù)據(jù)后就會根據(jù)對應的login_type去對應的用戶中心進行access_token和openid進行校驗。校驗不通過則返回對應錯誤碼

校驗通過后就會判斷本地是否有這個login_type和openid是否存在，不存在則進行獲取遠程的用戶名、頭像等基礎信息來作為本地基礎數(shù)據(jù)，并且返回code值

如果已經(jīng)存在，那就是進行登錄操作，返回code值。

客戶端拿到code值后進行token值的換取，這個完全遵照oauth2.0的協(xié)議來走的，后續(xù)每次請求必須帶上token，token值在服務端的時間比較久，因為我們想要做的是那種永不下線的操作，所以每次請求我們都將token過期時間進行累加。

users表只是單純針對我們業(yè)務側的登錄，主要是做自身業(yè)務的oauth2.0業(yè)務，

user_local_auth是做自己用戶名、密碼登錄，手機號碼登錄信息記錄，

user_third_auth是我們第三方用戶體系的數(shù)據(jù)記錄，

user_auth_rel是用來關聯(lián)我們users表與user_local_auth、user_third_auth。

整個設計理念就是將自建用戶與第三方在存儲上區(qū)分，這在架構演進上也是合乎情理的，開始用戶體系大多自建，而后才是對外接入。

總的來講，第三方用戶的接入技術上來講是比較簡單的，這里設計多一個user_thirds是可以支持足夠多的第三方接入，當然一般我們也就兩三個登錄就好，太多登錄方不僅自身維護成本，界面擺盤也不好看不是。

希望大家能夠通過以上學習，能夠?qū)τ谖覀兌噘~戶登錄有一個比較好的認知，這里設計方案不包含分表分庫、沒有服務化，就是簡單直接的設計，當然用戶量和需要的不一樣，在這個基礎上還要加很多東西，謝謝大家閱讀！！!