需求描述:根據用戶id生成與之對應的唯一邀請碼,范圍為‘0-9A-Z’。 這個需求的重點在於加粗的部分,也就是要能夠根據邀請碼反推出用戶ID,這樣邀請碼就不用入庫了,在用戶量很大的情況下,性能可以得到不小的提升。 錯誤思路 隨機生成一個字符串,再將用戶id拼接到字符串后面 ...
面試提到的需求:根據用戶的ID和字符串的組合來生成較短的邀請碼,還有就是根據這個邀請碼解析出邀請碼對應的用戶ID 生成這樣的邀請碼我們就不放在數據庫里面了,在用戶量很大的情況下,對於性能是一個很大的提升。 我錯誤的設計方案: 正確的方案: 因為當時面試時間短,沒有考慮的很詳細。后面我查了一些資料,看過之后我就想當時怎么這么菜,因為十進制的數據肯定長,但是我們的十六進制,相對十進制是很短的 這個時候 ...
2018-08-31 14:47 0 1508 推薦指數:
需求描述:根據用戶id生成與之對應的唯一邀請碼,范圍為‘0-9A-Z’。 這個需求的重點在於加粗的部分,也就是要能夠根據邀請碼反推出用戶ID,這樣邀請碼就不用入庫了,在用戶量很大的情況下,性能可以得到不小的提升。 錯誤思路 隨機生成一個字符串,再將用戶id拼接到字符串后面 ...
...
根據用戶id生成與之對應的唯一邀請碼,范圍為‘0-9A-Z’。這個需求的重點在於加粗的部分,也就是要能夠根據邀請碼反推出用戶ID,這樣邀請碼就不用入庫了,在用戶量很大的情況下,性能可以得到不小的提升。 錯誤思路 隨機生成一個字符串,再將用戶id拼接到字符串后面,但是這樣id就太明顯 ...
網上看到一個例子,借鑒修改一下 實現根據long類型的用戶ID生成6位隨機邀請碼,並且根據邀請碼能算出用戶ID。代碼如下: 上面6位邀請碼能表示的最大ID為728999999(“hhhhhh”),729000000(“wqqqqqq”)就要進位了。 上面方法同一個id生成 ...
分幾點來答: 1. 首先,這其實是個技術選型題。 做技術選型的時候不能單純的考慮性能,應該優先考慮業務類型,以及團隊水平。另外的話,框架只是其中一環,還有配套呢。 如果是數據驅動型,尤其是要用到 ...
(1)單塊架構 網站開始建立時,用戶少 , 網站架構都是用單體架構設計,共部署3台服務器,1台應用,1台數據庫,1台圖片。 1、應用服務器上發布,可能是把應用服務器上的Tomcat給關掉,替換系統的代碼war包,重新啟動Tomcat。 2、數據庫服務器,存全部核心 ...
今天群里一位朋友拋出一個問題,需要用26個字母和10個數字,組成一個不重復的4位字符,來作為邀請碼。既方便客戶記憶,又能適應大量的用戶。我就做了這個demo 用Redis把begin存儲起來,每次用的時候放入方法,拿到邀請碼,再自增1,設置回Redis。如此生成的邀請碼最多 ...
code ...