[發明專利]一種基于Redis的業務ID生成方法

在審

• 申請號: 202010513461.4
• 申請日: 2020-06-08
• 公開（公告）號: CN111651459A
• 公開（公告）日: 2020-09-11
• 發明（設計）人: 任超超;楊明
• 申請（專利權）人: 北京首汽智行科技有限公司
• 主分類號: G06F16/22
• 分類號: G06F16/22;G06F16/2458
• 代理公司: 北京世譽鑫誠專利代理事務所(普通合伙) 11368
• 代理人: 李世端

本發明涉及一種基于Redis的業務ID生成方法，包括：ID生成中心連接Redis集群，對Redis集群節點ID表進行初始化配置，所述初始化配置至少包括配置所述Redis集群中每個節點的節點ID，以及定義生成ID的初始時間戳；應用服務獲取某個節點的節點ID，Redis的當前時間戳，以及當前節點的節點自增長ID值；采用ID生成算法，基于所述初始時間戳、所述當前時間戳、所述節點ID和所述節點自增長ID值，生成64位的業務ID。本發明生成的業務ID高性能，高可用，性能穩定，可以靈活擴展，而且生成ID呈遞增趨勢。

技術領域

本發明涉及ID生成技術領域，尤其涉及一種基于Redis的業務ID生成方法。

背景技術

隨著業務的發展，用戶群體越來越大，業務數據量也在不斷的增長。在我們業務數據量不大的時候，單庫單表完全可以支撐現有業務，數據再大一點，MySQL主從同步讀寫分離也能支持。但隨著數據日漸增長，主從同步也不再適用了，就需要對數據庫進行分庫分表，但分庫分表后需要有一個唯一ID來標識一條數據，數據庫的自增ID顯然不能滿足需求；特別一點的如訂單、優惠券也都需要有唯一ID做標識。此時一個能夠生成全局唯一的業務ID的系統是非常必要的。

現階段，主流的唯一性ID生成方案有兩種，第一種是數據庫ID自增，第二種是生成唯一性的UUID。

方法一雖然穩定，生成方便，但增加了數據庫壓力，且受限于數據量；方法二雖然不依賴于外部，但不夠靈活，生成的ID沒有意義，沒有順序，極大影響數據在數據庫的存儲，且查詢效率低下。本次我設計的方法，目的就是解決以上兩種方法的弊端，設計、實現一個高性能、穩定、靈活擴展、呈遞增趨勢的唯一性業務ID生成方法.

發明內容

鑒于上述問題，提出了本發明以便提供克服上述問題或者至少部分地解決上述問題的一種基于Redis的業務ID生成方法。

根據本發明的一個方面，提供了一種基于Redis的業務ID生成方法，包括ID生成中心連接Redis集群，對Redis集群節點ID表進行初始化配置，所述初始化配置至少包括配置所述Redis集群中每個節點的節點ID，以及定義生成ID的初始時間戳；應用服務獲取某個節點的節點ID，Redis的當前時間戳，以及當前節點的節點自增長ID值；采用ID生成算法，基于所述初始時間戳、所述當前時間戳、所述節點ID和所述節點自增長ID值，生成64位的業務ID。

根據一種可能的設計，所述應用服務獲取某個節點的節點ID，具體包括：應用服務調用ID生成中心接口，所述ID生成中心從Redis節點ID表中獲取集群中某一節點的節點ID。

根據一種可能的設計，所述應用服務獲取Redis的當前時間戳，以及當前節點的節點自增長ID值，具體包括：應用服務調用ID生成中心接口，所述ID生成中心利用Lua腳本執行功能，獲取Redis當前時間戳，以及當前節點的自增值。

根據一種可能的設計，所述ID生成中心利用Lua腳本執行功能，獲取Redis當前時間戳，以及當前節點的自增值：采用Lua腳本根據Redis TIME命令，獲取Redis的當前時間戳，以及當前節點的節點自增長ID值。

根據一種可能的設計，所述64位的業務ID包括：1位標識符、41位時間戳和22位的ID值組，所述ID值組包括節點ID和節點增長ID值。

根據一種可能的設計，在所述22位的ID值組中，節點ID占12位，節點增長ID值占10位。

根據一種可能的設計，所述生成業務ID，具體包括；首先獲取Redis當前毫秒級的時間戳，減去初始預定的時間戳，得到差值的毫秒數，左移64-1-41＝22位，然后加上當前節點的節點ID左移10位后的值，最后加上節點的自增長ID值，其生成公式為：

(當前時間戳-初始時間戳)22+節點ID10+節點自增ID值。