CosId 通用、靈活、高性能的分布式ID生成器

English Document

簡介

CosId 旨在提供通用、靈活、高性能的分布式 ID 生成器。目前提供了倆類 ID 生成器：

SnowflakeId : 單機 TPS 性能：409W/s JMH 基準測試 , 主要解決 時鐘回撥問題 、機器號分配問題 并且提供更加友好、靈活的使用體驗。
SegmentId: 每次獲取一段 (Step) ID，來降低號段分發(fā)器的網(wǎng)絡(luò)IO請求頻次提升性能。
- IdSegmentDistributor: 號段分發(fā)器（號段存儲器）
  - RedisIdSegmentDistributor: 基于 Redis 的號段分發(fā)器。
  - JdbcIdSegmentDistributor: 基于 Jdbc 的號段分發(fā)器，支持各種關(guān)系型數(shù)據(jù)庫。
- SegmentChainId(推薦):SegmentChainId (lock-free) 是對 SegmentId 的增強。性能可達到近似 AtomicLong 的 TPS 性能:12743W+/s JMH 基準測試。
  - PrefetchWorker 維護安全距離(safeDistance), 并且支持基于饑餓狀態(tài)的動態(tài)safeDistance擴容/收縮。

快速開始

背景（為什么需要分布式ID）

在軟件系統(tǒng)演進過程中，隨著業(yè)務(wù)規(guī)模的增長，我們需要進行集群化部署來分攤計算、存儲壓力，應(yīng)用服務(wù)我們可以很輕松做到無狀態(tài)、彈性伸縮。但是僅僅增加服務(wù)副本數(shù)就夠了嗎？顯然不夠，因為性能瓶頸往往是在數(shù)據(jù)庫層面，那么這個時候我們就需要考慮如何進行數(shù)據(jù)庫的擴容、伸縮、集群化，通常使用分庫、分表的方式來處理。那么我如何分片(水平分片，當然還有垂直分片不過不是本文需要討論的內(nèi)容)呢，分片得前提是我們得先有一個ID，然后才能根據(jù)分片算法來分片。（比如比較簡單常用的ID取模分片算法，這個跟Hash算法的概念類似，我們得先有key才能進行Hash取得插入槽位。）

當然還有很多分布式場景需要分布式ID，這里不再一一列舉。

分布式ID方案的核心指標

