整理了一些Java方面的架構、面試資料(微服務、集群、分佈式、中間件等),有需要的小夥伴可以關注公眾號【程序員內點事】,無套路自行領取
寫在前邊
前兩天公眾號有個粉絲給我留言吐槽最近面試:“四哥,年前我在公司受點委屈一衝動就裸辭了,然後現在疫情嚴重兩個多月還沒找到工作,接了幾個視頻面試也都沒下文。好多面試官問完一個問題,緊接著說還會其他解決方法嗎?能幹活解決bug不就行了嗎?那還得會多少種方法?”
面試官應該是對應聘者的回答不太滿意,他想聽到一個他認為最優的解決方案,其實這無可厚非。同樣一個bug,能用一行代碼解決問題的人和用十行代碼解決問題的人,你會選哪個入職?顯而易見的事情!所以看待問題還是要從多個角度出發,每種方法都有各自的利弊。
一、為什麼要用分佈式ID?
在說分佈式ID的具體實現之前,我們來簡單分析一下為什麼用分佈式ID?分佈式ID應該滿足哪些特徵?
1、什麼是分佈式ID?
拿MySQL數據庫舉個栗子:
在我們業務數據量不大的時候,單庫單表完全可以支撐現有業務,數據再大一點搞個MySQL主從同步讀寫分離也能對付。
但隨著數據日漸增長,主從同步也扛不住了,就需要對數據庫進行分庫分表,但分庫分表後需要有一個唯一ID來標識一條數據,數據庫的自增ID顯然不能滿足需求;特別一點的如訂單、優惠券也都需要有唯一ID做標識。此時一個能夠生成全局唯一ID的系統是非常必要的。那麼這個全局唯一ID就叫分佈式ID。
2、那麼分佈式ID需要滿足那些條件?
全局唯一:必須保證ID是全局性唯一的,基本要求高性能:高可用低延時,ID生成響應要塊,否則反倒會成為業務瓶頸高可用:100%的可用性是騙人的,但是也要無限接近於100%的可用性好接入:要秉著拿來即用的設計原則,在系統設計和實現上要儘可能的簡單趨勢遞增:最好趨勢遞增,這個要求就得看具體業務場景了,一般不嚴格要求二、 分佈式ID都有哪些生成方式?
今天主要分析一下以下9種,分佈式ID生成器方式以及優缺點:
UUID數據庫自增ID數據庫多主模式號段模式Redis雪花算法(SnowFlake)滴滴出品(TinyID)百度 (Uidgenerator)美團(Leaf)那麼它們都是如何實現?以及各自有什麼優缺點?我們往下看
圖片源自網絡
1、基於UUID
在Java的世界裡,想要得到一個具有唯一性的ID,首先被想到可能就是UUID,畢竟它有著全球唯一的特性。那麼UUID可以做分佈式ID嗎?答案是可以的,但是並不推薦!
<code>public static void main(String[] args) { String uuid = UUID.randomUUID().toString().replaceAll("-",""); System.out.println(uuid); }/<code>
UUID的生成簡單到只有一行代碼,輸出結果 c2b8c2b9e46c47e3b30dca3b0d447718,但UUID卻並不適用於實際的業務需求。像用作訂單號UUID這樣的字符串沒有絲毫的意義,看不出和訂單相關的有用信息;而對於數據庫來說用作業務主鍵ID,它不僅是太長還是字符串,存儲性能差查詢也很耗時,所以不推薦用作分佈式ID。
優點:
生成足夠簡單,本地生成無網絡消耗,具有唯一性缺點:
無序的字符串,不具備趨勢自增特性沒有具體的業務含義長度過長16 字節128位,36位長度的字符串,存儲以及查詢對MySQL的性能消耗較大,MySQL官方明確建議主鍵要儘量越短越好,作為數據庫主鍵 UUID 的無序性會導致數據位置頻繁變動,嚴重影響性能。2、基於數據庫自增ID
基於數據庫的auto_increment自增ID完全可以充當分佈式ID,具體實現:需要一個單獨的MySQL實例用來生成ID,建表結構如下:
<code>CREATE DATABASE `SEQ_ID`;CREATE TABLE SEQID.SEQUENCE_ID ( id bigint(20) unsigned NOT NULL auto_increment, value char(10) NOT NULL default '', PRIMARY KEY (id),) ENGINE=MyISAM;/<code>
<code>insert into SEQUENCE_ID(value) VALUES ('values');/<code>
當我們需要一個ID的時候,向表中插入一條記錄返回主鍵ID,但這種方式有一個比較致命的缺點,訪問量激增時MySQL本身就是系統的瓶頸,用它來實現分佈式服務風險比較大,不推薦!
優點:
實現簡單,ID單調自增,數值類型查詢速度快缺點:
DB單點存在宕機風險,無法扛住高併發場景3、基於數據庫集群模式
前邊說了單點數據庫方式不可取,那對上邊的方式做一些高可用優化,換成主從模式集群。害怕一個主節點掛掉沒法用,那就做雙主模式集群,也就是兩個Mysql實例都能單獨的生產自增ID。
那這樣還會有個問題,兩個MySQL實例的自增ID都從1開始,會生成重複的ID怎麼辦?
解決方案:設置起始值和自增步長
MySQL_1 配置:
<code>set @@auto_increment_offset = 1; -- 起始值set @@auto_increment_increment = 2; -- 步長/<code>
MySQL_2 配置:
<code>set @@auto_increment_offset = 2; -- 起始值set @@auto_increment_increment = 2; -- 步長/<code>
這樣兩個MySQL實例的自增ID分別就是:
1、3、5、7、9 2、4、6、8、10
那如果集群后的性能還是扛不住高併發咋辦?就要進行MySQL擴容增加節點,這是一個比較麻煩的事。
在這裡插入圖片描述
從上圖可以看出,水平擴展的數據庫集群,有利於解決數據庫單點壓力的問題,同時為了ID生成特性,將自增步長按照機器數量來設置。
增加第三臺MySQL實例需要人工修改一、二兩臺MySQL實例的起始值和步長,把第三臺機器的ID起始生成位置設定在比現有最大自增ID的位置遠一些,但必須在一、二兩臺MySQL實例ID還沒有增長到第三臺MySQL實例的起始ID值的時候,否則自增ID就要出現重複了,
優點:
解決DB單點問題缺點:
不利於後續擴容,而且實際上單個數據庫自身壓力還是大,依舊無法滿足高併發場景。4、基於數據庫的號段模式
號段模式是當下分佈式ID生成器的主流實現方式之一,號段模式可以理解為從數據庫批量的獲取自增ID,每次從數據庫取出一個號段範圍,例如 (1,1000] 代表1000個ID,具體的業務服務將本號段,生成1~1000的自增ID並加載到內存。表結構如下:
<code>CREATE TABLE id_generator ( id int(10) NOT NULL, max_id bigint(20) NOT NULL COMMENT '當前最大id', step int(20) NOT NULL COMMENT '號段的布長', biz_type int(20) NOT NULL COMMENT '業務類型', version int(20) NOT NULL COMMENT '版本號', PRIMARY KEY (`id`)) /<code>
biz_type :代表不同業務類型
max_id :當前最大的可用id
step :代表號段的長度
version :是一個樂觀鎖,每次都更新version,保證併發時數據的正確性
idbiz_typemax_idstepversion1101100020000
等這批號段ID用完,再次向數據庫申請新號段,對max_id字段做一次update操作,update max_id= max_id + step,update成功則說明新號段獲取成功,新的號段範圍是(max_id ,max_id +step]。
<code>update id_generator set max_id = #{max_id+step}, version = version + 1 where version = # {version} and biz_type = XXX/<code>
由於多業務端可能同時操作,所以採用版本號version樂觀鎖方式更新,這種分佈式ID生成方式不強依賴於數據庫,不會頻繁的訪問數據庫,對數據庫的壓力小很多。
5、基於Redis模式
Redis也同樣可以實現,原理就是利用redis的 incr命令實現ID的原子性自增。
<code>127.0.0.1:6379> set seq_id 1 // 初始化自增ID為1OK127.0.0.1:6379> incr seq_id // 增加1,並返回遞增後的數值(integer) 2/<code>
用redis實現需要注意一點,要考慮到redis持久化的問題。redis有兩種持久化方式RDB和AOF
RDB會定時打一個快照進行持久化,假如連續自增但redis沒及時持久化,而這會Redis掛掉了,重啟Redis後會出現ID重複的情況。AOF會對每條寫命令進行持久化,即使Redis掛掉了也不會出現ID重複的情況,但由於incr命令的特殊性,會導致Redis重啟恢復的數據時間過長。6、基於雪花算法(Snowflake)模式
雪花算法(Snowflake)是twitter公司內部分佈式項目採用的ID生成算法,開源後廣受國內大廠的好評,在該算法影響下各大公司相繼開發出各具特色的分佈式生成器。
在這裡插入圖片描述
Snowflake生成的是Long類型的ID,一個Long類型佔8個字節,每個字節佔8比特,也就是說一個Long類型佔64個比特。
Snowflake ID組成結構:正數位(佔1比特)+ 時間戳(佔41比特)+ 機器ID(佔5比特)+ 數據中心(佔5比特)+ 自增值(佔12比特),總共64比特組成的一個Long類型。
第一個bit位(1bit):Java中long的最高位是符號位代表正負,正數是0,負數是1,一般生成ID都為正數,所以默認為0。時間戳部分(41bit):毫秒級的時間,不建議存當前時間戳,而是用(當前時間戳 - 固定開始時間戳)的差值,可以使產生的ID從更小的值開始;41位的時間戳可以使用69年,(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年工作機器id(10bit):也被叫做workId,這個可以靈活配置,機房或者機器號組合都可以。序列號部分(12bit),自增值支持同一毫秒內同一個節點可以生成4096個ID根據這個算法的邏輯,只需要將這個算法用Java語言實現出來,封裝為一個工具方法,那麼各個業務應用可以直接使用該工具方法來獲取分佈式ID,只需保證每個業務應用有自己的工作機器id即可,而不需要單獨去搭建一個獲取分佈式ID的應用。
<code>/** * Twitter的SnowFlake算法,使用SnowFlake算法生成一個整數,然後轉化為62進制變成一個短地址URL * * https://github.com/beyondfengyu/SnowFlake */public class SnowFlakeShortUrl { /** * 起始的時間戳 */ private final static long START_TIMESTAMP = 1480166465631L; /** * 每一部分佔用的位數 */ private final static long SEQUENCE_BIT = 12; //序列號佔用的位數 private final static long MACHINE_BIT = 5; //機器標識佔用的位數 private final static long DATA_CENTER_BIT = 5; //數據中心佔用的位數 /** * 每一部分的最大值 */ private final static long MAX_SEQUENCE = -1L ^ (-1L < MAX_DATA_CENTER_NUM || dataCenterId MAX_MACHINE_NUM || machineId /<code>
7、百度(uid-generator)
uid-generator是由百度技術部開發,項目GitHub地址 https://github.com/baidu/uid-generator
uid-generator是基於Snowflake算法實現的,與原始的snowflake算法不同在於,uid-generator支持自定義時間戳、工作機器ID和 序列號 等各部分的位數,而且uid-generator中採用用戶自定義workId的生成策略。
uid-generator需要與數據庫配合使用,需要新增一個WORKER_NODE表。當應用啟動時會向數據庫表中去插入一條數據,插入成功後返回的自增ID就是該機器的workId數據由host,port組成。
對於uid-generator ID組成結構:
workId,佔用了22個bit位,時間佔用了28個bit位,序列化佔用了13個bit位,需要注意的是,和原始的snowflake不太一樣,時間的單位是秒,而不是毫秒,workId也不一樣,而且同一應用每次重啟就會消費一個workId。
參考文獻https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md
8、美團(Leaf)
Leaf由美團開發,github地址:https://github.com/Meituan-Dianping/Leaf
Leaf同時支持號段模式和snowflake算法模式,可以切換使用。
號段模式
先導入源碼 https://github.com/Meituan-Dianping/Leaf ,在建一張表leaf_alloc
<code>DROP TABLE IF EXISTS `leaf_alloc`;CREATE TABLE `leaf_alloc` ( `biz_tag` varchar(128) NOT NULL DEFAULT '' COMMENT '業務key', `max_id` bigint(20) NOT NULL DEFAULT '1' COMMENT '當前已經分配了的最大id', `step` int(11) NOT NULL COMMENT '初始步長,也是動態調整的最小步長', `description` varchar(256) DEFAULT NULL COMMENT '業務key的描述', `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '數據庫維護的更新時間', PRIMARY KEY (`biz_tag`)) ENGINE=InnoDB;/<code>
然後在項目中開啟號段模式,配置對應的數據庫信息,並關閉snowflake模式
<code>leaf.name=com.sankuai.leaf.opensource.testleaf.segment.enable=trueleaf.jdbc.url=jdbc:mysql://localhost:3306/leaf_test?useUnicode=true&characterEncoding=utf8&characterSetResults=utf8leaf.jdbc.username=rootleaf.jdbc.password=rootleaf.snowflake.enable=false#leaf.snowflake.zk.address=#leaf.snowflake.port=/<code>
啟動leaf-server 模塊的 LeafServerApplication項目就跑起來了
號段模式獲取分佈式自增ID的測試url :http://localhost:8080/api/segment/get/leaf-segment-test
監控號段模式:http://localhost:8080/cache
snowflake模式
Leaf的snowflake模式依賴於ZooKeeper,不同於原始snowflake算法也主要是在workId的生成上,Leaf中workId是基於ZooKeeper的順序Id來生成的,每個應用在使用Leaf-snowflake時,啟動時都會都在Zookeeper中生成一個順序Id,相當於一臺機器對應一個順序節點,也就是一個workId。
<code>leaf.snowflake.enable=trueleaf.snowflake.zk.address=127.0.0.1leaf.snowflake.port=2181/<code>
snowflake模式獲取分佈式自增ID的測試url:http://localhost:8080/api/snowflake/get/test
9、滴滴(Tinyid)
Tinyid由滴滴開發,Github地址:https://github.com/didi/tinyid。
Tinyid是基於號段模式原理實現的與Leaf如出一轍,每個服務獲取一個號段(1000,2000]、(2000,3000]、(3000,4000]
在這裡插入圖片描述
Tinyid提供http和tinyid-client兩種方式接入
Http方式接入
(1)導入Tinyid源碼:
git clone https://github.com/didi/tinyid.git
(2)創建數據表:
<code>CREATE TABLE `tiny_id_info` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主鍵', `biz_type` varchar(63) NOT NULL DEFAULT '' COMMENT '業務類型,唯一', `begin_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '開始id,僅記錄初始值,無其他含義。初始化時begin_id和max_id應相同', `max_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '當前最大id', `step` int(11) DEFAULT '0' COMMENT '步長', `delta` int(11) NOT NULL DEFAULT '1' COMMENT '每次id增量', `remainder` int(11) NOT NULL DEFAULT '0' COMMENT '餘數', `create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '創建時間', `update_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新時間', `version` bigint(20) NOT NULL DEFAULT '0' COMMENT '版本號', PRIMARY KEY (`id`), UNIQUE KEY `uniq_biz_type` (`biz_type`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT 'id信息表';CREATE TABLE `tiny_id_token` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增id', `token` varchar(255) NOT NULL DEFAULT '' COMMENT 'token', `biz_type` varchar(63) NOT NULL DEFAULT '' COMMENT '此token可訪問的業務類型標識', `remark` varchar(255) NOT NULL DEFAULT '' COMMENT '備註', `create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '創建時間', `update_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新時間', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT 'token信息表';INSERT INTO `tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`)VALUES (1, 'test', 1, 1, 100000, 1, 0, '2018-07-21 23:52:58', '2018-07-22 23:19:27', 1);INSERT INTO `tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`)VALUES (2, 'test_odd', 1, 1, 100000, 2, 1, '2018-07-21 23:52:58', '2018-07-23 00:39:24', 3);INSERT INTO `tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`)VALUES (1, '0f673adf80504e2eaa552f5d791b644c', 'test', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48');INSERT INTO `tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`)VALUES (2, '0f673adf80504e2eaa552f5d791b644c', 'test_odd', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48');/<code>
(3)配置數據庫:
<code>datasource.tinyid.names=primarydatasource.tinyid.primary.driver-class-name=com.mysql.jdbc.Driverdatasource.tinyid.primary.url=jdbc:mysql://ip:port/databaseName?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8datasource.tinyid.primary.username=rootdatasource.tinyid.primary.password=123456/<code>
(4)啟動tinyid-server後測試
<code>獲取分佈式自增ID: http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c'返回結果: 3批量獲取分佈式自增ID:http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c&batchSize=10'返回結果: 4,5,6,7,8,9,10,11,12,13/<code>
Java客戶端方式接入
重複Http方式的(2)(3)操作
引入依賴
<code> <dependency> <groupid>com.xiaoju.uemc.tinyid/<groupid> <artifactid>tinyid-client/<artifactid> <version>${tinyid.version}/<version> /<dependency>/<code>
配置文件
<code>tinyid.server =localhost:9999tinyid.token =0f673adf80504e2eaa552f5d791b644c/<code>
test 、tinyid.token是在數據庫表中預先插入的數據,test 是具體業務類型,tinyid.token表示可訪問的業務類型
<code>// 獲取單個分佈式自增IDLong id = TinyId . nextId( " test " );// 按需批量分佈式自增IDList ids = TinyId . nextId( " test " , 10 );/<code>
總結
本文只是簡單介紹一下每種分佈式ID生成器,旨在給大家一個詳細學習的方向,每種生成方式都有它自己的優缺點,具體如何使用還要看具體的業務需求。
今天就說這麼多,如果本文對您有一點幫助,希望能得到您一個點贊哦
您的認可才是我寫作的動力!
整理了一些Java方面的架構、面試資料(微服務、集群、分佈式、中間件等),有需要的小夥伴可以關注公眾號【程序員內點事】,無套路自行領取