本文介紹如何使用redis設計一個小的微博系統資料庫（該例子來源於redis官網文件）。
對於關係型資料庫，設計資料庫通常等同於設計表、模式等。對於redis我們是不需要這些的，所以我們只需要設計我們程式中的資料結構用什麼key、用哪種value表示就足夠了。我們首先要設計的是使用者資訊這個資料結構，它裡邊會包含username, userid, password, followers等資訊。類似於關係型資料庫，我們也要找一個唯一的key來表示這個使用者資訊結構，我們通過userid來表示使用者。這裡有個小竅門，我們可以設定一個nextUserId鍵專門儲存使用者id，之後用INCR nextUserId來獲取一個沒有被使用過的使用者id。這是一個非常常用的鍵值儲存設計模式，以後你還會看見很多這樣的用法。有了使用者id後，我們就可以建立使用者資訊結構了。假設我們現在獲取了一個使用者id，它的值是1000.現在我們可來設定使用者資訊。

set uid：1000：username john

set uid：1000：password 12345

…………

如果你習慣了關係型資料庫後，看到這個設計模式一定會非常不適應，但是這就是鍵值儲存的設計模式。我們不需要專門定義資料結構的層次關係，我們完全可以直接用key的形式表示資料之間的關係。比如，如同上邊，我們可以這樣表示使用者資訊資料結構：

使用者id：使用者名稱；

使用者id：密碼；

使用者id：個人資訊：暱稱；

使用者id：個人資訊：性別；

……

也就是說鍵值資料結構設計模式中，資料之間的關係可以僅僅依靠key值來體現，而不用去建立複雜的表。現在是不是已經感受到NoSQL的強大了？前邊的資料結構如果使用關係型資料庫可是要建立很多個表才能表示的，更不用說如果表結構變了表也得重新定義。

設計完使用者資訊現在我們要設計使用者的粉絲資料結構。redis有一個非常適合表示這種資訊的資料型別，那就是set（集合）。我們可以為每一個使用者設計一個set，這個set裡邊存放這個使用者的粉絲的id。就像是這樣：uid:1000:followers。

之後我們還要設計每個使用者所發表的狀態的資料結構。狀態是一條一條按時間排序的，對於這種資料結構redis也有非常適合的資料型別來表示，那就是list（列表）。例如：uid：1000：posts，這個list儲存每個使用者所發表的狀態的id，然後我們可以通過這些id獲取使用者的狀態的其他資訊。狀態詳細資訊的設計跟前邊使用者資訊的設計類似。

到這裡這個微博系統用到的主要資料結構就設計好了，剩下的就是應用程式的設計了。