背景

為滿足運(yùn)維人員對(duì)于pika可以更好地運(yùn)維，需要方便地將數(shù)據(jù)從pika遷移到redis，在pika系統(tǒng)中之前已經(jīng)為運(yùn)維人員提供了Redis請(qǐng)求實(shí)時(shí)copy到pika工具可以實(shí)時(shí)將redis上的請(qǐng)求同步發(fā)送到pika，這個(gè)工具則是為了能夠?qū)㈦x線的pika數(shù)據(jù)遷移至redis。

最終目標(biāo)

1. 保證數(shù)據(jù)遷移結(jié)果的正確性
2. 滿足目標(biāo)的條件下，在能夠接收的時(shí)間下完成任務(wù)

實(shí)現(xiàn)

版本1:串行可用版

目標(biāo)

1. 走通這個(gè)數(shù)據(jù)遷移的流程，確定實(shí)現(xiàn)方案的可行性
2. 為下一版本優(yōu)化方向做準(zhǔn)備

方案

使用串行方式，將整個(gè)遷移過(guò)程分為三個(gè)階段，如下：

1. 利用pika數(shù)據(jù)引擎的接口，將所有數(shù)據(jù)遍歷出來(lái)
2. 利用得到的數(shù)據(jù)，生成相對(duì)應(yīng)的redis指令（SET,HSET,RPUSH）
3. 使用pika內(nèi)部的pink::RedisCli接口，將指令發(fā)送給redis服務(wù)器并接收響應(yīng) 并在每個(gè)階段計(jì)時(shí)分析以便后面優(yōu)化。

結(jié)果

驗(yàn)證方案可行，但是速度難以接受，遷移10G數(shù)據(jù)需要20小時(shí)以上。從遷移過(guò)程的三個(gè)步驟中，可以看到無(wú)論是數(shù)據(jù)掃描還是，指令的發(fā)送和接收響應(yīng)都非常慢。分析其原因，主要在于：

1. 單線程，沒(méi)有發(fā)揮機(jī)器多核優(yōu)勢(shì)
2. 在與redis服務(wù)器的交互過(guò)程為，發(fā)送一條數(shù)據(jù)，并等待一條數(shù)據(jù)的響應(yīng)，導(dǎo)致速度很慢

改進(jìn)措施

在版本1不能滿足速度要求之后，發(fā)現(xiàn)redis官方客戶端提供有一種可以大規(guī)模數(shù)據(jù)插入的方式pipeline mode，使用的基本形式如下：

cat cmd.txt | redis-cli --pipe
# 其中cmd.txt中存的是符合redis協(xié)議的指令

對(duì)現(xiàn)有程序稍加改動(dòng)，將生成的redis指令直接寫(xiě)入標(biāo)準(zhǔn)輸入流，即可使用pipe mode方式，通過(guò)千萬(wàn)條數(shù)據(jù)測(cè)試，在本地效果提高30%以上。這種方案速度較之前大幅提升，在于節(jié)省了大量浪費(fèi)在每個(gè)指令返回的時(shí)間。

但是直接使用這種方案，雖然速度提升不少，完成時(shí)間還是不能滿足要求。由于這種方式，還是只能使用一個(gè)發(fā)送端，不方便后期進(jìn)行多線程的優(yōu)化。接下來(lái)需要自己定制實(shí)現(xiàn)pipeline mode

版本2：定制實(shí)現(xiàn)pipeline模式

方案

在pika自己實(shí)現(xiàn)的客戶端中，只能是逐條發(fā)送指令，逐條接收。redis官方客戶端的實(shí)現(xiàn)方式：

1. socket_fd 設(shè)置為非阻塞
2. 使用poll監(jiān)聽(tīng)socket_fd的狀態(tài)，調(diào)度指令的發(fā)送和響應(yīng)的接收
3. 從標(biāo)準(zhǔn)輸入流中讀入數(shù)據(jù)（redis指令），放入一個(gè)buf中，在將buf中的數(shù)據(jù)不停寫(xiě)入到socket
4. 批量接收redis服務(wù)器的響應(yīng)，并將其解析判斷如果出現(xiàn)錯(cuò)誤，則將錯(cuò)誤顯示出來(lái)
5. 從標(biāo)準(zhǔn)輸入流中讀不到數(shù)據(jù)之后，向redis發(fā)送一條ECHO指令，用于標(biāo)示發(fā)送結(jié)束

實(shí)質(zhì)上官方客戶端是將生成指令和發(fā)送指令分別放在兩個(gè)不同的進(jìn)程中，在這里模擬標(biāo)準(zhǔn)輸入和標(biāo)準(zhǔn)輸出，則可以自己開(kāi)一條管道，一端將指令寫(xiě)入，一端讀出指令并發(fā)送。

結(jié)果

在實(shí)現(xiàn)了之后，速度確實(shí)有提升，但是發(fā)現(xiàn)之前官方客戶端從標(biāo)準(zhǔn)輸入中讀入數(shù)據(jù)是因?yàn)槭褂脠?chǎng)景所限制，大可將管道那一層去掉，讓自己管理buf，就少了將數(shù)據(jù)寫(xiě)入內(nèi)核，有從內(nèi)核讀出過(guò)程，只是自己需要維護(hù)buf的讀寫(xiě)，這是一個(gè)典型的生產(chǎn)者消費(fèi)者模型。在分析完成之后，對(duì)pipeline進(jìn)行小幅的改進(jìn)。

改進(jìn)版本：自己管理buf

1. 在內(nèi)存開(kāi)辟一個(gè)數(shù)組作為buf，并維護(hù)buf的中需要發(fā)送的數(shù)據(jù)長(zhǎng)度len和發(fā)送數(shù)據(jù)起始點(diǎn)pos
2. 為充分發(fā)揮非阻塞發(fā)送的優(yōu)勢(shì)，將發(fā)送部分單獨(dú)放在一個(gè)線程中執(zhí)行，需要改變len和pos對(duì)其加鎖

