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

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對(duì)這個(gè)行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡(jiǎn)單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名注冊(cè)、網(wǎng)頁空間、營(yíng)銷軟件、網(wǎng)站建設(shè)、七星網(wǎng)站維護(hù)、網(wǎng)站推廣。

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

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

項(xiàng)目開源地址：https://github.com/newsettle/ns4_gear_idgen

一、引子

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

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

2.1 時(shí)間戳方案

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

優(yōu)點(diǎn)

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

缺點(diǎn)

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

2.2 UUID 方案

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

優(yōu)點(diǎn)

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

缺點(diǎn)

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

• ID作為主鍵時(shí)在特定的環(huán)境會(huì)存在一些問題，比如做DB主鍵的場(chǎng)景下，UUID就非常不適用:

  • A：MySQL官方有明確的建議主鍵要盡量越短越好[4]，36 個(gè)字符長(zhǎng)度的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：對(duì)MySQL索引不利。如果作為數(shù)據(jù)庫主鍵，在InnoDB引擎下，UUID的無序性可能會(huì)引起數(shù)據(jù)位置頻繁變動(dòng)，嚴(yán)重影響性能。

2.3 Snowflake 方案

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

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

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

優(yōu)點(diǎn)

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

缺點(diǎn)

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

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

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

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

優(yōu)點(diǎn)

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

缺點(diǎn)

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

2.5 redis 生成 ID

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

考慮到單節(jié)點(diǎn)的性能瓶頸，可以使用Redis集群來獲取更高的吞吐量。假如一個(gè)集群中有5臺(tái)Redis?？梢猿跏蓟颗_(tái)Redis的值分別是1, 2, 3, 4, 5，然后步長(zhǎng)都是5。各個(gè)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)點(diǎn)

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

缺點(diǎn)

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

2.6 ns4_gear_idgen 方案

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

字段說明:

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

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

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

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

優(yōu)點(diǎn)

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

三、 功能介紹

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

其功能可分為以下幾個(gè)部分:

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

四、 請(qǐng)求方式

五、 SQL腳本

見 ns4_gear_idgen 源碼下 gear_key.sql

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

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

當(dāng)前題目：開源|為什么要使用ns4_gear_idgenID生成器？-創(chuàng)新互聯(lián)
網(wǎng)頁鏈接：http://jinyejixie.com/article2/ddeioc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、建站公司、域名注冊(cè)、App設(shè)計(jì)、品牌網(wǎng)站制作、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)