一，常見的下單途徑
- Web網站下單
- 手機Wap下單
- 打電話到呼叫中心下單(少見)
如果采用常見的單數據庫來存儲的話，隨着訂單量的增加，單庫的寫壓力增大，造成數據庫服務器性能降低，一般會采用分庫來緩解數據庫服務器的壓力，分庫就分成不同的幾個訂單數據庫，Web來源訂單，存入Web訂單庫；手機Wap來源，存入Wap訂單庫等。最后再將這幾種類型的數據庫同步到訂單主庫中。在同步到訂單主庫的時候，首先電商網站一般用訂單號來作為訂單表的主鍵，因此，必須保證訂單號的唯一性。
二，訂單命名的幾種規則
- 不重復：訂單號的唯一性
- 安全性：訂單編號中不能透露公司的任何信息，不要使用流水號，容易暴露公司的運營情況
- 不要使用大規模隨機碼：隨機碼可以保證訂單號的安全性，但是當數據量比較大的時候，如果再生成新的訂單，需要與之前數據的訂單號進行比較，效率太低
- 防止並發：有時間的設定，防止並發，同一用戶同一時間(精確到秒、毫秒)不會產生兩個訂單編碼
- 控制位數：10-15位，有時間日期的可以方便客服，在用戶投訴時，長的訂單號報錯幾率高，影響效率
- 純數字性，便於索引查詢，文本型“字母+數字”不利於索引
淘寶的訂單號規則：18位，前14位為序號，15-16位是用戶ID倒數1-2位，17-18位是用戶ID倒數3-4位
比較常見的幾種訂單號生成方法
一，使用UUID
UUID是一個128位長的數字，一般用16進制表示，算法的思想是結合機器的網卡、當地時間、一個隨機數來生成GUID，從理論上講，一台機器每秒產生1千萬個GUID，可以保證3240年不重復。
優缺點：
二，使用數據庫自增序列生成
利用數據庫全局唯一。設置MySQL數據庫自增起始值和步長，起始值不同，步長相等，則每個數據庫生成的自增序列碼可以避免相同。
優缺點：
三，推特雪花(snowflake)算法 (推薦)
推特公司的一款通過划分命名空間並行生成的算法，來解決全局唯一ID的需求。雪花算法，是64位二進制，轉十進制，18位，第一位是符號位為0，第二階梯的41位是毫秒，然后是5位datacenterId（最大支持2^5＝32個，二進制表示從00000-11111，也即是十進制0-31），和5位workerId（最大支持2^5＝32個，原理同datacenterId），所以datacenterId*workerId最多支持部署1024個節點，第四階段最后12位每毫秒從0遞增生產ID(12位的計數順序號支持每個節點每毫秒產生4096個ID序列)，那么一秒就是4096000，理論上每秒可以生成400萬+，實際可能要低一點，大概300萬左右。
四，基於Redis的自增
當使用數據庫來生成ID性能不夠要求時，我們可以嘗試使用Redis來生成ID，這主要依賴於Redis單線程，所以可以生成全局唯一ID，使用Redis的INCR和INCRBY來實現。
可以使用Redis集群來獲取更高的吞吐量。假如一個集群中有5台Redis，可以初始化1,2,3,4,5，然后步長為5，生成唯一ID。使用Redis集群還可以防止單點故障的問題。
優缺點：
五，全局訂單號數據池
這個方法是個人的一個思考，沒有實操過，歡迎指正。
盡量使用有意義的訂單號，便利與客服和客戶，比如說，這種生成規則：業務編碼 + 時間戳 + 機器編號[前4位] + 隨機4位數 + 毫秒數
業務編碼就是哪一種訂單數據庫(Web、手機等)，機器編號前4位(服務器的標識)。
每天的零點新生成一批訂單號，然后放入Redis，走緩存，不要放入數據庫，Redis使用List隊列的先進先出，根據自己分公司的業務量設置一個容量，低於一半就添加，滿了就停止，適用於並發量比較小的，這個可以不在並發量比較高的時候去大量生成，而是在空閑的時候成，直接存取Redis，效率還是比較高的。
本文參考：
https://blog.csdn.net/m0_37774696/article/details/85012554
https://blog.csdn.net/jiabeis/article/details/80999498
https://blog.csdn.net/li396864285/article/details/54668031
https://blog.csdn.net/qq_39597203/article/details/86504239
https://mp.weixin.qq.com/s/FJKHORl_PSaTrCPLrZ1ouQ