鬼佬大哥大
  • / 15
  • 下載費用:30 金幣  

一種ID生成方法、裝置和系統.pdf

關 鍵 詞:
一種 ID 生成 方法 裝置 系統
  專利查詢網所有資源均是用戶自行上傳分享,僅供網友學習交流,未經上傳用戶書面授權,請勿作他用。
摘要
申請專利號:

CN201210223724.3

申請日:

2012.06.29

公開號:

CN102769667B

公開日:

2015.01.28

當前法律狀態:

授權

有效性:

有權

法律詳情: 授權|||實質審查的生效IPC(主分類):H04L 29/08申請日:20120629|||公開
IPC分類號: H04L29/08 主分類號: H04L29/08
申請人: 北京奇虎科技有限公司; 奇智軟件(北京)有限公司
發明人: 桂勇哲; 陳斌; 陳超
地址: 100088 北京市西城區新街口外大街28號D座112室(德勝園區)
優先權:
專利代理機構: 工業和信息化部電子專利中心 11010 代理人: 齊潔茹
PDF完整版下載: PDF下載
法律狀態
申請(專利)號:

CN201210223724.3

授權公告號:

102769667B||||||

法律狀態公告日:

2015.01.28|||2012.12.26|||2012.11.07

法律狀態類型:

授權|||實質審查的生效|||公開

摘要

本發明公開了一種ID生成方法、裝置和系統,所述方法包括:第一服務端接收調用端發起的ID獲取指令,根據所述ID獲取指令,生成基于服務端標識號和自增序列的ID值,或者生成基于當前時間戳、服務端標識號和自增序列的ID值,并將生成的所述ID值發送至所述調用端。本發明所述技術方案通過面向服務的方式來生成全局唯一ID,具有良好的可擴展性,高可用性,高可靠性;同時還保證了生成的ID是有序的,遞增的,ID占用的空間相比UUID更小,使用便捷。

權利要求書

