它是您在購物**購物後獲得的訂單號,記錄的是購物訂單資訊。
在您需要與購物**進行訂單查詢等操作時,需要給購物**提供商家訂單號。
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臺。分布式環境下訂單號的生成要求 必要 全域性唯一 其他的 趨勢遞增,高併發,高可用,資訊保安,長度 過長會造成儲存壓力過大 生成策...