今天下午,使用新浪微博的查找好友功能查找好友時,突然想起這樣的一個功能,應該說這個問題我之前也考慮過,但是一直沒有很好的答案,這里做一個描述.

其實問題說白了也很簡單,查找好友的時候,可以根據用戶的一個或者多個屬性來定位數據.比如一個用戶有用戶名,性別,地址三個屬性,如何做到可以根據其中的一個或者多個屬性來定位用戶呢?

首先來看存儲端的設計,我個人認為這個功能雖然可能用的次數不多,但是不應該是直接去訪問查找數據庫的,否則量如果大了起來響應會很慢.好了,如果不是直接查找數據庫的話,那么擋在數據庫前面應該有cache服務器了.第二個問題來了,cache總是有限的,不能緩存所有的數據,那么在這里查找就可能會丟失一些數據,這個問題又怎么解決呢?嗯,我個人的猜測是,這里有一個平衡點的問題,即有一個準則,比如說經常登錄的活躍用戶信息才會留在cache中,不常訪問的用戶,找不到也不打緊了.

接下來,如果數據真的在cache中,即使如此,那么要實現這里提到的可以根據多個屬性來查找數據也不是很容易實現的.

現在大部分的cache系統,比如memcached,還有我之前寫的ccache,本質上都是key-value形式的cache,也就是僅能針對一個key值進行搜索查找.

考慮如下的兩種實現:
1) 緩存中數據key是用戶名,而value是用戶的其它信息如性別,城市,主頁等,那么這里就存在一個key值不唯一的問題.好了,如果把所有相同key值的數據組織在一起,比如用一個鏈表串起來,如果找到這個用戶名,再遍歷這個鏈表根據其余的參數來定位數據.但是,如果用戶不是根據用戶名也就是key值來查找數據的,如何是好呢?難道說,要建立一個多key的數據結構用于查找,就我現在對cache設計的了解,還沒有這種多key設計的cache,基本上都是單key的cache.

2) 緩存中數據key不僅包括用戶名,還包括了其它可以定位到用戶的屬性,也就是,與前面的實現不同的是,這個實現把多個屬性都放在key里面了.但是,如果這樣組織數據,又如何定位數據呢?假設key里面有三個屬性,某次使用了其中的一個屬性來查找,下一次使用其中的兩個屬性來查找....這種設計實現起來還是很難的.

以上幾個問題,我今天考慮了一下,沒有太好的思路,這也越發激起我去研究數據庫實現的想法.疑問未除,做個紀念.


=========== 分割線 ==================
這個問題似乎我想的復雜了,問了一下朋友,說是應該直接搜索數據庫,因為一般這樣的搜索量不會很多.