專為編程打造，自動寫代碼機(jī)器人，免費(fèi)開通

前言

隨著系統(tǒng)的運(yùn)行，數(shù)據(jù)量變得越來越大，單純的將數(shù)據(jù)存儲在mysql中，已然不能滿足查詢要求了，此時我們引入Redis作為查詢的緩存層，將業(yè)務(wù)中的熱數(shù)據(jù)保存到Redis，擴(kuò)展傳統(tǒng)關(guān)系型數(shù)據(jù)庫的服務(wù)能力，用戶通過應(yīng)用直接從Redis中快速獲取常用數(shù)據(jù)，或者在交互式應(yīng)用中使用Redis保存活躍用戶的會話，都可以極大地降低后端關(guān)系型數(shù)據(jù)庫的負(fù)載，提升用戶體驗(yàn)。

網(wǎng)站建設(shè)公司,為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁設(shè)計(jì)及定制網(wǎng)站建設(shè)服務(wù),專注于成都定制網(wǎng)頁設(shè)計(jì),高端網(wǎng)頁制作,對成都門窗定制等多個行業(yè)擁有豐富的網(wǎng)站建設(shè)經(jīng)驗(yàn)的網(wǎng)站建設(shè)公司。專業(yè)網(wǎng)站設(shè)計(jì),網(wǎng)站優(yōu)化推廣哪家好,專業(yè)成都網(wǎng)站營銷優(yōu)化,H5建站,響應(yīng)式網(wǎng)站。

傳統(tǒng)命令的缺點(diǎn)

使用傳統(tǒng)的redis client命令在大數(shù)據(jù)量的導(dǎo)入場景下存在如下缺陷：

由于redis是單線程模型，雖然避免了多線程下線程切換所耗費(fèi)的時間，單一順序的執(zhí)行命令也很快，但是在大批量數(shù)據(jù)導(dǎo)入的場景下，發(fā)送命令所花費(fèi)的時間和接收服務(wù)器響應(yīng)結(jié)果耗費(fèi)的時間就會被放大。

假如需要導(dǎo)入100萬條數(shù)據(jù)，那光是命令執(zhí)行時間，就需要花費(fèi)100萬*（t1 + t2）。

除了逐條命令發(fā)送，當(dāng)然redis設(shè)計(jì)肯定也會考慮這個問題，所以出現(xiàn)了pipelining管道模式。

但是pipelining在命令行中是沒有的，使得我們又需要編寫新的處理代碼，來接收批量的響應(yīng)。但是只有很少很少的客戶端代碼支持，比如php-redis的擴(kuò)展就不支持異步。

pipelining管道模式，其實(shí)就是減少了TCP連接的交互時間，當(dāng)一批命令執(zhí)行完畢后，一次性發(fā)送結(jié)果。

其實(shí)現(xiàn)原理是采用FIFO(先進(jìn)先出)的隊(duì)列來保證數(shù)據(jù)的順序性。

只有一小部分客戶端支持非阻塞I/O，并不是所有的客戶端都能夠以一種有效的方式解析應(yīng)答，以最大化吞吐量。

由于這些原因，將龐大數(shù)據(jù)導(dǎo)入到Redis的首選方法是生成一個包含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)聽并不是一個非?？煽康姆绞絹韴?zhí)行大規(guī)模的數(shù)據(jù)導(dǎo)入，因?yàn)閚etcat并不真正知道何時傳輸了所有數(shù)據(jù)，也無法檢查錯誤。在2.6或更高版本的Redis中，Redis -cli腳本支持一種稱為pipe管道模式的新模式，這種模式是為了執(zhí)行大規(guī)模插入而設(shè)計(jì)的。
使用管道模式的命令運(yùn)行如下:

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

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

協(xié)議的格式為：

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

比如：
插入一條hash類型的數(shù)據(jù)。

HSET  id  book1  book_description1

根據(jù)Redis協(xié)議，總共有4個部分，所以開頭為*4，其余內(nèi)容解釋如下：

內(nèi)容	長度	協(xié)議命令
HSET	4	$4
id	2	$2
book1	5	$5
book_description1	17	$17

