Mysql百萬量級(jí)數(shù)據(jù)如何高效導(dǎo)入Redis

MySQL百萬量級(jí)數(shù)據(jù)如何高效導(dǎo)入redis,很多新手對此不是很清楚,為了幫助大家解決這個(gè)難題,下面小編將為大家詳細(xì)講解,有這方面需求的人可以來學(xué)習(xí)下,希望你能有所收獲。

在五蓮等地區(qū),都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局,加強(qiáng)發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力,以專注、極致的服務(wù)理念,為客戶提供做網(wǎng)站、網(wǎng)站建設(shè) 網(wǎng)站設(shè)計(jì)制作按需定制網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),成都全網(wǎng)營銷推廣,成都外貿(mào)網(wǎng)站制作,五蓮網(wǎng)站建設(shè)費(fèi)用合理。

隨著系統(tǒng)的運(yùn)行,數(shù)據(jù)量變得越來越大,單純的將數(shù)據(jù)存儲(chǔ)在mysql中,已然不能滿足查詢要求了,此時(shí)我們引入Redis作為查詢的緩存層,將業(yè)務(wù)中的熱數(shù)據(jù)保存到Redis,擴(kuò)展傳統(tǒng)關(guān)系型數(shù)據(jù)庫的服務(wù)能力,用戶通過應(yīng)用直接從Redis中快速獲取常用數(shù)據(jù),或者在交互式應(yīng)用中使用Redis保存活躍用戶的會(huì)話,都可以極大地降低后端關(guān)系型數(shù)據(jù)庫的負(fù)載,提升用戶體驗(yàn)。
傳統(tǒng)命令的缺點(diǎn)
使用傳統(tǒng)的redis client命令在大數(shù)據(jù)量的導(dǎo)入場景下存在如下缺陷:
由于redis是單線程模型,雖然避免了多線程下線程切換所耗費(fèi)的時(shí)間,單一順序的執(zhí)行命令也很快,但是在大批量數(shù)據(jù)導(dǎo)入的場景下,發(fā)送命令所花費(fèi)的時(shí)間和接收服務(wù)器響應(yīng)結(jié)果耗費(fèi)的時(shí)間就會(huì)被放大。
假如需要導(dǎo)入100萬條數(shù)據(jù),那光是命令執(zhí)行時(shí)間,就需要花費(fèi)100萬*(t1 + t2)。
除了逐條命令發(fā)送,當(dāng)然redis設(shè)計(jì)肯定也會(huì)考慮這個(gè)問題,所以出現(xiàn)了pipelining管道模式。

但是pipelining在命令行中是沒有的,使得我們又需要編寫新的處理代碼,來接收批量的響應(yīng)。但是只有很少很少的客戶端代碼支持,比如php-redis的擴(kuò)展就不支持異步。
pipelining管道模式,其實(shí)就是減少了TCP連接的交互時(shí)間,當(dāng)一批命令執(zhí)行完畢后,一次性發(fā)送結(jié)果。
其實(shí)現(xiàn)原理是采用FIFO(先進(jìn)先出)的隊(duì)列來保證數(shù)據(jù)的順序性。
只有一小部分客戶端支持非阻塞I/O,并不是所有的客戶端都能夠以一種有效的方式解析應(yīng)答,以最大化吞吐量。
由于這些原因,將龐大數(shù)據(jù)導(dǎo)入到Redis的首選方法是生成一個(gè)包含Redis協(xié)議數(shù)據(jù)格式,批量的發(fā)送過去。
數(shù)據(jù)導(dǎo)入Redis熱身
采用nc命令導(dǎo)入數(shù)據(jù)
nc是netcat的簡寫,nc的作用有:
1、實(shí)現(xiàn)任意TCP/UDP端口的偵聽,增加-l參數(shù)后,nc可以作為server以TCP或UDP方式偵聽指定端口
2、端口的掃描,nc可以作為client發(fā)起TCP或UDP連接
3、機(jī)器之間傳輸文件
4、機(jī)器之間網(wǎng)絡(luò)測速
采用pipe模式導(dǎo)入數(shù)據(jù)
然而,使用nc監(jiān)聽并不是一個(gè)非??煽康姆绞絹韴?zhí)行大規(guī)模的數(shù)據(jù)導(dǎo)入,因?yàn)閚etcat并不真正知道何時(shí)傳輸了所有數(shù)據(jù),也無法檢查錯(cuò)誤。在2.6或更高版本的Redis中,Redis -cli腳本支持一種稱為pipe管道模式的新模式,這種模式是為了執(zhí)行大規(guī)模插入而設(shè)計(jì)的。

