redis分片

本文是我們學(xué)院課程的一部分，標(biāo)題為Redis NoSQL鍵值存儲(chǔ) 。

這是Redis的速成課程。 您將學(xué)習(xí)如何安裝Redis和啟動(dòng)服務(wù)器。 此外，您還會(huì)在Redis命令行上亂七八糟。 接下來是更高級(jí)的主題，例如復(fù)制，分片和集群，同時(shí)還介紹了Redis與Spring Data的集成。 在這里查看 ！

目錄

1.簡(jiǎn)介 2.何時(shí)使用分片（分區(qū)） 3.分片（分區(qū)）方案 4.分片（分區(qū)）實(shí)現(xiàn) 5.規(guī)劃分片（分區(qū)） 6.分片（分區(qū)）和復(fù)制 7.用Twemproxy進(jìn)行分片（分區(qū)） 8.接下來

1.簡(jiǎn)介

我們每天處理的數(shù)據(jù)量呈指數(shù)級(jí)增長(zhǎng)。 當(dāng)必要的數(shù)據(jù)無(wú)法容納在內(nèi)存中，甚至物理存儲(chǔ)空間不足時(shí)，我們經(jīng)常面臨單個(gè)設(shè)備的硬件限制。 多年來，這些問題導(dǎo)致業(yè)界開發(fā)了可以克服此類限制的數(shù)據(jù)分片（或數(shù)據(jù)分區(qū)）解決方案。

在Redis中，數(shù)據(jù)分片（分區(qū)）是一種在多個(gè)Redis實(shí)例之間拆分所有數(shù)據(jù)的技術(shù)，以便每個(gè)實(shí)例僅包含鍵的一個(gè)子集。 通過添加越來越多的實(shí)例并將數(shù)據(jù)劃分為較小的部分（碎片或分區(qū)），這樣的過程可以減輕數(shù)據(jù)的增長(zhǎng)。 不僅如此，這還意味著越來越多的計(jì)算能力可用于處理數(shù)據(jù)，有效地支持水平縮放。

盡管并非所有解決方案都是雙贏的，但仍需要權(quán)衡取舍：通過在多個(gè)實(shí)例之間拆分?jǐn)?shù)據(jù)，查找特定鍵（或多個(gè)鍵）的問題成為一個(gè)問題。 這就是分片（分區(qū)）方案的用武之地：應(yīng)該按照一些一致或固定的規(guī)則對(duì)數(shù)據(jù)進(jìn)行分片（分區(qū)），以便對(duì)同一密鑰的寫入和讀取操作應(yīng)轉(zhuǎn)到擁有（擁有）此密鑰的Redis實(shí)例。

本教程的材料基于與分區(qū)和分區(qū)有關(guān)的出色Redis文檔： http : //redis.io/topics/partitioning

2.何時(shí)使用分片（分區(qū)）

根據(jù)Redis文檔（ http://redis.io/topics/partitioning ），如果要執(zhí)行以下操作，應(yīng)考慮對(duì)數(shù)據(jù)進(jìn)行分片（分區(qū)）：

• 使用多臺(tái)計(jì)算機(jī)的內(nèi)存來管理更大的數(shù)據(jù)庫(kù)（否??則，您將受限于單臺(tái)計(jì)算機(jī)可以支持的內(nèi)存量）
• 擴(kuò)展多個(gè)CPU，多個(gè)計(jì)算機(jī)的計(jì)算能力，并利用它們的網(wǎng)絡(luò)帶寬

如果您認(rèn)為現(xiàn)在沒有數(shù)據(jù)縮放問題，則可能會(huì)在不久的將來遇到此問題，因此最好做好準(zhǔn)備并提前考慮（請(qǐng)參閱規(guī)劃分片（分區(qū)） ）。 但是在這樣做之前，請(qǐng)考慮分片（分區(qū)）帶來的復(fù)雜性和缺點(diǎn)：

