redis分片

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

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

目錄

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

1.簡介

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

下載 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 。 安裝后，最重要（但是非常簡單）的部分是其配置。

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ù)的名稱。 可能的值為： - 一次一個 – md5（ http://en.wikipedia.org/wiki/MD5 ） – crc16（ http://en.wikipedia.org/wiki/Cyclic_redundancy_check ） – crc32（與libmemcached兼容的crc32實現(xiàn)） – crc32a（根據(jù)規(guī)范正確的crc32實現(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ā)模式（請參閱http://en.wikipedia.org/wiki/Consistent_hashing ）。 可能的值為： –凱塔瑪 –模數(shù) –隨機(jī)
例	分布：ketama

表3

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

表4

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

表5

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

表6

設(shè)置	server_failure_limit：<數(shù)字>
描述	當(dāng)auto_eject_host設(shè)置為true時，服務(wù)器上導(dǎo)致其暫時退出的連續(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

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

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

twemproxy （ nutcracker ）發(fā)行版中的conf/nutcracker.yml文件是尋找不同配置示例的良好起點。 至于示范，我們將與下面開始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)該有三個Redis的情況下，并在端口6380，6381和6382上運(yùn)行。

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

之后，可以使用以下命令啟動帶有示例配置的twemproxy （ nutcracker ）實例：

nutcracker -c nutcracker-sharded.yml

圖2. Twemproxy（胡桃夾子）已成功啟動

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

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

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

圖4. Redis＃1沒有存儲密鑰

圖5. Redis的＃2僅具有一個鍵userkey存儲

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

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

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

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

8.接下來

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

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

redis分片

總結(jié)

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

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