快捷導(dǎo)航

mybatis-plus主鍵生成策略

更新時(shí)間：2020年08月27日 10:38:40 作者：愛瑪999

這篇文章主要介紹了mybatis-plus主鍵生成策略，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧

MP 支持多種主鍵策略默認(rèn)是推特的“” 雪花算法“” ，也可以設(shè)置其他策略下面我演示主鍵策略使用

MP的主鍵定義在一個(gè)一個(gè)枚舉類中源碼如下

public enum IdType {
  AUTO(0),//數(shù)據(jù)庫自增 依賴數(shù)據(jù)庫
  NONE(1),// 表示該類型未甚至主鍵類型 （如果沒有主鍵策略）默認(rèn)根據(jù)雪花算法生成
  INPUT(2),//用戶輸入ID（該類型可以通過自己注冊(cè)填充插件進(jìn)行填充）
　　//下面這三種類型,只有當(dāng)插入對(duì)象id為空時(shí) 才會(huì)自動(dòng)填充。
  ID_WORKER(3),//全局唯一（idWorker）數(shù)值類型
  UUID(4),//全局唯一（UUID）
  ID_WORKER_STR(5);//全局唯一（idWorker的字符串表示）

  private final int key;

  private IdType(int key) {
    this.key = key;
  }

  public int getKey() {
    return this.key;
  }
}

1，局部主鍵策略實(shí)現(xiàn)

在實(shí)體類中 ID屬性加注解

@TableId(type = IdType.AUTO) 主鍵自增 數(shù)據(jù)庫中需要設(shè)置主鍵自增
private Long id;
@TableId(type = IdType.NONE) 默認(rèn) 跟隨全局策略走
private Long id;
@TableId(type = IdType.UUID) UUID類型主鍵
private Long id;
@TableId(type = IdType.ID_WORKER) 數(shù)值類型 數(shù)據(jù)庫中也必須是數(shù)值類型 否則會(huì)報(bào)錯(cuò)
private Long id;
@TableId(type = IdType.ID_WORKER_STR) 字符串類型  數(shù)據(jù)庫也要保證一樣字符類型
private Long id;
@TableId(type = IdType.INPUT) 用戶自定義了 數(shù)據(jù)類型和數(shù)據(jù)庫保持一致就行
private Long id;

2，全局主鍵策略實(shí)現(xiàn)

需要在application.yml文件中

添加