注意一下：HSET命令本身也作為協(xié)議的其中一個參數(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\n

格式化一下：

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

RESP協(xié)議 bulk

Redis客戶機(jī)使用一種稱為RESP (Redis序列化協(xié)議)的協(xié)議與Redis服務(wù)器通信。

redis-cli pipe模式需要和nc命令一樣快，并且解決了nc命令不知道何時命令結(jié)束的問題。

在發(fā)送數(shù)據(jù)的同時，它同樣會去讀取響應(yīng)，嘗試去解析。

一旦輸入流中沒有讀取到更多的數(shù)據(jù)之后，它就會發(fā)送一個特殊的20比特的echo命令，標(biāo)識最后一個命令已經(jīng)發(fā)送完畢
如果在響應(yīng)結(jié)果中匹配到這個相同數(shù)據(jù)后，說明本次批量發(fā)送是成功的。

使用這個技巧，我們不需要解析發(fā)送給服務(wù)器的協(xié)議來了解我們發(fā)送了多少命令，只需要解析應(yīng)答即可。

在解析應(yīng)答時，redis會對解析的應(yīng)答進(jìn)行一個計(jì)數(shù)，在最后能夠告訴用戶大量插入會話向服務(wù)器傳輸?shù)拿畹臄?shù)量。也就是上面我們使用pipe模式實(shí)際操作的響應(yīng)結(jié)果。

將輸入數(shù)據(jù)源換成mysql

上面的例子中，我們以一個txt文本為輸入數(shù)據(jù)源，使用了pipe模式導(dǎo)入數(shù)據(jù)。

基于上述協(xié)議的學(xué)習(xí)和理解，我們只需要將mysql中的數(shù)據(jù)按照既定的協(xié)議通過pipe模式導(dǎo)入Redis即可。

實(shí)際案例—從Mysql導(dǎo)入百萬級數(shù)據(jù)到Redis

首先造數(shù)據(jù)

由于環(huán)境限制，所以這里沒有用真實(shí)數(shù)據(jù)來實(shí)現(xiàn)導(dǎo)入，那么我們就先使用一個存儲過程來造一百萬條數(shù)據(jù)把。使用存儲過程如下：

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)用存儲過程：

 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í)行耗時： "$((end_seconds-start_seconds))"s"

執(zhí)行截圖：

可以看到百萬級的數(shù)據(jù)導(dǎo)入redis，只花費(fèi)了7秒，效率非常高。

注意事項(xiàng)

如果mysql表特別大，可以考慮分批導(dǎo)入，或者將表拆分，否則在導(dǎo)入過程中可能會發(fā)生

lost connection to mysql server during query

由于max_allowed_packed和超時時間限制，查詢數(shù)據(jù)的過程中，可能會造成連接斷開，所以在數(shù)據(jù)表的數(shù)據(jù)量特別大的時候，需要分頁或者將表拆分導(dǎo)入。

總結(jié)

本篇文章主要探討了，Mysql百萬級數(shù)據(jù)量級下，如何高效的遷移到Redis中去，逐步實(shí)現(xiàn)目標(biāo)的過程中，總結(jié)了如下幾點(diǎn)

1. redis單線程執(zhí)行命令，避免了線程切換所消耗的時間，但是在超大數(shù)據(jù)量級下，其發(fā)送、響應(yīng)接收的時延不可忽視。

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

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

4. 百萬量級Mysql數(shù)據(jù)的Redis快速導(dǎo)入案例。

為了方便大家學(xué)習(xí)討論，我創(chuàng)建了一個java疑難攻堅(jiān)互助大家庭，和其他傳統(tǒng)的學(xué)習(xí)交流不同。本群主要致力于解決項(xiàng)目中的疑難問題，在遇到項(xiàng)目難以解決的。

問題時，都可以在這個大家庭里尋求幫助。

公眾號回復(fù)【問題的答案】進(jìn)入：java中Integer包裝類的基本數(shù)據(jù)類型是？

如果你也經(jīng)歷過遇到項(xiàng)目難題，無從下手，

他人有可能可以給你提供一些思路和看法，一百個人就有一百種思路，

同樣，如果你也樂于幫助別人，那解決別人遇到的問題，也同樣對你是一種鍛煉。

文章標(biāo)題：IT明星不是夢#Mysql百萬數(shù)據(jù)量級數(shù)據(jù)快速導(dǎo)入Red
網(wǎng)頁路徑：http://www.ekvhdxd.cn/article38/jcgosp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供虛擬主機(jī)、網(wǎng)站建設(shè)、小程序開發(fā)、建站公司、用戶體驗(yàn)、網(wǎng)站導(dǎo)航

廣告

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