Redis

本文將從Redis的基本特性入手，通過講述Redis的數(shù)據(jù)結(jié)構(gòu)和主要命令對Redis的基本能力進行直觀介紹化焕。之后概覽Redis提供的高級能力，并在部署熙参、維護析命、性能調(diào)優(yōu)等多個方面進行更深入的介紹和指導(dǎo)。
本文適合使用Redis的普通開發(fā)人員工育，以及對Redis進行選型虾宇、架構(gòu)設(shè)計和性能調(diào)優(yōu)的架構(gòu)設(shè)計人員。

目錄

• 概述
• Redis的數(shù)據(jù)結(jié)構(gòu)和相關(guān)常用命令
• 數(shù)據(jù)持久化
• 內(nèi)存管理與數(shù)據(jù)淘汰機制
• Pipelining
• 事務(wù)與Scripting
• Redis性能調(diào)優(yōu)
• 主從復(fù)制與集群分片
• Redis Java客戶端的選擇

概述

Redis是一個開源的如绸，基于內(nèi)存的結(jié)構(gòu)化數(shù)據(jù)存儲媒介嘱朽，可以作為數(shù)據(jù)庫、緩存服務(wù)或消息服務(wù)使用怔接。
Redis支持多種數(shù)據(jù)結(jié)構(gòu)搪泳，包括字符串、哈希表扼脐、鏈表岸军、集合奋刽、有序集合、位圖艰赞、Hyperloglogs等佣谐。
Redis具備LRU淘汰、事務(wù)實現(xiàn)方妖、以及不同級別的硬盤持久化等能力狭魂，并且支持副本集和通過Redis Sentinel實現(xiàn)的高可用方案，同時還支持通過Redis Cluster實現(xiàn)的數(shù)據(jù)自動分片能力党觅。

Redis的主要功能都基于單線程模型實現(xiàn)雌澄，也就是說Redis使用一個線程來服務(wù)所有的客戶端請求，同時Redis采用了非阻塞式IO杯瞻，并精細地優(yōu)化各種命令的算法時間復(fù)雜度掷伙，這些信息意味著：

• Redis是線程安全的（因為只有一個線程），其所有操作都是原子的又兵，不會因并發(fā)產(chǎn)生數(shù)據(jù)異常
• Redis的速度非橙喂瘢快（因為使用非阻塞式IO，且大部分命令的算法時間復(fù)雜度都是O(1))
• 使用高耗時的Redis命令是很危險的沛厨，會占用唯一的一個線程的大量處理時間宙地，導(dǎo)致所有的請求都被拖慢。（例如時間復(fù)雜度為O(N)的KEYS命令逆皮，嚴格禁止在生產(chǎn)環(huán)境中使用）

Redis的數(shù)據(jù)結(jié)構(gòu)和相關(guān)常用命令

本節(jié)中將介紹Redis支持的主要數(shù)據(jù)結(jié)構(gòu)宅粥，以及相關(guān)的常用Redis命令。本節(jié)只對Redis命令進行扼要的介紹电谣，且只列出了較常用的命令秽梅。如果想要了解完整的Redis命令集，或了解某個命令的詳細使用方法剿牺，請參考官方文檔：https://redis.io/commands

Key

Redis采用Key-Value型的基本數(shù)據(jù)結(jié)構(gòu)企垦，任何二進制序列都可以作為Redis的Key使用（例如普通的字符串或一張JPEG圖片）
關(guān)于Key的一些注意事項：

• 不要使用過長的Key。例如使用一個1024字節(jié)的key就不是一個好主意晒来，不僅會消耗更多的內(nèi)存钞诡，還會導(dǎo)致查找的效率降低
• Key短到缺失了可讀性也是不好的，例如"u1000flw"比起"user:1000:followers"來說湃崩，節(jié)省了寥寥的存儲空間荧降，卻引發(fā)了可讀性和可維護性上的麻煩
• 最好使用統(tǒng)一的規(guī)范來設(shè)計Key，比如"object-type:id:attr"攒读，以這一規(guī)范設(shè)計出的Key可能是"user:1000"或"comment:1234:reply-to"
• Redis允許的最大Key長度是512MB（對Value的長度限制也是512MB）

String

String是Redis的基礎(chǔ)數(shù)據(jù)類型朵诫，Redis沒有Int、Float薄扁、Boolean等數(shù)據(jù)類型的概念剪返，所有的基本類型在Redis中都以String體現(xiàn)瞎领。

與String相關(guān)的常用命令：

• SET：為一個key設(shè)置value，可以配合EX/PX參數(shù)指定key的有效期随夸，通過NX/XX參數(shù)針對key是否存在的情況進行區(qū)別操作九默，時間復(fù)雜度O(1)
• GET：獲取某個key對應(yīng)的value，時間復(fù)雜度O(1)
• GETSET：為一個key設(shè)置value宾毒，并返回該key的原value驼修，時間復(fù)雜度O(1)
• MSET：為多個key設(shè)置value，時間復(fù)雜度O(N)
• MSETNX：同MSET诈铛，如果指定的key中有任意一個已存在乙各，則不進行任何操作，時間復(fù)雜度O(N)
• MGET：獲取多個key對應(yīng)的value幢竹，時間復(fù)雜度O(N)

上文提到過耳峦，Redis的基本數(shù)據(jù)類型只有String，但Redis可以把String作為整型或浮點型數(shù)字來使用焕毫，主要體現(xiàn)在INCR蹲坷、DECR類的命令上：

• INCR：將key對應(yīng)的value值自增1，并返回自增后的值邑飒。只對可以轉(zhuǎn)換為整型的String數(shù)據(jù)起作用循签。時間復(fù)雜度O(1)
• INCRBY：將key對應(yīng)的value值自增指定的整型數(shù)值，并返回自增后的值疙咸。只對可以轉(zhuǎn)換為整型的String數(shù)據(jù)起作用县匠。時間復(fù)雜度O(1)
• DECR/DECRBY：同INCR/INCRBY，自增改為自減撒轮。

INCR/DECR系列命令要求操作的value類型為String乞旦，并可以轉(zhuǎn)換為64位帶符號的整型數(shù)字，否則會返回錯誤题山。
也就是說兰粉，進行INCR/DECR系列命令的value，必須在[-2^63 ~ 2^63 - 1]范圍內(nèi)臀蛛。

前文提到過亲桦，Redis采用單線程模型，天然是線程安全的浊仆，這使得INCR/DECR命令可以非常便利的實現(xiàn)高并發(fā)場景下的精確控制。

例1：庫存控制

在高并發(fā)場景下實現(xiàn)庫存余量的精準校驗豫领，確保不出現(xiàn)超賣的情況抡柿。

設(shè)置庫存總量：

SET inv:remain "100"

庫存扣減+余量校驗：

DECR inv:remain

當DECR命令返回值大于等于0時，說明庫存余量校驗通過等恐，如果返回小于0的值洲劣，則說明庫存已耗盡备蚓。

假設(shè)同時有300個并發(fā)請求進行庫存扣減，Redis能夠確保這300個請求分別得到99到-200的返回值囱稽，每個請求得到的返回值都是唯一的，絕對不會找出現(xiàn)兩個請求得到一樣的返回值的情況战惊。

例2：自增序列生成