• 通常不支持涉及多個(gè)鍵的操作。 例如，如果兩個(gè)集合（ SINTER ）存儲(chǔ)在映射到不同Redis實(shí)例的鍵中，則不可能直接執(zhí)行它們之間的交集。
• 涉及映射到不同Redis實(shí)例的多個(gè)密鑰的事務(wù)是不可能的。
• 分區(qū)是基于鍵的，因此無(wú)法使用單個(gè)大鍵（很大的排序集或列表）對(duì)數(shù)據(jù)集進(jìn)行分片（分區(qū)）。
• 備份和持久管理要復(fù)雜得多：您必須處理多個(gè)RDB / AOF文件，備份涉及來自許多實(shí)例的RDB文件的聚合（合并）。
• 除非您對(duì)此進(jìn)行了計(jì)劃，否則在運(yùn)行時(shí)添加和刪除實(shí)例可能會(huì)導(dǎo)致數(shù)據(jù)失衡（請(qǐng)參閱規(guī)劃分片（分區(qū)） ）。

3.分片（分區(qū)）方案

Redis可以使用幾種經(jīng)過戰(zhàn)斗驗(yàn)證的分片（分區(qū)）方案，具體取決于您的數(shù)據(jù)模式。

• 范圍劃分
  通過將對(duì)象范圍映射到特定的Redis實(shí)例中來完成。 例如，假設(shè)我們正在存儲(chǔ)一些用戶數(shù)據(jù)，并且每個(gè)用戶都有其唯一的標(biāo)識(shí)符（ID）。 在我們的分區(qū)方案中，我們可以定義ID從0到10000的用戶將進(jìn)入實(shí)例Redis 1，而ID從10001到20000的用戶將進(jìn)入實(shí)例Redis 2，依此類推。 該方案的缺點(diǎn)是，范圍和實(shí)例之間的映射應(yīng)該被維護(hù)，并且應(yīng)該與Redis中保留的對(duì)象（用戶，產(chǎn)品等）的種類一樣多的映射。
• 哈希分區(qū)
  該方案適用于任何密鑰，但涉及哈希函數(shù) ：此函數(shù)應(yīng)將密鑰名稱映射到某個(gè)數(shù)字。 假設(shè)我們有這樣一個(gè)函數(shù)（我們稱其為hash_func ），這樣的方案就是這樣的：
  • 取得鍵名，并使用hash_func將其映射到數(shù)字

  哈希函數(shù)的選擇非常重要。 良好的哈希函數(shù)可確保密鑰在所有Redis實(shí)例上平均分布，因此不會(huì)在任何單個(gè)實(shí)例上建立過多的密鑰。

• 一致性哈希
  它是hash partitioning的一種高級(jí)形式，被許多解決方案用于數(shù)據(jù)分片（分區(qū)）。

4.分片（分區(qū)）實(shí)現(xiàn)

從實(shí)現(xiàn)的角度來看，根據(jù)應(yīng)用程序的體系結(jié)構(gòu)，有幾種可能的數(shù)據(jù)分片（分區(qū)）實(shí)現(xiàn)：

• 客戶端分區(qū)
  客戶端直接選擇正確的實(shí)例來寫入或讀取給定的密鑰。
• 代理輔助分區(qū)
  客戶端將請(qǐng)求發(fā)送到支持Redis協(xié)議的代理，而不是直接將請(qǐng)求發(fā)送到正確的Redis實(shí)例。 代理將確保根據(jù)配置的分區(qū)方案將請(qǐng)求轉(zhuǎn)發(fā)到正確的Redis實(shí)例，并將答復(fù)發(fā)送回客戶端（最著名的實(shí)現(xiàn)是Twitter的Twemproxy ， https：//github.com/twitter/ twemproxy ）。
• 查詢路由
  客戶端將查詢發(fā)送到隨機(jī)Redis實(shí)例，該實(shí)例將確保將查詢轉(zhuǎn)發(fā)到正確的實(shí)例。 查詢路由的混合形式假定客戶端被重定向到正確的實(shí)例（但是查詢不會(huì)直接從一個(gè)Redis實(shí)例轉(zhuǎn)發(fā)到另一個(gè)實(shí)例），并將在本教程的第5部分 Redis Clustering中進(jìn)行介紹 。

5.規(guī)劃分片（分區(qū)）

如前所述，一旦您開始在許多Redis實(shí)例之間使用數(shù)據(jù)分片（分區(qū)），則在運(yùn)行時(shí)添加和刪除實(shí)例可能會(huì)很困難。 您經(jīng)常會(huì)在Redis中使用的一種技術(shù)被稱為Presharding （ http://redis.io/topics/partitioning ）。

