問(wèn)答專欄Q & A COLUMN
1、UUID
2、數(shù)據(jù)庫(kù)自增
3、Snowflake
4、Redis
評(píng)論0
加載中...
這種方式比較方便，有現(xiàn)成可用的JAR包，但是也有缺點(diǎn)：ID可讀性不好，而且會(huì)造成索引樹頻繁頁(yè)分裂，影響數(shù)據(jù)庫(kù)性能和空間使用
維護(hù)一張序列表?？紤]到性能問(wèn)題，不必每次生成ID都去操作數(shù)據(jù)庫(kù)，可以設(shè)置一定的步長(zhǎng)比如1000，每次從表中拿1000個(gè)序列號(hào)，從每臺(tái)服務(wù)器內(nèi)存中線性去取
維護(hù)一個(gè)序列號(hào)鍵值對(duì)，利用Redis自增的原子性，生成序列號(hào)
同一毫秒可以產(chǎn)生ID數(shù)量4194304個(gè)，優(yōu)點(diǎn)是完全內(nèi)存操作性能好，缺點(diǎn)是依賴于系統(tǒng)時(shí)鐘一致性。如果某臺(tái)機(jī)器的系統(tǒng)時(shí)鐘回?fù)埽锌赡茉斐蒊D沖突，或者ID亂序
最重要的還是根據(jù)項(xiàng)目的場(chǎng)景，尤其是并發(fā)量，選擇最合適的方法
請(qǐng)點(diǎn)擊關(guān)注按鈕【IT徐胖子】會(huì)持續(xù)為大家奉獻(xiàn)互聯(lián)網(wǎng)和技術(shù)干貨內(nèi)容，感謝支持
評(píng)論0
加載中...
由于是高并發(fā)情況，所以不建議使用數(shù)據(jù)庫(kù)自增ID，可以參考如下方案：
1、redis自增id
2、UUID
3、時(shí)間戳+隨機(jī)數(shù)
4、Twitter的snowflake算法
5、利用zookeeper生成唯一id，性能不如redis
6、MongoDB的ObjectId，和snowflake算法類似
評(píng)論0
加載中...
隨便哪個(gè)程序員都可以寫出來(lái)一個(gè)生成訂單的算法，除了美團(tuán)、淘寶這種需要考慮訂單重復(fù)，大多數(shù)企業(yè)還是發(fā)愁沒有訂單的狀態(tài)，需要考慮這個(gè)問(wèn)題的企業(yè)應(yīng)該不差錢了，希望我的公司有機(jī)會(huì)讓我來(lái)解決這個(gè)問(wèn)題。
評(píng)論0
加載中...
1:獲取當(dāng)前日期作為訂單號(hào)的前8位
2:獲取uuid，它是通用唯一識(shí)別碼，進(jìn)行hashcode轉(zhuǎn)碼仍然可以保證其唯一性，可以取12位
3:日期和uuid轉(zhuǎn)碼之后的12位拼接，一共20位，可以生成唯一訂單號(hào)
評(píng)論0
加載中...
最簡(jiǎn)單的辦法就是用用戶名?ip?時(shí)間生成訂單號(hào)，然后計(jì)算哈希值后做一定轉(zhuǎn)換就可以生成唯一訂單號(hào)。不過(guò)唯一的問(wèn)題就是不太好查。畢竟這種訂單號(hào)沒有任何規(guī)律可言，后期查詢是個(gè)大麻煩。其實(shí)最建議的方式就是分渠道分地區(qū)建立訂單號(hào)。就和身份證號(hào)生成機(jī)制一樣，各個(gè)地區(qū)可以獨(dú)立生成身份證號(hào)，最后合在一起還沒有任何問(wèn)題。
評(píng)論0
加載中...
用算法呀。對(duì)訂單這種，很簡(jiǎn)單。
商品id +用戶id+時(shí)間戳+隨機(jī)數(shù)+自增數(shù)
就能保證唯一性?，F(xiàn)實(shí)中，沒哪個(gè)用戶去高并發(fā)下單（除非bug）。
評(píng)論0
加載中...
看一下美團(tuán)的leaf
https://tech.meituan.com/2019/03/07/open-source-project-leaf.html評(píng)論0
加載中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
