開源|為什么要使用ns4_gear_idgen ID生成器？

導語：宜信于2019年3月29日正式開源nextsystem4（以下簡稱“NS4”）系列模塊。此次開源的NS4系列模塊是圍繞當前支付系統笨重、代碼耦合度高、維護成本高而產生的分布式業務系統解決方案。NS4系列框架允許創建復雜的流程/業務流，對于業務服務節點的實現可串聯，可分布式。其精簡、輕量，實現了“脫容器”（不依賴tomcat、jetty等容器）獨立運行。NS4系列框架的設計理念是將業務和邏輯進行分離，開發人員只需通過簡單的配置和業務實現就可以實現邏輯復雜、性能高效、功能穩定的業務系統。點擊查看框架整體介紹

NS4系列包括4個開源模塊，分別是：ns4_frame 分布式服務框架（詳情點擊查看：開源|ns4_frame分布式服務框架開發指南）、ns4_gear_idgen ID生成器組件（NS4框架Demo示例）、ns4_gear_watchdog 監控系統組件（服務守護、應用性能監控、數據采集、自動化報警系統）和ns4_chatbot通訊組件。

其中，ns4_gear_idgen（ID生成器）是基于ns4_frame框架實現的，它支持分布式部署，生成全局唯一的 ID，其中長度、前綴、后綴、步長、進制也可根據自己的業務自由配置，還可以通過ns4_gear_idgen對NS4.0框架進行測試。本文重點介紹ns4_gear_idgen （ID生成器）方案具備哪些優點。

項目開源地址：https://github.com/newsettle/ns4_gear_idgen

一、引子

在復雜的系統中，往往需要使用一個有意義且有序的序列號來作為全局唯一的ID，來對大量的數據（如訂單賬戶）進行標識。

二、業內方案簡介

2.1 時間戳方案

取當前毫秒數/微秒作為ID ，如System.currentTimeMillis()

優點

• 本地生成ID，不需要進行遠程調用，時延低。
• 生成的ID趨勢遞增。
• 生成的ID是整數，建立索引后查詢效率高。

缺點

• 并發量過高，會生成重復的ID。
• 不能高可用，存在單點故障問題。
• 不夠靈活，不能實現對不同業務的ID隔離。

2.2 UUID 方案

UUID(Universally Unique Identifier)的標準型式包含32個16進制數字，以連字號分為五段，形式為8-4-4-4-12的36個字符。示例：550e8400-e29b-41d4-a716- 446655440000，到目前為止業界一共有 5 種方式生成UUID，詳情見IETF發布的UUID規范 A Universally Unique IDentifier (UUID) URN Namespace。

優點

• 性能非常高：本地生成，沒有網絡消耗。

缺點

• 不易于存儲：UUID太長，16字節128位，通常以36長度的字符串表示，很多場景不適用。
• 信息不安全：基于MAC地址生成UUID的算法可能會造成MAC地址泄露，這個漏洞曾被用于尋找梅麗莎病×××者位置。
• 無序ID：于ID之前毫無順序可言。

• ID作為主鍵時在特定的環境會存在一些問題，比如做DB主鍵的場景下，UUID就非常不適用:

  • A：MySQL官方有明確的建議主鍵要盡量越短越好[4]，36 個字符長度的UUID不符合要求。

  All indexes other than the clustered index are known as secondary indexes. In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary key value to search for the row in the clustered index. If the primary key is long, the secondary indexes use more space, so it is advantageous to have a short primary key.

  • B：對MySQL索引不利。如果作為數據庫主鍵，在InnoDB引擎下，UUID的無序性可能會引起數據位置頻繁變動，嚴重影響性能。

2.3 Snowflake 方案

這種方案大致來說是一種以劃分命名空間(UUID也算，由于比較常見，所以單獨分析)來生成ID的一種算法，這種方案把64-bit分別劃分成多段，分開來標示機器、時間等，比如在snowflake中的64-bit分別表示。如下圖(圖片來自網絡)所示:

41-bit的時間可以表示(1L<<41)/(1000L*3600*24*365)=69年的時間，10-bit機器可以分別表示1024臺機器。如果我們對IDC劃分有需求，還可以將10-bit分5-bit給IDC，分5-bit給工作機器。這樣就可以表示32個IDC，每個IDC下可以有32臺機器，可以根據自身需求定義。

12 個自增序列號可以表示2^12個ID，理論上snowflake方案的QPS約為409.6w/s，這種分配方式可以保證在任何一個IDC的任何一臺機器在任意毫秒內生成的ID都是不同的。

優點