實現(xiàn)類似于RDBMS的Sequence功能流昏，生成一系列唯一的序列號

設(shè)置序列起始值：

SET sequence "10000"

獲取一個序列值：

INCR sequence

直接將返回值作為序列使用即可。

獲取一批（如100個）序列值：

INCRBY sequence 100

假設(shè)返回值為N吞获，那么[N - 99 ~ N]的數(shù)值都是可用的序列值况凉。

當多個客戶端同時向Redis申請自增序列時，Redis能夠確保每個客戶端得到的序列值或序列范圍都是全局唯一的各拷，絕對不會出現(xiàn)不同客戶端得到了重復(fù)的序列值的情況刁绒。

List

Redis的List是鏈表型的數(shù)據(jù)結(jié)構(gòu)，可以使用LPUSH/RPUSH/LPOP/RPOP等命令在List的兩端執(zhí)行插入元素和彈出元素的操作烤黍。雖然List也支持在特定index上插入和讀取元素的功能知市，但其時間復(fù)雜度較高（O(N)），應(yīng)小心使用速蕊。

與List相關(guān)的常用命令：

• LPUSH：向指定List的左側(cè)（即頭部）插入1個或多個元素初狰，返回插入后的List長度。時間復(fù)雜度O(N)互例，N為插入元素的數(shù)量
• RPUSH：同LPUSH奢入，向指定List的右側(cè)（即尾部）插入1或多個元素
• LPOP：從指定List的左側(cè)（即頭部）移除一個元素并返回，時間復(fù)雜度O(1)
• RPOP：同LPOP媳叨，從指定List的右側(cè)（即尾部）移除1個元素并返回
• LPUSHX/RPUSHX：與LPUSH/RPUSH類似腥光，區(qū)別在于，LPUSHX/RPUSHX操作的key如果不存在糊秆，則不會進行任何操作
• LLEN：返回指定List的長度武福，時間復(fù)雜度O(1)
• LRANGE：返回指定List中指定范圍的元素（雙端包含，即LRANGE key 0 10會返回11個元素）痘番，時間復(fù)雜度O(N)捉片。應(yīng)盡可能控制一次獲取的元素數(shù)量，一次獲取過大范圍的List元素會導(dǎo)致延遲汞舱，同時對長度不可預(yù)知的List伍纫，避免使用LRANGE key 0 -1這樣的完整遍歷操作。

應(yīng)謹慎使用的List相關(guān)命令：

• LINDEX：返回指定List指定index上的元素昂芜，如果index越界莹规，返回nil。index數(shù)值是回環(huán)的泌神，即-1代表List最后一個位置良漱，-2代表List倒數(shù)第二個位置舞虱。時間復(fù)雜度O(N)
• LSET：將指定List指定index上的元素設(shè)置為value，如果index越界則返回錯誤母市，時間復(fù)雜度O(N)矾兜，如果操作的是頭/尾部的元素，則時間復(fù)雜度為O(1)
• LINSERT：向指定List中指定元素之前/之后插入一個新元素患久，并返回操作后的List長度椅寺。如果指定的元素不存在，返回-1墙杯。如果指定key不存在配并，不會進行任何操作，時間復(fù)雜度O(N)

由于Redis的List是鏈表結(jié)構(gòu)的高镐，上述的三個命令的算法效率較低溉旋，需要對List進行遍歷，命令的耗時無法預(yù)估嫉髓，在List長度大的情況下耗時會明顯增加观腊，應(yīng)謹慎使用。

換句話說算行，Redis的List實際是設(shè)計來用于實現(xiàn)隊列梧油，而不是用于實現(xiàn)類似ArrayList這樣的列表的。如果你不是想要實現(xiàn)一個雙端出入的隊列州邢，那么請盡量不要使用Redis的List數(shù)據(jù)結(jié)構(gòu)儡陨。

為了更好支持隊列的特性，Redis還提供了一系列阻塞式的操作命令量淌，如BLPOP/BRPOP等骗村，能夠?qū)崿F(xiàn)類似于BlockingQueue的能力，即在List為空時呀枢，阻塞該連接胚股，直到List中有對象可以出隊時再返回。針對阻塞類的命令裙秋，此處不做詳細探討琅拌，請參考官方文檔（https://redis.io/topics/data-types-intro） 中"Blocking operations on lists"一節(jié)。

Hash

Hash即哈希表摘刑，Redis的Hash和傳統(tǒng)的哈希表一樣进宝，是一種field-value型的數(shù)據(jù)結(jié)構(gòu)，可以理解成將HashMap搬入Redis泣侮。
Hash非常適合用于表現(xiàn)對象類型的數(shù)據(jù)即彪，用Hash中的field對應(yīng)對象的field即可。
Hash的優(yōu)點包括：

• 可以實現(xiàn)二元查找活尊，如"查找ID為1000的用戶的年齡"
• 比起將整個對象序列化后作為String存儲的方法隶校，Hash能夠有效地減少網(wǎng)絡(luò)傳輸?shù)南?/li>
• 當使用Hash維護一個集合時，提供了比List效率高得多的隨機訪問命令

與Hash相關(guān)的常用命令：

• HSET：將key對應(yīng)的Hash中的field設(shè)置為value蛹锰。如果該Hash不存在深胳，會自動創(chuàng)建一個。時間復(fù)雜度O(1)
• HGET：返回指定Hash中field字段的值铜犬，時間復(fù)雜度O(1)
• HMSET/HMGET：同HSET和HGET舞终，可以批量操作同一個key下的多個field，時間復(fù)雜度：O(N)癣猾，N為一次操作的field數(shù)量
• HSETNX：同HSET敛劝，但如field已經(jīng)存在，HSETNX不會進行任何操作纷宇，時間復(fù)雜度O(1)
• HEXISTS：判斷指定Hash中field是否存在夸盟，存在返回1，不存在返回0像捶，時間復(fù)雜度O(1)
• HDEL：刪除指定Hash中的field（1個或多個）上陕，時間復(fù)雜度：O(N)，N為操作的field數(shù)量
• HINCRBY：同INCRBY命令拓春，對指定Hash中的一個field進行INCRBY释簿，時間復(fù)雜度O(1)

應(yīng)謹慎使用的Hash相關(guān)命令：

• HGETALL：返回指定Hash中所有的field-value對。返回結(jié)果為數(shù)組硼莽，數(shù)組中field和value交替出現(xiàn)庶溶。時間復(fù)雜度O(N)
• HKEYS/HVALS：返回指定Hash中所有的field/value，時間復(fù)雜度O(N)

上述三個命令都會對Hash進行完整遍歷懂鸵，Hash中的field數(shù)量與命令的耗時線性相關(guān)偏螺，對于尺寸不可預(yù)知的Hash，應(yīng)嚴格避免使用上面三個命令矾瑰，而改為使用HSCAN命令進行游標式的遍歷砖茸，具體請見 https://redis.io/commands/scan

Set

Redis Set是無序的，不可重復(fù)的String集合殴穴。

與Set相關(guān)的常用命令：

