一緻性Hash算法在資料庫分表中的實踐

最近有一個項目，其中某個功能單表資料在可預估的未來達到了億級，初步估算在90億左右。與同僚詳細讨論後，決定采用一緻性Hash算法來完成資料庫的自動擴容和資料遷移。整個程式細節由我同僚完成，我隻是将其了解并成文，供有相同問題的同行參考。

參看此文的兄弟，預設各位已經熟悉一緻性hash算法了。此文僅僅闡述代碼細節，實作語言為<code>Java</code>。

項目是一個實驗室項目

其中有一個表叫做試驗表，用于存儲車型的試驗資料，每個試驗大概有6000條資料

總計初期約有2萬個車型，每個車型初期包含超過50個試驗。後期還會動态增長

試驗表中的資料僅需要根據車型試驗ID能取出來即可，沒有其他更複雜的業務邏輯

項目正式上線初期，資料量不會直接爆發式增長到90億，需要時間上的積累（逐漸做實驗），最終可能達到90億資料，甚至超過90億資料。

按照我們實際了解情況，oracle存儲資料量達到1千萬的時候，性能擅可。而Oracle官方的說法，如單表存儲1g有分區（大緻500萬資料），查詢效率非常高。而試驗表中僅四個字段，每條資料資料量較小。是以我們最終決定以1000萬為節點，水準拆表。當表資料達到1千萬時，即增加下一波表。進行資料自動遷移。

按照90億的總量，1000萬資料一個表的劃分，最終大緻會産生900個左右的表。是以我們最終使用了4個資料庫。1個存儲其他業務子產品的表，3個存儲此大資料表。每個資料庫大緻有300張表。性能上和數量上都可達到我們的要求。

試驗資訊表（EXPERIMENT_MESSAGE），挂接車型和試驗的關系。試驗資料表（EXPERIMENT_DATA），存儲試驗資料

試驗資訊表：

字段

含義

ID

主鍵，采用UUID生成

EXPERIMENT_ID

試驗表中的ID

CAR_ID

車型表中的ID

...

其餘數十個字段省略

試驗資料表：

EXPERIMENT_MESSAGE_ID

對應的實驗資訊id

X_VALUE

試驗資料X值

Y_VALUE

試驗資料Y值

我們采用作一緻性hash的key，就是試驗資料表中的<code>EXPERIMENT_MESSAGE_ID</code>字段。也就是說，每個試驗資料表，不存則以，存則一次性大緻有6000條資料。取同理。

一緻性Hash算法的hash部分，采用了著名的ketama算法。在此，我們不多讨論ketama算法的細節，若各位有興趣，請查閱ketama算法

有了Hash的算法，接下來就要構造Hash環了。Hash環采用的SortedMap資料結構實作。

其中添加節點和移除節點部分，需要根據hash算法得到節點在環上的位置，具體代碼如下：

而hash環中得到節點部分比較特殊，根據一緻性hash算法的介紹，得到hash環中的節點，實際上是計算出的hash值順時針找到的第一個節點。

上面完成了一緻性hash算法的實作，包含了hash算法和hash環的實作。接下來就要處理具體業務中，如何使用這個hash環和算法了。

我們業務中，主要操作這張表的資料，也就是增删查。然後我們資料庫拆分成了3個，是以需要增删查的操作基本一緻，都是先通過一緻性hash得到庫，再通過一緻性hash得到表。

擷取資料庫名的操作如下，擷取到資料庫後，根據資料庫名到對應的連接配接池中擷取連接配接。

擷取表名的操作如下，擷取到資料庫後，在對應的資料庫中找到需要的表，再從該表中查詢資料。

剩下的增删改操作和平常一緻，在此不多贅述。

一緻性hash勢必涉及到資料遷移問題，我們采取的資料遷移方式為定時任務，針對每個資料庫在每天夜裡全量掃描一次。檢查是否有資料量超過1000萬的表，若存在這樣的表，就把現有的表數量double。

資料遷移隻會在同庫之間遷移，不會涉及跨資料庫的情況。

此方案為初步方案，後續會改進的更加智能，根據表的數量，增加不同數量的表。而不是簡單的把表數量翻倍。

表建立後，将需要遷移的表資料逐個遷移。

在連接配接到資料源後，我們做了如下事情進行資料遷移

1.擷取庫中所有的表

2.周遊表，檢查表中資料是否超過邊界線（我們為1000萬）

3.根據所有的表計算現有的虛拟節點

4.把表加倍

5.計算加倍後的虛拟節點

6.資料遷移

以上為我們所做的一緻性hash實踐，其中還存在很多問題，比如遷移過程單線程導緻遷移較慢、自動擴容機制不智能、遷移過程中資料通路不穩定等情況。

我們将會在後續的開發中逐漸進行完善改進。

以上就是我們針對一緻性hash在oracle分表中的實踐

一緻性雜湊演算法原理

ketama算法