欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

帶你入門(mén)java雪花算法原理

 更新時(shí)間:2021年06月22日 15:06:25   作者:流浪の青春  
SnowFlake 算法,是 Twitter 開(kāi)源的分布式 id 生成算法。其核心思想就是:使用一個(gè) 64 bit 的 long 型的數(shù)字作為全局唯一 id。在分布式系統(tǒng)中的應(yīng)用十分廣泛,且ID 引入了時(shí)間戳,基本上保持自增的

雪花算法(SnowFlake)

雪花算法是Twitter開(kāi)源的分布式ID生成算法.

主要是由64bit的long型生成的全局ID,引入了時(shí)間戳和ID保持自增的屬性.

64bit分為四個(gè)部分:

第一個(gè)部分是1bit, 這不 使用,沒(méi)有意義;

第二個(gè)部分是41bit, 組成時(shí)間戳;

第三個(gè)部分是10bit, 工作機(jī)器ID,里面分為兩個(gè)部分,5個(gè)bit是的是機(jī)房號(hào),代表最多有25即32個(gè)機(jī)房,5個(gè)bit是指機(jī)器的ID,代表最多有25個(gè)機(jī)器,即32個(gè)機(jī)器 .

第四部分是12bit, 代表是同一個(gè)毫秒類(lèi)產(chǎn)生不同的ID,區(qū)分同一個(gè)毫秒內(nèi)產(chǎn)生的ID.

總的來(lái)說(shuō)就是一個(gè)機(jī)房,一臺(tái)機(jī)器,在同一號(hào)毫秒時(shí)產(chǎn)生的ID,可能在同一秒鐘產(chǎn)生不同的ID,最后12bit序列號(hào)可以區(qū)分在同一秒鐘的不同ID.

雪花算法保證:

1.所生成的ID按時(shí)間遞增

2.整個(gè)分布式系統(tǒng)不會(huì)有重復(fù)的ID

在這里插入圖片描述

SnowFlake 算法,是 Twitter 開(kāi)源的分布式 id 生成算法。其核心思想就是:使用一個(gè) 64 bit 的 long 型的數(shù)字作為全局唯一 id。在分布式系統(tǒng)中的應(yīng)用十分廣泛,且ID 引入了時(shí)間戳,基本上保持自增的,后面的代碼中有詳細(xì)的注解。

這 64 個(gè) bit 中,其中 1 個(gè) bit 是不用的,然后用其中的 41 bit 作為毫秒數(shù),用 10 bit 作為工作機(jī)器 id,12 bit 作為序列號(hào)。

給大家舉個(gè)例子吧,比如下面那個(gè) 64 bit 的 long 型數(shù)字:

  • 第一個(gè)部分,是 1 個(gè) bit:0,這個(gè)是無(wú)意義的。
  • 第二個(gè)部分是 41 個(gè) bit:表示的是時(shí)間戳。
  • 第三個(gè)部分是 5 個(gè) bit:表示的是機(jī)房 id,10001。
  • 第四個(gè)部分是 5 個(gè) bit:表示的是機(jī)器 id,1 1001。
  • 第五個(gè)部分是 12 個(gè) bit:表示的序號(hào),就是某個(gè)機(jī)房某臺(tái)機(jī)器上這一毫秒內(nèi)同時(shí)生成的 id 的序號(hào),0000 00000000。

①1 bit:是不用的,為啥呢?

因?yàn)槎M(jìn)制里第一個(gè) bit 為如果是 1,那么都是負(fù)數(shù),但是我們生成的 id 都是正數(shù),所以第一個(gè) bit 統(tǒng)一都是 0

②41 bit:表示的是時(shí)間戳,單位是毫秒。

41 bit 可以表示的數(shù)字多達(dá) 2^41 - 1,也就是可以標(biāo)識(shí) 2 ^ 41 - 1 個(gè)毫秒值,換算成年就是表示 69 年的時(shí)間。