版本3：多客戶端并行和多庫(kù)并行

方案

在完成了上面的版本之后，就可以對(duì)整個(gè)流程進(jìn)行多線程的優(yōu)化。由于當(dāng)前數(shù)據(jù)的發(fā)送并非是整條發(fā)送出去，buf的管理都粒度都是在字符級(jí)別，所以采用一個(gè)指令生成線程（parser）和發(fā)送線程(sender)一一對(duì)應(yīng)。

1. 多客戶端并行：建立一個(gè)線程池，parser和sender線程組成一個(gè)線程組。
2. 多庫(kù)并行：由于nemo底層上，不同數(shù)據(jù)格式的管理都有一個(gè)自己rocksdb實(shí)例，所以多庫(kù)并行，做起來(lái)也是非常簡(jiǎn)便的。最終結(jié)果能夠提升10%左右。

整體架構(gòu)圖如下： 

migrator線程

1. 掃描不同數(shù)據(jù)類型的分庫(kù)
2. 將掃描到key分發(fā)給parser線程

parser線程

1. 接收migrator發(fā)送的key
2. 將key進(jìn)行解析成響應(yīng)數(shù)據(jù)redis指令
3. 將解析好的redis指令加載到sender的發(fā)送buf中

sender線程

1. 從發(fā)送buf中讀取數(shù)據(jù)，以非阻塞方式向redis發(fā)送數(shù)據(jù)
2. 接收redis返回的結(jié)果并解析，如果出現(xiàn)錯(cuò)誤則顯示錯(cuò)誤結(jié)果

結(jié)果

至此，數(shù)據(jù)遷移工具在性能上已經(jīng)從原先需要20小時(shí)遷移的數(shù)據(jù)到現(xiàn)在大概40分鐘左右，完全滿足最初的時(shí)間要求。

測(cè)試

測(cè)試結(jié)果：

1. 在每個(gè)同時(shí)使用10個(gè)發(fā)送端(可配置)情況下，不同機(jī)器之間每小時(shí)平均能夠轉(zhuǎn)移15G
2. 測(cè)試結(jié)果，均得到正確性驗(yàn)證

測(cè)試分析：

1. 數(shù)據(jù)條數(shù)對(duì)速度影響比數(shù)據(jù)量更大，見(jiàn)Test2
2. 并行線程越多，速度越快，見(jiàn)Test3
3. 本地遷移比不同機(jī)器上速度快50%左右，見(jiàn)Test4

測(cè)試說(shuō)明

機(jī)器配置說(shuō)明：

測(cè)試數(shù)據(jù)源說(shuō)明：

性能測(cè)試

Test1:遠(yuǎn)程測(cè)試

bada05->bada06 短數(shù)

Test2:數(shù)據(jù)源的影響

遠(yuǎn)程測(cè)試：bada05->bada06

數(shù)據(jù)庫(kù)| 發(fā)送端數(shù)量| 數(shù)據(jù)量| 數(shù)據(jù)條數(shù) |消耗時(shí)間| 速度（每小時(shí)） ---|---|---|---|---|---|---|---|---|---|---|--- All(短)| 10| 16G| 1.5億*5 |3.5h| 4.5G/2.1億 set(短)| 10| 2.8G| 1.5億 |40min| 4.2G/2.3億 set(長(zhǎng))| 10| 2.5G |3.8千萬(wàn) |10min |15G/2.2億 hash(長(zhǎng)）| 10| 3.3G|3.8千萬(wàn) |10min |20G/2.2億 kv(長(zhǎng))| 10| 1.6G| 3.8千萬(wàn)| 8min| 12G/2.8億 list(長(zhǎng))| 10| 2.8|3.8千萬(wàn)| 10min| 16G/2.2億 注：由于長(zhǎng)數(shù)據(jù)中，不同數(shù)據(jù)類型key有重復(fù)，無(wú)法正常導(dǎo)入redis，故采用分庫(kù)導(dǎo)入

Test3:發(fā)送線程數(shù)量的影響

bada05->bada06 短數(shù)據(jù)

線程數(shù)量| 數(shù)據(jù)量|數(shù)據(jù)條數(shù) |消耗時(shí)間| 速度(每小時(shí)) ---|---|---|---|---|---|---|---|--- 10| 16G| 1.5億5| 3.5小時(shí)| 4.5G/2.1億 16| 16G| 1.5億5| 2.3小時(shí)| 7.1G/3.3億 20| 16G| 1.5億*5| 2.1小時(shí)| 7.5G/3.5億

Test4:本地和遠(yuǎn)程對(duì)比

|線程數(shù)量| 數(shù)據(jù)量| 數(shù)據(jù)條數(shù)| 速度(每小時(shí)) ---|---|---|---|---|---|--- 異地|10 |16G |1.5億5| 3.5h 4.5G/2.1億 本地|10 |16G |1.5億5| 1.9h 8.1G/3.8億

正確性測(cè)試

測(cè)試方法：

1. 壓入一批pika數(shù)據(jù)，每條數(shù)據(jù)的key，都有唯一的順序的序列號(hào)
2. 遷移完畢之后。向redis發(fā)送不同數(shù)據(jù)get請(qǐng)求，得到返回之后與預(yù)期結(jié)果做對(duì)比

測(cè)試結(jié)果:

1. 本地遷移不同類型數(shù)據(jù)各1000萬(wàn)條，完全通過(guò)
2. 遠(yuǎn)程遷移不同數(shù)據(jù)各1000萬(wàn)條，完全通過(guò)