使用者系統使用 email 來做使用者名稱，但在資料庫中的唯一標識是一個 uid 。使用者應該允許修改登陸名（使用者很可能更換 email）。使用者的身份識別是用 id 來定位的。所以，在資料庫中就應該有如下幾組 Key ：

• account:count id
• account:userlist set(id)
• account:email:[email] id

這裡，account:userlist 對應的 value 是一個 set ，裡面存放了所有存在的 user id 。用於遍歷所有的 user 。這個暫時可能用不上，而且當用戶量相當大的時候可能有問題。不過暫時不用考慮這麼多問題，等以後改進。

account:count 是一個計數器，可以用來生成唯一 id 。

account:email:[email] 用來標示每個註冊的 account 的登陸名。[email] 指登陸用 email 地址。

這裡，email 內可能也存在符號 ":" ，為了迴避這個問題，許多對 email 進行編碼。我的方案是，將字母數字 @ . _ 之外的字元編碼為 %XX 的形式。用 lua 幹這件事情非常簡單：

local function _encode(str)
    return string.format("%%%02X",string.byte(str))
end

function emailEncode(str)
    return string.gsub(str,"([^%
 
[email protected]])",_encode)
end

當然，解碼回來也很簡單

local function _decode(str)
    return string.char(tonumber(str,16))
end

function emailDecode(str)
    return string.gsub(str,"%%(%w%w)",_decode)
end

之後，就是 account 下每個 id 的資料：

• account:[id]:version number
• account:[id]:email string
• account:[id]:password string // md5(password..salt)
• account:[id]:nickname string
• account:[id]:lastlogin hashes
  • ip string
  • time string
• account:[id]:history list(string)
• account:[id]:available enum(open/locked/delete)

其中，密碼不想儲存為明文。因為任何可能的資料洩露都會導致使用者的損失，我也不想任何人看到使用者的密碼。所以採用 md5(password .. salt) 的風格。

md5 運算前，加一個 salt 字尾，是因為單純的文字 md5 值也是有資料庫可查的。

lastlogin 下儲存了使用者最後一次登陸的資訊，使用了一張 hashes 表，因為這些資訊在未來會進一步擴充。

history 儲存了使用者登陸的所有歷史記錄，用一個 string 連結串列記錄。

使用者刪除自己的賬戶時，不想把資料從資料庫刪除，只想在 available 下做一個標記。

考慮到資料庫內資料結構有可能發生變化，所以加了 version 域做版本標識。

我不想讓各種服務可以直接讀寫這份資料，所以，會單獨寫一個認證伺服器做處理。

認證伺服器提供三項服務：

1. 使用者註冊

2. 使用者名稱 密碼 認證 (用於 ssl 連線上的 web 服務)

3. 使用者名稱 密碼 挑戰式認證 (用於 client 的認證服務)

下面是基本的場景服務用的資料：

• account:[id]:avatars set(id)
• avatar:count id
• avatar:[id]:version number
• avatar:[id]:account id
• avatar:[id]:scene string
• avatar:[id]:available enum(open/delete)
• avatar:[id]:data hashes
  • name string
  • figure string
• world:scene hashes
  • [name] id
• scene:count id
• scene:[id]:name string
• scene:[id]:available enum(open/close/delete)
• scene:[id]:info hashes
  • time string
  • pc number
• scene:[id]:pc hashes
  • [id] enum[online/offline]
• scene:[id]:pc:[id] hashes
  • status string

使用者賬號下可以有許多遊戲角色，列表放在 account:[id]:avatars 下。

每個角色也擁有一個唯一 id 。這個 id 原則上和 account id 是獨立體系，但是為了人類好區格，avatar:count 的起點和 account:count 不同。

角色所在場景記錄一個字串的場景名 avatar:[id]:scene ，角色的其它各種資料放在一個 hashes 裡。

所有的場景索引方在 world:scene 下。如果日後有多個世界，可以採用 world:[id]:scene 。但目前不必考慮。

scene 下面的所有 pc 的線上狀態放在 scene:[id]:pc hashes 中，pc 離線也把它的 id 記錄在內，只有 pc 轉移場景才移除。

每個 PC 的位置狀態資訊記錄在 scene:[id]:pc:[id] 中，第一個 id 是 scene 的 id ，第二個則是 PC 的 avatar id 。

btw. 這是一份草稿，雖然思考不周，但足夠滿足專案一期的需求。當然許多欠考慮的地方也並非是考慮不到，而是希望儘量簡單，以滿足一期需求為目的。這個日後修改的代價並不大。

最後吐槽一下 Redis 的 Windows 版。辦公室的 Linux 伺服器還沒有裝好，我暫時在 Windows 下做開發。取了一份 google 搜到的 非官方 Redis 的 Windows 版 。為了圖方便，使用的是 luajit ffi 去呼叫 hiredis 的 dll 。一開始怎麼都搞不定。建立不了 socket 連線，出錯碼也取不到。

對比了原始碼，發現修改版把 C Struct 結構改了，前面增加了幾個域，而我以 hiredis 官方標準來定義的介面。

改好後，能夠正確取出出錯碼了。發現萬惡的 Windows socks api 需要呼叫 WSAStartup 才可以用。而 hiredis 的 Windows 修改版居然沒有去呼叫。讓我大費周折才改好，前後折騰了一個多小時。

再吐槽一下 hiredis 的 API 設計，居然依賴 C Struct 的佈局。良好的 C 庫的介面設計不會這麼幹的吧。比如 lua ，又比如 zmq 。唉，用這種東西有點小不爽。不過比 C++ 庫還是好太多了。