由上圖,可以看到pipe命令的返回結(jié)果,txt文件中有多少行命令,返回的replies數(shù)就是多少, errors表示其中執(zhí)行錯(cuò)誤的命令條數(shù)。

redis協(xié)議學(xué)習(xí)

協(xié)議的格式為:

*<參數(shù)數(shù)量>  \r
$<參數(shù) 1 的字節(jié)數(shù)量>  \r
<參數(shù) 1 的數(shù)據(jù)> \r
...
$<參數(shù) N 的字節(jié)數(shù)量> \r
<參數(shù) N 的數(shù)據(jù)> \r\n

比如:插入一條hash類型的數(shù)據(jù)。
HSET  id  book1  book_description1
根據(jù)Redis協(xié)議,總共有4個(gè)部分,所以開頭為*4,其余內(nèi)容解釋如下:

注意一下:HSET命令本身也作為協(xié)議的其中一個(gè)參數(shù)來發(fā)送。
構(gòu)造出來的協(xié)議數(shù)據(jù)結(jié)構(gòu):
*4\r\n$4\r\nHSET\r\n$2\r\nid\r\n$5\r\nbook1\r\n$17\r\nbook_description1\r

格式化一下:

*4\r
$4\r
HSET\r
$2\r
idvvvv\r
$5\r
book1\r
$17\r
book_description1\r\n

RESP協(xié)議 bulk
Redis客戶機(jī)使用一種稱為RESP (Redis序列化協(xié)議)的協(xié)議與Redis服務(wù)器通信。
redis-cli pipe模式需要和nc命令一樣快,并且解決了nc命令不知道何時(shí)命令結(jié)束的問題。
在發(fā)送數(shù)據(jù)的同時(shí),它同樣會(huì)去讀取響應(yīng),嘗試去解析。
一旦輸入流中沒有讀取到更多的數(shù)據(jù)之后,它就會(huì)發(fā)送一個(gè)特殊的20比特的echo命令,標(biāo)識(shí)最后一個(gè)命令已經(jīng)發(fā)送完畢 如果在響應(yīng)結(jié)果中匹配到這個(gè)相同數(shù)據(jù)后,說明本次批量發(fā)送是成功的。

使用這個(gè)技巧,我們不需要解析發(fā)送給服務(wù)器的協(xié)議來了解我們發(fā)送了多少命令,只需要解析應(yīng)答即可。
在解析應(yīng)答時(shí),redis會(huì)對解析的應(yīng)答進(jìn)行一個(gè)計(jì)數(shù),在最后能夠告訴用戶大量插入會(huì)話向服務(wù)器傳輸?shù)拿畹臄?shù)量。也就是上面我們使用pipe模式實(shí)際操作的響應(yīng)結(jié)果。
將輸入數(shù)據(jù)源換成mysql
上面的例子中,我們以一個(gè)txt文本為輸入數(shù)據(jù)源,使用了pipe模式導(dǎo)入數(shù)據(jù)。
基于上述協(xié)議的學(xué)習(xí)和理解,我們只需要將mysql中的數(shù)據(jù)按照既定的協(xié)議通過pipe模式導(dǎo)入Redis即可。
實(shí)際案例--從Mysql導(dǎo)入百萬級(jí)數(shù)據(jù)到Redis
首先造數(shù)據(jù)
由于環(huán)境限制,所以這里沒有用真實(shí)數(shù)據(jù)來實(shí)現(xiàn)導(dǎo)入,那么我們就先使用一個(gè)存儲(chǔ)過程來造一百萬條數(shù)據(jù)吧。使用存儲(chǔ)過程如下:
DELIMITER $$
USE `cb_mon`$$