• SADD：向指定Set中添加1個或多個member凉夯，如果指定Set不存在，會自動創(chuàng)建一個采幌。時間復(fù)雜度O(N)劲够，N為添加的member個數(shù)
• SREM：從指定Set中移除1個或多個member，時間復(fù)雜度O(N)休傍，N為移除的member個數(shù)
• SRANDMEMBER：從指定Set中隨機返回1個或多個member征绎，時間復(fù)雜度O(N)，N為返回的member個數(shù)
• SPOP：從指定Set中隨機移除并返回count個member，時間復(fù)雜度O(N)人柿，N為移除的member個數(shù)
• SCARD：返回指定Set中的member個數(shù)柴墩，時間復(fù)雜度O(1)
• SISMEMBER：判斷指定的value是否存在于指定Set中，時間復(fù)雜度O(1)
• SMOVE：將指定member從一個Set移至另一個Set

慎用的Set相關(guān)命令：

• SMEMBERS：返回指定Hash中所有的member凫岖，時間復(fù)雜度O(N)
• SUNION/SUNIONSTORE：計算多個Set的并集并返回/存儲至另一個Set中江咳，時間復(fù)雜度O(N)，N為參與計算的所有集合的總member數(shù)
• SINTER/SINTERSTORE：計算多個Set的交集并返回/存儲至另一個Set中哥放，時間復(fù)雜度O(N)歼指，N為參與計算的所有集合的總member數(shù)
• SDIFF/SDIFFSTORE：計算1個Set與1或多個Set的差集并返回/存儲至另一個Set中，時間復(fù)雜度O(N)甥雕，N為參與計算的所有集合的總member數(shù)

上述幾個命令涉及的計算量大踩身，應(yīng)謹慎使用，特別是在參與計算的Set尺寸不可知的情況下社露，應(yīng)嚴格避免使用挟阻。可以考慮通過SSCAN命令遍歷獲取相關(guān)Set的全部member（具體請見 https://redis.io/commands/scan ）呵哨，如果需要做并集/交集/差集計算赁濒，可以在客戶端進行，或在不服務(wù)實時查詢請求的Slave上進行孟害。

Sorted Set

Redis Sorted Set是有序的拒炎、不可重復(fù)的String集合。Sorted Set中的每個元素都需要指派一個分數(shù)(score)挨务，Sorted Set會根據(jù)score對元素進行升序排序击你。如果多個member擁有相同的score，則以字典序進行升序排序谎柄。

Sorted Set非常適合用于實現(xiàn)排名丁侄。

Sorted Set的主要命令：

• ZADD：向指定Sorted Set中添加1個或多個member，時間復(fù)雜度O(Mlog(N))朝巫，M為添加的member數(shù)量鸿摇，N為Sorted Set中的member數(shù)量
• ZREM：從指定Sorted Set中刪除1個或多個member，時間復(fù)雜度O(Mlog(N))劈猿，M為刪除的member數(shù)量拙吉，N為Sorted Set中的member數(shù)量
• ZCOUNT：返回指定Sorted Set中指定score范圍內(nèi)的member數(shù)量，時間復(fù)雜度：O(log(N))
• ZCARD：返回指定Sorted Set中的member數(shù)量揪荣，時間復(fù)雜度O(1)
• ZSCORE：返回指定Sorted Set中指定member的score筷黔，時間復(fù)雜度O(1)
• ZRANK/ZREVRANK：返回指定member在Sorted Set中的排名，ZRANK返回按升序排序的排名仗颈，ZREVRANK則返回按降序排序的排名佛舱。時間復(fù)雜度O(log(N))
• ZINCRBY：同INCRBY，對指定Sorted Set中的指定member的score進行自增，時間復(fù)雜度O(log(N))

慎用的Sorted Set相關(guān)命令：

• ZRANGE/ZREVRANGE：返回指定Sorted Set中指定排名范圍內(nèi)的所有member请祖，ZRANGE為按score升序排序订歪，ZREVRANGE為按score降序排序陌粹，時間復(fù)雜度O(log(N)+M)撒犀，M為本次返回的member數(shù)
• ZRANGEBYSCORE/ZREVRANGEBYSCORE：返回指定Sorted Set中指定score范圍內(nèi)的所有member福压，返回結(jié)果以升序/降序排序，min和max可以指定為-inf和+inf或舞，代表返回所有的member荆姆。時間復(fù)雜度O(log(N)+M)
• ZREMRANGEBYRANK/ZREMRANGEBYSCORE：移除Sorted Set中指定排名范圍/指定score范圍內(nèi)的所有member。時間復(fù)雜度O(log(N)+M)

上述幾個命令映凳，應(yīng)盡量避免傳遞[0 -1]或[-inf +inf]這樣的參數(shù)胆筒，來對Sorted Set做一次性的完整遍歷，特別是在Sorted Set的尺寸不可預(yù)知的情況下诈豌∑途龋可以通過ZSCAN命令來進行游標式的遍歷（具體請見 https://redis.io/commands/scan ），或通過LIMIT參數(shù)來限制返回member的數(shù)量（適用于ZRANGEBYSCORE和ZREVRANGEBYSCORE命令）矫渔，以實現(xiàn)游標式的遍歷彤蔽。

Bitmap和HyperLogLog

Redis的這兩種數(shù)據(jù)結(jié)構(gòu)相較之前的并不常用，在本文中只做簡要介紹庙洼，如想要詳細了解這兩種數(shù)據(jù)結(jié)構(gòu)與其相關(guān)的命令顿痪，請參考官方文檔https://redis.io/topics/data-types-intro 中的相關(guān)章節(jié)

Bitmap在Redis中不是一種實際的數(shù)據(jù)類型，而是一種將String作為Bitmap使用的方法油够∫舷可以理解為將String轉(zhuǎn)換為bit數(shù)組。使用Bitmap來存儲true/false類型的簡單數(shù)據(jù)極為節(jié)省空間石咬。

HyperLogLogs是一種主要用于數(shù)量統(tǒng)計的數(shù)據(jù)結(jié)構(gòu)揩悄，它和Set類似删性，維護一個不可重復(fù)的String集合厦章，但是HyperLogLogs并不維護具體的member內(nèi)容汗侵，只維護member的個數(shù)发乔。也就是說栏尚，HyperLogLogs只能用于計算一個集合中不重復(fù)的元素數(shù)量，所以它比Set要節(jié)省很多內(nèi)存空間纵菌。

其他常用命令

• EXISTS：判斷指定的key是否存在，返回1代表存在序苏，0代表不存在，時間復(fù)雜度O(1)
• DEL：刪除指定的key及其對應(yīng)的value踱阿，時間復(fù)雜度O(N)，N為刪除的key數(shù)量
• EXPIRE/PEXPIRE：為一個key設(shè)置有效期佛点，單位為秒或毫秒超营，時間復(fù)雜度O(1)
• TTL/PTTL：返回一個key剩余的有效時間，單位為秒或毫秒米碰，時間復(fù)雜度O(1)
• RENAME/RENAMENX：將key重命名為newkey虐译。使用RENAME時，如果newkey已經(jīng)存在厢拭，其值會被覆蓋；使用RENAMENX時，如果newkey已經(jīng)存在正林，則不會進行任何操作，時間復(fù)雜度O(1)
• TYPE：返回指定key的類型杈绸，string, list, set, zset, hash瞳脓。時間復(fù)雜度O(1)
• CONFIG GET：獲得Redis某配置項的當前值，可以使用*通配符，時間復(fù)雜度O(1)
• CONFIG SET：為Redis某個配置項設(shè)置新值审姓，時間復(fù)雜度O(1)
• CONFIG REWRITE：讓Redis重新加載redis.conf中的配置

