使用者系統，主要分為賬號體系和使用者資訊兩大類。賬號體系包括，登陸驗證、註冊、第三方授權、以及許可權管理。使用者資訊包括，使用者地理位置、使用者屬性、使用者裝置資訊、還有使用者日誌資訊。本文會介紹使用者系統的具體落地方案。

登陸驗證

使用者身份與登入的授權方式是獨立開的，即使用者uid和登入方式是一對多的關係。舉例來說，使用者A在使用微博授權登陸後，服務端鑑別身份資訊為uid=123。使用者A下次使用微信登陸，服務端鑑別身份同樣為uid=123。不存在同一使用者A擁有多個賬號資訊的現象。

使用者資訊

使用者資訊，為便於擴充套件，分成兩類。使用者基礎資訊和使用者拓展資訊。基本資訊用來儲存使用者的基本屬性，年齡、性別、生日、頭像、手機號碼等。擴充套件資訊，用來儲存使用者的裝置資訊或其他可擴充套件的內容。另外還有位置資訊，這個可獨立出來，也可合併到擴充套件資訊中，根據自己的使用場景來定。

使用者日誌資訊

日誌資訊，用來儲存使用者註冊或者登陸行為的。另外會有一些修改密碼或者修改重要資訊的日誌記錄。

全域性uid

建議不要使用表的主鍵作為使用者ID，而是使用ID生成器(發號器)生成使用者的唯一標示guid。當用戶量急劇上升時，往往會採取分庫分表的方法，然後透過將uid取餘寫到不同的表中。如果單純的以某個表主鍵作為ID。會限制插入效能和增加業務複雜度,其次在分散式資料庫中也無法保證ID唯一性。

全域性ID生成，是有很多方案的。簡單一點，可以採用redis自增屬性，因為其具有原子性，在分散式壞境中，能保證ID的唯一性。另外還有其他的一些開源方案，可自行Google。

Access Token

與傳統的Session相比，Access Token比較適合做RESTful Api開發。傳統Web應用中，使用者登陸後會寫使用者資訊到cookie中，服務端透過Session就能得到使用者的身份。

Access Token的是OAuth2.0中使用者經過授權後，返回呼叫API的憑證。對於自己的應用來講，使用者在登入後，即返回accesstoken。在token有效期內可憑藉此憑證，呼叫其他介面。對於accesstoken的重新整理有兩種方案，第一種每次使用者重啟app時，重新refresh。第二種，在呼叫週期內服務端發現access token可能過期時，返回新的token給客戶端。

至於Access Token的生成，這個並沒有規定，只要保證其唯一性即可。簡單點，對使用者uid和當前時間雜湊得到新的Access Token，並設定過期時間。另外也可以採用JWT實現。