全局（相同業(yè)務(wù)）唯一性：唯一性保證是ID的必要條件，假設(shè)ID不唯一就會產(chǎn)生主鍵沖突，這點很容易可以理解。
- 通常所說的全局唯一性并不是指所有業(yè)務(wù)服務(wù)都要唯一，而是相同業(yè)務(wù)服務(wù)不同部署副本唯一。比如 Order 服務(wù)的多個部署副本在生成t_order這張表的Id時是要求全局唯一的。至于t_order_item生成的ID與t_order是否唯一，并不影響唯一性約束，也不會產(chǎn)生什么副作用。不同業(yè)務(wù)模塊間也是同理。即唯一性主要解決的是ID沖突問題。
有序性：有序性保證是面向查詢的數(shù)據(jù)結(jié)構(gòu)算法（除了Hash算法）所必須的，是二分查找法(分而治之)的前提。
- MySq-InnoDB B+樹是使用最為廣泛的，假設(shè) Id 是無序的，B+ 樹為了維護 ID 的有序性，就會頻繁的在索引的中間位置插入而挪動后面節(jié)點的位置，甚至導致頻繁的頁分裂，這對于性能的影響是極大的。那么如果我們能夠保證ID的有序性這種情況就完全不同了，只需要進行追加寫操作。所以 ID 的有序性是非常重要的，也是ID設(shè)計不可避免的特性。
吞吐量/性能(ops/time)：即單位時間（每秒）能產(chǎn)生的ID數(shù)量。生成ID是非常高頻的操作，也是最為基本的。假設(shè)ID生成的性能緩慢，那么不管怎么進行系統(tǒng)優(yōu)化也無法獲得更好的性能。
- 一般我們會首先生成ID，然后再執(zhí)行寫入操作，假設(shè)ID生成緩慢，那么整體性能上限就會受到限制，這一點應(yīng)該不難理解。
穩(wěn)定性(time/op)：穩(wěn)定性指標一般可以采用每個操作的時間進行百分位采樣來分析，比如 CosId 百分位采樣 P9999=0.208 us/op，即 0% ~ 99.99% 的單位操作時間小于等于 0.208 us/op。
- 百分位數(shù) WIKI ：統(tǒng)計學術(shù)語，若將一組數(shù)據(jù)從小到大排序，并計算相應(yīng)的累計百分點，則某百分點所對應(yīng)數(shù)據(jù)的值，就稱為這百分點的百分位數(shù)，以Pk表示第k百分位數(shù)。百分位數(shù)是用來比較個體在群體中的相對地位量數(shù)。
- 為什么不用平均每個操作的時間：馬老師的身價跟你的身價能平均么？平均后的值有意義不？
- 可以使用最小每個操作的時間、最大每個操作的時間作為參考嗎？因為最小、最大值只說明了零界點的情況，雖說可以作為穩(wěn)定性的參考，但依然不夠全面。而且百分位數(shù)已經(jīng)覆蓋了這倆個指標。
自治性（依賴）：主要是指對外部環(huán)境有無依賴，比如號段模式會強依賴第三方存儲中間件來獲取NexMaxId。自治性還會對可用性造成影響。
可用性：分布式ID的可用性主要會受到自治性影響，比如SnowflakeId會受到時鐘回撥影響，導致處于短暫時間的不可用狀態(tài)。而號段模式會受到第三方發(fā)號器（NexMaxId）的可用性影響。
- 可用性 WIKI ：在一個給定的時間間隔內(nèi)，對于一個功能個體來講，總的可用時間所占的比例。
- MTBF：平均故障間隔
- MDT：平均修復/恢復時間
- Availability=MTBF/(MTBF+MDT)
- 假設(shè)MTBF為1年，MDT為1小時，即Availability=(365*24)/(365*24+1)=0.999885857778792≈99.99%，也就是我們通常所說對可用性4個9。
適應(yīng)性：是指在面對外部環(huán)境變化的自適應(yīng)能力，這里我們主要說的是面對流量突發(fā)時動態(tài)伸縮分布式ID的性能，
- SegmentChainId可以基于饑餓狀態(tài)進行安全距離的動態(tài)伸縮。
- SnowflakeId常規(guī)位分配方案性能恒定409.6W，雖然可以通過調(diào)整位分配方案來獲得不同的TPS性能，但是位分配方法的變更是破壞性的，一般根據(jù)業(yè)務(wù)場景確定位分配方案后不再變更。
存儲空間：還是用MySq-InnoDB B+樹來舉例，普通索引（二級索引）會存儲主鍵值，主鍵越大占用的內(nèi)存緩存、磁盤空間也會越大。Page頁存儲的數(shù)據(jù)越少，磁盤IO訪問的次數(shù)會增加。總之在滿足業(yè)務(wù)需求的情況下，盡可能小的存儲空間占用在絕大多數(shù)場景下都是好的設(shè)計原則。

不同分布式ID方案核心指標對比

分布式ID	全局唯一性	有序性	吞吐量	穩(wěn)定性（1s=1000,000us）	自治性	可用性	適應(yīng)性	存儲空間
UUID/GUID	是	完全無序	3078638(ops/s)	P9999=0.325(us/op)	完全自治	100%	否	128-bit
SnowflakeId	是	本地單調(diào)遞增，全局趨勢遞增(受全局時鐘影響)	4096000(ops/s)	P9999=0.244(us/op)	依賴時鐘	時鐘回撥會導致短暫不可用	否	64-bit
SegmentId	是	本地單調(diào)遞增，全局趨勢遞增(受Step影響)	29506073(ops/s)	P9999=46.624(us/op)	依賴第三方號段分發(fā)器	受號段分發(fā)器可用性影響	否	64-bit
SegmentChainId	是	本地單調(diào)遞增，全局趨勢遞增(受Step、安全距離影響)	127439148(ops/s)	P9999=0.208(us/op)	依賴第三方號段分發(fā)器	受號段分發(fā)器可用性影響，但因安全距離存在，預留ID段，所以高于SegmentId	是	64-bit