數(shù)據(jù)持久化

Redis提供了將數(shù)據(jù)定期自動持久化至硬盤的能力次坡，包括RDB和AOF兩種方案砸琅，兩種方案分別有其長處和短板淫僻，可以配合起來同時運行棕所，確保數(shù)據(jù)的穩(wěn)定性。

必須使用數(shù)據(jù)持久化嗎？

Redis的數(shù)據(jù)持久化機制是可以關(guān)閉的桦他。如果你只把Redis作為緩存服務(wù)使用快压，Redis中存儲的所有數(shù)據(jù)都不是該數(shù)據(jù)的主體而僅僅是同步過來的備份皆警，那么可以關(guān)閉Redis的數(shù)據(jù)持久化機制鸵隧。
但通常來說，仍然建議至少開啟RDB方式的數(shù)據(jù)持久化外驱，因為：

• RDB方式的持久化幾乎不損耗Redis本身的性能磅崭，在進行RDB持久化時蒋譬，Redis主進程唯一需要做的事情就是fork出一個子進程癣漆，所有持久化工作都由子進程完成
• Redis無論因為什么原因crash掉之后，重啟時能夠自動恢復(fù)到上一次RDB快照中記錄的數(shù)據(jù)。這省去了手工從其他數(shù)據(jù)源（如DB）同步數(shù)據(jù)的過程，而且要比其他任何的數(shù)據(jù)恢復(fù)方式都要快
• 現(xiàn)在硬盤那么大附井，真的不缺那一點地方

RDB

采用RDB持久方式讨越，Redis會定期保存數(shù)據(jù)快照至一個rbd文件中，并在啟動時自動加載rdb文件永毅，恢復(fù)之前保存的數(shù)據(jù)把跨。可以在配置文件中配置Redis進行快照保存的時機：

save [seconds] [changes]

意為在[seconds]秒內(nèi)如果發(fā)生了[changes]次數(shù)據(jù)修改沼死，則進行一次RDB快照保存，例如

save 60 100

會讓Redis每60秒檢查一次數(shù)據(jù)變更情況秀姐，如果發(fā)生了100次或以上的數(shù)據(jù)變更伸头，則進行RDB快照保存锌妻。
可以配置多條save指令擂橘，讓Redis執(zhí)行多級的快照保存策略茎用。
Redis默認開啟RDB快照蒿褂，默認的RDB策略如下：

save 900 1
save 300 10
save 60 10000

也可以通過BGSAVE命令手工觸發(fā)RDB快照保存诈嘿。

RDB的優(yōu)點：

• 對性能影響最小作郭。如前文所述，Redis在保存RDB快照時會fork出子進程進行，幾乎不影響Redis處理客戶端請求的效率午绳。
• 每次快照會生成一個完整的數(shù)據(jù)快照文件据忘，所以可以輔以其他手段保存多個時間點的快照（例如把每天0點的快照備份至其他存儲媒介中），作為非辰咭担可靠的災(zāi)難恢復(fù)手段咐柜。
• 使用RDB文件進行數(shù)據(jù)恢復(fù)比使用AOF要快很多拙友。

RDB的缺點：

• 快照是定期生成的，所以在Redis crash時或多或少會丟失一部分數(shù)據(jù)其做。
• 如果數(shù)據(jù)集非常大且CPU不夠強（比如單核CPU），Redis在fork子進程時可能會消耗相對較長的時間（長至1秒）凛剥，影響這期間的客戶端請求侠仇。

AOF

采用AOF持久方式時，Redis會把每一個寫請求都記錄在一個日志文件里犁珠。在Redis重啟時傅瞻，會把AOF文件中記錄的所有寫操作順序執(zhí)行一遍，確保數(shù)據(jù)恢復(fù)到最新盲憎。

AOF默認是關(guān)閉的，如要開啟胳挎，進行如下配置：

appendonly yes

AOF提供了三種fsync配置饼疙，always/everysec/no，通過配置項[appendfsync]指定：

• appendfsync no：不進行fsync，將flush文件的時機交給OS決定窑眯，速度最快
• appendfsync always：每寫入一條日志就進行一次fsync操作屏积，數(shù)據(jù)安全性最高，但速度最慢
• appendfsync everysec：折中的做法磅甩，交由后臺線程每秒fsync一次

隨著AOF不斷地記錄寫操作日志炊林，必定會出現(xiàn)一些無用的日志，例如某個時間點執(zhí)行了命令SET key1 "abc"卷要，在之后某個時間點又執(zhí)行了SET key1 "bcd"渣聚，那么第一條命令很顯然是沒有用的。大量的無用日志會讓AOF文件過大僧叉，也會讓數(shù)據(jù)恢復(fù)的時間過長奕枝。
所以Redis提供了AOF rewrite功能，可以重寫AOF文件瓶堕，只保留能夠把數(shù)據(jù)恢復(fù)到最新狀態(tài)的最小寫操作集隘道。
AOF rewrite可以通過BGREWRITEAOF命令觸發(fā)爱沟，也可以配置Redis定期自動進行：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

上面兩行配置的含義是潭辈，Redis在每次AOF rewrite時，會記錄完成rewrite后的AOF日志大小旅赢，當AOF日志大小在該基礎(chǔ)上增長了100%后宛蚓，自動進行AOF rewrite激捏。同時如果增長的大小沒有達到64mb，則不會進行rewrite苍息。

AOF的優(yōu)點：

• 最安全缩幸，在啟用appendfsync always時，任何已寫入的數(shù)據(jù)都不會丟失竞思，使用在啟用appendfsync everysec也至多只會丟失1秒的數(shù)據(jù)表谊。
• AOF文件在發(fā)生斷電等問題時也不會損壞，即使出現(xiàn)了某條日志只寫入了一半的情況盖喷，也可以使用redis-check-aof工具輕松修復(fù)爆办。
• AOF文件易讀，可修改课梳，在進行了某些錯誤的數(shù)據(jù)清除操作后距辆，只要AOF文件沒有rewrite，就可以把AOF文件備份出來暮刃，把錯誤的命令刪除跨算，然后恢復(fù)數(shù)據(jù)。

AOF的缺點：

• AOF文件通常比RDB文件更大
• 性能消耗比RDB高
• 數(shù)據(jù)恢復(fù)速度比RDB慢

內(nèi)存管理與數(shù)據(jù)淘汰機制

最大內(nèi)存設(shè)置

默認情況下椭懊，在32位OS中诸蚕，Redis最大使用3GB的內(nèi)存，在64位OS中則沒有限制。

在使用Redis時背犯，應(yīng)該對數(shù)據(jù)占用的最大空間有一個基本準確的預(yù)估坏瘩，并為Redis設(shè)定最大使用的內(nèi)存。否則在64位OS中Redis會無限制地占用內(nèi)存（當物理內(nèi)存被占滿后會使用swap空間）漠魏，容易引發(fā)各種各樣的問題倔矾。

通過如下配置控制Redis使用的最大內(nèi)存：

maxmemory 100mb