預(yù)分片的想法是從一開始就以許多實(shí)例開始（但實(shí)際節(jié)點(diǎn)/服務(wù)器只有一個(gè)或很少數(shù)量）。 自開始以來，實(shí)例的數(shù)量可能會(huì)有所不同并且可能會(huì)很大（對(duì)于大多數(shù)用例而言，32或64個(gè)實(shí)例就足夠了）。 由于Redis非常輕巧，因此完全有可能在單個(gè)服務(wù)器上運(yùn)行64個(gè)Redis實(shí)例。

這樣，隨著數(shù)據(jù)存儲(chǔ)需求的增長(zhǎng)以及需要更多Redis節(jié)點(diǎn)/服務(wù)器來處理它，可以將實(shí)例從一臺(tái)服務(wù)器簡(jiǎn)單地移動(dòng)到另一臺(tái)服務(wù)器。 例如，如果您有一臺(tái)服務(wù)器并添加了另外一臺(tái)服務(wù)器，則應(yīng)將第一臺(tái)服務(wù)器的一半Redis實(shí)例移至第二臺(tái)服務(wù)器。 當(dāng)每個(gè)服務(wù)器/節(jié)點(diǎn)上有一個(gè)Redis實(shí)例時(shí)，此技巧可能會(huì)一直持續(xù)下去。

但是要記住一件事：如果將Redis用作數(shù)據(jù)的內(nèi)存緩存（而不是持久性數(shù)據(jù)存儲(chǔ)），則可能不需要使用預(yù)分片。 一致的散列實(shí)現(xiàn)通常能夠在運(yùn)行時(shí)處理新的或刪除的實(shí)例。 例如，如果給定密鑰的首選實(shí)例不可用，則該密鑰將被其他實(shí)例拾取。 或者，如果添加新實(shí)例，則新密鑰的一部分將存儲(chǔ)在該新實(shí)例上。

6.分片（分區(qū)）和復(fù)制

在許多實(shí)例之間分片（分區(qū)）數(shù)據(jù)并不能解決數(shù)據(jù)安全和冗余問題。 如果其中一個(gè)分片（分區(qū)）由于硬件故障而死亡，而您沒有備份來還原數(shù)據(jù)，則意味著您將永遠(yuǎn)丟失數(shù)據(jù)。

這就是為什么分片（分區(qū)）與復(fù)制并存的原因。 如果將Redis用作持久性數(shù)據(jù)存儲(chǔ)，則最好為不同服務(wù)器/節(jié)點(diǎn)上的每個(gè)分片（分區(qū)）配置至少一個(gè)副本。 這可能會(huì)使您的容量需求增加一倍，但確保數(shù)據(jù)安全就顯得更為重要。

復(fù)制的配置與本教程第3部分“ Redis復(fù)制 ”中介紹的配置沒有任何不同。

7.用Twemproxy進(jìn)行分片（分區(qū)）

Twemproxy （也稱為nutcracker ）是由Twitter（ https://github.com/twitter/twemproxy ）開發(fā)和開源的，它是Redis的廣泛使用，非常快速且輕量級(jí)的代理。 盡管它具有許多功能，但我們要介紹的功能與其向Redis添加分片（分區(qū)）的能力有關(guān)：

• 在多臺(tái)服務(wù)器之間自動(dòng)分片數(shù)據(jù)
• 支持多種哈希模式，包括一致的哈希和分布

Twemproxy （ nutcracker ）非常易于安裝和配置。 本教程的最新版本是0.3.0 ，可以從http://code.google.com/p/twemproxy/downloads/list下載。 安裝非常簡(jiǎn)單。

下載 wget http://twemproxy.googlecode.com/files/nutcracker-0.3.0.tar.gz

解壓縮檔案 tar xfz nutcracker-0.3.0.tar.gz

構(gòu)建（您需要的唯一預(yù)裝軟件包是gcc和make ）。 cd nutcracker-0.3.0 ./configure make

安裝 sudo make install

默認(rèn)情況下， twemproxy （ nutcracker ）將位于/usr/local/sbin/nutcracker 。 安裝后，最重要（但是非常簡(jiǎn)單）的部分是其配置。