有序性(要想分而治之·二分查找法，必須要維護我)

剛剛我們已經(jīng)討論了ID有序性的重要性，所以我們設(shè)計ID算法時應(yīng)該盡可能地讓ID是單調(diào)遞增的，比如像表的自增主鍵那樣。但是很遺憾，因全局時鐘、性能等分布式系統(tǒng)問題，我們通常只能選擇局部單調(diào)遞增、全局趨勢遞增的組合（就像我們在分布式系統(tǒng)中不得不的選擇最終一致性那樣）以獲得多方面的權(quán)衡。下面我們來看一下什么是單調(diào)遞增與趨勢遞增。

有序性之單調(diào)遞增

單調(diào)遞增：T表示全局絕對時點，假設(shè)有Tn+1>Tn（絕對時間總是往前進的，這里不考慮相對論、時間機器等），那么必然有F(Tn+1)>F(Tn)，數(shù)據(jù)庫自增主鍵就屬于這一類。另外需要特別說明的是單調(diào)遞增跟連續(xù)性遞增是不同的概念。連續(xù)性遞增：F(n+1)=(F(n)+step)即下一次獲取的ID一定等于當前ID+Step，當Step=1時類似于這樣一個序列:1->2->3->4->5。

擴展小知識：數(shù)據(jù)庫的自增主鍵也不是連續(xù)性遞增的，相信你一定遇到過這種情況，請思考一下數(shù)據(jù)庫為什么這樣設(shè)計？

有序性之趨勢遞增

趨勢遞增：Tn>Tn-s，那么大概率有F(Tn)>F(Tn-s)。雖然在一段時間間隔內(nèi)有亂序，但是整體趨勢是遞增。從上圖上看，是有上升趨勢的（趨勢線）。

在SnowflakeId中n-s受到全局時鐘同步影響。
在號段模式(SegmentId)中n-s受到號段可用區(qū)間(Step)影響。

分布式ID分配方案

UUID/GUID

不依賴任何第三方中間件
性能高
完全無序
空間占用大，需要占用128位存儲空間。

UUID最大的缺陷是隨機的、無序的，當用于主鍵時會導致數(shù)據(jù)庫的主鍵索引效率低下（為了維護索引樹，頻繁的索引中間位置插入數(shù)據(jù)，而不是追加寫）。這也是UUID不適用于數(shù)據(jù)庫主鍵的最為重要的原因。

SnowflakeId

SnowflakeId使用Long（64-bit）位分區(qū)來生成ID的一種分布式ID算法。通用的位分配方案為：timestamp(41-bit)+machineId(10-bit)+sequence(12-bit)=63-bit。

41-bittimestamp=(1L<<41)/(1000/3600/365)，約可以存儲69年的時間戳，即可以使用的絕對時間為EPOCH+69年，一般我們需要自定義EPOCH為產(chǎn)品開發(fā)時間，另外還可以通過壓縮其他區(qū)域的分配位數(shù)，來增加時間戳位數(shù)來延長可用時間。
10-bitmachineId=(1L<<10)=1024，即相同業(yè)務(wù)可以部署1024個副本(在Kubernetes概念里沒有主從副本之分，這里直接沿用Kubernetes的定義)。一般情況下沒有必要使用這么多位，所以會根據(jù)部署規(guī)模需要重新定義。
12-bitsequence=(1L<<12)*1000=4096000，即單機每秒可生成約409W的ID，全局同業(yè)務(wù)集群可產(chǎn)生4096000*1024=419430W=41.9億(TPS)。

從 SnowflakeId 設(shè)計上可以看出:

timestamp在高位，單實例SnowflakeId是會保證時鐘總是向前的（校驗本機時鐘回撥），所以是本機單調(diào)遞增的。受全局時鐘同步/時鐘回撥影響SnowflakeId是全局趨勢遞增的。
SnowflakeId不對任何第三方中間件有強依賴關(guān)系，并且性能也非常高。
位分配方案可以按照業(yè)務(wù)系統(tǒng)需要靈活配置，來達到最優(yōu)使用效果。
強依賴本機時鐘，潛在的時鐘回撥問題會導致ID重復、處于短暫的不可用狀態(tài)。
machineId需要手動設(shè)置，實際部署時如果采用手動分配machineId，會非常低效。

SnowflakeId之機器號分配問題

在SnowflakeId中根據(jù)業(yè)務(wù)設(shè)計的位分配方案確定了基本上就不再有變更了，也很少需要維護。但是machineId總是需要配置的，而且集群中是不能重復的，否則分區(qū)原則就會被破壞而導致ID唯一性原則破壞，當集群規(guī)模較大時machineId的維護工作是非常繁瑣，低效的。

有一點需要特別說明的，SnowflakeId的MachineId是邏輯上的概念，而不是物理概念。想象一下假設(shè)MachineId是物理上的，那么意味著一臺機器擁有只能擁有一個MachineId，那會產(chǎn)生什么問題呢？

目前 CosId 提供了以下三種 MachineId 分配器。

ManualMachineIdDistributor: 手動配置machineId，一般只有在集群規(guī)模非常小的時候才有可能使用，不推薦。
StatefulSetMachineIdDistributor: 使用Kubernetes的StatefulSet提供的穩(wěn)定的標識ID（HOSTNAME=service-01）作為機器號。
RedisMachineIdDistributor: 使用Redis作為機器號的分發(fā)存儲，同時還會存儲MachineId的上一次時間戳，用于啟動時時鐘回撥的檢查。

SnowflakeId之時鐘回撥問題

時鐘回撥的致命問題是會導致ID重復、沖突（這一點不難理解），ID重復顯然是不能被容忍的。在SnowflakeId算法中，按照MachineId分區(qū)ID，我們不難理解的是不同MachineId是不可能產(chǎn)生相同ID的。所以我們解決的時鐘回撥問題是指當前MachineId的時鐘回撥問題，而不是所有集群節(jié)點的時鐘回撥問題。

MachineId時鐘回撥問題大體可以分為倆種情況：

運行時時鐘回撥：即在運行時獲取的當前時間戳比上一次獲取的時間戳小。這個場景的時鐘回撥是很容易處理的，一般SnowflakeId代碼實現(xiàn)時都會存儲lastTimestamp用于運行時時鐘回撥的檢查，并拋出時鐘回撥異常。
- 時鐘回撥時直接拋出異常是不太好地實踐，因為下游使用方幾乎沒有其他處理方案（噢，我還能怎么辦呢，等吧），時鐘同步是唯一的選擇，當只有一種選擇時就不要再讓用戶選擇了。
- ClockSyncSnowflakeId是SnowflakeId的包裝器，當發(fā)生時鐘回撥時會使用ClockBackwardsSynchronizer主動等待時鐘同步來重新生成ID，提供更加友好的使用體驗。
啟動時時鐘回撥：即在啟動服務(wù)實例時獲取的當前時鐘比上次關(guān)閉服務(wù)時小。此時的lastTimestamp是無法存儲在進程內(nèi)存中的。當獲取的外部存儲的機器狀態(tài)大于當前時鐘時鐘時，會使用ClockBackwardsSynchronizer主動同步時鐘。
- LocalMachineStateStorage：使用本地文件存儲MachineState(機器號、最近一次時間戳)。因為使用的是本地文件所以只有當實例的部署環(huán)境是穩(wěn)定的，LocalMachineStateStorage才適用。
- RedisMachineIdDistributor：將MachineState存儲在Redis分布式緩存中，這樣可以保證總是可以獲取到上次服務(wù)實例停機時機器狀態(tài)。

SnowflakeId之JavaScript數(shù)值溢出問題