③10 bit:記錄工作機(jī)器 id,代表的是這個(gè)服務(wù)最多可以部署在 2^10 臺(tái)機(jī)器上,也就是 1024 臺(tái)機(jī)器

但是 10 bit 里 5 個(gè) bit 代表機(jī)房 id,5 個(gè) bit 代表機(jī)器 id。意思就是最多代表 2 ^ 5 個(gè)機(jī)房(32 個(gè)機(jī)房),每個(gè)機(jī)房里可以代表 2 ^ 5 個(gè)機(jī)器(32 臺(tái)機(jī)器),也可以根據(jù)自己公司的實(shí)際情況確定。

④12 bit:這個(gè)是用來(lái)記錄同一個(gè)毫秒內(nèi)產(chǎn)生的不同 id。

12 bit 可以代表的最大正整數(shù)是 2 ^ 12 - 1 = 4096,也就是說(shuō)可以用這個(gè) 12 bit 代表的數(shù)字來(lái)區(qū)分同一個(gè)毫秒內(nèi)的 4096 個(gè)不同的 id。

簡(jiǎn)單來(lái)說(shuō),你的某個(gè)服務(wù)假設(shè)要生成一個(gè)全局唯一 id,那么就可以發(fā)送一個(gè)請(qǐng)求給部署了 SnowFlake 算法的系統(tǒng),由這個(gè) SnowFlake 算法系統(tǒng)來(lái)生成唯一 id。

這個(gè) SnowFlake 算法系統(tǒng)首先肯定是知道自己所在的機(jī)房和機(jī)器的,比如機(jī)房 id = 17,機(jī)器 id = 12。

接著 SnowFlake 算法系統(tǒng)接收到這個(gè)請(qǐng)求之后,首先就會(huì)用二進(jìn)制位運(yùn)算的方式生成一個(gè) 64 bit 的 long 型 id,64 個(gè) bit 中的第一個(gè) bit 是無(wú)意義的。

接著 41 個(gè) bit,就可以用當(dāng)前時(shí)間戳(單位到毫秒),然后接著 5 個(gè) bit 設(shè)置上這個(gè)機(jī)房 id,還有 5 個(gè) bit 設(shè)置上機(jī)器 id。

最后再判斷一下,當(dāng)前這臺(tái)機(jī)房的這臺(tái)機(jī)器上這一毫秒內(nèi),這是第幾個(gè)請(qǐng)求,給這次生成 id 的請(qǐng)求累加一個(gè)序號(hào),作為最后的 12 個(gè) bit。

最終一個(gè) 64 個(gè) bit 的 id 就出來(lái)了,類(lèi)似于:

這個(gè)算法可以保證說(shuō),一個(gè)機(jī)房的一臺(tái)機(jī)器上,在同一毫秒內(nèi),生成了一個(gè)唯一的 id??赡芤粋€(gè)毫秒內(nèi)會(huì)生成多個(gè) id,但是有最后 12 個(gè) bit 的序號(hào)來(lái)區(qū)分開(kāi)來(lái)。

下面我們簡(jiǎn)單看看這個(gè) SnowFlake 算法的一個(gè)代碼實(shí)現(xiàn),這就是個(gè)示例,大家如果理解了這個(gè)意思之后,以后可以自己嘗試改造這個(gè)算法。

總之就是用一個(gè) 64 bit 的數(shù)字中各個(gè) bit 位來(lái)設(shè)置不同的標(biāo)志位,區(qū)分每一個(gè) id。

SnowFlake 算法的實(shí)現(xiàn)代碼如下:

public class IdWorker {

	//因?yàn)槎M(jìn)制里第一個(gè) bit 為如果是 1,那么都是負(fù)數(shù),但是我們生成的 id 都是正數(shù),所以第一個(gè) bit 統(tǒng)一都是 0。