Twemproxy （ nutcracker ）使用YAML作為配置文件格式（ http://www.yaml.org/ ）。 在twemproxy （ nutcracker ）支持的許多設(shè)置中，我們將選擇與分片（分區(qū)）相關(guān)的設(shè)置。

設(shè)置	聽：名稱：端口| ip：端口
描述	此服務(wù)器池的偵聽地址和端口（ name:port或ip:port ）。
例	聽：127.0.0.1:22121

表格1

設(shè)置	哈希：<功能>
描述	哈希函數(shù)的名稱。 可能的值為： - 一次一個(gè) – md5（ http://en.wikipedia.org/wiki/MD5 ） – crc16（ http://en.wikipedia.org/wiki/Cyclic_redundancy_check ） – crc32（與libmemcached兼容的crc32實(shí)現(xiàn)） – crc32a（根據(jù)規(guī)范正確的crc32實(shí)現(xiàn)） – fnv1_64（ http://en.wikipedia.org/wiki/Fowler–Noll–Vo_hash_function ） – fnv1a_64（ http://en.wikipedia.org/wiki/Fowler-Noll-Vo_hash_function ） – fnv1_32（ http://en.wikipedia.org/wiki/Fowler–Noll–Vo_hash_function ） – fnv1a_32（ http://en.wikipedia.org/wiki/Fowler–Noll–Vo_hash_function ） – hsieh（ http://www.azillionmonkeys.com/qed/hash.html ） –雜音（ http://en.wikipedia.org/wiki/MurmurHash ） –詹金斯（ http://en.wikipedia.org/wiki/Jenkins_hash_function ）
例	雜湊：fnv1a_64

表2

設(shè)置	分布：<模式>
描述	密鑰分發(fā)模式（請(qǐng)參閱http://en.wikipedia.org/wiki/Consistent_hashing ）。 可能的值為： –凱塔瑪 –模數(shù) –隨機(jī)
例	分布：ketama

表3

設(shè)置	redis：是|否
描述	一個(gè)布爾值，它控制服務(wù)器池是否使用Redis或Memcached協(xié)議。 由于我們將僅使用Redis，因此此設(shè)置應(yīng)設(shè)置為true 。 默認(rèn)為false 。
例	redis：是的

表4

設(shè)置	auto_eject_hosts：true | 假
描述	一個(gè)布爾值，它控制服務(wù)器連續(xù)失敗server_failure_limit次后是否應(yīng)暫時(shí)退出服務(wù)器。 默認(rèn)為false 。
例	auto_eject_hosts：否

表5

設(shè)置	server_retry_timeout：<毫秒>
描述	當(dāng)auto_eject_host設(shè)置為true時(shí)，在臨時(shí)彈出的服務(wù)器上重試之前等待的超時(shí)值（以毫秒為單位）。 默認(rèn)值為30000毫秒。
例	server_retry_timeout：30000

表6

設(shè)置	server_failure_limit：<數(shù)字>
描述	當(dāng)auto_eject_host設(shè)置為true時(shí)，服務(wù)器上導(dǎo)致其暫時(shí)退出的連續(xù)失敗次數(shù)。 默認(rèn)為2 。
例	server_failure_limit：2

表7

設(shè)置	服務(wù)器： – 名稱：端口：重量| ip：端口：重量 – 名稱：端口：重量| ip：端口：重量
描述	特定服務(wù)器池的服務(wù)器地址，端口和權(quán)重（ name:port:weight或ip:port:weight)的列表。
例	服務(wù)器： – 127.0.0.1:6379:1 – 127.0.0.1:6380:1

表8

我們將使用三個(gè)Redis實(shí)例（服務(wù)器池）構(gòu)建一個(gè)簡(jiǎn)單的拓?fù)?#xff0c;并在它們前面配置twemproxy （ nutcracker ），如下圖所示：

圖1. Twemproxy和Redis服務(wù)器池配置由三個(gè)實(shí)例組成

twemproxy （ nutcracker ）發(fā)行版中的conf/nutcracker.yml文件是尋找不同配置示例的良好起點(diǎn)。 至于示范，我們將與下面開始sharded服務(wù)器池，反映了上面顯示的拓?fù)浣Y(jié)構(gòu)。