JavaScript的Number.MAX_SAFE_INTEGER只有53-bit，如果直接將63位的SnowflakeId返回給前端，那么會產(chǎn)生值溢出的情況（所以這里我們應(yīng)該知道后端傳給前端的long值溢出問題，遲早會出現(xiàn)，只不過SnowflakeId出現(xiàn)得更快而已）。很顯然溢出是不能被接受的，一般可以使用以下倆種處理方案：

將生成的63-bitSnowflakeId轉(zhuǎn)換為String類型。
- 直接將long轉(zhuǎn)換成String。
- 使用SnowflakeFriendlyId將SnowflakeId轉(zhuǎn)換成比較友好的字符串表示：{timestamp}-{machineId}-{sequence} -> 20210623131730192-1-0
自定義SnowflakeId位分配來縮短SnowflakeId的位數(shù)（53-bit）使 ID 提供給前端時不溢出
- 使用SafeJavaScriptSnowflakeId(JavaScript 安全的 SnowflakeId)

號段模式（SegmentId）

從上面的設(shè)計圖中，不難看出號段模式基本設(shè)計思路是通過每次獲取一定長度（Step）的可用ID（Id段/號段），來降低網(wǎng)絡(luò)IO請求次數(shù)，提升性能。

強依賴第三方號段分發(fā)器，可用性受到第三方分發(fā)器影響。
每次號段用完時獲取NextMaxId需要進行網(wǎng)絡(luò)IO請求，此時的性能會比較低。
單實例ID單調(diào)遞增，全局趨勢遞增。
- 從設(shè)計圖中不難看出Instance 1每次獲取的NextMaxId，一定比上一次大，意味著下一次的號段一定比上一次大，所以從單實例上來看是單調(diào)遞增的。
- 多實例各自持有的不同的號段，意味著同一時刻不同實例生成的ID是亂序的，但是整體趨勢的遞增的，所以全局趨勢遞增。
ID亂序程度受到Step長度以及集群規(guī)模影響（從趨勢遞增圖中不難看出）。
- 假設(shè)集群中只有一個實例時號段模式就是單調(diào)遞增的。
- Step越小，亂序程度越小。當Step=1時，將無限接近單調(diào)遞增。需要注意的是這里是無限接近而非等于單調(diào)遞增，具體原因你可以思考一下這樣一個場景：
  - 號段分發(fā)器T1時刻給Instance 1分發(fā)了ID=1,T2時刻給Instance 2分發(fā)了ID=2。因為機器性能、網(wǎng)絡(luò)等原因，Instance 2網(wǎng)絡(luò)IO寫請求先于Instance 1到達。那么這個時候?qū)τ跀?shù)據(jù)庫來說，ID依然是亂序的。

號段鏈模式（SegmentChainId）

分布式ID(CosId)之號段鏈模式性能(1.2億/s)解析

SegmentChainId是SegmentId增強版，相比于SegmentId有以下優(yōu)勢：

穩(wěn)定性：SegmentId的穩(wěn)定性問題（P9999=46.624(us/op)）主要是因為號段用完之后同步進行NextMaxId的獲取導致的（會產(chǎn)生網(wǎng)絡(luò)IO）。
- SegmentChainId （P9999=0.208(us/op)）引入了新的角色PrefetchWorker用以維護和保證安全距離，理想情況下使得獲取ID的線程幾乎完全不需要進行同步的等待NextMaxId獲取，性能可達到近似 AtomicLong 的 TPS 性能:12743W+/s JMH 基準測試。
適應(yīng)性：從SegmentId介紹中我們知道了影響ID亂序的因素有倆個：集群規(guī)模、Step大小。集群規(guī)模是我們不能控制的，但是Step是可以調(diào)節(jié)的。
- Step應(yīng)該近可能小才能使得ID單調(diào)遞增的可能性增大。
- Step太小會影響吞吐量，那么我們?nèi)绾魏侠碓O(shè)置Step呢？答案是我們無法準確預估所有時點的吞吐量需求，那么最好的辦法是吞吐量需求高時，Step自動增大，吞吐量低時Step自動收縮。
- SegmentChainId引入了饑餓狀態(tài)的概念，PrefetchWorker會根據(jù)饑餓狀態(tài)檢測當前安全距離是否需要膨脹或者收縮，以便獲得吞吐量與有序性之間的權(quán)衡，這便是SegmentChainId的自適應(yīng)性。