在內(nèi)存占用達到了maxmemory后，再向Redis寫入數(shù)據(jù)時柱锹，Redis會：

• 根據(jù)配置的數(shù)據(jù)淘汰策略嘗試淘汰數(shù)據(jù)哪自，釋放空間
• 如果沒有數(shù)據(jù)可以淘汰，或者沒有配置數(shù)據(jù)淘汰策略奕纫，那么Redis會對所有寫請求返回錯誤提陶，但讀請求仍然可以正常執(zhí)行

在為Redis設(shè)置maxmemory時，需要注意：

• 如果采用了Redis的主從同步匹层，主節(jié)點向從節(jié)點同步數(shù)據(jù)時隙笆，會占用掉一部分內(nèi)存空間，如果maxmemory過于接近主機的可用內(nèi)存升筏，導(dǎo)致數(shù)據(jù)同步時內(nèi)存不足撑柔。所以設(shè)置的maxmemory不要過于接近主機可用的內(nèi)存，留出一部分預(yù)留用作主從同步您访。

數(shù)據(jù)淘汰機制

Redis提供了5種數(shù)據(jù)淘汰策略：

• volatile-lru：使用LRU算法進行數(shù)據(jù)淘汰（淘汰上次使用時間最早的铅忿，且使用次數(shù)最少的key），只淘汰設(shè)定了有效期的key
• allkeys-lru：使用LRU算法進行數(shù)據(jù)淘汰灵汪，所有的key都可以被淘汰
• volatile-random：隨機淘汰數(shù)據(jù)檀训，只淘汰設(shè)定了有效期的key
• allkeys-random：隨機淘汰數(shù)據(jù)，所有的key都可以被淘汰
• volatile-ttl：淘汰剩余有效期最短的key

最好為Redis指定一種有效的數(shù)據(jù)淘汰策略以配合maxmemory設(shè)置享言，避免在內(nèi)存使用滿后發(fā)生寫入失敗的情況峻凫。

一般來說，推薦使用的策略是volatile-lru览露，并辨識Redis中保存的數(shù)據(jù)的重要性荧琼。對于那些重要的，絕對不能丟棄的數(shù)據(jù)（如配置類數(shù)據(jù)等）差牛，應(yīng)不設(shè)置有效期命锄，這樣Redis就永遠不會淘汰這些數(shù)據(jù)。對于那些相對不是那么重要的偏化，并且能夠熱加載的數(shù)據(jù)（比如緩存最近登錄的用戶信息脐恩，當在Redis中找不到時，程序會去DB中讀日焯帧）被盈，可以設(shè)置上有效期析孽，這樣在內(nèi)存不夠時Redis就會淘汰這部分數(shù)據(jù)。

配置方法：

maxmemory-policy volatile-lru   #默認是noeviction只怎，即不進行數(shù)據(jù)淘汰

Pipelining

Pipelining

Redis提供許多批量操作的命令，如MSET/MGET/HMSET/HMGET等等怜俐，這些命令存在的意義是減少維護網(wǎng)絡(luò)連接和傳輸數(shù)據(jù)所消耗的資源和時間身堡。
例如連續(xù)使用5次SET命令設(shè)置5個不同的key，比起使用一次MSET命令設(shè)置5個不同的key拍鲤，效果是一樣的贴谎，但前者會消耗更多的RTT(Round Trip Time)時長，永遠應(yīng)優(yōu)先使用后者季稳。

然而擅这，如果客戶端要連續(xù)執(zhí)行的多次操作無法通過Redis命令組合在一起，例如：

SET a "abc"
INCR b
HSET c name "hi"

此時便可以使用Redis提供的pipelining功能來實現(xiàn)在一次交互中執(zhí)行多條命令景鼠。
使用pipelining時仲翎，只需要從客戶端一次向Redis發(fā)送多條命令（以\r\n）分隔，Redis就會依次執(zhí)行這些命令铛漓，并且把每個命令的返回按順序組裝在一起一次返回溯香，比如：

$ (printf "PING\r\nPING\r\nPING\r\n"; sleep 1) | nc localhost 6379
+PONG
+PONG
+PONG

大部分的Redis客戶端都對Pipelining提供支持，所以開發(fā)者通常并不需要自己手工拼裝命令列表浓恶。

Pipelining的局限性

Pipelining只能用于執(zhí)行連續(xù)且無相關(guān)性的命令玫坛，當某個命令的生成需要依賴于前一個命令的返回時，就無法使用Pipelining了包晰。

通過Scripting功能湿镀，可以規(guī)避這一局限性

事務(wù)與Scripting

Pipelining能夠讓Redis在一次交互中處理多條命令，然而在一些場景下伐憾，我們可能需要在此基礎(chǔ)上確保這一組命令是連續(xù)執(zhí)行的勉痴。

比如獲取當前累計的PV數(shù)并將其清0

> GET vCount
12384
> SET vCount 0
OK

如果在GET和SET命令之間插進來一個INCR vCount，就會使客戶端拿到的vCount不準確塞耕。

Redis的事務(wù)可以確保復(fù)數(shù)命令執(zhí)行時的原子性蚀腿。也就是說Redis能夠保證：一個事務(wù)中的一組命令是絕對連續(xù)執(zhí)行的，在這些命令執(zhí)行完成之前扫外，絕對不會有來自于其他連接的其他命令插進去執(zhí)行莉钙。

通過MULTI和EXEC命令來把這兩個命令加入一個事務(wù)中：

> MULTI
OK
> GET vCount
QUEUED
> SET vCount 0
QUEUED
> EXEC
1) 12384
2) OK

Redis在接收到MULTI命令后便會開啟一個事務(wù)，這之后的所有讀寫命令都會保存在隊列中但并不執(zhí)行筛谚，直到接收到EXEC命令后磁玉，Redis會把隊列中的所有命令連續(xù)順序執(zhí)行，并以數(shù)組形式返回每個命令的返回結(jié)果驾讲。

可以使用DISCARD命令放棄當前的事務(wù)蚊伞，將保存的命令隊列清空席赂。

需要注意的是，Redis事務(wù)不支持回滾：
如果一個事務(wù)中的命令出現(xiàn)了語法錯誤时迫，大部分客戶端驅(qū)動會返回錯誤颅停，2.6.5版本以上的Redis也會在執(zhí)行EXEC時檢查隊列中的命令是否存在語法錯誤，如果存在掠拳，則會自動放棄事務(wù)并返回錯誤癞揉。
但如果一個事務(wù)中的命令有非語法類的錯誤（比如對String執(zhí)行HSET操作），無論客戶端驅(qū)動還是Redis都無法在真正執(zhí)行這條命令之前發(fā)現(xiàn)溺欧，所以事務(wù)中的所有命令仍然會被依次執(zhí)行喊熟。在這種情況下，會出現(xiàn)一個事務(wù)中部分命令成功部分命令失敗的情況姐刁，然而與RDBMS不同芥牌，Redis不提供事務(wù)回滾的功能，所以只能通過其他方法進行數(shù)據(jù)的回滾聂使。

通過事務(wù)實現(xiàn)CAS

Redis提供了WATCH命令與事務(wù)搭配使用壁拉，實現(xiàn)CAS樂觀鎖的機制。

假設(shè)要實現(xiàn)將某個商品的狀態(tài)改為已售：