	//機(jī)器ID  2進(jìn)制5位  32位減掉1位 31個(gè)
	private long workerId;
	//機(jī)房ID 2進(jìn)制5位  32位減掉1位 31個(gè)
	private long datacenterId;
	//代表一毫秒內(nèi)生成的多個(gè)id的最新序號(hào)  12位 4096 -1 = 4095 個(gè)
	private long sequence;
	//設(shè)置一個(gè)時(shí)間初始值    2^41 - 1   差不多可以用69年
	private long twepoch = 1585644268888L;
	//5位的機(jī)器id
	private long workerIdBits = 5L;
	//5位的機(jī)房id
	private long datacenterIdBits = 5L;
	//每毫秒內(nèi)產(chǎn)生的id數(shù) 2 的 12次方
	private long sequenceBits = 12L;
	// 這個(gè)是二進(jìn)制運(yùn)算,就是5 bit最多只能有31個(gè)數(shù)字,也就是說(shuō)機(jī)器id最多只能是32以?xún)?nèi)
	private long maxWorkerId = -1L ^ (-1L << workerIdBits);
	// 這個(gè)是一個(gè)意思,就是5 bit最多只能有31個(gè)數(shù)字,機(jī)房id最多只能是32以?xún)?nèi)
	private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);

	private long workerIdShift = sequenceBits;
	private long datacenterIdShift = sequenceBits + workerIdBits;
	private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
	private long sequenceMask = -1L ^ (-1L << sequenceBits);
	//記錄產(chǎn)生時(shí)間毫秒數(shù),判斷是否是同1毫秒
	private long lastTimestamp = -1L;
	public long getWorkerId(){
		return workerId;
	}
	public long getDatacenterId() {
		return datacenterId;
	}
	public long getTimestamp() {
		return System.currentTimeMillis();
	}



	public IdWorker(long workerId, long datacenterId, long sequence) {

		// 檢查機(jī)房id和機(jī)器id是否超過(guò)31 不能小于0
		if (workerId > maxWorkerId || workerId < 0) {
			throw new IllegalArgumentException(
					String.format("worker Id can't be greater than %d or less than 0",maxWorkerId));
		}

		if (datacenterId > maxDatacenterId || datacenterId < 0) {

			throw new IllegalArgumentException(
					String.format("datacenter Id can't be greater than %d or less than 0",maxDatacenterId));
		}
		this.workerId = workerId;
		this.datacenterId = datacenterId;
		this.sequence = sequence;
	}

	// 這個(gè)是核心方法,通過(guò)調(diào)用nextId()方法,讓當(dāng)前這臺(tái)機(jī)器上的snowflake算法程序生成一個(gè)全局唯一的id
	public synchronized long nextId() {
		// 這兒就是獲取當(dāng)前時(shí)間戳,單位是毫秒
		long timestamp = timeGen();
		if (timestamp < lastTimestamp) {

			System.err.printf(
					"clock is moving backwards. Rejecting requests until %d.", lastTimestamp);
			throw new RuntimeException(
					String.format("Clock moved backwards. Refusing to generate id for %d milliseconds",
							lastTimestamp - timestamp));
		}

		// 下面是說(shuō)假設(shè)在同一個(gè)毫秒內(nèi),又發(fā)送了一個(gè)請(qǐng)求生成一個(gè)id
		// 這個(gè)時(shí)候就得把seqence序號(hào)給遞增1,最多就是4096
		if (lastTimestamp == timestamp) {

			// 這個(gè)意思是說(shuō)一個(gè)毫秒內(nèi)最多只能有4096個(gè)數(shù)字,無(wú)論你傳遞多少進(jìn)來(lái),
			//這個(gè)位運(yùn)算保證始終就是在4096這個(gè)范圍內(nèi),避免你自己傳遞個(gè)sequence超過(guò)了4096這個(gè)范圍
			sequence = (sequence + 1) & sequenceMask;
			//當(dāng)某一毫秒的時(shí)間,產(chǎn)生的id數(shù) 超過(guò)4095,系統(tǒng)會(huì)進(jìn)入等待,直到下一毫秒,系統(tǒng)繼續(xù)產(chǎn)生ID
			if (sequence == 0) {
				timestamp = tilNextMillis(lastTimestamp);
			}

		} else {
			sequence = 0;
		}
		// 這兒記錄一下最近一次生成id的時(shí)間戳,單位是毫秒
		lastTimestamp = timestamp;
		// 這兒就是最核心的二進(jìn)制位運(yùn)算操作,生成一個(gè)64bit的id
		// 先將當(dāng)前時(shí)間戳左移,放到41 bit那兒;將機(jī)房id左移放到5 bit那兒;將機(jī)器id左移放到5 bit那兒;將序號(hào)放最后12 bit
		// 最后拼接起來(lái)成一個(gè)64 bit的二進(jìn)制數(shù)字,轉(zhuǎn)換成10進(jìn)制就是個(gè)long型
		return ((timestamp - twepoch) << timestampLeftShift) |
				(datacenterId << datacenterIdShift) |
				(workerId << workerIdShift) | sequence;
	}

	/**
	 * 當(dāng)某一毫秒的時(shí)間,產(chǎn)生的id數(shù) 超過(guò)4095,系統(tǒng)會(huì)進(jìn)入等待,直到下一毫秒,系統(tǒng)繼續(xù)產(chǎn)生ID
	 * @param lastTimestamp
	 * @return
	 */
	private long tilNextMillis(long lastTimestamp) {

		long timestamp = timeGen();

		while (timestamp <= lastTimestamp) {
			timestamp = timeGen();
		}
		return timestamp;
	}
	//獲取當(dāng)前時(shí)間戳
	private long timeGen(){
		return System.currentTimeMillis();
	}

	/**
	 *  main 測(cè)試類(lèi)
	 * @param args
	 */
	public static void main(String[] args) {
		System.out.println(1&4596);
		System.out.println(2&4596);
		System.out.println(6&4596);
		System.out.println(6&4596);
		System.out.println(6&4596);
		System.out.println(6&4596);
//		IdWorker worker = new IdWorker(1,1,1);
//		for (int i = 0; i < 22; i++) {
//			System.out.println(worker.nextId());
//		}
	}
}