集成

CosIdPlugin（MyBatis 插件）

Kotlin DSL

    implementation("me.ahoo.cosid:cosid-mybatis:${cosidVersion}")

public class Order {

    @CosId(value = "order")
    private Long orderId;
    private Long userId;

    public Long getOrderId() {
        return orderId;
    }

    public void setOrderId(Long orderId) {
        this.orderId = orderId;
    }

    public Long getUserId() {
        return userId;
    }

    public void setUserId(Long userId) {
        this.userId = userId;
    }
}

ShardingSphere 插件

CosIdKeyGenerateAlgorithm、CosIdModShardingAlgorithm、CosIdIntervalShardingAlgorithm 已合并至 ShardingSphere 官方，未來 cosid-shardingsphere 模塊的維護可能會以官方為主。

Kotlin DSL

    implementation("me.ahoo.cosid:cosid-shardingsphere:${cosidVersion}")

CosIdKeyGenerateAlgorithm (分布式主鍵)

spring:
  shardingsphere:
    rules:
      sharding:
        key-generators:
          cosid:
            type: COSID
            props:
              id-name: __share__

基于間隔的時間范圍分片算法

易用性: 支持多種數(shù)據(jù)類型 (Long/LocalDateTime/DATE/ String / SnowflakeId)，而官方實現(xiàn)是先轉(zhuǎn)換成字符串再轉(zhuǎn)換成LocalDateTime，轉(zhuǎn)換成功率受時間格式化字符影響。
性能 : 相比于 org.apache.shardingsphere.sharding.algorithm.sharding.datetime.IntervalShardingAlgorithm 性能高出 1200~4000 倍。

PreciseShardingValue	RangeShardingValue

gradle cosid-shardingsphere:jmh

# JMH version: 1.29
# VM version: JDK 11.0.13, OpenJDK 64-Bit Server VM, 11.0.13+8-LTS
# VM options: -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/work/CosId/cosid-shardingsphere/build/tmp/jmh -Duser.country=CN -Duser.language=zh -Duser.variant
# Blackhole mode: full + dont-inline hint
# Warmup: 1 iterations, 10 s each
# Measurement: 1 iterations, 10 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
Benchmark                                                         (days)   Mode  Cnt         Score   Error  Units
IntervalShardingAlgorithmBenchmark.cosid_precise_local_date_time      10  thrpt       53279788.772          ops/s
IntervalShardingAlgorithmBenchmark.cosid_precise_local_date_time     100  thrpt       38114729.365          ops/s
IntervalShardingAlgorithmBenchmark.cosid_precise_local_date_time    1000  thrpt       32714318.129          ops/s
IntervalShardingAlgorithmBenchmark.cosid_precise_local_date_time   10000  thrpt       22317905.643          ops/s
IntervalShardingAlgorithmBenchmark.cosid_precise_timestamp            10  thrpt       20028091.211          ops/s
IntervalShardingAlgorithmBenchmark.cosid_precise_timestamp           100  thrpt       19272744.794          ops/s
IntervalShardingAlgorithmBenchmark.cosid_precise_timestamp          1000  thrpt       17814417.856          ops/s
IntervalShardingAlgorithmBenchmark.cosid_precise_timestamp         10000  thrpt       12384788.025          ops/s
IntervalShardingAlgorithmBenchmark.cosid_range_local_date_time        10  thrpt       18716732.080          ops/s
IntervalShardingAlgorithmBenchmark.cosid_range_local_date_time       100  thrpt        8436553.492          ops/s
IntervalShardingAlgorithmBenchmark.cosid_range_local_date_time      1000  thrpt        1655952.254          ops/s
IntervalShardingAlgorithmBenchmark.cosid_range_local_date_time     10000  thrpt         185348.831          ops/s
IntervalShardingAlgorithmBenchmark.cosid_range_timestamp              10  thrpt        9410931.643          ops/s
IntervalShardingAlgorithmBenchmark.cosid_range_timestamp             100  thrpt        5792861.181          ops/s
IntervalShardingAlgorithmBenchmark.cosid_range_timestamp            1000  thrpt        1585344.761          ops/s
IntervalShardingAlgorithmBenchmark.cosid_range_timestamp           10000  thrpt         196663.812          ops/s
IntervalShardingAlgorithmBenchmark.office_precise_timestamp           10  thrpt          72189.800          ops/s
IntervalShardingAlgorithmBenchmark.office_precise_timestamp          100  thrpt          11245.324          ops/s
IntervalShardingAlgorithmBenchmark.office_precise_timestamp         1000  thrpt           1339.128          ops/s
IntervalShardingAlgorithmBenchmark.office_precise_timestamp        10000  thrpt            113.396          ops/s
IntervalShardingAlgorithmBenchmark.office_range_timestamp             10  thrpt          64679.422          ops/s
IntervalShardingAlgorithmBenchmark.office_range_timestamp            100  thrpt           4267.860          ops/s
IntervalShardingAlgorithmBenchmark.office_range_timestamp           1000  thrpt            227.817          ops/s
IntervalShardingAlgorithmBenchmark.office_range_timestamp          10000  thrpt              7.579          ops/s