if(exec(HGET stock:1001 state) == "in stock")
    exec(HSET stock:1001 state "sold");

這一偽代碼執(zhí)行時岩遗，無法確保并發(fā)安全性扇商，有可能多個客戶端都獲取到了"in stock"的狀態(tài)，導(dǎo)致一個庫存被售賣多次宿礁。

使用WATCH命令和事務(wù)可以解決這一問題：

exec(WATCH stock:1001);
if(exec(HGET stock:1001 state) == "in stock") {
    exec(MULTI);
    exec(HSET stock:1001 state "sold");
    exec(EXEC);
}

WATCH的機制是：在事務(wù)EXEC命令執(zhí)行時案铺，Redis會檢查被WATCH的key，只有被WATCH的key從WATCH起始時至今沒有發(fā)生過變更梆靖，EXEC才會被執(zhí)行控汉。如果WATCH的key在WATCH命令到EXEC命令之間發(fā)生過變化，則EXEC命令會返回失敗返吻。

Scripting

通過EVAL與EVALSHA命令姑子，可以讓Redis執(zhí)行LUA腳本。這就類似于RDBMS的存儲過程一樣测僵，可以把客戶端與Redis之間密集的讀/寫交互放在服務(wù)端進行街佑，避免過多的數(shù)據(jù)交互，提升性能捍靠。

Scripting功能是作為事務(wù)功能的替代者誕生的沐旨，事務(wù)提供的所有能力Scripting都可以做到。Redis官方推薦使用LUA Script來代替事務(wù)榨婆，前者的效率和便利性都超過了事務(wù)磁携。

關(guān)于Scripting的具體使用，本文不做詳細介紹良风，請參考官方文檔 https://redis.io/commands/eval

Redis性能調(diào)優(yōu)

盡管Redis是一個非骋昶快速的內(nèi)存數(shù)據(jù)存儲媒介闷供，也并不代表Redis不會產(chǎn)生性能問題。
前文中提到過统诺，Redis采用單線程模型歪脏，所有的命令都是由一個線程串行執(zhí)行的，所以當某個命令執(zhí)行耗時較長時粮呢，會拖慢其后的所有命令唾糯，這使得Redis對每個任務(wù)的執(zhí)行效率更加敏感。

針對Redis的性能優(yōu)化鬼贱，主要從下面幾個層面入手：

• 最初的也是最重要的，確保沒有讓Redis執(zhí)行耗時長的命令
• 使用pipelining將連續(xù)執(zhí)行的命令組合執(zhí)行
• 操作系統(tǒng)的Transparent huge pages功能必須關(guān)閉：

echo never > /sys/kernel/mm/transparent_hugepage/enabled

• 如果在虛擬機中運行Redis香璃，可能天然就有虛擬機環(huán)境帶來的固有延遲这难。可以通過./redis-cli --intrinsic-latency 100命令查看固有延遲葡秒。同時如果對Redis的性能有較高要求的話姻乓，應(yīng)盡可能在物理機上直接部署Redis。
• 檢查數(shù)據(jù)持久化策略
• 考慮引入讀寫分離機制

長耗時命令

Redis絕大多數(shù)讀寫命令的時間復(fù)雜度都在O(1)到O(N)之間眯牧，在文本和官方文檔中均對每個命令的時間復(fù)雜度有說明蹋岩。

通常來說，O(1)的命令是安全的学少，O(N)命令在使用時需要注意剪个，如果N的數(shù)量級不可預(yù)知，則應(yīng)避免使用版确。例如對一個field數(shù)未知的Hash數(shù)據(jù)執(zhí)行HGETALL/HKEYS/HVALS命令扣囊，通常來說這些命令執(zhí)行的很快，但如果這個Hash中的field數(shù)量極多绒疗，耗時就會成倍增長侵歇。
又如使用SUNION對兩個Set執(zhí)行Union操作，或使用SORT對List/Set執(zhí)行排序操作等時吓蘑，都應(yīng)該嚴加注意惕虑。

避免在使用這些O(N)命令時發(fā)生問題主要有幾個辦法：

• 不要把List當做列表使用，僅當做隊列來使用
• 通過機制嚴格控制Hash磨镶、Set溃蔫、Sorted Set的大小
• 可能的話，將排序棋嘲、并集酒唉、交集等操作放在客戶端執(zhí)行
• 絕對禁止使用KEYS命令
• 避免一次性遍歷集合類型的所有成員，而應(yīng)使用SCAN類的命令進行分批的沸移，游標式的遍歷

Redis提供了SCAN命令痪伦，可以對Redis中存儲的所有key進行游標式的遍歷侄榴，避免使用KEYS命令帶來的性能問題。同時還有SSCAN/HSCAN/ZSCAN等命令网沾，分別用于對Set/Hash/Sorted Set中的元素進行游標式遍歷癞蚕。SCAN類命令的使用請參考官方文檔：https://redis.io/commands/scan

Redis提供了Slow Log功能，可以自動記錄耗時較長的命令辉哥。相關(guān)的配置參數(shù)有兩個：

slowlog-log-slower-than xxxms  #執(zhí)行時間慢于xxx毫秒的命令計入Slow Log
slowlog-max-len xxx  #Slow Log的長度桦山，即最大紀錄多少條Slow Log

使用SLOWLOG GET [number]命令，可以輸出最近進入Slow Log的number條命令醋旦。
使用SLOWLOG RESET命令恒水，可以重置Slow Log

網(wǎng)絡(luò)引發(fā)的延遲

• 盡可能使用長連接或連接池，避免頻繁創(chuàng)建銷毀連接
• 客戶端進行的批量數(shù)據(jù)操作饲齐，應(yīng)使用Pipeline特性在一次交互中完成钉凌。具體請參照本文的Pipelining章節(jié)

數(shù)據(jù)持久化引發(fā)的延遲

Redis的數(shù)據(jù)持久化工作本身就會帶來延遲，需要根據(jù)數(shù)據(jù)的安全級別和性能要求制定合理的持久化策略：

• AOF + fsync always的設(shè)置雖然能夠絕對確保數(shù)據(jù)安全捂人，但每個操作都會觸發(fā)一次fsync御雕，會對Redis的性能有比較明顯的影響
• AOF + fsync every second是比較好的折中方案，每秒fsync一次
• AOF + fsync never會提供AOF持久化方案下的最優(yōu)性能
• 使用RDB持久化通常會提供比使用AOF更高的性能滥搭，但需要注意RDB的策略配置
• 每一次RDB快照和AOF Rewrite都需要Redis主進程進行fork操作酸纲。fork操作本身可能會產(chǎn)生較高的耗時，與CPU和Redis占用的內(nèi)存大小有關(guān)瑟匆。根據(jù)具體的情況合理配置RDB快照和AOF Rewrite時機闽坡，避免過于頻繁的fork帶來的延遲

Redis在fork子進程時需要將內(nèi)存分頁表拷貝至子進程，以占用了24GB內(nèi)存的Redis實例為例脓诡，共需要拷貝24GB / 4kB * 8 = 48MB的數(shù)據(jù)无午。在使用單Xeon 2.27Ghz的物理機上，這一fork操作耗時216ms祝谚。

