面試提到的需求:根據使用者的id和字串的組合來生成較短的邀請碼,還有就是根據這個邀請碼解析出邀請碼對應的使用者id;生成這樣的邀請碼我們就不放在資料庫裡面了,在使用者量很大的情況下,對於效能是乙個很大的提公升。
方案一:隨機生成乙個字串在和使用者id做拼接,首先這樣的想法就是錯的,如果是在這樣生成的,別人也會拿到使用者的id,這個時候我們的資料就不安全;還有一點不滿足需求,需求說邀請碼盡可能短。方案二:我們將我們的使用者id,按照一定的規則插入到隨機字串,比如隔乙個字元或或者兩個字元插入,這樣可以解決方案一安全的問題,但是長度的問題是不能解決的,這個方案又死了;
後面我也沒有想到什麼方案去解決,面試就死了。
因為當時面試時間短,沒有考慮的很詳細。後面我查了一些資料,看過之後我就想當時怎麼這麼菜,因為十進位制的資料肯定長,但是我們的十六進製制,相對十進位制是很短的;這個時候看到一篇文章上面的思路是將使用者的id轉換為10+26=36進製的數不就可以了嘛
1function createcode($user_id)2
12return
$code
;13 }
邀請碼保證了唯一性,並且長度不會太長,使用者id也能夠根據邀請碼反推出來,但是有一點不好的是,別人也可以根據邀請碼去反推出user_id,因此,我們需要做一些優化。
把0剔除,當做補位符號,比如小於四位的邀請碼在高位補0,這樣36進製就變成了35進製,然後把字串順序打亂,這樣,在不知道$source_string的情況下,是沒辦法解出正確的user_id的。
1//生成邀請碼
2function createcode ($user_id)3
12if(empty($code[3]))
15return
$code
;16 }
這樣,對應user_id的唯一邀請碼就生成了,再附乙個解碼函式:
1//解析邀請碼
2function decode ($code) 3
8$len = strlen($code);9
$code = strrev($code
);10
$num = 0;
11for ($i=0; $i
< $len; $i++)
14return
$num
;15 }
Django適合做大使用者量的系統嗎?
分幾點來答 做技術選型的時候不能單純的考慮效能,應該優先考慮業務型別,以及團隊水平。另外的話,框架只是其中一環,還有配套呢。如果是資料驅動型,尤其是要用到關係型資料庫,那麼選擇django足以,orm會比較省事,但是效能損耗是個很明顯的問題。不過還是看團隊,如果大家玩flask或者bottle都賊溜...
百萬級使用者量的站內信群發資料庫設計
隨著web2.0的發展,使用者之間的資訊互動也變得十分龐大,而且實時性要求越來越高。現在很多sns 和一部分cms 都廣泛地應用了站內信這一模組,這個看似簡單的東西其實背後隱藏著很多需要設計師重視的設計細節,要做好這個 郵遞員 是很不容易的。為什麼這麼說呢?下面我們就一步步來探索設計乙個百萬級使用者...
百萬級使用者量的站內信群發資料庫設計
隨著web2.0的發展,使用者之間的資訊互動也變得十分龐大,而且實時性要求越來越高。現在很多sns 和一部分cms 都廣泛地應用了站內信這一模組,這個看似簡單的東西其實背後隱藏著很多需要設計師重視的設計細節,要做好這個 郵遞員 是很不容易的。為什麼這麼說呢?下面我們就一步步來探索設計乙個百萬級使用者...