SmartIntervalShardingAlgorithm
- type: COSID_INTERVAL
DateIntervalShardingAlgorithm
- type: COSID_INTERVAL_DATE
LocalDateTimeIntervalShardingAlgorithm
- type: COSID_INTERVAL_LDT
TimestampIntervalShardingAlgorithm
- type: COSID_INTERVAL_TS
TimestampOfSecondIntervalShardingAlgorithm
- type: COSID_INTERVAL_TS_SECOND
SnowflakeIntervalShardingAlgorithm
- type: COSID_INTERVAL_SNOWFLAKE

spring:
  shardingsphere:
    rules:
      sharding:
        sharding-algorithms:
          alg-name:
            type: COSID_INTERVAL_{type_suffix}
            props:
              logic-name-prefix: logic-name-prefix
              id-name: cosid-name
              datetime-lower: 2021-12-08 22:00:00
              datetime-upper: 2022-12-01 00:00:00
              sharding-suffix-pattern: yyyyMM
              datetime-interval-unit: MONTHS
              datetime-interval-amount: 1

取模分片算法

性能 : 相比于 org.apache.shardingsphere.sharding.algorithm.sharding.mod.ModShardingAlgorithm 性能高出 1200~4000 倍。并且穩(wěn)定性更高，不會出現(xiàn)嚴重的性能退化。

PreciseShardingValue	RangeShardingValue

gradle cosid-shardingsphere:jmh