SnowFlake算法的優(yōu)點(diǎn)

(1)高性能高可用:生成時(shí)不依賴(lài)于數(shù)據(jù)庫(kù),完全在內(nèi)存中生成。

(2)容量大:每秒中能生成數(shù)百萬(wàn)的自增ID。

(3)ID自增:存入數(shù)據(jù)庫(kù)中,索引效率高。

 SnowFlake算法的缺點(diǎn):

依賴(lài)與系統(tǒng)時(shí)間的一致性,如果系統(tǒng)時(shí)間被回調(diào),或者改變,可能會(huì)造成id沖突或者重復(fù)。

實(shí)際中我們的機(jī)房并沒(méi)有那么多,我們可以改進(jìn)改算法,將10bit的機(jī)器id優(yōu)化,成業(yè)務(wù)表或者和我們系統(tǒng)相關(guān)的業(yè)務(wù)。

總結(jié)

本篇文章的內(nèi)容就到這了,希望大家可以喜歡,也希望大家可以多多關(guān)注腳本之家的其他精彩內(nèi)容!

相關(guān)文章

  • flink進(jìn)階富函數(shù)生命周期介紹

    flink進(jìn)階富函數(shù)生命周期介紹

    這篇文章主要為大家介紹了flink進(jìn)階富函數(shù)生命周期的舉例介紹,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2023-03-03
  • 如何解決springboot自動(dòng)重啟問(wèn)題

    如何解決springboot自動(dòng)重啟問(wèn)題

    這篇文章主要介紹了如何解決springboot自動(dòng)重啟問(wèn)題,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教
    2023-09-09
  • Scala中優(yōu)雅的處理Null問(wèn)題

    Scala中優(yōu)雅的處理Null問(wèn)題

    Spark 采用混合方式,大部分情況下使用 Option,但個(gè)別時(shí)候出于性能原因才使用了null。一個(gè)很好的習(xí)慣是當(dāng)有方法返回值可能為null的時(shí)候,使用Option來(lái)代替,本文給大家介紹Scala處理Null的知識(shí)詳解,一起看看吧
    2021-08-08
  • Java中臨時(shí)文件目錄的使用

    Java中臨時(shí)文件目錄的使用

    :Java提供了系統(tǒng)屬性java.io.tmpdir來(lái)獲取默認(rèn)臨時(shí)文件目錄,適用于不同操作系統(tǒng),使用Files.createTempFile方法創(chuàng)建臨時(shí)文件,并在不需要時(shí)應(yīng)及時(shí)刪除,下面就來(lái)介紹一下
    2024-10-10
  • SpringBoot實(shí)現(xiàn)XSS攻擊防御的幾種方式

    SpringBoot實(shí)現(xiàn)XSS攻擊防御的幾種方式

    隨著Web應(yīng)用的普及,網(wǎng)絡(luò)安全問(wèn)題也日益凸顯,跨站腳本攻擊(Cross-Site Scripting,簡(jiǎn)稱(chēng)XSS)是一種常見(jiàn)的Web安全漏洞,本文旨在探討如何在Spring Boot應(yīng)用程序中有效地防御XSS攻擊,我們將介紹兩種主要的防御手段:注解和過(guò)濾器,需要的朋友可以參考下
    2024-07-07
  • Spring Cloud Config配置文件使用對(duì)稱(chēng)加密的方法

    Spring Cloud Config配置文件使用對(duì)稱(chēng)加密的方法

    Spring Cloud Config提供了兩種加密解密方式,一種是對(duì)稱(chēng)加密,一種是非對(duì)稱(chēng)加密。這篇文章將先展示如何使用對(duì)稱(chēng)加密。感興趣的朋友跟隨腳步之家小編一起學(xué)習(xí)吧
    2018-05-05
  • Java四種線程池的使用詳解

    Java四種線程池的使用詳解

    本篇文章主要介紹了Java四種線程池的使用詳解,小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧
    2017-08-08
  • Spring框架中IoC容器與DI依賴(lài)注入教程

    Spring框架中IoC容器與DI依賴(lài)注入教程

    IOC也是Spring的核心之一了,之前學(xué)的時(shí)候是采用xml配置文件的方式去實(shí)現(xiàn)的,后來(lái)其中也多少穿插了幾個(gè)注解,但是沒(méi)有說(shuō)完全采用注解實(shí)現(xiàn)。那么這篇文章就和大家分享一下,全部采用注解來(lái)實(shí)現(xiàn)IOC + DI
    2023-01-01
  • 淺談java常量池

    淺談java常量池

    下面小編就為大家?guī)?lái)一篇淺談java常量池。小編覺(jué)得挺不錯(cuò)的,現(xiàn)在就分享給大家,也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧
    2016-06-06
  • java關(guān)鍵字abstract(抽象)實(shí)例詳解

    java關(guān)鍵字abstract(抽象)實(shí)例詳解

    在Java中,抽象類(lèi)是不能實(shí)例化的類(lèi),它通常作為其他子類(lèi)的父類(lèi)存在,并提供了一種繼承的框架,抽象類(lèi)中可以包含抽象方法,這些方法沒(méi)有具體的實(shí)現(xiàn),必須由子類(lèi)來(lái)提供,本文給大家介紹java關(guān)鍵字abstract(抽象)實(shí)例詳解,感興趣的朋友跟隨小編一起看看吧
    2024-10-10

最新評(píng)論