1: 一種 ID 生成方法, 其特征在于, 包括 : 第一服務端接收調用端發起的 ID 獲取指令, 根據所述 ID 獲取指令, 生成基于服務端標 識號和自增序列的 ID 值, 或者生成基于當前時間戳、 服務端標識號和自增序列的 ID 值, 并 將生成的所述 ID 值發送至所述調用端。
2: 如權利要求 1 所述的方法, 其特征在于, 所述第一服務端配置有 Get 接口, 負責收發 與各所述調用端間的信息 ; 所述調用端配置有調用接口, 負責收發與所述第一服務端間的 信息。
3: 如權利要求 1 所述的方法, 其特征在于, 所述第一服務端與調用端間采用 memcache 協議進行通信。
4: 如權利要求 1 所述的方法, 其特征在于, 所述 ID 獲取指令中攜帶有業務類型信息和 ID 類型指示符 ; 所述第一服務端根據所述 ID 類型指示符的指示, 生成基于服務端標識號和自增序列 的 ID 值, 或者, 生成基于當前時間戳、 服務端標識號和自增序列的 ID 值。
5: 如權利要求 1 所述的方法, 其特征在于, 所述 ID 獲取指令中攜帶有業務類型信息 ; 所述第一服務端接收到所述 ID 獲取指令后, 根據配置的業務類型與 ID 類型的對應關 系, 生成基于服務端標識號和自增序列的 ID 值, 或者, 生成基于當前時間戳、 服務端標識號 和自增序列的 ID 值。
6: 如權利要求 1 所述的方法, 其特征在于, 所述第一服務端在利用所述自增序列進行 ID 值生成時, 本次生成的 ID 值對應的自增序列在上次生成的 ID 值對應的自增序列基礎上 連續遞增。
7: 如權利要求 1 所述的方法, 其特征在于, 所述第一服務端生成的基于服務端標識號 和自增序列的 ID 值為位寬為 32 位的 ID 值 ; 所述第一服務端生成的基于當前時間戳、 服務 端標識號和自增序列的 ID 值為位寬為 64 位的 ID 值。
8: 如權利要求 1 至 7 任一項所述的方法, 其特征在于, 所述方法還包括 : 當所述第一服 務端故障時, 通過第二服務端接收所述調用端發起的 ID 獲取指令, 并為所述調用端生成 ID 值; 其中, 所述第二服務端與所述第一服務端具有不同的服務端標識號。
9: 一種 ID 生成裝置, 其特征在于, 包括 : 指令接收單元, 用于接收調用端發起的 ID 獲取指令 ; ID 生成單元, 用于根據所述 ID 獲取指令, 生成基于裝置標識號和自增序列的 ID 值, 或 者生成基于當前時間戳、 裝置標識號和自增序列的 ID 值 ; ID 發送單元, 用于將所述 ID 生成單元生成的 ID 發送至所述調用端。
10: 如權利要求 9 所述的裝置, 其特征在于, 所述指令接收單元和 ID 發送單元通過配置 的 Get 接口與所述調用端通信。
11: 如權利要求 9 所述的裝置, 其特征在于, 所述裝置與所述調用端間采用 memcache 協 議進行通信。
12: 如權利要求 9 所述的裝置, 其特征在于, 所述指令接收單元接收到的 ID 獲取指令中攜帶有業務類型信息和 ID 類型指示符 ; 所述 ID 生成單元, 用于根據所述 ID 類型指示符的指示, 生成基于裝置標識號和自增序 2 列的 ID 值, 或者, 生成基于當前時間戳、 裝置標識號和自增序列的 ID 值。
13: 如權利要求 9 所述的裝置, 其特征在于, 所述指令接收單元接收到的 ID 獲取指令中攜帶有業務類型信息 ; 所述 ID 生成單元, 用于在接收到所述 ID 獲取指令后, 根據配置的業務類型與 ID 類型 的對應關系, 生成基于裝置標識號和自增序列的 ID 值, 或者, 生成基于當前時間戳、 裝置標 識號和自增序列的 ID 值。
14: 如權利要求 9 所述的裝置, 其特征在于, 所述 ID 生成單元, 在利用所述自增序列進 行 ID 值生成時, 本次生成的 ID 值對應的自增序列在上次生成的 ID 值對應的自增序列基礎 上連續遞增。
15: 如權利要求 9 所述的裝置, 其特征在于, 所述 ID 生成單元生成的基于裝置標識號和 自增序列的 ID 值為位寬為 32 位的 ID 值, 生成的基于當前時間戳、 裝置標識號和自增序列 的 ID 值為位寬為 64 位的 ID 值。
16: 一種 ID 生成系統, 其特征在于, 包括 : 第一服務端、 以及一個或多個調用端 ; 所述調用端, 用于在業務的觸發下, 向所述第一服務端發起 ID 獲取指令, 并接收所述 第一服務端反饋的 ID 值 ; 所述第一服務端, 用于根據接收的所述 ID 獲取指令, 生成基于服務端標識號和自增序 列的 ID 值, 或者生成基于當前時間戳、 服務端標識號和自增序列的 ID 值, 并將生成的所述 ID 值發送至所述調用端。
17: 如權利要求 16 所述的系統, 其特征在于, 所述第一服務端配置有 Get 接口, 負責收 發與各所述調用端的間信息 ; 所述調用端配置有調用接口, 負責收發與所述第一服務端間 的信息。
18: 如權利要求 16 所述的系統, 其特征在于, 所述第一服務端與各所述調用端間采用 memcache 協議進行通信。
19: 如權利要求 16 所述的系統, 其特征在于, 所述調用端發起的所述 ID 獲取指令中攜帶有業務類型信息和 ID 類型指示符 ; 所述第一服務端根據所述 ID 類型指示符的指示, 生成基于服務端標識號和自增序列 的 ID 值, 或者, 生成基于當前時間戳、 服務端標識號和自增序列的 ID 值。
20: 如權利要求 16 所述的系統, 其特征在于, 所述調用端發起的所述 ID 獲取指令中攜帶有業務類型信息 ; 所述第一服務端接收到所述 ID 獲取指令后, 根據配置的業務類型與 ID 類型的對應關 系, 生成基于服務端標識號和自增序列的 ID 值, 或者, 生成基于當前時間戳、 服務端標識號 和自增序列的 ID 值。
21: 如權利要求 16 所述的系統, 其特征在于, 所述第一服務端在利用所述自增序列進 行 ID 值生成時, 本次生成的 ID 值對應的自增序列在上次生成的 ID 值對應的自增序列基礎 上連續遞增。
22: 如權利要求 16 所述的系統, 其特征在于, 所述第一服務端生成的基于服務端標識 號和自增序列的 ID 值為位寬為 32 位的 ID 值 ; 所述第一服務端生成的基于當前時間戳、 服 務端標識號和自增序列的 ID 值為位寬為 64 位的 ID 值。
23: 如權利要求 16 至 22 任一項所述的系統, 其特征在于, 所述系統還包括 : 第二服務 3 端; 所述第二服務端, 用于在所述第一服務端故障時, 接收所述調用端發起的 ID 獲取指 令, 并為所述調用端生成 ID 值 ; 其中, 所述第二服務端與所述第一服務端具有不同的服務 端標識號。

說明書


