當前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

redis分片_Redis分片

發(fā)布時間：2023/12/3 数据库 54 豆豆

生活随笔收集整理的這篇文章主要介紹了 redis分片_Redis分片小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

redis分片

本文是我們學院課程的一部分，標題為Redis NoSQL鍵值存儲。

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

1.簡介

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

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

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

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

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

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

使用多臺計算機的內存來管理更大的數據庫（否??則，您將受限于單臺計算機可以支持的內存量）
擴展多個CPU，多個計算機的計算能力，并利用它們的網絡帶寬

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

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

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

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

范圍劃分
通過將對象范圍映射到特定的Redis實例中來完成。例如，假設我們正在存儲一些用戶數據，并且每個用戶都有其唯一的標識符（ID）。在我們的分區(qū)方案中，我們可以定義ID從0到10000的用戶將進入實例Redis 1，而ID從10001到20000的用戶將進入實例Redis 2，依此類推。該方案的缺點是，范圍和實例之間的映射應該被維護，并且應該與Redis中保留的對象（用戶，產品等）的種類一樣多的映射。
哈希分區(qū)
該方案適用于任何密鑰，但涉及哈希函數：此函數應將密鑰名稱映射到某個數字。假設我們有這樣一個函數（我們稱其為hash_func ），這樣的方案就是這樣的：
- 取得鍵名，并使用hash_func將其映射到數字
哈希函數的選擇非常重要。良好的哈希函數可確保密鑰在所有Redis實例上平均分布，因此不會在任何單個實例上建立過多的密鑰。
一致性哈希
它是hash partitioning的一種高級形式，被許多解決方案用于數據分片（分區(qū)）。

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

從實現的角度來看，根據應用程序的體系結構，有幾種可能的數據分片（分區(qū)）實現：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

構建（您需要的唯一預裝軟件包是gcc和make ）。 cd nutcracker-0.3.0 ./configure make

安裝 sudo make install

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

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

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

表格1

設置

哈希：<功能>

描述

哈希函數的名稱。可能的值為：

- 一次一個

– md5（ http://en.wikipedia.org/wiki/MD5 ）

– crc16（ http://en.wikipedia.org/wiki/Cyclic_redundancy_check ）

– crc32（與libmemcached兼容的crc32實現）

– crc32a（根據規(guī)范正確的crc32實現）

– 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

設置

分布：<模式>

描述

密鑰分發(fā)模式（請參閱http://en.wikipedia.org/wiki/Consistent_hashing ）。可能的值為：

–凱塔瑪

–模數

–隨機

例

分布：ketama

表3

設置	redis：是\|否
描述	一個布爾值，它控制服務器池是否使用Redis或Memcached協議。由于我們將僅使用Redis，因此此設置應設置為true 。默認為false 。
例	redis：是的

表4

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

表5

設置	server_retry_timeout：<毫秒>
描述	當auto_eject_host設置為true時，在臨時彈出的服務器上重試之前等待的超時值（以毫秒為單位）。默認值為30000毫秒。
例	server_retry_timeout：30000

表6

設置	server_failure_limit：<數字>
描述	當auto_eject_host設置為true時，服務器上導致其暫時退出的連續(xù)失敗次數。默認為2 。
例	server_failure_limit：2

表7

設置

服務器：

– 名稱：端口：重量| ip：端口：重量

描述

特定服務器池的服務器地址，端口和權重（ name:port:weight或ip:port:weight)的列表。

例

服務器：

– 127.0.0.1:6379:1

– 127.0.0.1:6380:1

表8

我們將使用三個Redis實例（服務器池）構建一個簡單的拓撲，并在它們前面配置twemproxy （ nutcracker ），如下圖所示：

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

twemproxy （ nutcracker ）發(fā)行版中的conf/nutcracker.yml文件是尋找不同配置示例的良好起點。至于示范，我們將與下面開始sharded服務器池，反映了上面顯示的拓撲結構。

文件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服務器池使用ketama與關鍵散列器設置為密鑰分發(fā)一致性哈希fnv1a_64 。

在開始之前twemproxy （ nutcracker ），我們應該有三個Redis的情況下，并在端口6380，6381和6382上運行。

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實例中獲取所有存儲的鍵：每個鍵應返回一個且只有一個例如，其他人應該返回（ nil ）。雖然，從twemproxy （ nutcracker ）查詢相同的鍵將始終twemproxy先前存儲的值。根據我們的樣本配置， twemproxy （ nutcracker ）正在偵聽端口22122 ，可以使用常規(guī)redis-cli工具進行連接。三個鍵userkey ， somekey和anotherkey將設置為一些值。

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

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

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

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

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

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

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

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

8.接下來

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

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