mybatis-plus:
 mapper-locations:
  - com/mp/mapper/*
 global-config:
  db-config:
   id-type: uuid/none/input/id_worker/id_worker_str/auto  表示全局主鍵都采用該策略（如果全局策略和局部策略都有設(shè)置，局部策略優(yōu)先級(jí)高）

Mybatis-Plus中另外的幾種主鍵生成策略

1、分布式系統(tǒng)中主鍵的生成策略

在分布式系統(tǒng)中，常見的主鍵生成策略有以下幾種：

1.1 數(shù)據(jù)庫自增長序列或字段

最常見的方式。利用數(shù)據(jù)庫，全數(shù)據(jù)庫唯一。

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

1）簡(jiǎn)單，代碼方便，性能可以接受。

2）數(shù)字ID天然排序，對(duì)分頁或者需要排序的結(jié)果很有幫助。

缺點(diǎn)：

1）不同數(shù)據(jù)庫語法和實(shí)現(xiàn)不同，數(shù)據(jù)庫遷移的時(shí)候或多數(shù)據(jù)庫版本支持的時(shí)候需要處理。

2）在單個(gè)數(shù)據(jù)庫或讀寫分離或一主多從的情況下，只有一個(gè)主庫可以生成。有單點(diǎn)故障的風(fēng)險(xiǎn)。

3）在性能達(dá)不到要求的情況下，比較難于擴(kuò)展。

4）如果遇見多個(gè)系統(tǒng)需要合并或者涉及到數(shù)據(jù)遷移會(huì)相當(dāng)痛苦。

5）分表分庫的時(shí)候會(huì)有麻煩。

優(yōu)化方案：

針對(duì)主庫單點(diǎn)，如果有多個(gè)Master庫，則每個(gè)Master庫設(shè)置的起始數(shù)字不一樣，步長一樣，可以是Master的個(gè)數(shù)。比如：Master1 生成的是 1，4，7，10，Master2生成的是2,5,8,11 Master3生成的是 3,6,9,12。這樣就可以有效生成集群中的唯一ID，也可以大大降低ID生成數(shù)據(jù)庫操作的負(fù)載。類似于Redis的生成策略

1.2 UUID

常見的方式。可以利用數(shù)據(jù)庫也可以利用程序生成，一般來說全球唯一。

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

1）簡(jiǎn)單，代碼方便。

2）生成ID性能非常好，基本不會(huì)有性能問題。

3）全球唯一，在遇見數(shù)據(jù)遷移，系統(tǒng)數(shù)據(jù)合并，或者數(shù)據(jù)庫變更等情況下，可以從容應(yīng)對(duì)。

缺點(diǎn)：

1）沒有排序，無法保證趨勢(shì)遞增。

2）UUID往往是使用字符串存儲(chǔ)，查詢的效率比較低。

3）存儲(chǔ)空間比較大，如果是海量數(shù)據(jù)庫，就需要考慮存儲(chǔ)量的問題。

4）傳輸數(shù)據(jù)量大

5）可讀性差

1.3 UUID to Int64

UUID的變種：解決了UUID可讀性差和無序的問題

1.4 Redis生成ID

當(dāng)使用數(shù)據(jù)庫來生成ID性能不夠要求的時(shí)候，我們可以嘗試使用Redis來生成ID。這主要依賴于Redis是單線程的，所以也可以用生成全局唯一的ID?？梢杂肦edis的原子操作 INCR和INCRBY來實(shí)現(xiàn)。

可以使用Redis集群來獲取更高的吞吐量。假如一個(gè)集群中有5臺(tái)Redis?？梢猿跏蓟颗_(tái)Redis的值分別是1,2,3,4,5，然后步長都是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

這個(gè)，隨便負(fù)載到哪個(gè)機(jī)確定好，未來很難做修改。但是3-5臺(tái)服務(wù)器基本能夠滿足器上，都可以獲得不同的ID。但是步長和初始值一定需要事先需要了。使用Redis集群也可以方式單點(diǎn)故障的問題。

另外，比較適合使用Redis來生成每天從0開始的流水號(hào)。比如訂單號(hào)=日期+當(dāng)日自增長號(hào)。可以每天在Redis中生成一個(gè)Key，使用INCR進(jìn)行累加。

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

1）不依賴于數(shù)據(jù)庫，靈活方便，且性能優(yōu)于數(shù)據(jù)庫。

2）數(shù)字ID天然排序，對(duì)分頁或者需要排序的結(jié)果很有幫助。

缺點(diǎn)：

1）如果系統(tǒng)中沒有Redis，還需要引入新的組件，增加系統(tǒng)復(fù)雜度。

2）需要編碼和配置的工作量比較大。

1.5 Twitter的snowflake算法（雪花算法）

snowflake是Twitter開源的分布式ID生成算法，結(jié)果是一個(gè)long型的ID。其核心思想是：使用41bit作為毫秒數(shù)，10bit作為機(jī)器的ID（5個(gè)bit是數(shù)據(jù)中心，5個(gè)bit的機(jī)器ID），12bit作為毫秒內(nèi)的流水號(hào)（意味著每個(gè)節(jié)點(diǎn)在每毫秒可以產(chǎn)生 4096 個(gè) ID），最后還有一個(gè)符號(hào)位，永遠(yuǎn)是0。具體實(shí)現(xiàn)的代碼可以參看https://github.com/twitter/snowflake。

snowflake算法可以根據(jù)自身項(xiàng)目的需要進(jìn)行一定的修改。比如估算未來的數(shù)據(jù)中心個(gè)數(shù)，每個(gè)數(shù)據(jù)中心的機(jī)器數(shù)以及統(tǒng)一毫秒可以能的并發(fā)數(shù)來調(diào)整在算法中所需要的bit數(shù)。

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

1）不依賴于數(shù)據(jù)庫，靈活方便，且性能優(yōu)于數(shù)據(jù)庫。

2）ID按照時(shí)間在單機(jī)上是遞增的。

缺點(diǎn)：

1）在單機(jī)上是遞增的，但是由于涉及到分布式環(huán)境，每臺(tái)機(jī)器上的時(shí)鐘不可能完全同步，也許有時(shí)候也會(huì)出現(xiàn)不是全局遞增的情況。

MP中的ID_WORKER就是使用的這種算法

1.6 zookeeper生成唯一ID

zookeeper主要通過其znode數(shù)據(jù)版本來生成序列號(hào)，可以生成32位和64位的數(shù)據(jù)版本號(hào)，客戶端可以使用這個(gè)版本號(hào)來作為唯一的序列號(hào)。
很少會(huì)使用zookeeper來生成唯一ID。主要是由于需要依賴zookeeper，并且是多步調(diào)用API，如果在競(jìng)爭(zhēng)較大的情況下，需要考慮使用分布式鎖。因此，性能在高并發(fā)的分布式環(huán)境下，也不甚理想。

1.7 MongoDB的ObjectId

MongoDB的ObjectId和snowflake算法類似。它設(shè)計(jì)成輕量型的，不同的機(jī)器都能用全局唯一的同種方法方便地生成它。MongoDB 從一開始就設(shè)計(jì)用來作為分布式數(shù)據(jù)庫，處理多個(gè)節(jié)點(diǎn)是一個(gè)核心要求。使其在分片環(huán)境中要容易生成得多。

到此這篇關(guān)于mybatis-plus主鍵生成策略的文章就介紹到這了,更多相關(guān)mybatis-plus 主鍵內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: