分庫分表：

跨庫的問題

分布式事務問題

查詢數據結果集合并

全局唯一性ID保證

要求：

1、全局唯一性：不能出現重復的id號（基本的要求）。

2、信息安全：防止惡意用戶規矩id的規則來獲取數據。混淆效果

3、數據遞增：保證我下一個ID一定大于上一個ID。

當前201709122030下一個：201709122031下一個：201709122032

互斥關系：信息安全、數據遞增規律

CREATE TABLE `tl_id` (`id` varchar(255) NOT NULL,PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;

業界分案：

UUID:

通用唯一識別碼16個字節128位的長數字、

組成部分：當前日期和時間序列+全局的唯一性網卡mac地址

執行任務數：10000------------------------所有線程共耗時：38.305 s并發執行完耗時：449.0 ms單任務平均耗時：3.8305 ms單線程最小耗時：0.0 ms單線程最大耗時：193.0 ms

總結：

優點代碼實現簡單、不占用寬帶、數據遷移不受影響

缺點無序、無法保證趨勢遞增（要求3）字符存儲、傳輸、查詢慢、不可讀

Snowflake雪花算法

國外的twitter分布式下iD生成算法

1bit+41bit+10bit+10+bit=62bit

高位隨機+毫秒數+機器碼（數據中心+機器id）+10的流水號

國內：

保證數據的唯一性就行了IDC機房。

總結：

優點代碼實現簡單、不占用寬帶、數據遷移不受影響、低位趨勢遞增缺點強以來時鐘（多臺服務器時間一定要一樣）、無序無法保證趨勢遞增（要求3）

Mysql:

奇數跟我們偶數遞增步長2

適合小型互聯網公司、比如可以知道我們一定生成的ID數量 五萬的訂單量

一年1千8百萬

Mysql一張表500萬

如果公司每天訂單量5萬的數據 我們用mysql設置步長位100的話可以用27年

只能為100庫 公司來到風投了 每天的訂單量50萬100萬的時候

總結：

優點代碼實現方便、性能不錯、數字排序、可讀性很強缺點受限數據庫、擴展麻煩、插入數據庫才能拿到ID、單點故障的問題

主從同步的時候：電商下單->支付insert master db select數據 因為數據同步延遲導致查不到這個數據。加cache（不是最好的解決方式）數據要求比較嚴謹的話查master主庫。

CREATE TABLE `tl_num` (

`id` bigint(11) NOT NULL AUTO_INCREMENT,

KEY (`id`) USING BTREE

) ENGINE=InnoDB auto_increment=1 DEFAULT CHARSET=utf8;

Redis:

執行任務數：10000------------------------所有線程共耗時：136.587 s并發執行完耗時：1.515 s單任務平均耗時：13.6587 ms單線程最小耗時：1.0 ms單線程最大耗時：254.0 ms

總結：

優點不依賴數據、靈活方便、性能優于數據庫的、沒有單點故障（高可用）缺點需要占用網絡資源、性能要比本地生成慢、需要增加插件