文件nutcracker-sharded.yml ：

sharded:listen: 127.0.0.1:22122hash: fnv1a_64distribution: ketamaauto_eject_hosts: trueredis: trueserver_retry_timeout: 2000server_failure_limit: 2servers:- 127.0.0.1:6380:1- 127.0.0.1:6381:1- 127.0.0.1:6382:1

在sharded服務(wù)器池使用ketama與關(guān)鍵散列器設(shè)置為密鑰分發(fā)一致性哈希fnv1a_64 。

在開始之前twemproxy （ nutcracker ），我們應(yīng)該有三個(gè)Redis的情況下，并在端口6380，6381和6382上運(yùn)行。

redis-server --port 6380 redis-server --port 6381 redis-server --port 6382

之后，可以使用以下命令啟動(dòng)帶有示例配置的twemproxy （ nutcracker ）實(shí)例：

nutcracker -c nutcracker-sharded.yml

圖2. Twemproxy（胡桃夾子）已成功啟動(dòng)

驗(yàn)證分片（分區(qū)）操作的最簡(jiǎn)單方法是連接到twemproxy （ nutcracker ），存儲(chǔ)一對(duì)鍵/值對(duì)，然后嘗試從每個(gè)Redis實(shí)例中獲取所有存儲(chǔ)的鍵：每個(gè)鍵應(yīng)返回一個(gè)且只有一個(gè)例如，其他人應(yīng)該返回（ nil ）。 雖然，從twemproxy （ nutcracker ）查詢相同的鍵將始終twemproxy先前存儲(chǔ)的值。 根據(jù)我們的樣本配置， twemproxy （ nutcracker ）正在偵聽端口22122 ，可以使用常規(guī)redis-cli工具進(jìn)行連接。 三個(gè)鍵userkey ， somekey和anotherkey將設(shè)置為一些值。

圖3.在Twemproxy（胡桃夾子）中設(shè)置幾個(gè)鍵/值對(duì)并驗(yàn)證它們是否已存儲(chǔ)

現(xiàn)在，如果我們從twemproxy （ nutcracker ）服務(wù)器池中查詢每個(gè)單獨(dú)的Redis實(shí)例，則某些實(shí)例（而不是其他實(shí)例）將解析某些鍵（ userkey ， somekey ， anotherkey ）。

圖4. Redis＃1沒有存儲(chǔ)密鑰

圖5. Redis的＃2僅具有一個(gè)鍵userkey存儲(chǔ)

圖6. Redis＃3有兩個(gè)一個(gè)密鑰，一個(gè)是somekey ， anotherkey另一個(gè)key

可能會(huì)提出一個(gè)有趣的問題：為什么密鑰以這種方式存儲(chǔ)？ 答案是配置的hash function ：密鑰在服務(wù)器池中的所有Redis實(shí)例中一致地分布。 但是，為了獲得平衡（均勻或隨機(jī)）的分布，應(yīng)根據(jù)應(yīng)用程序使用的鍵命名模式非常仔細(xì)地選擇配置的hash function 。 如我們的示例所示，密鑰并非在所有實(shí)例中均勻分布（第一個(gè)實(shí)例沒有任何內(nèi)容，第二個(gè)實(shí)例有一個(gè)密鑰，第三個(gè)實(shí)例有兩個(gè)密鑰）。

最后的注意事項(xiàng)：盡管twemproxy （ nutcracker ）確實(shí)支持Redis協(xié)議，但由于“ 何時(shí)使用分片（分區(qū)）”部分中討論的限制，因此不支持所有命令。

有關(guān)twemproxy （ nutcracker ）的更多詳細(xì)信息，請(qǐng)參閱https://github.com/twitter/twemproxy ，它提供了許多不錯(cuò)的最新文檔。

8.接下來

在本節(jié)中，我們僅介紹了一種如何在Redis中處理分片（分區(qū)）的方法。 接下來的第5部分 ， Redis群集 ，我們將發(fā)現(xiàn)替代解決方案。

翻譯自: https://www.javacodegeeks.com/2015/09/redis-sharding.html

redis分片

總結(jié)

以上是生活随笔為你收集整理的redis分片_Redis分片的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。