一種 ID 生成方法、 裝置和系統

    【技術領域】
     本發明涉及數據處理技術領域, 尤其涉及一種 ID 生成方法、 裝置和系統。背景技術 在數據庫的使用中, 對每一條數據進行 insert, update, delete 等操作時, 通常都 會使用主鍵來進行操作。每一條數據的主鍵都必須是唯一的, 否則會因為主鍵沖突導致操 作失敗。
     關于主鍵的生成, 目前存在如下幾種方案 :
     方案一, 數據庫本身提供了 auto_increment 的功能, 來提供自增 ID。當使用數據 庫時指明主鍵為 auto_increment, 寫入數據時將主鍵設置為 null 值, 數據庫會自動生成遞 增的 ID 來作為主鍵。對于單表的操作來說, 這種方案較簡單, 便于部署實現。
     然而, 該方案存在如下缺點 : 大規模的線上業務在使用數據庫時, 因為數據規模較 大的原因, 不會使用單表來存儲數據。而是將數據水平分割, 保存在多張結構相同的表中,
     減少每張表中數據, 從而保證數據庫的性能。在這種情況下, 由于數據庫自身提供的 auto_ increment 只能對一張表生成自增 ID, 無法使用技術方案一。當數據規模較大, 需要對數據 庫進行水平分割等操作時, 方案一就不再適用了, 可擴展性較差, 只適合小業務使用。
     方案二, 數據庫的 auto_increment 支持步長的設定, 即在每次建立新 ID 的時候, ID 的增長量不是 1, 而是某個預先設置好的值。自增量設置為 10, 則生成的自增 ID 就可以 是 1,11,21,31,41 這樣的序列。如果對數據庫進行了分表, 分為了 100 張表 : 對一張表設置 自增量為 10, 初始值為 1, 則生成 1,11,21,31 這樣的 ID 序列, 對第二張表設置初始值為 2, 生成 2,12,22,32 這樣的 id, 則能保證 id 是全局唯一的。
     然而, 該方案存在如下缺點 : 每張表中的 ID 是彼此獨立的。先表 1 中寫入兩條數 據, 對應的 ID 為 1、 11, 再在表 2 中寫入數據 ID 為 2。在這種情況下無法再使用 ID 作為排 序的依據。如果誤操作導致某張表的自增量設置錯誤, 會在兩張表中生成相同的 ID, ID 的 全局唯一性就不能保證了。采用基于數據庫的方案還存在一個嚴重問題, 當使用了主從同 步的方案后 : 將從服務器切換為主, 可能因此數據同步的延時導致產生的新 ID 已經在服務 器上產生過了, 主鍵沖突導致數據同步出現問題。
     方案三, 使用 UUID(Universally Unique Identifier, 通用唯一識別碼) 作為唯 一主鍵。 UUID 是在一臺機器上生成的數字, 它保證對在同一時空中的所有機器都是唯一的, 保證了時鐘序列。
     然而, 該方案存在的缺點如下 : UUID 的缺陷在于生成的結果串很長, 占用 128 位。 在數據庫中使用會導致占用更多的空間。 UUID 是在不同機器上生成的, 因此盡管 UUID 本身 支持了時鐘序列, 但是如果使用 UUID 來進行排序, 則依賴于分布式系統中不同機器之間的 時間是否同步。而實際上分布式系統之間的時間不可能做到完全一致, 因此在分布式系統 中使用 UUID 來排序會存在問題。發明內容 本發明提供一種 ID 生成方法、 裝置和系統, 用以解決現有技術不能有效地生成全 局唯一 ID 的問題。
     為了解決上述問題, 本發明采用的技術方案如下 :
     一方面, 本發明提供了一種 ID 生成方法, 包括 :
     第一服務端接收調用端發起的 ID 獲取指令, 根據所述 ID 獲取指令, 生成基于服 務端標識號和自增序列的 ID 值, 或者生成基于當前時間戳、 服務端標識號和自增序列的 ID 值, 并將生成的所述 ID 值發送至所述調用端。
     進一步地, 本發明所述方法中, 所述第一服務端配置有 Get 接口, 負責收發與各所 述調用端間的信息 ; 所述調用端配置有調用接口, 負責收發與所述第一服務端間的信息。
     進一步地, 本發明所述方法中, 所述第一服務端與調用端間采用 memcache 協議進 行通信。
     進一步地, 本發明所述方法中, 所述 ID 獲取指令中攜帶有業務類型信息和 ID 類型 指示符 ; 所述第一服務端根據所述 ID 類型指示符的指示, 生成基于服務端標識號和自增序 列的 ID 值, 或者, 生成基于當前時間戳、 服務端標識號和自增序列的 ID 值。
     進一步地, 本發明所述方法中, 所述 ID 獲取指令中攜帶有業務類型信息 ; 所述第 一服務端接收到所述 ID 獲取指令后, 根據配置的業務類型與 ID 類型的對應關系, 生成基于 服務端標識號和自增序列的 ID 值, 或者, 生成基于當前時間戳、 服務端標識號和自增序列 的 ID 值。
     進一步地, 本發明所述方法中, 所述第一服務端在利用所述自增序列進行 ID 值生 成時, 本次生成的 ID 值對應的自增序列在上次生成的 ID 值對應的自增序列基礎上連續遞 增。
     進一步地, 本發明所述方法中, 所述第一服務端生成的基于服務端標識號和自增 序列的 ID 值為位寬為 32 位的 ID 值 ; 所述第一服務端生成的基于當前時間戳、 服務端標識 號和自增序列的 ID 值為位寬為 64 位的 ID 值。
     優選地, 本發明所述方法還包括 : 當所述第一服務端故障時, 通過第二服務端接收 所述調用端發起的 ID 獲取指令, 并為所述調用端生成 ID 值 ; 其中, 所述第二服務端與所述 第一服務端具有不同的服務端標識號。
     另一方面, 本發明還提供了一種 ID 生成裝置, 包括 :
     指令接收單元, 用于接收調用端發起的 ID 獲取指令 ;
     ID 生成單元, 用于根據所述 ID 獲取指令, 生成基于裝置標識號和自增序列的 ID 值, 或者生成基于當前時間戳、 裝置標識號和自增序列的 ID 值 ;
     ID 發送單元, 用于將所述 ID 生成單元生成的 ID 發送至所述調用端。
     進一步地, 本發明所述裝置中, 所述指令接收單元和 ID 發送單元通過配置的 Get 接口與所述調用端通信。
     進一步地, 本發明所述裝置與所述調用端間采用 memcache 協議進行通信。
     進一步地, 本發明所述裝置中, 所述指令接收單元接收到的 ID 獲取指令中攜帶有 業務類型信息和 ID 類型指示符 ; 所述 ID 生成單元, 用于根據所述 ID 類型指示符的指示, 生 成基于裝置標識號和自增序列的 ID 值, 或者, 生成基于當前時間戳、 裝置標識號和自增序
     列的 ID 值。
     進一步地, 本發明所述裝置中, 所述指令接收單元接收到的 ID 獲取指令中攜帶有 業務類型信息 ; 所述 ID 生成單元, 用于在接收到所述 ID 獲取指令后, 根據配置的業務類型 與 ID 類型的對應關系, 生成基于裝置標識號和自增序列的 ID 值, 或者, 生成基于當前時間 戳、 裝置標識號和自增序列的 ID 值。
     進一步地, 本發明所述裝置中, 所述 ID 生成單元, 在利用所述自增序列進行 ID 值 生成時, 本次生成的 ID 值對應的自增序列在上次生成的 ID 值對應的自增序列基礎上連續 遞增。
     進一步地, 本發明所述裝置中, 所述 ID 生成單元生成的基于裝置標識號和自增序 列的 ID 值為位寬為 32 位的 ID 值, 生成的基于當前時間戳、 裝置標識號和自增序列的 ID 值 為位寬為 64 位的 ID 值。
     再者, 本發明還提供了一種 ID 生成系統, 包括 : 第一服務端、 以及一個或多個調用 端;
     所述調用端, 用于在業務的觸發下, 向所述第一服務端發起 ID 獲取指令, 并接收 所述第一服務端反饋的 ID 值 ; 所述第一服務端, 用于根據接收的所述 ID 獲取指令, 生成基于服務端標識號和自 增序列的 ID 值, 或者生成基于當前時間戳、 服務端標識號和自增序列的 ID 值, 并將生成的 所述 ID 值發送至所述調用端。
     進一步地, 本發明所述系統中, 所述第一服務端配置有 Get 接口, 負責收發與各所 述調用端的間信息 ; 所述調用端配置有調用接口, 負責收發與所述第一服務端間的信息。
     進一步地, 本發明所述系統中, 所述第一服務端與各所述調用端間采用 memcache 協議進行通信。
     進一步地, 本發明所述系統中, 所述調用端發起的所述 ID 獲取指令中攜帶有業務 類型信息和 ID 類型指示符 ; 所述第一服務端根據所述 ID 類型指示符的指示, 生成基于服務 端標識號和自增序列的 ID 值, 或者, 生成基于當前時間戳、 服務端標識號和自增序列的 ID 值。
     進一步地, 本發明所述系統中, 所述調用端發起的所述 ID 獲取指令中攜帶有業務 類型信息 ; 所述第一服務端接收到所述 ID 獲取指令后, 根據配置的業務類型與 ID 類型的對 應關系, 生成基于服務端標識號和自增序列的 ID 值, 或者, 生成基于當前時間戳、 服務端標 識號和自增序列的 ID 值。
     進一步地, 本發明所述系統中, 所述第一服務端在利用所述自增序列進行 ID 值生 成時, 本次生成的 ID 值對應的自增序列在上次生成的 ID 值對應的自增序列基礎上連續遞 增。
     進一步地, 本發明所述系統中, 所述第一服務端生成的基于服務端標識號和自增 序列的 ID 值為位寬為 32 位的 ID 值 ; 所述第一服務端生成的基于當前時間戳、 服務端標識 號和自增序列的 ID 值為位寬為 64 位的 ID 值。
     優選地, 本發明所述系統還包括 : 第二服務端 ;
     所述第二服務端, 用于在所述第一服務端故障時, 接收所述調用端發起的 ID 獲取 指令, 并為所述調用端生成 ID 值 ; 其中, 所述第二服務端與所述第一服務端具有不同的服
     務端標識號。
     與現有技術相比, 本發明有益效果如下 :
     本發明所述方案不在依賴數據庫自由的 ID 生成方式, 而是將全局唯一 ID 生成抽 象成服務。對調用端來說調用接口簡單方便, 生成的 id 全局唯一、 有序、 便于使用。對大規 模的數據處理, 也能夠良好支持。 同時, 本發明還保證了服務的高性能, 高可靠性, 不存在宕 機時間。 附圖說明 為了更清楚地說明本發明實施例或現有技術中的技術方案, 下面將對實施例或現 有技術描述中所需要使用的附圖作一簡單地介紹, 顯而易見地, 下面描述中的附圖僅僅是 本發明的一些實施例, 對于本領域普通技術人員來講, 在不付出創造性勞動性的前提下, 還 可以根據這些附圖獲得其他的附圖。
     圖 1 為本發明實施例一提供的一種全局唯一 ID 生成方法的流程圖 ;
     圖 2 為本發明實施例二提供的一種全局唯一 ID 生成裝置的結構框圖 ;
     圖 3 為本發明實施例三提供的一種全局唯一 ID 生成系統的結構框圖 ;
     圖 4 為本發明實施例三提供的一種全局唯一 ID 生成系統的又一結構框圖。具體實施方式
     下面將結合本發明實施例中的附圖, 對本發明實施例中的技術方案進行清楚、 完 整地描述, 顯然, 所描述的實施例僅僅是本發明一部分實施例, 而不是全部的實施例。基于 本發明中的實施例, 本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他 實施例, 都屬于本發明保護的范圍。
     本發明實施例提供一種生成方法、 裝置和系統, 其基本原理是 : 將生成 ID 從數據 庫本身抽取出來, 作為統一的公共服務, 提供給不同的業務使用。具體表現為 : 調用端在需 要生成一個全局唯一 ID 時, 調用 id=idGenerator:genID(product_name), 向第一服務端發 起 ID 獲取請求 ; 第一服務端為調用端提供 get 接口, 當接收到調用端的 ID 獲取請求時, 利 用設定的 ID 生成算法生成對應的 ID 給調用端。本發明實施例所述方法、 裝置和系統以一 種便捷、 簡單、 高效、 安全的方式來生成全局唯一的數字 ID, 作為數據庫的主鍵, 保證了服務 的高可靠性, 即使部分服務器故障仍然可以正常服務, 服務高效, 可靠。
     下面通過幾個具體實施例對本發明的實現過程進行詳細闡述, 具體如下 :
     實施例一
     本發明實施例提供一種 ID 生成方法, 如圖 1 所示, 包括 :
     步驟 S101、 第一服務端接收調用端發起的 ID 獲取指令 ;
     該步驟中, 所述第一服務端配置有 Get 接口, 用于收發與各所述調用端間的信息 ; 所述調用端配置有調用接口, 用于收發與所述第一服務端間的信息。
     優 選 地, 所 述 第 一 服 務 端 與 調 用 端 間 采 用 memcache 協 議 進 行 通 信。 當 采 用 memcache 協議通信時, 可以直接使用 memcache 的客戶端作為調用端, 降低了調用端部署的 工作量, 便于維護。
     步驟 S102、 第一服務端根據所述 ID 獲取指令, 生成基于服務端標識號和自增序列的 ID 值, 或者生成基于當前時間戳、 服務端標識號和自增序列的 ID 值, 并將所述 ID 值發送 至調用端 ;
     該步驟中, 所述 ID 獲取指令中攜帶有業務類型信息, 用以指示標識待生成 ID 值對 應的業務類型。 其中, 業務類型信息可以包括產品名稱 + 業務名稱, 例如 : 360_cloud+file, 即表示調用端請求第一服務端為 360_cloud/file 分配 ID。
     該步驟中, 優選地, 在所述 ID 獲取指令中還攜帶 ID 類型指示符, 或者, 在第一服務 端內配置業務類型與 ID 類型的對應關系, 指示第一服務端在接收到 ID 獲取指令時, 生成基 于服務端標識號和自增序列的 ID 值, 還是生成基于當前時間戳、 服務端標識號和自增序列 的 ID 值。
     舉例說明, 當 ID 類型指示符采用 @l 或者 @s 表示時, @l 表示指示第一服務端生成 基于當前時間戳、 服務端標識號和自增序列的 ID 值 ; @s 表示指示第一服務端生成基于服務 端標識號和自增序列的 ID 值, 若 ID 獲取指令中攜帶 360_cloud/[email protected], 則表示調用端請求 第一服務端為 360_cloud/file 生成基于當前時間戳、 服務端標識號和自增序列的 ID 值。
     其中, 生成的基于服務端標識號和自增序列的 ID 值, 或者生成的基于當前時間 戳、 服務端標識號和自增序列的 ID 值分別對應著不同的 ID 位寬, 優選地, 所述基于服務端 標識號和自增序列的 ID 值為 32 位 ID 值, 所述基于當前時間戳、 服務端標識號和自增序列 的 ID 值為 64 位 ID 值。在具體實現時, 生成哪種位寬的 ID 值依賴于業務規模的大小, 通常 情況下業務規模較大時, 采用長 ID(即 64 位) , 否則, 采用短 ID(即 32 位) 。 其中, 對于長 ID 的生成算法為 : 第一服務端獲取當前時間戳、 本機的標識號 (數字 編號) 、 序列號 ( 一個自增的數字, 新 ID 則序列號為 0), 組合為一個 ID。如 : 生成的 ID 為 13210036700100000120, 其中, 1321003670 為時間戳、 01 為本機標識號、 00000120 為生成的 自增序列號。 再次生成的 ID 則為 13210036700100000121。 當 00000120 增長達到 99999999 后再次獲取 ID, 自增序列號會重新變為 0。由于時間戳是秒級別的, 因此當每秒獲取 ID 不 超過 100000000 個時, 第一服務端能保證生成的 ID 是全局唯一的。
     對于短 ID 的生成算法, 通常用于滿足一些規模較小的業務, 因為保存一個 32 位的 ID 能夠降低對數據庫空間大小的占用。短 ID 的生成算法對長 ID 生成算法進行了簡化, 去 掉時間戳, 使用服務端標識號和自增序列號組成 ID。如 : 生成的 ID 為 0100001243, 其中, 01 為服務端標識號, 00001243 為自增序列號。當業務規模不超過 100000000 時, 可以使用短 ID 算法。
     根據上述算法可知, 所述第一服務端生成 ID 值時, 本次生成 ID 值對應的自增序列 在相鄰上次生成 ID 值對應的自增序列基礎上連續遞增。另外, 需要說明的是, 對于長 ID 算 法, 在同一時間下, 若第一服務端生成 ID 超出自增序列個數的上限, 則向調用端返回錯誤 消息 false ; 對于短 ID 算法, 若第一服務端生成所有 ID 的個數超出自增序列個數的上限, 則向調用端返回錯誤消息 false。
     進一步地, 所述步驟 S102 中, 第一服務端在生成 ID 值后, 通過保存生成的 ID 值對應的自增序列, 為生成下一個 ID 值提供自增序列遞增參考依據。當然, 第一服務 端也可將 ID 值及其對應的業務類型等信息均保存下來, 例如 : 保存 360_cloud|[email protected] : 13210036700100000120。 本發明實施例中, 由于第一服務端保存的數據量較小, 所有數據都 可以加載到內存中進行操作, 因此可以保證服務的高效性。
     優選方案, 本發明實施例所述方法還支持 failover 機制, 具體表現為 : 當第一服 務端故障時, 令第二服務端接替第一服務端為調用端生成相應的 ID。其中, 第二服務端的 相關配置與第一服務端完全相同, 只有服務端標識號不同。由此可見, 本發明實施例中, 當 第一服務端發生故障時, 第二服務端為調用端提供 ID 生成服務, 進而實現了服務的高可靠 性。
     綜上所述, 可見本發明實施例所述方法通過面向服務的方式來生成全局唯一 ID, 具有良好的可擴展性, 高可用性, 高可靠性 ; 同時還保證了生成的 ID 是有序的, 遞增的, ID 占用的空間相比 UUID 更小, 使用便捷。
     實施例二
     本發明實施例提供一種 ID 生成裝置, 該裝置優選為一個服務器, 如圖 2 所示, 包 括: 指令接收單元 210、 ID 生成單元 220 和 ID 發送單元 230, 其中 :
     指令接收單元 210, 用于接收調用端發起的 ID 獲取指令 ;
     ID 生成單元 220, 用于根據所述 ID 獲取指令, 生成基于裝置標識號和自增序列的 ID 值, 或者生成基于當前時間戳、 裝置標識號和自增序列的 ID 值 ;
     ID 發送單元 230, 用于將 ID 生成單元 220 生成的 ID 發送至調用端。
     其中, 指令接收單元 210 和 ID 發送單元 230 通過裝置配置的 Get 接口與各調用端 進行通信。優選地, 通信所采用協議為 memcache 協議。
     進一步地, 指令接收單元 210 接收到的 ID 獲取指令中攜帶有業務類型信息, 用以 標識待生成 ID 值對應的業務類型。其中, 業務類型信息可以包括產品名稱 + 業務名稱, 例 如: 360_cloud+file, 即表示調用端請求本發明實施例所述裝置為 360_cloud/file 分配 ID。
     優選地, 在所述 ID 獲取指令中還攜帶有 ID 類型指示符, 或者, 在 ID 生成單元 220 內配置有業務類型與 ID 類型的對應關系, 用以指示 ID 生成單元 220 生成基于裝置標識號 和自增序列的 ID 值, 或者, 指示 ID 生成單元 220 生成基于當前時間戳、 裝置標識號和自增 序列的 ID 值。
     其中, ID 生成單元 220 生成的基于裝置標識號和自增序列的 ID 值, 或者生成的基 于當前時間戳、 裝置標識號和自增序列的 ID 值分別對應著不同的 ID 位寬, 優選地, 所述基 于裝置標識號和自增序列的 ID 值為 32 位 ID 值, 所述基于當前時間戳、 裝置標識號和自增 序列的 ID 值為 64 位 ID 值。在具體實現時, 生成哪種位寬的 ID 值依賴于業務規模的大小, 通常情況下業務規模較大時, 采用長 ID(即 64 位) , 否則, 采用短 ID(即 32 位) 。
     其中, 對于長 ID 的生成算法為 : ID 生成單元 220 獲取當前時間戳、 裝置的標識號 (數字編號) 、 序列號 ( 一個自增的數字, 新 ID 則序列號為 0), 組合為一個 ID。如 : 生成的 ID 為 13210036700100000120, 其中, 1321003670 為時間戳、 01 為裝置標識號、 00000120 為 生成的自增序列號。再次生成的 ID 則為 13210036700100000121。當 00000120 增長達到 99999999 后再次獲取 ID, 自增序列號會重新變為 0。 由于時間戳是秒級別的, 因此當每秒獲 取 ID 不超過 100000000 個時, 本發明實施例所述裝置能保證生成的 ID 是全局唯一的。
     對于短 ID 的生成算法, 通常用于滿足一些規模較小的業務, 因為保存一個 32 位的 ID 能夠降低對數據庫空間大小的占用。短 ID 的生成算法對長 ID 生成算法進行了簡化, 去 掉時間戳, 使用裝置標識號和自增序列號組成 ID。 如: 生成的 ID 為 0100001243, 其中, 01 為裝置標識號, 00001243 為自增序列號。當業務規模不超過 100000000 時, 可以使用短 ID 算 法。
     根據上述算法可知, ID 生成單元 220 生成 ID 值時, 本次生成 ID 值對應的自增序 列在相鄰上次生成 ID 值對應的自增序列基礎上連續遞增。另外, 需要說明的是, 對于長 ID 算法, 在同一時間下, 若 ID 生成單元 220 生成 ID 超出自增序列個數的上限, 則向調用端返 回錯誤消息 false ; 對于短 ID 算法, 若 ID 生成單元 220 生成所有 ID 的個數超出自增序列 個數的上限, 則向調用端返回錯誤消息 false。
     進一步地, 本發明實施例所述裝置中, ID 生成單元 220 在生成 ID 值后, 可以通過 保存生成的 ID 值對應的自增序列, 為生成下一個 ID 值提供自增序列遞增參考依據。當然, ID 生成單元 220 也可將 ID 值及其對應的業務類型等信息均保存下來。本發明實施例所述 裝置保存的數據量較小, 所有數據都可以加載到內存中進行操作, 因此可以保證服務的高 效性。
     綜上所述, 可見本發明實施例所述裝置通過面向服務的方式來生成全局唯一 ID, 具有良好的可擴展性, 高可用性等 ; 同時還保證了生成的 ID 是有序的, 遞增的, ID 占用的空 間相比 UUID 更小, 使用便捷。 實施例三
     本發明實施例提供一種 ID 生成系統, 如圖 3 所示, 包括 : 第一服務端 310、 以及一 個或多個調用端 320 ;
     調用端 320, 用于在業務的觸發下, 向第一服務端 310 發起 ID 獲取指令, 并接收第 一服務端 320 反饋的 ID 值 ;
     第一服務端 310, 用于根據接收的 ID 獲取指令, 生成基于服務端標識號和自增序 列的 ID 值, 或者生成基于當前時間戳、 服務端標識號和自增序列的 ID 值, 并將生成的 ID 值 發送至調用端 320。
     其中, 第一服務端 310 配置有負責收發與各調用端 320 間信息的 Get 接口 ; 調用端 320 配置有收發與第一服務端 310 間信息的調用接口。 優選地, 第一服務端 310 與各調用端 320 間采用 memcache 協議進行通信。 當采用 memcache 協議通信時, 可以直接使用 memcache 的客戶端作為調用端, 降低了調用端部署的工作量, 便于維護。
     具體地, 對于調用端側, 有:
     調用端 320 發起的 ID 獲取指令中攜帶有業務類型信息, 用以標識待生成 ID 值對 應的業務類型。 其中, 業務類型信息可以包括產品名稱 + 業務名稱, 例如 : 360_cloud+file, 即表示調用端請求第一服務端為 360_cloud/file 分配 ID。
     優選地, 調用端 320 發起的 ID 獲取指令中還攜帶有 ID 類型指示符, 用以指示第一 服務端 310 生成基于服務端標識號和自增序列的 ID 值, 或者, 指示第一服務端 310 生成基 于當前時間戳、 服務端標識號和自增序列的 ID 值。舉例說明, 當 ID 類型指示符采用 @l 或 者 @s 表示時, @l 表示指示指示第一服務端生成基于當前時間戳、 服務端標識號和自增序列 的 ID 值 ; @s 指示第一服務端生成基于服務端標識號和自增序列的 ID 值, 若 ID 獲取指令中 攜帶 360_cloud/[email protected], 則表示調用端請求第一服務端為 360_cloud/file 生成基于當前 時間戳、 服務端標識號和自增序列的 ID 值。
     具體地, 對于第一服務端側, 有:
     第一服務端 310 根據 ID 獲取指令中攜帶的 ID 類型指示符, 為調用端 320 生成基 于服務端標識號和自增序列的 ID 值, 或者生成基于當前時間戳、 服務端標識號和自增序列 的 ID 值。或者, 第一服務端 310 內配置有業務類型與 ID 類型的對應關系, 第一服務端 310 根據該對應關系生成基于服務端標識號和自增序列的 ID 值, 或者, 生成基于當前時間戳、 服務端標識號和自增序列的 ID 值。
     其中, 生成的基于服務端標識號和自增序列的 ID 值, 或者生成的基于當前時間 戳、 服務端標識號和自增序列的 ID 值分別對應著不同的 ID 位寬, 優選地, 所述基于服務端 標識號和自增序列的 ID 值為 32 位 ID 值, 所述基于當前時間戳、 服務端標識號和自增序列 的 ID 值為 64 位 ID 值。在具體實現時, 生成哪種位寬的 ID 值依賴于業務規模的大小, 通常 情況下業務規模較大時, 采用長 ID(即 64 位) , 否則, 采用短 ID(即 32 位) 。
     其中, 對于長 ID 的生成算法為 : 第一服務端 310 獲取當前時間戳、 本機的標識號 (數字編號) 、 序列號 ( 一個自增的數字, 新 ID 則序列號為 0), 組合為一個 ID。如 : 生成的 ID 為 13210036700100000120, 其中, 1321003670 為時間戳、 01 為本機標識號、 00000120 為 生成的自增序列號。再次生成的 ID 則為 13210036700100000121。當 00000120 增長達到 99999999 后再次獲取 ID, 自增序列號會重新變為 0。 由于時間戳是秒級別的, 因此當每秒獲 取 ID 不超過 100000000 個時, 第一服務端 310 能保證生成的 ID 是全局唯一的。 對于短 ID 的生成算法, 通常用于滿足一些規模較小的業務, 因為保存一個 32 位的 ID 能夠降低對數據庫空間大小的占用。短 ID 的生成算法對長 ID 生成算法進行了簡化, 去 掉時間戳, 使用服務端標識號和自增序列號組成 ID。如 : 生成的 ID 為 0100001243, 其中, 01 為服務端標識號, 00001243 為自增序列號。當業務規模不超過 100000000 時, 可以使用短 ID 算法。
     根據上述算法可知, 第一服務端 310 生成 ID 值時, 本次生成 ID 值對應的自增序列 在相鄰上次生成 ID 值對應的自增序列基礎上連續遞增。另外, 需要說明的是, 對于長 ID 算 法, 在同一時間下, 若第一服務端 310 生成 ID 超出自增序列個數的上限, 則向調用端 320 返 回錯誤消息 false ; 對于短 ID 算法, 若第一服務端 310 生成所有 ID 的個數超出自增序列個 數的上限, 則向調用端 320 返回錯誤消息 false。
     進 一 步 地, 第 一 服 務 端 310 在 生 成 ID 值 后, 可 以 通 過 保 存 生 成 的 ID 值 對 應 的 自 增 序 列, 為 生 成 下 一 個 ID 值 提 供 自 增 序 列 遞 增 參 考 依 據。 當 然, 第一服務端也 可 將 ID 值 及 其 對 應 的 業 務 類 型 等 信 息 均 保 存 下 來, 例如 : 保 存 360_cloud|[email protected] : 13210036700100000120。本發明實施例中, 由于第一服務端 310 保存的數據量較小, 所有數 據都可以加載到內存中進行操作, 因此可以保證服務的高效性。
     優選方案, 如圖 4 所示, 本發明實施例所述系統還包括 : 第二服務端 330 ; 所述第二 服務端 330, 用于在第一服務端 310 故障時, 接收調用端 320 發起的 ID 獲取指令, 并為該調 用端生成 ID 值。其中, 第二服務端 330 與第一服務端 310 的相關配置完全相同, 只有服務 端標識號不同。本優選方案使得本發明實施例所述系統支持了 failover 機制, 進而實現了 服務的高可靠性。
     綜上所述, 可見本發明實施例所述系統通過面向服務的方式來生成全局唯一 ID, 具有良好的可擴展性, 高可用性, 高可靠性 ; 同時還保證了生成的 ID 是有序的, 遞增的, ID 占用的空間相比 UUID 更小, 使用便捷。
     顯然, 本領域的技術人員可以對本發明進行各種改動和變型而不脫離本發明的精 神和范圍。這樣, 倘若本發明的這些修改和變型屬于本發明權利要求及其等同技術的范圍 之內, 則本發明也意圖包含這些改動和變型在內。

關于本文
本文標題:一種ID生成方法、裝置和系統.pdf
鏈接地址:http://www.wwszu.club/p-6420829.html
關于我們 - 網站聲明 - 網站地圖 - 資源地圖 - 友情鏈接 - 網站客服 - 聯系我們

[email protected] 2017-2018 zhuanlichaxun.net網站版權所有
經營許可證編號:粵ICP備17046363號-1 
 


收起
展開
鬼佬大哥大