# JMH version: 1.29
# VM version: JDK 11.0.13, OpenJDK 64-Bit Server VM, 11.0.13+8-LTS
# VM options: -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/work/CosId/cosid-shardingsphere/build/tmp/jmh -Duser.country=CN -Duser.language=zh -Duser.variant
# Blackhole mode: full + dont-inline hint
# Warmup: 1 iterations, 10 s each
# Measurement: 1 iterations, 10 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
Benchmark                                     (divisor)   Mode  Cnt          Score   Error  Units
ModShardingAlgorithmBenchmark.cosid_precise          10  thrpt       121431137.111          ops/s
ModShardingAlgorithmBenchmark.cosid_precise         100  thrpt       119947284.141          ops/s
ModShardingAlgorithmBenchmark.cosid_precise        1000  thrpt       113095657.321          ops/s
ModShardingAlgorithmBenchmark.cosid_precise       10000  thrpt       108435323.537          ops/s
ModShardingAlgorithmBenchmark.cosid_precise      100000  thrpt        84657505.579          ops/s
ModShardingAlgorithmBenchmark.cosid_range            10  thrpt        37397323.508          ops/s
ModShardingAlgorithmBenchmark.cosid_range           100  thrpt        16905691.783          ops/s
ModShardingAlgorithmBenchmark.cosid_range          1000  thrpt         2969820.981          ops/s
ModShardingAlgorithmBenchmark.cosid_range         10000  thrpt          312881.488          ops/s
ModShardingAlgorithmBenchmark.cosid_range        100000  thrpt           31581.396          ops/s
ModShardingAlgorithmBenchmark.office_precise         10  thrpt         9135460.160          ops/s
ModShardingAlgorithmBenchmark.office_precise        100  thrpt         1356582.418          ops/s
ModShardingAlgorithmBenchmark.office_precise       1000  thrpt          104500.125          ops/s
ModShardingAlgorithmBenchmark.office_precise      10000  thrpt            8619.933          ops/s
ModShardingAlgorithmBenchmark.office_precise     100000  thrpt             629.353          ops/s
ModShardingAlgorithmBenchmark.office_range           10  thrpt         5535645.737          ops/s
ModShardingAlgorithmBenchmark.office_range          100  thrpt           83271.925          ops/s
ModShardingAlgorithmBenchmark.office_range         1000  thrpt             911.534          ops/s
ModShardingAlgorithmBenchmark.office_range        10000  thrpt               9.133          ops/s
ModShardingAlgorithmBenchmark.office_range       100000  thrpt               0.208          ops/s

spring:
  shardingsphere:
    rules:
      sharding:
        sharding-algorithms:
          alg-name:
            type: COSID_MOD
            props:
              mod: 4
              logic-name-prefix: t_table_

CosId分布式系統(tǒng) ID 生成器

CosId 通用、靈活、高性能的分布式ID生成器

簡介

快速開始

背景（為什么需要分布式ID）

分布式ID方案的核心指標

不同分布式ID方案核心指標對比

有序性(要想分而治之·二分查找法，必須要維護我)

有序性之單調(diào)遞增

有序性之趨勢遞增

分布式ID分配方案

UUID/GUID

SnowflakeId

SnowflakeId之機器號分配問題

SnowflakeId之時鐘回撥問題

SnowflakeId之JavaScript數(shù)值溢出問題

號段模式（SegmentId）

號段鏈模式（SegmentChainId）

集成

CosIdPlugin（MyBatis 插件）

ShardingSphere 插件

CosIdKeyGenerateAlgorithm (分布式主鍵)

基于間隔的時間范圍分片算法

取模分片算法

性能測試報告

SegmentChainId-吞吐量 (ops/s)

RedisChainIdBenchmark-Throughput

MySqlChainIdBenchmark-Throughput

SegmentChainId-每次操作耗時的百分位數(shù)(us/op)

RedisChainIdBenchmark-Percentile

MySqlChainIdBenchmark-Percentile

基準測試報告運行環(huán)境說明

CosId分布式系統(tǒng) ID 生成器

CosId 通用、靈活、高性能的分布式ID生成器

簡介

快速開始

背景（為什么需要分布式ID）

分布式ID方案的核心指標

不同分布式ID方案核心指標對比

有序性(要想分而治之·二分查找法，必須要維護我)

有序性之單調(diào)遞增

有序性之趨勢遞增

分布式ID分配方案

UUID/GUID

SnowflakeId

SnowflakeId之機器號分配問題

SnowflakeId之時鐘回撥問題

SnowflakeId之JavaScript數(shù)值溢出問題

號段模式（SegmentId）

號段鏈模式（SegmentChainId）

集成

CosIdPlugin（MyBatis 插件）

ShardingSphere 插件

CosIdKeyGenerateAlgorithm (分布式主鍵)

基于間隔的時間范圍分片算法

取模分片算法

性能測試報告

SegmentChainId-吞吐量 (ops/s)

RedisChainIdBenchmark-Throughput

MySqlChainIdBenchmark-Throughput

SegmentChainId-每次操作耗時的百分位數(shù)(us/op)

RedisChainIdBenchmark-Percentile

MySqlChainIdBenchmark-Percentile

基準測試報告運行環(huán)境說明

有序性(要想分而治之·二分查找法，必須要維護我)