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

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

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

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

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

一、引子

在復(fù)雜的系統(tǒng)中，往往需要使用一個有意義且有序的序列號來作為全局唯一的ID，來對大量的數(shù)據(jù)（如訂單賬戶）進行標(biāo)識。

二、業(yè)內(nèi)方案簡介

2.1 時間戳方案

取當(dāng)前毫秒數(shù)/微秒作為ID ，如System.currentTimeMillis()

優(yōu)點

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

缺點

• 并發(fā)量過高，會生成重復(fù)的ID。
• 不能高可用，存在單點故障問題。
• 不夠靈活，不能實現(xiàn)對不同業(yè)務(wù)的ID隔離。

2.2 UUID 方案

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

優(yōu)點

• 性能非常高：本地生成，沒有網(wǎng)絡(luò)消耗。

缺點

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

• ID作為主鍵時在特定的環(huán)境會存在一些問題，比如做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索引不利。如果作為數(shù)據(jù)庫主鍵，在InnoDB引擎下，UUID的無序性可能會引起數(shù)據(jù)位置頻繁變動，嚴(yán)重影響性能。

2.3 Snowflake 方案

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

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

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

優(yōu)點

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

缺點

• 強依賴機器時鐘，如果機器上時鐘回撥，會導(dǎo)致發(fā)號重復(fù)或者服務(wù)會處于不可用狀態(tài)。
• 不夠靈活，不能實現(xiàn)對不同業(yè)務(wù)的ID隔離。

2.4 數(shù)據(jù)庫 auto_increment 方案

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

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

優(yōu)點

• 非常簡單，利用現(xiàn)有數(shù)據(jù)庫系統(tǒng)的功能實現(xiàn)，成本小，有DBA專業(yè)維護。
• ID號單調(diào)自增，可以實現(xiàn)一些對ID有特殊要求的業(yè)務(wù)。

缺點

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

2.5 redis 生成 ID

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

考慮到單節(jié)點的性能瓶頸，可以使用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

優(yōu)點

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

缺點

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

2.6 ns4_gear_idgen 方案

先看下數(shù)據(jù)庫表設(shè)計:

字段說明:

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

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

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

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

優(yōu)點

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

三、 功能介紹

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

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

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

四、 請求方式

五、 SQL腳本

見 ns4_gear_idgen 源碼下 gear_key.sql

內(nèi)容來源：宜信技術(shù)學(xué)院