伺服器開發之訂單號生成策略

2021-07-23 13:47:16 字數 2635 閱讀 8071

它是您在購物**購物後獲得的訂單號,記錄的是購物訂單資訊。

在您需要與購物**進行訂單查詢等操作時,需要給購物**提供商家訂單號。

web**下單

打**到呼叫中心(callcenter)下單

手機wap下單

如果採用單資料庫來儲存的話,隨著訂單量的增加,單庫的寫壓力增大,造成資料庫伺服器效能下降。一般會採用分庫來緩解資料庫伺服器的壓力。

那麼怎麼來進行分庫呢?

web**訂單,存入web訂單庫。

callcenter**訂單,存入callcenter訂單庫。

wap**訂單,存入wap訂單庫。

最終,將這三種型別的資料庫同步到訂單主庫中。

問題來了,怎麼把不同的訂單同步到訂單主庫呢?

電商**一般利用訂單號來作為訂單表的主鍵。因此,我們必須保證訂單號不重複,才能將訂單安全的同步到訂單主庫中。

這個大家都明白,主要保證訂單號不重複。

訂單編號不能透露你公司的真實運營資訊,比如你的訂單就是流水號的話,那麼別人就可以從訂單號推測出你公司的整體運營概括了。所以訂單編碼必須是除了你們公司少部分人外,其他人基本看不懂的。可以參考京東和**的編碼規則。

因為大規模的隨機碼隨機生成,因為本身就沒有意義所以無所謂洩密了。但是事實上這種編碼規則在實現上會有很大問題的。隨機碼滿足第二點安全性要求,為了滿足唯一性,那就得在生成隨機碼的時候對比歷史資料是否有重複,如果你的訂單數量到達了十萬次,你每次生成訂單編碼時就得對比十萬條歷史資料。

隨機碼就不能在編碼中使用了嗎?小規模的隨機碼是可以使用的,比如2~3位,這種隨機碼一般都是和流水號等結合使用,主要作用是為了隱藏流水號的真實資料而進行使用的。

主要針對編碼中有時間的設定。

訂單號的作用就是便於查詢。一般正常使用場景應該是訂單出異狀或者退貨的時候,使用者將訂單號報給客服,由客服進行查詢。所以一般在10~15位為好。目前京東11位,**16位。

比如「業務編碼 + 時間戳 + 機器編號[前4位] + 隨機4位數 + 毫秒數」。

說明:業務編碼(ordertype: web=1 callcenter=2 wap=3) 機器編號(用來表示由那台伺服器生成的訂單)

偽**如下:

import org.apache.commons.lang3.randomstringutils;

public static string genorderno(ordertype type)

缺點:這種方式在高併發下會頻繁更新訂單量記錄表,很容易產生鎖表。但是鎖表問題也是可以解決的,加一層快取。

資料庫建立乙個訂單號資料庫表(order_id_generator);利用python指令碼生成一批訂單號,將這批訂單號存入到order_id_generator表中。生成訂單時,會首先呼叫事務get_order_id_for_register,獲得當前訂單號,再生成訂單。這樣就保證了子庫訂單號不會重複。

資料庫**如下:

create table `order_id_generator` (

`random_value` bigint(20) not null,

`order_id` int(11) not null,

primary key (`random_value`)

) engine=innodb default charset=utf8;

drop procedure if exists `get_order_id_for_register`;

delimiter ;;

create definer=`root`@`%` procedure `get_order_id_for_register`()

begin

declare usermid int default 0;

declare randomvalue bigint default 0;

start transaction;

select order_id, random_value into orderid, randomvalue from order_id_generator limit 1 for update;

if usermid > 0 then

delete from order_id_generator where random_value = randomvalue;

end if;

commit;

select orderid from dual;

end;;

delimiter ;

偽**如下:

/**

* 得到乙個訂單號。

* * @return

*/long getidfororder();

訂單號的生成方案,需要根據目前的訂單量而定;因為各種方案都有各自的使用場景。

部落格已遷移,歡迎關注 最新部落格

電商平台訂單號生成策略

訂單是整個電子商務的核心。整個電子商務的流程也是圍繞訂單的狀態執行的。這篇部落格主要向大家介紹訂單號的生成方式。現在大型電商 大多都有好幾種下單途徑。比如 通過web 下單,通過打 到呼叫中心下單 callcenter 使用手機wap下單。如果只採用單資料庫來儲存訂單資訊的話,其隨著訂單量的增加,單...

訂單號的生成規則和不同生成策略

不重複 訂單號的唯一行 安全性 訂單編號中不要透露任何和公司有關的資訊,不要使用流水號,容易暴露公司的運營情況 不要使用大規模隨機碼 隨機編碼可以滿足安全性,但為了滿足不重複性要費很大的力氣。比如現在已經有了10萬條訂單,如果再新生成的訂單,它的訂單號需要與之前的10萬條資料的訂單號進行比較,結果可...

分布式環境下訂單號的生成策略

什麼是分布式 如專案分布 訂單模組,商品模組,支付模組。由於每個模組之間的訪問壓力的不同,可以根據需要各自部署在不同數量的伺服器上,如訂單模組3臺,商品4臺,支付模組2臺。分布式環境下訂單號的生成要求 必要 全域性唯一 其他的 趨勢遞增,高併發,高可用,資訊保安,長度 過長會造成儲存壓力過大 生成策...