• 毫秒數在高位，自增序列在低位，整個ID都是趨勢遞增的。
• 不依賴數據庫等第三方系統，以服務的方式部署，穩定性更高，生成ID的性能也是非常高的。
• 可以根據自身業務特性分配bit位，非常靈活。

缺點

• 強依賴機器時鐘，如果機器上時鐘回撥，會導致發號重復或者服務會處于不可用狀態。
• 不夠靈活，不能實現對不同業務的ID隔離。

2.4 數據庫 auto_increment 方案

以MySQL舉例，利用給字段設置auto_increment_increment和 auto_increment_offset來保證ID自增，每次業務使用下列SQL讀寫MySQL得到ID號。

begin;
REPLACE INTO Tickets64 (stub) VALUES ('a');
SELECT LAST_INSERT_ID();
commit;

優點

• 非常簡單，利用現有數據庫系統的功能實現，成本小，有DBA專業維護。
• ID號單調自增，可以實現一些對ID有特殊要求的業務。

缺點

• 強依賴DB，當DB異常時整個系統不可用，屬于致命問題。配置主從復制可以盡可能的。
• 增加可用性，但是數據一致性在特殊情況下難以保證。主從切換時的不一致可能會導致重復發號。
• ID發號性能瓶頸限制在單臺MySQL的讀寫性能。

2.5 redis 生成 ID

Redis的所有命令操作都是單線程的，本身提供像incr和increby這樣的自增原子命令，所以能保證生成的ID肯定是唯一有序的。

考慮到單節點的性能瓶頸，可以使用Redis集群來獲取更高的吞吐量。假如一個集群中有5臺Redis。可以初始化每臺Redis的值分別是1, 2, 3, 4, 5，然后步長都是5。各個Redis生成的ID為:

A:1, 6, 11, 16, 21

B:2, 7, 12, 17, 22

C:3, 8, 13, 18, 23

D:4, 9, 14, 19, 24

E:5, 10, 15, 20, 25

優點

• 不依賴于數據庫，靈活方便，且性能優于數據庫。
• 數字ID天然排序，對分頁或者需要排序的結果很有幫助。
• 使用集群可以防止單點故障問題。

缺點

• 如果系統中沒有Redis，還需要引入新的組件，增加系統復雜度。
• 需要編碼和配置的工作量比較大。
• 步長、初始值需提前確定好且不易于擴展。

2.6 ns4_gear_idgen 方案

先看下數據庫表設計:

字段說明:

• id：數據庫主鍵，無實際含義。
• key_name ：用來區分業務，不同的業務使用不同的。
• key_name，每個key_name的ID相互隔離，互不影響。如果以后有性能需求需要對數據庫擴容，不需要上述描述的復雜的擴容操作，只需要對 biz_tag 分庫分表就行。
• key_value：表示該key_name目前所被分配的ID號段的最大值。
• key_length：生成ID的長度。
• key_cache：表示每次分配的號段長度。原來獲取ID每次都需要寫數據庫，現在只需要把key_cache設置得足夠大，比如1000。那么只有當 1000個號被消耗完了之后才會去重新讀寫一次數據庫。讀寫數據庫的頻率從1減小到了1/step。

• key_prefix：生成ID的前綴，可配置自定義前綴+日期部分 如: ${date14}/TEST${date14}

  • ID前綴日期部分支持以下幾種日期格式:
    

    • key_suffix=：生成ID的后綴，可配置亦可不配置
    • key_digit:ID 進制數，支持10進制36進制62進制 。
• Version：每條記錄對應的版本號，用戶更新記錄。

優點

• 很方便的線性擴展，能夠支撐大多數業務場景。
• 生成ID規則多樣，可配置且支持10進制、36進制、62進制。
• 業務之間ID相互隔離，互不影響。
• 獲取ID不用頻繁操作數據庫，快消耗完號段內ID時才會操作數據庫，減輕了數據庫的壓力。
• 提前初始化號段內的ID，保證在每個號段內ID使用完之前初始化完成，避免業務使用完ID后才初始化帶來的影響。
• 可以自定義key_value的大小，非常方便業務從原有的ID方式上遷移過來。
• 容災性高：服務內部有號段緩存，即使 DB 宕機，短時間內服務仍能正常對外提供服務。

三、 功能介紹

該ID生成器是基于NS4框架實現的，支持分布式部署，同時生成的ID長度、前綴、后綴、步長，進制也可根據自己的業務自由的配置。

其功能可分為以下幾個部分:

• 獲取單個 Long 類型的 ID 如 66310
• 獲取批量 String 類型的 ID:19011123221266312, 19011123221266313, 19011123221266314, 19011123221266315

四、 請求方式

五、 SQL腳本

見 ns4_gear_idgen 源碼下 gear_key.sql

內容來源：宜信技術學院