建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
這篇文章，我們來(lái)聊一下對(duì)于一個(gè)支撐日活百萬(wàn)用戶(hù)的高并系統(tǒng)，他的數(shù)據(jù)庫(kù)架構(gòu)應(yīng)該如何設(shè)計(jì)?
成都一家集口碑和實(shí)力的網(wǎng)站建設(shè)服務(wù)商，擁有專(zhuān)業(yè)的企業(yè)建站團(tuán)隊(duì)和靠譜的建站技術(shù)，十年企業(yè)及個(gè)人網(wǎng)站建設(shè)經(jīng)驗(yàn) ,為成都千余家客戶(hù)提供網(wǎng)頁(yè)設(shè)計(jì)制作,網(wǎng)站開(kāi)發(fā),企業(yè)網(wǎng)站制作建設(shè)等服務(wù),包括成都營(yíng)銷(xiāo)型網(wǎng)站建設(shè)，品牌網(wǎng)站設(shè)計(jì)，同時(shí)也為不同行業(yè)的客戶(hù)提供成都網(wǎng)站建設(shè)、成都網(wǎng)站制作的服務(wù),包括成都電商型網(wǎng)站制作建設(shè),裝修行業(yè)網(wǎng)站制作建設(shè)，傳統(tǒng)機(jī)械行業(yè)網(wǎng)站建設(shè),傳統(tǒng)農(nóng)業(yè)行業(yè)網(wǎng)站制作建設(shè)。在成都做網(wǎng)站,選網(wǎng)站制作建設(shè)服務(wù)商就選成都創(chuàng)新互聯(lián)公司。
看到這個(gè)題目，很多人***反應(yīng)就是：分庫(kù)分表啊!但是實(shí)際上，數(shù)據(jù)庫(kù)層面的分庫(kù)分表到底是用來(lái)干什么的，他的不同的作用如何應(yīng)對(duì)不同的場(chǎng)景，我覺(jué)得很多同學(xué)可能都沒(méi)搞清楚。
用一個(gè)創(chuàng)業(yè)公司的發(fā)展作為背景引入
假如我們現(xiàn)在是一個(gè)小創(chuàng)業(yè)公司，注冊(cè)用戶(hù)就 20 萬(wàn)，每天活躍用戶(hù)就 1 萬(wàn)，每天單表數(shù)據(jù)量就 1000，然后高峰期每秒鐘并發(fā)請(qǐng)求最多就 10。
天哪!就這種系統(tǒng)，隨便找一個(gè)有幾年工作經(jīng)驗(yàn)的高級(jí)工程師，然后帶幾個(gè)年輕工程師，隨便干干都可以做出來(lái)。
因?yàn)檫@樣的系統(tǒng)，實(shí)際上主要就是在前期快速的進(jìn)行業(yè)務(wù)功能的開(kāi)發(fā)，搞一個(gè)單塊系統(tǒng)部署在一臺(tái)服務(wù)器上，然后連接一個(gè)數(shù)據(jù)庫(kù)就可以了。
接著大家就是不停的在一個(gè)工程里填充進(jìn)去各種業(yè)務(wù)代碼，盡快把公司的業(yè)務(wù)支撐起來(lái)。
如下圖所示：
結(jié)果呢，沒(méi)想到我們運(yùn)氣這么好，碰上個(gè)優(yōu)秀的 CEO 帶著我們走上了康莊大道!
公司業(yè)務(wù)發(fā)展迅猛，過(guò)了幾個(gè)月，注冊(cè)用戶(hù)數(shù)達(dá)到了 2000 萬(wàn)!每天活躍用戶(hù)數(shù) 100 萬(wàn)!每天單表新增數(shù)據(jù)量達(dá)到 50 萬(wàn)條!高峰期每秒請(qǐng)求量達(dá)到 1 萬(wàn)!
同時(shí)公司還順帶著融資了兩輪，估值達(dá)到了驚人的幾億美金!一只朝氣蓬勃的幼年獨(dú)角獸的節(jié)奏!
好吧，現(xiàn)在大家感覺(jué)壓力已經(jīng)有點(diǎn)大了，為啥呢?因?yàn)槊刻靻伪硇略?50 萬(wàn)條數(shù)據(jù)，一個(gè)月就多 1500 萬(wàn)條數(shù)據(jù)，一年下來(lái)單表會(huì)達(dá)到上億條數(shù)據(jù)。
經(jīng)過(guò)一段時(shí)間的運(yùn)行，現(xiàn)在咱們單表已經(jīng)兩三千萬(wàn)條數(shù)據(jù)了，勉強(qiáng)還能支撐著。
但是，眼見(jiàn)著系統(tǒng)訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)的性能怎么越來(lái)越差呢，單表數(shù)據(jù)量越來(lái)越大，拖垮了一些復(fù)雜查詢(xún) SQL 的性能啊!
然后高峰期請(qǐng)求現(xiàn)在是每秒 1 萬(wàn)，咱們的系統(tǒng)在線(xiàn)上部署了 20 臺(tái)機(jī)器，平均每臺(tái)機(jī)器每秒支撐 500 請(qǐng)求，這個(gè)還能抗住，沒(méi)啥大問(wèn)題。但是數(shù)據(jù)庫(kù)層面呢?
如果說(shuō)此時(shí)你還是一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器在支撐每秒上萬(wàn)的請(qǐng)求，負(fù)責(zé)任的告訴你，每次高峰期會(huì)出現(xiàn)下述問(wèn)題：
- 你的數(shù)據(jù)庫(kù)服務(wù)器的磁盤(pán) IO、網(wǎng)絡(luò)帶寬、CPU 負(fù)載、內(nèi)存消耗，都會(huì)達(dá)到非常高的情況，數(shù)據(jù)庫(kù)所在服務(wù)器的整體負(fù)載會(huì)非常重，甚至都快不堪重負(fù)了。
- 高峰期時(shí)，本來(lái)你單表數(shù)據(jù)量就很大，SQL 性能就不太好，這時(shí)加上你的數(shù)據(jù)庫(kù)服務(wù)器負(fù)載太高導(dǎo)致性能下降，就會(huì)發(fā)現(xiàn)你的 SQL 性能更差了。
- 最明顯的一個(gè)感覺(jué)，就是你的系統(tǒng)在高峰期各個(gè)功能都運(yùn)行的很慢，用戶(hù)體驗(yàn)很差，點(diǎn)一個(gè)按鈕可能要幾十秒才出來(lái)結(jié)果。
- 如果你運(yùn)氣不太好，數(shù)據(jù)庫(kù)服務(wù)器的配置不是特別的高的話(huà)，弄不好你還會(huì)經(jīng)歷數(shù)據(jù)庫(kù)宕機(jī)的情況，因?yàn)樨?fù)載太高對(duì)數(shù)據(jù)庫(kù)壓力太大了。
多臺(tái)服務(wù)器分庫(kù)支撐高并發(fā)讀寫(xiě)
首先我們先考慮***個(gè)問(wèn)題，數(shù)據(jù)庫(kù)每秒上萬(wàn)的并發(fā)請(qǐng)求應(yīng)該如何來(lái)支撐呢?
要搞清楚這個(gè)問(wèn)題，先得明白一般數(shù)據(jù)庫(kù)部署在什么配置的服務(wù)器上。通常來(lái)說(shuō)，假如你用普通配置的服務(wù)器來(lái)部署數(shù)據(jù)庫(kù)，那也起碼是 16 核 32G 的機(jī)器配置。
這種非常普通的機(jī)器配置部署的數(shù)據(jù)庫(kù)，一般線(xiàn)上的經(jīng)驗(yàn)是：不要讓其每秒請(qǐng)求支撐超過(guò) 2000，一般控制在 2000 左右。
控制在這個(gè)程度，一般數(shù)據(jù)庫(kù)負(fù)載相對(duì)合理，不會(huì)帶來(lái)太大的壓力，沒(méi)有太大的宕機(jī)風(fēng)險(xiǎn)。
所以首先***步，就是在上萬(wàn)并發(fā)請(qǐng)求的場(chǎng)景下，部署個(gè) 5 臺(tái)服務(wù)器，每臺(tái)服務(wù)器上都部署一個(gè)數(shù)據(jù)庫(kù)實(shí)例。
然后每個(gè)數(shù)據(jù)庫(kù)實(shí)例里，都創(chuàng)建一個(gè)一樣的庫(kù)，比如說(shuō)訂單庫(kù)。此時(shí)在 5 臺(tái)服務(wù)器上都有一個(gè)訂單庫(kù)，名字可以類(lèi)似為：db_order_01，db_order_02，等等。
然后每個(gè)訂單庫(kù)里，都有一個(gè)相同的表，比如說(shuō)訂單庫(kù)里有訂單信息表，那么此時(shí) 5 個(gè)訂單庫(kù)里都有一個(gè)訂單信息表。
比如 db_order_01 庫(kù)里就有一個(gè) tb_order_01 表，db_order_02 庫(kù)里就有一個(gè) tb_order_02 表。
這就實(shí)現(xiàn)了一個(gè)基本的分庫(kù)分表的思路，原來(lái)的一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器變成了 5 臺(tái)數(shù)據(jù)庫(kù)服務(wù)器，原來(lái)的一個(gè)庫(kù)變成了 5 個(gè)庫(kù)，原來(lái)的一張表變成了 5 個(gè)表。
然后你在寫(xiě)入數(shù)據(jù)的時(shí)候，需要借助數(shù)據(jù)庫(kù)中間件，比如 sharding-jdbc，或者是 mycat，都可以。
你可以根據(jù)比如訂單 id 來(lái) hash 后按 5 取模，比如每天訂單表新增 50 萬(wàn)數(shù)據(jù)，此時(shí)其中 10 萬(wàn)條數(shù)據(jù)會(huì)落入 db_order_01 庫(kù)的 tb_order_01 表，另外 10 萬(wàn)條數(shù)據(jù)會(huì)落入 db_order_02 庫(kù)的 tb_order_02 表，以此類(lèi)推。
這樣就可以把數(shù)據(jù)均勻分散在 5 臺(tái)服務(wù)器上了，查詢(xún)的時(shí)候，也可以通過(guò)訂單 id 來(lái) hash 取模，去對(duì)應(yīng)的服務(wù)器上的數(shù)據(jù)庫(kù)里，從對(duì)應(yīng)的表里查詢(xún)那條數(shù)據(jù)出來(lái)即可。
依據(jù)這個(gè)思路畫(huà)出的圖如下所示，大家可以看看：
做這一步有什么好處呢?***個(gè)好處，原來(lái)比如訂單表就一張表，這個(gè)時(shí)候不就成了 5 張表了么，那么每個(gè)表的數(shù)據(jù)就變成 1/5 了。
假設(shè)訂單表一年有 1 億條數(shù)據(jù)，此時(shí) 5 張表里每張表一年就 2000 萬(wàn)數(shù)據(jù)了。
那么假設(shè)當(dāng)前訂單表里已經(jīng)有 2000 萬(wàn)數(shù)據(jù)了，此時(shí)做了上述拆分，每個(gè)表里就只有 400 萬(wàn)數(shù)據(jù)了。
而且每天新增 50 萬(wàn)數(shù)據(jù)的話(huà)，那么每個(gè)表才新增 10 萬(wàn)數(shù)據(jù)，這樣是不是初步緩解了單表數(shù)據(jù)量過(guò)大影響系統(tǒng)性能的問(wèn)題?
另外就是每秒 1 萬(wàn)請(qǐng)求到 5 臺(tái)數(shù)據(jù)庫(kù)上，每臺(tái)數(shù)據(jù)庫(kù)就承載每秒 2000 的請(qǐng)求，是不是一下子把每臺(tái)數(shù)據(jù)庫(kù)服務(wù)器的并發(fā)請(qǐng)求降低到了安全范圍內(nèi)?
這樣，降低了數(shù)據(jù)庫(kù)的高峰期負(fù)載，同時(shí)還保證了高峰期的性能。
大量分表來(lái)保證海量數(shù)據(jù)下的查詢(xún)性能
但是上述的數(shù)據(jù)庫(kù)架構(gòu)還有一個(gè)問(wèn)題，那就是單表數(shù)據(jù)量還是過(guò)大，現(xiàn)在訂單表才分為了 5 張表，那么如果訂單一年有 1 億條，每個(gè)表就有 2000 萬(wàn)條，這也還是太大了。
所以還應(yīng)該繼續(xù)分表，大量分表。比如可以把訂單表一共拆分為 1024 張表，這樣 1 億數(shù)據(jù)量的話(huà)，分散到每個(gè)表里也就才 10 萬(wàn)量級(jí)的數(shù)據(jù)量，然后這上千張表分散在 5 臺(tái)數(shù)據(jù)庫(kù)里就可以了。
在寫(xiě)入數(shù)據(jù)的時(shí)候，需要做兩次路由，先對(duì)訂單 id hash 后對(duì)數(shù)據(jù)庫(kù)的數(shù)量取模，可以路由到一臺(tái)數(shù)據(jù)庫(kù)上，然后再對(duì)那臺(tái)數(shù)據(jù)庫(kù)上的表數(shù)量取模，就可以路由到數(shù)據(jù)庫(kù)上的一個(gè)表里了。
通過(guò)這個(gè)步驟，就可以讓每個(gè)表里的數(shù)據(jù)量非常小，每年 1 億數(shù)據(jù)增長(zhǎng)，但是到每個(gè)表里才 10 萬(wàn)條數(shù)據(jù)增長(zhǎng)，這個(gè)系統(tǒng)運(yùn)行 10 年，每個(gè)表里可能才***的數(shù)據(jù)量。
這樣可以一次性為系統(tǒng)未來(lái)的運(yùn)行做好充足的準(zhǔn)備，看下面的圖，一起來(lái)感受一下：
全局唯一 id 如何生成
在分庫(kù)分表之后你必然要面對(duì)的一個(gè)問(wèn)題，就是 id 咋生成?因?yàn)橐且粋€(gè)表分成多個(gè)表之后，每個(gè)表的 id 都是從 1 開(kāi)始累加自增長(zhǎng)，那肯定不對(duì)啊。
舉個(gè)例子，你的訂單表拆分為了 1024 張訂單表，每個(gè)表的 id 都從 1 開(kāi)始累加，這個(gè)肯定有問(wèn)題了!
你的系統(tǒng)就沒(méi)辦法根據(jù)表主鍵來(lái)查詢(xún)訂單了，比如 id = 50 這個(gè)訂單，在每個(gè)表里都有!
所以此時(shí)就需要分布式架構(gòu)下的全局唯一 id 生成的方案了，在分庫(kù)分表之后，對(duì)于插入數(shù)據(jù)庫(kù)中的核心 id，不能直接簡(jiǎn)單使用表自增 id，要全局生成唯一 id，然后插入各個(gè)表中，保證每個(gè)表內(nèi)的某個(gè) id，全局唯一。
比如說(shuō)訂單表雖然拆分為了 1024 張表，但是 id = 50 這個(gè)訂單，只會(huì)存在于一個(gè)表里。
那么如何實(shí)現(xiàn)全局唯一 id 呢?有以下幾種方案：
方案一：獨(dú)立數(shù)據(jù)庫(kù)自增 id
這個(gè)方案就是說(shuō)你的系統(tǒng)每次要生成一個(gè) id，都是往一個(gè)獨(dú)立庫(kù)的一個(gè)獨(dú)立表里插入一條沒(méi)什么業(yè)務(wù)含義的數(shù)據(jù)，然后獲取一個(gè)數(shù)據(jù)庫(kù)自增的一個(gè) id。拿到這個(gè) id 之后再往對(duì)應(yīng)的分庫(kù)分表里去寫(xiě)入。
比如說(shuō)你有一個(gè) auto_id 庫(kù)，里面就一個(gè)表，叫做 auto_id 表，有一個(gè) id 是自增長(zhǎng)的。
那么你每次要獲取一個(gè)全局唯一 id，直接往這個(gè)表里插入一條記錄，獲取一個(gè)全局唯一 id 即可，然后這個(gè)全局唯一 id 就可以插入訂單的分庫(kù)分表中。
這個(gè)方案的好處就是方便簡(jiǎn)單，誰(shuí)都會(huì)用。缺點(diǎn)就是單庫(kù)生成自增 id，要是高并發(fā)的話(huà)，就會(huì)有瓶頸的，因?yàn)?auto_id 庫(kù)要是承載個(gè)每秒幾萬(wàn)并發(fā)，肯定是不現(xiàn)實(shí)的了。
方案二：UUID
這個(gè)每個(gè)人都應(yīng)該知道吧，就是用 UUID 生成一個(gè)全局唯一的 id。
好處就是每個(gè)系統(tǒng)本地生成，不要基于數(shù)據(jù)庫(kù)來(lái)了。不好之處就是，UUID 太長(zhǎng)了，作為主鍵性能太差了，不適合用于主鍵。
如果你是要隨機(jī)生成個(gè)什么文件名了，編號(hào)之類(lèi)的，你可以用 UUID，但是作為主鍵是不能用 UUID 的。
方案三：獲取系統(tǒng)當(dāng)前時(shí)間
這個(gè)方案的意思就是獲取當(dāng)前時(shí)間作為全局唯一的 id。但是問(wèn)題是，并發(fā)很高的時(shí)候，比如一秒并發(fā)幾千，會(huì)有重復(fù)的情況，這個(gè)肯定是不合適的。
一般如果用這個(gè)方案，是將當(dāng)前時(shí)間跟很多其他的業(yè)務(wù)字段拼接起來(lái)，作為一個(gè) id，如果業(yè)務(wù)上你覺(jué)得可以接受，那么也是可以的。
你可以將別的業(yè)務(wù)字段值跟當(dāng)前時(shí)間拼接起來(lái)，組成一個(gè)全局唯一的編號(hào)，比如說(shuō)訂單編號(hào)：時(shí)間戳 + 用戶(hù) id + 業(yè)務(wù)含義編碼。
方案四：SnowFlake 算法的思想分析
SnowFlake 算法，是 Twitter 開(kāi)源的分布式 id 生成算法。其核心思想就是：使用一個(gè) 64 bit 的 long 型的數(shù)字作為全局唯一 id。
這 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ī)器)。
④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 {
- private long workerId; // 這個(gè)就是代表了機(jī)器id
- private long datacenterId; // 這個(gè)就是代表了機(jī)房id
- private long sequence; // 這個(gè)就是代表了一毫秒內(nèi)生成的多個(gè)id的***序號(hào)
- public IdWorker(long workerId, long datacenterId, long sequence) {
- // sanity check for workerId
- // 這兒不就檢查了一下，要求就是你傳遞進(jìn)來(lái)的機(jī)房id和機(jī)器id不能超過(guò)32，不能小于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;
- }
- private long twepoch = 1288834974657L;
- private long workerIdBits = 5L;
- private long datacenterIdBits = 5L;
- // 這個(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 sequenceBits = 12L;
- private long workerIdShift = sequenceBits;
- private long datacenterIdShift = sequenceBits + workerIdBits;
- private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
- private long sequenceMask = -1L ^ (-1L << sequenceBits);
- private long lastTimestamp = -1L;
- public long getWorkerId(){
- return workerId;
- }
- public long getDatacenterId() {
- return datacenterId;
- }
- public long getTimestamp() {
- return System.currentTimeMillis();
- }
- // 這個(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;
- 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;
- }
- private long tilNextMillis(long lastTimestamp) {
- long timestamp = timeGen();
- while (timestamp <= lastTimestamp) {
- timestamp = timeGen();
- }
- return timestamp;
- }
- private long timeGen(){
- return System.currentTimeMillis();
- }
- //---------------測(cè)試---------------
- public static void main(String[] args) {
- IdWorker worker = new IdWorker(1,1,1);
- for (int i = 0; i < 30; i++) {
- System.out.println(worker.nextId());
- }
- }
- }
SnowFlake 算法一個(gè)小小的改進(jìn)思路：其實(shí)在實(shí)際的開(kāi)發(fā)中，這個(gè)SnowFlake算法可以做一點(diǎn)點(diǎn)改進(jìn)。
因?yàn)榇蠹铱梢钥紤]一下，我們?cè)谏晌ㄒ?id 的時(shí)候，一般都需要指定一個(gè)表名，比如說(shuō)訂單表的唯一 id。
所以上面那 64 個(gè) bit 中，代表機(jī)房的那 5 個(gè) bit，可以使用業(yè)務(wù)表名稱(chēng)來(lái)替代，比如用 00001 代表的是訂單表。
因?yàn)槠鋵?shí)很多時(shí)候，機(jī)房并沒(méi)有那么多，所以那 5 個(gè) bit 用做機(jī)房 id 可能意義不是太大。
這樣就可以做到，SnowFlake 算法系統(tǒng)的每一臺(tái)機(jī)器，對(duì)一個(gè)業(yè)務(wù)表，在某一毫秒內(nèi)，可以生成一個(gè)唯一的 id，一毫秒內(nèi)生成很多 id，用*** 12 個(gè) bit 來(lái)區(qū)分序號(hào)對(duì)待。
讀寫(xiě)分離來(lái)支撐按需擴(kuò)容以及性能提升
這個(gè)時(shí)候整體效果已經(jīng)挺不錯(cuò)了，大量分表的策略保證可能未來(lái) 10 年，每個(gè)表的數(shù)據(jù)量都不會(huì)太大，這可以保證單表內(nèi)的 SQL 執(zhí)行效率和性能。
然后多臺(tái)數(shù)據(jù)庫(kù)的拆分方式，可以保證每臺(tái)數(shù)據(jù)庫(kù)服務(wù)器承載一部分的讀寫(xiě)請(qǐng)求，降低每臺(tái)服務(wù)器的負(fù)載。
但是此時(shí)還有一個(gè)問(wèn)題，假如說(shuō)每臺(tái)數(shù)據(jù)庫(kù)服務(wù)器承載每秒 2000 的請(qǐng)求，然后其中 400 請(qǐng)求是寫(xiě)入，1600 請(qǐng)求是查詢(xún)。
也就是說(shuō)，增刪改的 SQL 才占到了 20% 的比例，80% 的請(qǐng)求是查詢(xún)。此時(shí)假如說(shuō)隨著用戶(hù)量越來(lái)越大，又變成每臺(tái)服務(wù)器承載 4000 請(qǐng)求了。
那么其中 800 請(qǐng)求是寫(xiě)入，3200 請(qǐng)求是查詢(xún)，如果說(shuō)你按照目前的情況來(lái)擴(kuò)容，就需要增加一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器。
但是此時(shí)可能就會(huì)涉及到表的遷移，因?yàn)樾枰w移一部分表到新的數(shù)據(jù)庫(kù)服務(wù)器上去，是不是很麻煩?
其實(shí)完全沒(méi)必要，數(shù)據(jù)庫(kù)一般都支持讀寫(xiě)分離，也就是做主從架構(gòu)。
寫(xiě)入的時(shí)候?qū)懭胫鲾?shù)據(jù)庫(kù)服務(wù)器，查詢(xún)的時(shí)候讀取從數(shù)據(jù)庫(kù)服務(wù)器，就可以讓一個(gè)表的讀寫(xiě)請(qǐng)求分開(kāi)落地到不同的數(shù)據(jù)庫(kù)上去執(zhí)行。
這樣的話(huà)，假如寫(xiě)入主庫(kù)的請(qǐng)求是每秒 400，查詢(xún)從庫(kù)的請(qǐng)求是每秒 1600。
那么圖大概如下所示：
寫(xiě)入主庫(kù)的時(shí)候，會(huì)自動(dòng)同步數(shù)據(jù)到從庫(kù)上去，保證主庫(kù)和從庫(kù)數(shù)據(jù)一致。
然后查詢(xún)的時(shí)候都是走從庫(kù)去查詢(xún)的，這就通過(guò)數(shù)據(jù)庫(kù)的主從架構(gòu)實(shí)現(xiàn)了讀寫(xiě)分離的效果了。
現(xiàn)在的好處就是，假如說(shuō)現(xiàn)在主庫(kù)寫(xiě)請(qǐng)求增加到 800，這個(gè)無(wú)所謂，不需要擴(kuò)容。然后從庫(kù)的讀請(qǐng)求增加到了 3200，需要擴(kuò)容了。
這時(shí)，你直接給主庫(kù)再掛載一個(gè)新的從庫(kù)就可以了，兩個(gè)從庫(kù)，每個(gè)從庫(kù)支撐 1600 的讀請(qǐng)求，不需要因?yàn)樽x請(qǐng)求增長(zhǎng)來(lái)擴(kuò)容主庫(kù)。
實(shí)際上線(xiàn)上生產(chǎn)你會(huì)發(fā)現(xiàn)，讀請(qǐng)求的增長(zhǎng)速度遠(yuǎn)遠(yuǎn)高于寫(xiě)請(qǐng)求，所以讀寫(xiě)分離之后，大部分時(shí)候就是擴(kuò)容從庫(kù)支撐更高的讀請(qǐng)求就可以了。
而且另外一點(diǎn)，對(duì)同一個(gè)表，如果你既寫(xiě)入數(shù)據(jù)(涉及加鎖)，還從該表查詢(xún)數(shù)據(jù)，可能會(huì)牽扯到鎖沖突等問(wèn)題，無(wú)論是寫(xiě)性能還是讀性能，都會(huì)有影響。
所以一旦讀寫(xiě)分離之后，對(duì)主庫(kù)的表就僅僅是寫(xiě)入，沒(méi)任何查詢(xún)會(huì)影響他，對(duì)從庫(kù)的表就僅僅是查詢(xún)。
高并發(fā)下的數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)總結(jié)
從大的一個(gè)簡(jiǎn)化的角度來(lái)說(shuō)，高并發(fā)的場(chǎng)景下，數(shù)據(jù)庫(kù)層面的架構(gòu)肯定是需要經(jīng)過(guò)精心的設(shè)計(jì)的。
尤其是涉及到分庫(kù)來(lái)支撐高并發(fā)的請(qǐng)求，大量分表保證每個(gè)表的數(shù)據(jù)量別太大，讀寫(xiě)分離實(shí)現(xiàn)主庫(kù)和從庫(kù)按需擴(kuò)容以及性能保證。
這篇文章就是從一個(gè)大的角度來(lái)梳理了一下思路，各位同學(xué)可以結(jié)合自己公司的業(yè)務(wù)和項(xiàng)目來(lái)考慮自己的系統(tǒng)如何做分庫(kù)分表。
另外就是，具體的分庫(kù)分表落地的時(shí)候，需要借助數(shù)據(jù)庫(kù)中間件來(lái)實(shí)現(xiàn)分庫(kù)分表和讀寫(xiě)分離，大家可以自己參考 Sharding-JDBC 或者 MyCAT 的官網(wǎng)即可，里面的文檔都有詳細(xì)的使用描述。
中華石杉：十余年 BAT 架構(gòu)經(jīng)驗(yàn)，一線(xiàn)互聯(lián)網(wǎng)公司技術(shù)總監(jiān)。帶領(lǐng)上百人團(tuán)隊(duì)開(kāi)發(fā)過(guò)多個(gè)億級(jí)流量高并發(fā)系統(tǒng)?，F(xiàn)將多年工作中積累下的研究手稿、經(jīng)驗(yàn)總結(jié)整理成文，傾囊相授。微信公眾號(hào)：石杉的架構(gòu)筆記(ID：shishan100)。
分享標(biāo)題：支撐百萬(wàn)并發(fā)的數(shù)據(jù)庫(kù)架構(gòu)如何設(shè)計(jì)？
標(biāo)題來(lái)源：http://fisionsoft.com.cn/article/dpdcehe.html
