java web系統在高併發下如何實現訂單號生成唯一?

時間 2021-05-29 23:43:30

1樓:你就說酷不酷

最簡單的解決方式,其實這個問題關鍵就在最後的流水號不能重複,重複了訂單號也就重複了,我認為最簡單的就是直接新建一張表,表的字段主鍵id自增,另乙個字段隨意定,這個id直接充當流水號,多個請求同時進來的話就insert這個表,mysql插入一條資料同時返回其對應的自增id,這個語句可以看鏈結mysql插入一條資料,返回其對應的id,再設定乙個定時任務,每天閉店的時候(這個時間看個人專案實際情況),執行語句使自增主鍵歸0,鏈結也有mybatis裡面如何寫truncate table,第二天再有訂單進來的時候就又從1開始了。

總結:實現需要兩步,1.加表,2.每天定時任務清空表資料

2樓:曉風輕

首先,不要利用系統自己產生的隨機碼,都是會產生的,別和我說uuid不會重複,實際上會。

最靠譜的方式還是產生資料庫序列生成,但是步長要設定為大一些,如一次去100-1000,然後放到記憶體裡面使用,這樣可以保證效能的前提並且不會重複。

3樓:圓胖腫

典型的對記憶體計算速度沒有概念

這種生成規則,一秒鐘可以生成上千萬條

這還不夠用?

壓力會出現在io上,記憶體中生成器唯一

然後io非同步一下就搞定咯

4樓:

這個組合是唯一的:

伺服器時間戳+伺服器IP位址+伺服器執行緒ID可以用乙個int128存起來。頭64位存時間戳,中間32位是IP,最後32位是執行緒ID。

鹽一下然後求雜湊值即可。

若是擔心雜湊碰撞,可能需要做帶鎖查詢。否則查詢都不需要。

5樓:

哎。。。。

企業級高併發,切記減少記憶體式鎖生產。這樣的設計一看就知道是象牙塔出來的,沒真的經歷過。

一般來說這種流水號,在需要的時候再惰性生成,就已經晚了,要考慮負載前置。

你的業務場景不充分,補充更多業務場景可能會導致solution變化,但是就目前這樣的做思考題來說已經足夠。首先你的業務場景有乙個前提,訂單號並不需要嚴格按照進入系統的時間來區分流水先後,因為你已經是高併發了,快1,2個毫秒,訂單號一定要按順序,這除非找茬,不會真實存在於系統之中。所以,你可以採取高效能Q,預先生成流水號(關鍵點1),按照業務量分片(關鍵點2),進行分級快取(關鍵點3)。

一級快取肯定在記憶體裡,你可以準備大約10秒的流水號在記憶體裡。由十個分片控制,在業務邏輯取流水的時候,由演算法控制去不同片取。(輪詢也好,計數也好,這都隨便,看你業務場景)這樣的話,好處是你加鎖等待時間,平均來說,除以10了。

切記架構設計是軟硬體一體設計,二級快取放在高效能SSD裡面,每5秒查詢下一級快取是否接近臨界值(比如流水還剩15%),則尾端補充。

當然,時間間隔什麼的,都是示意,要按照實際場景測試優化。和上面所有的記憶體同步式取法不同,我這個還支援scale out。

6樓:

分布式場景下,可以看看這篇:<從PAXOS到ZOOKEEPER分布式一致性原理與實踐>讀書筆記-zookeeper全域性唯一id生成 - bohu83的部落格 - CSDN部落格

7樓:孫立偉

1. 最原始的辦法: 做乙個SequenceId的資料庫表,表中字段可以有兩個,乙個儲存SequenceId的型別,如obj_type,另乙個儲存最新的SequenceId, obj_id。

然後自己寫乙個類專門讀寫這張表。

2. 用資料庫提供的Sequence物件,MySQL, Oracle等都有。由於你的規則有些複雜,可能需要寫儲存過程或者自定義函式來做。

3. 前面有人已經提過,使用snowflake。

不知道你的高併發到底有多大,但是以上每種方案都有優化的空間,具體得看你的業務邏輯了。

如何設計這樣乙個高併發系統

ReggieDing 自己設計建議裝置和平台解耦,使用訊息中介軟體隔離。最好是支援高併發高可用的,同時可以隨業務量的大小自由擴充套件節點,比如ActiveMQ Kafak等都是可選。另外,按你需求看其實即使要給 IOT物聯網系統,如果上線時間緊可以考慮使用雲服務構建,比如阿里雲等,免去自己搭建的穩定...

如何理解 程式 程序 執行緒 併發 並行 高併發?

大魚 這篇文章講得挺細的,可以看看https markdowner.net article 142723313666699264 zhang 單程序 包含多個磁碟讀寫請求 IO 非併發 單程序單執行緒同步 說明 乙個程序,多個請求同步執行,請求阻塞說明 同一時間段只執行乙個請求 併發 單程序 單執行...

在高併發的情況下,session存redis和session存mongodb差異大麼?

張麗軍 redis 資料讀寫都在記憶體而Mongo DB 資料讀寫在硬碟 速度自然不是乙個數量級的。對session來說一般沒有持久化的需求,在加上redis 有資料到有效期後清除機制,redis比較適合存session了吧 陳林林 不同意樓上說法,redis 和mango都屬於nosql,兩者都可...