可以通過INFO命令返回的latest_fork_usec字段查看上一次fork操作的耗時（微秒）

Swap引發(fā)的延遲

當Linux將Redis所用的內(nèi)存分頁移至swap空間時宪迟，將會阻塞Redis進程，導(dǎo)致Redis出現(xiàn)不正常的延遲交惯。Swap通常在物理內(nèi)存不足或一些進程在進行大量I/O操作時發(fā)生次泽，應(yīng)盡可能避免上述兩種情況的出現(xiàn)。

/proc/<pid>/smaps文件中會保存進程的swap記錄席爽，通過查看這個文件意荤，能夠判斷Redis的延遲是否由Swap產(chǎn)生。如果這個文件中記錄了較大的Swap size只锻，則說明延遲很有可能是Swap造成的玖像。

數(shù)據(jù)淘汰引發(fā)的延遲

當同一秒內(nèi)有大量key過期時，也會引發(fā)Redis的延遲齐饮。在使用時應(yīng)盡量將key的失效時間錯開捐寥。

引入讀寫分離機制

Redis的主從復(fù)制能力可以實現(xiàn)一主多從的多節(jié)點架構(gòu)笤昨，在這一架構(gòu)下，主節(jié)點接收所有寫請求握恳，并將數(shù)據(jù)同步給多個從節(jié)點瞒窒。
在這一基礎(chǔ)上，我們可以讓從節(jié)點提供對實時性要求不高的讀請求服務(wù)乡洼，以減小主節(jié)點的壓力崇裁。
尤其是針對一些使用了長耗時命令的統(tǒng)計類任務(wù)，完全可以指定在一個或多個從節(jié)點上執(zhí)行束昵，避免這些長耗時命令影響其他請求的響應(yīng)拔稳。

關(guān)于讀寫分離的具體說明，請參見后續(xù)章節(jié)

主從復(fù)制與集群分片

主從復(fù)制

Redis支持一主多從的主從復(fù)制架構(gòu)锹雏。一個Master實例負責處理所有的寫請求壳炎，Master將寫操作同步至所有Slave。
借助Redis的主從復(fù)制逼侦，可以實現(xiàn)讀寫分離和高可用：

• 實時性要求不是特別高的讀請求，可以在Slave上完成腰耙，提升效率榛丢。特別是一些周期性執(zhí)行的統(tǒng)計任務(wù)，這些任務(wù)可能需要執(zhí)行一些長耗時的Redis命令挺庞，可以專門規(guī)劃出1個或幾個Slave用于服務(wù)這些統(tǒng)計任務(wù)
• 借助Redis Sentinel可以實現(xiàn)高可用晰赞，當Master crash后，Redis Sentinel能夠自動將一個Slave晉升為Master选侨，繼續(xù)提供服務(wù)

啟用主從復(fù)制非常簡單掖鱼，只需要配置多個Redis實例，在作為Slave的Redis實例中配置：

slaveof 192.168.1.1 6379  #指定Master的IP和端口

當Slave啟動后援制，會從Master進行一次冷啟動數(shù)據(jù)同步戏挡，由Master觸發(fā)BGSAVE生成RDB文件推送給Slave進行導(dǎo)入，導(dǎo)入完成后Master再將增量數(shù)據(jù)通過Redis Protocol同步給Slave晨仑。之后主從之間的數(shù)據(jù)便一直以Redis Protocol進行同步

使用Sentinel做自動failover

Redis的主從復(fù)制功能本身只是做數(shù)據(jù)同步褐墅，并不提供監(jiān)控和自動failover能力，要通過主從復(fù)制功能來實現(xiàn)Redis的高可用洪己，還需要引入一個組件：Redis Sentinel

Redis Sentinel是Redis官方開發(fā)的監(jiān)控組件妥凳，可以監(jiān)控Redis實例的狀態(tài)，通過Master節(jié)點自動發(fā)現(xiàn)Slave節(jié)點答捕，并在監(jiān)測到Master節(jié)點失效時選舉出一個新的Master逝钥，并向所有Redis實例推送新的主從配置。

Redis Sentinel需要至少部署3個實例才能形成選舉關(guān)系拱镐。

關(guān)鍵配置：

sentinel monitor mymaster 127.0.0.1 6379 2  #Master實例的IP艘款、端口持际，以及選舉需要的贊成票數(shù)
sentinel down-after-milliseconds mymaster 60000  #多長時間沒有響應(yīng)視為Master失效
sentinel failover-timeout mymaster 180000  #兩次failover嘗試間的間隔時長
sentinel parallel-syncs mymaster 1  #如果有多個Slave，可以通過此配置指定同時從新Master進行數(shù)據(jù)同步的Slave數(shù)磷箕，避免所有Slave同時進行數(shù)據(jù)同步導(dǎo)致查詢服務(wù)也不可用

另外需要注意的是选酗，Redis Sentinel實現(xiàn)的自動failover不是在同一個IP和端口上完成的，也就是說自動failover產(chǎn)生的新Master提供服務(wù)的IP和端口與之前的Master是不一樣的岳枷，所以要實現(xiàn)HA芒填，還要求客戶端必須支持Sentinel，能夠與Sentinel交互獲得新Master的信息才行空繁。

集群分片

為何要做集群分片：

• Redis中存儲的數(shù)據(jù)量大殿衰，一臺主機的物理內(nèi)存已經(jīng)無法容納
• Redis的寫請求并發(fā)量大，一個Redis實例以無法承載

當上述兩個問題出現(xiàn)時盛泡，就必須要對Redis進行分片了闷祥。
Redis的分片方案有很多種，例如很多Redis的客戶端都自行實現(xiàn)了分片功能傲诵，也有向Twemproxy這樣的以代理方式實現(xiàn)的Redis分片方案凯砍。然而首選的方案還應(yīng)該是Redis官方在3.0版本中推出的Redis Cluster分片方案。

本文不會對Redis Cluster的具體安裝和部署細節(jié)進行介紹拴竹，重點介紹Redis Cluster帶來的好處與弊端悟衩。

Redis Cluster的能力

• 能夠自動將數(shù)據(jù)分散在多個節(jié)點上
• 當訪問的key不在當前分片上時，能夠自動將請求轉(zhuǎn)發(fā)至正確的分片
• 當集群中部分節(jié)點失效時仍能提供服務(wù)

其中第三點是基于主從復(fù)制來實現(xiàn)的栓拜，Redis Cluster的每個數(shù)據(jù)分片都采用了主從復(fù)制的結(jié)構(gòu)座泳，原理和前文所述的主從復(fù)制完全一致，唯一的區(qū)別是省去了Redis Sentinel這一額外的組件幕与，由Redis Cluster負責進行一個分片內(nèi)部的節(jié)點監(jiān)控和自動failover挑势。

Redis Cluster分片原理

Redis Cluster中共有16384個hash slot，Redis會計算每個key的CRC16啦鸣，將結(jié)果與16384取模潮饱，來決定該key存儲在哪一個hash slot中，同時需要指定Redis Cluster中每個數(shù)據(jù)分片負責的Slot數(shù)诫给。Slot的分配在任何時間點都可以進行重新分配饼齿。

客戶端在對key進行讀寫操作時，可以連接Cluster中的任意一個分片蝙搔，如果操作的key不在此分片負責的Slot范圍內(nèi)缕溉，Redis Cluster會自動將請求重定向到正確的分片上。