DROP PROCEDURE IF EXISTS `test_insert`$$
CREATE DEFINER=`root`@`%` PROCEDURE `test_insert`()
BEGIN

       DECLARE i INT DEFAULT 1;
       WHILE i<= 1000000
           DO
           INSERT INTO t_book(id,number,NAME,descrition)
           VALUES (i, CONCAT("00000",i) , CONCAT('book',i)
           , CONCAT('book_description',i));
           SET i=i+1;
       END WHILE ;
       COMMIT;
   END$$

DELIMITER ;

調(diào)用存儲(chǔ)過程
CALL test_insert();
查看表數(shù)據(jù):
按協(xié)議構(gòu)造查詢語句
按照上述redis協(xié)議,我們使用如下sql來構(gòu)造協(xié)議數(shù)據(jù):
SELECT
 CONCAT(
   "*4\r\n",
   "$",
   LENGTH(redis_cmd),
   "\r\n",
   redis_cmd,
   "\r\n",
   "$",
   LENGTH(redis_key),
   "\r\n",
   redis_key,
   "\r\n",
   "$",
   LENGTH(hkey),
   "\r\n",
   hkey,
   "\r\n",
   "$",
   LENGTH(hval),
   "\r\n",
   hval,
   "\r"
 )
FROM
 (SELECT
   "HSET" AS redis_cmd,
   id AS redis_key,
   NAME AS hkey,
   descrition AS hval
 FROM
   cb_mon.t_book
 ) AS t limit 1000000

并將內(nèi)容保存至redis.sql 文件中。

編寫腳本使用pipe模式導(dǎo)入redis

編寫shell腳本。由于我在主機(jī)上是通過docker安裝的redis和mysql,以下腳本供參考:

#!/bin/bash
starttime=`date +'%Y-%m-%d %H:%M:%S'`

docker exec -i 899fe01d4dbc mysql --default-character-set=utf8
--skip-column-names --raw < ./redis.sql
| docker exec -i 4c90ef506acd redis-cli --pipe

endtime=`date +'%Y-%m-%d %H:%M:%S'`
start_seconds=$(date --date="$starttime" +%s);
end_seconds=$(date --date="$endtime" +%s);

echo "腳本執(zhí)行耗時(shí):"$((end_seconds-start_seconds))"s"
執(zhí)行截圖:
可以看到百萬級(jí)的數(shù)據(jù)導(dǎo)入redis,只花費(fèi)了7秒,效率非常高。
注意事項(xiàng)
如果mysql表特別大,可以考慮分批導(dǎo)入,或者將表拆分,否則在導(dǎo)入過程中可能會(huì)發(fā)生:
lost connection to mysql server during query

由于max_allowed_packed和超時(shí)時(shí)間限制,查詢數(shù)據(jù)的過程中,可能會(huì)造成連接斷開,所以在數(shù)據(jù)表的數(shù)據(jù)量特別大的時(shí)候,需要分頁或者將表拆分導(dǎo)入。
總結(jié)了如下幾點(diǎn):
1、redis單線程執(zhí)行命令,避免了線程切換所消耗的時(shí)間,但是在超大數(shù)據(jù)量級(jí)下,其發(fā)送、響應(yīng)接收的時(shí)延不可忽視。

2、網(wǎng)絡(luò)nc命令的應(yīng)用場景,及在數(shù)據(jù)導(dǎo)入時(shí)存在的缺點(diǎn)。

3、redis RESP協(xié)議的理解和應(yīng)用。

看完上述內(nèi)容是否對您有幫助呢?如果還想對相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章,請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道,感謝您對創(chuàng)新互聯(lián)的支持。

本文標(biāo)題:Mysql百萬量級(jí)數(shù)據(jù)如何高效導(dǎo)入Redis
文章轉(zhuǎn)載:http://muchs.cn/article0/ihgdoo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供自適應(yīng)網(wǎng)站、App開發(fā)關(guān)鍵詞優(yōu)化、品牌網(wǎng)站建設(shè)、域名注冊

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)

成都網(wǎng)站建設(shè)