hash tags

在基礎(chǔ)的分片原則上吃型，Redis還支持hash tags功能证鸥，以hash tags要求的格式明明的key，將會確保進入同一個Slot中。例如：{uiv}user:1000和{uiv}user:1001擁有同樣的hash tag {uiv}枉层，會保存在同一個Slot中泉褐。

使用Redis Cluster時，pipelining鸟蜡、事務(wù)和LUA Script功能涉及的key必須在同一個數(shù)據(jù)分片上膜赃，否則將會返回錯誤。如要在Redis Cluster中使用上述功能揉忘，就必須通過hash tags來確保一個pipeline或一個事務(wù)中操作的所有key都位于同一個Slot中跳座。

有一些客戶端（如Redisson）實現(xiàn)了集群化的pipelining操作，可以自動將一個pipeline里的命令按key所在的分片進行分組泣矛，分別發(fā)到不同的分片上執(zhí)行疲眷。但是Redis不支持跨分片的事務(wù)，事務(wù)和LUA Script還是必須遵循所有key在一個分片上的規(guī)則要求您朽。

主從復(fù)制 vs 集群分片

在設(shè)計軟件架構(gòu)時狂丝，要如何在主從復(fù)制和集群分片兩種部署方案中取舍呢？

從各個方面看哗总，Redis Cluster都是優(yōu)于主從復(fù)制的方案

• Redis Cluster能夠解決單節(jié)點上數(shù)據(jù)量過大的問題
• Redis Cluster能夠解決單節(jié)點訪問壓力過大的問題
• Redis Cluster包含了主從復(fù)制的能力

那是不是代表Redis Cluster永遠是優(yōu)于主從復(fù)制的選擇呢几颜？

并不是。

軟件架構(gòu)永遠不是越復(fù)雜越好讯屈，復(fù)雜的架構(gòu)在帶來顯著好處的同時菠剩，一定也會帶來相應(yīng)的弊端。采用Redis Cluster的弊端包括：

• 維護難度增加耻煤。在使用Redis Cluster時，需要維護的Redis實例數(shù)倍增准颓，需要監(jiān)控的主機數(shù)量也相應(yīng)增加哈蝇，數(shù)據(jù)備份/持久化的復(fù)雜度也會增加。同時在進行分片的增減操作時攘已，還需要進行reshard操作炮赦，遠比主從模式下增加一個Slave的復(fù)雜度要高。
• 客戶端資源消耗增加样勃。當客戶端使用連接池時吠勘，需要為每一個數(shù)據(jù)分片維護一個連接池，客戶端同時需要保持的連接數(shù)成倍增多峡眶，加大了客戶端本身和操作系統(tǒng)資源的消耗剧防。
• 性能優(yōu)化難度增加。你可能需要在多個分片上查看Slow Log和Swap日志才能定位性能問題辫樱。
• 事務(wù)和LUA Script的使用成本增加峭拘。在Redis Cluster中使用事務(wù)和LUA Script特性有嚴格的限制條件，事務(wù)和Script中操作的key必須位于同一個分片上，這就使得在開發(fā)時必須對相應(yīng)場景下涉及的key進行額外的規(guī)劃和規(guī)范要求鸡挠。如果應(yīng)用的場景中大量涉及事務(wù)和Script的使用辉饱，如何在保證這兩個功能的正常運作前提下把數(shù)據(jù)平均分到多個數(shù)據(jù)分片中就會成為難點。

所以說拣展，在主從復(fù)制和集群分片兩個方案中做出選擇時彭沼，應(yīng)該從應(yīng)用軟件的功能特性、數(shù)據(jù)和訪問量級备埃、未來發(fā)展規(guī)劃等方面綜合考慮姓惑，只在確實有必要引入數(shù)據(jù)分片時再使用Redis Cluster。
下面是一些建議：

1. 需要在Redis中存儲的數(shù)據(jù)有多大瓜喇？未來2年內(nèi)可能發(fā)展為多大挺益？這些數(shù)據(jù)是否都需要長期保存？是否可以使用LRU算法進行非熱點數(shù)據(jù)的淘汰乘寒？綜合考慮前面幾個因素望众，評估出Redis需要使用的物理內(nèi)存。
2. 用于部署Redis的主機物理內(nèi)存有多大伞辛？有多少可以分配給Redis使用烂翰？對比(1)中的內(nèi)存需求評估，是否足夠用蚤氏？
3. Redis面臨的并發(fā)寫壓力會有多大甘耿？在不使用pipelining時，Redis的寫性能可以超過10萬次/秒（更多的benchmark可以參考 https://redis.io/topics/benchmarks ）
4. 在使用Redis時竿滨，是否會使用到pipelining和事務(wù)功能佳恬？使用的場景多不多？

綜合上面幾點考慮于游，如果單臺主機的可用物理內(nèi)存完全足以支撐對Redis的容量需求毁葱，且Redis面臨的并發(fā)寫壓力距離Benchmark值還尚有距離，建議采用主從復(fù)制的架構(gòu)贰剥，可以省去很多不必要的麻煩倾剿。同時，如果應(yīng)用中大量使用pipelining和事務(wù)蚌成，也建議盡可能選擇主從復(fù)制架構(gòu)前痘，可以減少設(shè)計和開發(fā)時的復(fù)雜度。

Redis Java客戶端的選擇

Redis的Java客戶端很多担忧，官方推薦的有三種：Jedis芹缔、Redisson和lettuce。

在這里對Jedis和Redisson進行對比介紹

Jedis：

• 輕量瓶盛，簡潔乖菱，便于集成和改造
• 支持連接池
• 支持pipelining坡锡、事務(wù)、LUA Scripting窒所、Redis Sentinel鹉勒、Redis Cluster
• 不支持讀寫分離，需要自己實現(xiàn)
• 文檔差（真的很差吵取，幾乎沒有……）

Redisson：

• 基于Netty實現(xiàn)禽额，采用非阻塞IO，性能高
• 支持異步請求
• 支持連接池
• 支持pipelining皮官、LUA Scripting脯倒、Redis Sentinel、Redis Cluster
• 不支持事務(wù)捺氢，官方建議以LUA Scripting代替事務(wù)
• 支持在Redis Cluster架構(gòu)下使用pipelining
• 支持讀寫分離藻丢，支持讀負載均衡，在主從復(fù)制和Redis Cluster架構(gòu)下都可以使用
• 內(nèi)建Tomcat Session Manager摄乒，為Tomcat 6/7/8提供了會話共享功能
• 可以與Spring Session集成悠反，實現(xiàn)基于Redis的會話共享
• 文檔較豐富，有中文文檔

對于Jedis和Redisson的選擇馍佑，同樣應(yīng)遵循前述的原理斋否，盡管Jedis比起Redisson有各種各樣的不足，但也應(yīng)該在需要使用Redisson的高級特性時再選用Redisson拭荤，避免造成不必要的程序復(fù)雜度提升茵臭。

Jedis：
github：https://github.com/xetorthio/jedis
文檔：https://github.com/xetorthio/jedis/wiki

Redisson：
github：https://github.com/redisson/redisson
文檔：https://github.com/redisson/redisson/wiki