Redis基礎(chǔ)卿吐、高級(jí)特性與性能調(diào)優(yōu)

本文將從Redis的基本特性入手旁舰，通過講述Redis的數(shù)據(jù)結(jié)構(gòu)和主要命令對(duì)Redis的基本能力進(jìn)行直觀介紹。之后概覽Redis提供的高級(jí)能力嗡官，并在部署箭窜、維護(hù)、性能調(diào)優(yōu)等多個(gè)方面進(jìn)行更深入的介紹和指導(dǎo)衍腥。
本文適合使用Redis的普通開發(fā)人員磺樱，以及對(duì)Redis進(jìn)行選型、架構(gòu)設(shè)計(jì)和性能調(diào)優(yōu)的架構(gòu)設(shè)計(jì)人員婆咸。

目錄

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

概述

Redis是一個(gè)開源的竹捉，基于內(nèi)存的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)媒介，可以作為數(shù)據(jù)庫(kù)尚骄、緩存服務(wù)或消息服務(wù)使用块差。
Redis支持多種數(shù)據(jù)結(jié)構(gòu)，包括字符串倔丈、哈希表憨闰、鏈表、集合乃沙、有序集合起趾、位圖、Hyperloglogs等警儒。
Redis具備LRU淘汰训裆、事務(wù)實(shí)現(xiàn)、以及不同級(jí)別的硬盤持久化等能力蜀铲，并且支持副本集和通過Redis Sentinel實(shí)現(xiàn)的高可用方案边琉，同時(shí)還支持通過Redis Cluster實(shí)現(xiàn)的數(shù)據(jù)自動(dòng)分片能力。

Redis的主要功能都基于單線程模型實(shí)現(xiàn)记劝，也就是說(shuō)Redis使用一個(gè)線程來(lái)服務(wù)所有的客戶端請(qǐng)求变姨，同時(shí)Redis采用了非阻塞式IO，并精細(xì)地優(yōu)化各種命令的算法時(shí)間復(fù)雜度厌丑，這些信息意味著：

  • Redis是線程安全的（因?yàn)橹挥幸粋€(gè)線程）定欧，其所有操作都是原子的，不會(huì)因并發(fā)產(chǎn)生數(shù)據(jù)異常
  • Redis的速度非撑停快（因?yàn)槭褂梅亲枞絀O砍鸠，且大部分命令的算法時(shí)間復(fù)雜度都是O(1))
  • 使用高耗時(shí)的Redis命令是很危險(xiǎn)的，會(huì)占用唯一的一個(gè)線程的大量處理時(shí)間耕驰，導(dǎo)致所有的請(qǐng)求都被拖慢爷辱。（例如時(shí)間復(fù)雜度為O(N)的KEYS命令，嚴(yán)格禁止在生產(chǎn)環(huán)境中使用）

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

本節(jié)中將介紹Redis支持的主要數(shù)據(jù)結(jié)構(gòu)，以及相關(guān)的常用Redis命令饭弓。本節(jié)只對(duì)Redis命令進(jìn)行扼要的介紹双饥，且只列出了較常用的命令。如果想要了解完整的Redis命令集弟断，或了解某個(gè)命令的詳細(xì)使用方法咏花，請(qǐng)參考官方文檔：https://redis.io/commands

Key

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

  • 不要使用過長(zhǎng)的Key夫嗓。例如使用一個(gè)1024字節(jié)的key就不是一個(gè)好主意迟螺，不僅會(huì)消耗更多的內(nèi)存冲秽，還會(huì)導(dǎo)致查找的效率降低
  • Key短到缺失了可讀性也是不好的舍咖，例如"u1000flw"比起"user:1000:followers"來(lái)說(shuō)，節(jié)省了寥寥的存儲(chǔ)空間锉桑，卻引發(fā)了可讀性和可維護(hù)性上的麻煩
  • 最好使用統(tǒng)一的規(guī)范來(lái)設(shè)計(jì)Key排霉，比如"object-type:id:attr"，以這一規(guī)范設(shè)計(jì)出的Key可能是"user:1000"或"comment:1234:reply-to"
  • Redis允許的最大Key長(zhǎng)度是512MB（對(duì)Value的長(zhǎng)度限制也是512MB）

String

String是Redis的基礎(chǔ)數(shù)據(jù)類型民轴，Redis沒有Int攻柠、Float、Boolean等數(shù)據(jù)類型的概念后裸，所有的基本類型在Redis中都以String體現(xiàn)瑰钮。

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

  • SET：為一個(gè)key設(shè)置value，可以配合EX/PX參數(shù)指定key的有效期微驶，通過NX/XX參數(shù)針對(duì)key是否存在的情況進(jìn)行區(qū)別操作浪谴，時(shí)間復(fù)雜度O(1)
  • GET：獲取某個(gè)key對(duì)應(yīng)的value，時(shí)間復(fù)雜度O(1)
  • GETSET：為一個(gè)key設(shè)置value因苹，并返回該key的原value苟耻，時(shí)間復(fù)雜度O(1)
  • MSET：為多個(gè)key設(shè)置value，時(shí)間復(fù)雜度O(N)
  • MSETNX：同MSET扶檐，如果指定的key中有任意一個(gè)已存在凶杖，則不進(jìn)行任何操作，時(shí)間復(fù)雜度O(N)
  • MGET：獲取多個(gè)key對(duì)應(yīng)的value款筑，時(shí)間復(fù)雜度O(N)

上文提到過智蝠，Redis的基本數(shù)據(jù)類型只有String，但Redis可以把String作為整型或浮點(diǎn)型數(shù)字來(lái)使用奈梳，主要體現(xiàn)在INCR杈湾、DECR類的命令上：

  • INCR：將key對(duì)應(yīng)的value值自增1，并返回自增后的值颈嚼。只對(duì)可以轉(zhuǎn)換為整型的String數(shù)據(jù)起作用毛秘。時(shí)間復(fù)雜度O(1)
  • INCRBY：將key對(duì)應(yīng)的value值自增指定的整型數(shù)值，并返回自增后的值。只對(duì)可以轉(zhuǎn)換為整型的String數(shù)據(jù)起作用叫挟。時(shí)間復(fù)雜度O(1)
  • DECR/DECRBY：同INCR/INCRBY艰匙，自增改為自減。

INCR/DECR系列命令要求操作的value類型為String抹恳，并可以轉(zhuǎn)換為64位帶符號(hào)的整型數(shù)字员凝，否則會(huì)返回錯(cuò)誤。
也就是說(shuō)奋献，進(jìn)行INCR/DECR系列命令的value健霹，必須在[-2^63 ~ 2^63 - 1]范圍內(nèi)。

前文提到過瓶蚂，Redis采用單線程模型糖埋，天然是線程安全的，這使得INCR/DECR命令可以非常便利的實(shí)現(xiàn)高并發(fā)場(chǎng)景下的精確控制窃这。

例1：庫(kù)存控制

在高并發(fā)場(chǎng)景下實(shí)現(xiàn)庫(kù)存余量的精準(zhǔn)校驗(yàn)瞳别，確保不出現(xiàn)超賣的情況。

設(shè)置庫(kù)存總量：

SET inv:remain "100"

庫(kù)存扣減+余量校驗(yàn)：

DECR inv:remain

當(dāng)DECR命令返回值大于等于0時(shí)杭攻，說(shuō)明庫(kù)存余量校驗(yàn)通過祟敛，如果返回小于0的值，則說(shuō)明庫(kù)存已耗盡兆解。

假設(shè)同時(shí)有300個(gè)并發(fā)請(qǐng)求進(jìn)行庫(kù)存扣減馆铁，Redis能夠確保這300個(gè)請(qǐng)求分別得到99到-200的返回值，每個(gè)請(qǐng)求得到的返回值都是唯一的锅睛，絕對(duì)不會(huì)找出現(xiàn)兩個(gè)請(qǐng)求得到一樣的返回值的情況埠巨。

例2：自增序列生成

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

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

SET sequence "10000"

獲取一個(gè)序列值：

INCR sequence

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

獲取一批（如100個(gè)）序列值：

INCRBY sequence 100

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

當(dāng)多個(gè)客戶端同時(shí)向Redis申請(qǐng)自增序列時(shí)具练，Redis能夠確保每個(gè)客戶端得到的序列值或序列范圍都是全局唯一的乍构，絕對(duì)不會(huì)出現(xiàn)不同客戶端得到了重復(fù)的序列值的情況。

List

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

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

  • LPUSH：向指定List的左側(cè)（即頭部）插入1個(gè)或多個(gè)元素，返回插入后的List長(zhǎng)度铜邮。時(shí)間復(fù)雜度O(N)仪召，N為插入元素的數(shù)量
  • RPUSH：同LPUSH寨蹋，向指定List的右側(cè)（即尾部）插入1或多個(gè)元素
  • LPOP：從指定List的左側(cè)（即頭部）移除一個(gè)元素并返回，時(shí)間復(fù)雜度O(1)
  • RPOP：同LPOP扔茅，從指定List的右側(cè)（即尾部）移除1個(gè)元素并返回
  • LPUSHX/RPUSHX：與LPUSH/RPUSH類似已旧，區(qū)別在于，LPUSHX/RPUSHX操作的key如果不存在召娜，則不會(huì)進(jìn)行任何操作
  • LLEN：返回指定List的長(zhǎng)度运褪，時(shí)間復(fù)雜度O(1)
  • LRANGE：返回指定List中指定范圍的元素（雙端包含，即LRANGE key 0 10會(huì)返回11個(gè)元素）玖瘸，時(shí)間復(fù)雜度O(N)秸讹。應(yīng)盡可能控制一次獲取的元素?cái)?shù)量，一次獲取過大范圍的List元素會(huì)導(dǎo)致延遲雅倒，同時(shí)對(duì)長(zhǎng)度不可預(yù)知的List璃诀，避免使用LRANGE key 0 -1這樣的完整遍歷操作。

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

  • LINDEX：返回指定List指定index上的元素屯断，如果index越界文虏，返回nil。index數(shù)值是回環(huán)的殖演，即-1代表List最后一個(gè)位置，-2代表List倒數(shù)第二個(gè)位置年鸳。時(shí)間復(fù)雜度O(N)
  • LSET：將指定List指定index上的元素設(shè)置為value趴久，如果index越界則返回錯(cuò)誤，時(shí)間復(fù)雜度O(N)搔确，如果操作的是頭/尾部的元素彼棍，則時(shí)間復(fù)雜度為O(1)
  • LINSERT：向指定List中指定元素之前/之后插入一個(gè)新元素，并返回操作后的List長(zhǎng)度膳算。如果指定的元素不存在座硕，返回-1。如果指定key不存在涕蜂，不會(huì)進(jìn)行任何操作华匾，時(shí)間復(fù)雜度O(N)

由于Redis的List是鏈表結(jié)構(gòu)的，上述的三個(gè)命令的算法效率較低机隙，需要對(duì)List進(jìn)行遍歷蜘拉，命令的耗時(shí)無(wú)法預(yù)估，在List長(zhǎng)度大的情況下耗時(shí)會(huì)明顯增加有鹿，應(yīng)謹(jǐn)慎使用旭旭。

換句話說(shuō)，Redis的List實(shí)際是設(shè)計(jì)來(lái)用于實(shí)現(xiàn)隊(duì)列葱跋，而不是用于實(shí)現(xiàn)類似ArrayList這樣的列表的持寄。如果你不是想要實(shí)現(xiàn)一個(gè)雙端出入的隊(duì)列源梭，那么請(qǐng)盡量不要使用Redis的List數(shù)據(jù)結(jié)構(gòu)。

為了更好支持隊(duì)列的特性稍味，Redis還提供了一系列阻塞式的操作命令咸产，如BLPOP/BRPOP等，能夠?qū)崿F(xiàn)類似于BlockingQueue的能力仲闽，即在List為空時(shí)脑溢，阻塞該連接，直到List中有對(duì)象可以出隊(duì)時(shí)再返回赖欣。針對(duì)阻塞類的命令屑彻，此處不做詳細(xì)探討，請(qǐng)參考官方文檔（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)對(duì)象類型的數(shù)據(jù)，用Hash中的field對(duì)應(yīng)對(duì)象的field即可湃交。
Hash的優(yōu)點(diǎn)包括：

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

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

  • HSET：將key對(duì)應(yīng)的Hash中的field設(shè)置為value息罗。如果該Hash不存在，會(huì)自動(dòng)創(chuàng)建一個(gè)才沧。時(shí)間復(fù)雜度O(1)
  • HGET：返回指定Hash中field字段的值迈喉，時(shí)間復(fù)雜度O(1)
  • HMSET/HMGET：同HSET和HGET，可以批量操作同一個(gè)key下的多個(gè)field温圆，時(shí)間復(fù)雜度：O(N)挨摸，N為一次操作的field數(shù)量
  • HSETNX：同HSET，但如field已經(jīng)存在岁歉，HSETNX不會(huì)進(jìn)行任何操作得运，時(shí)間復(fù)雜度O(1)
  • HEXISTS：判斷指定Hash中field是否存在，存在返回1刨裆，不存在返回0澈圈，時(shí)間復(fù)雜度O(1)
  • HDEL：刪除指定Hash中的field（1個(gè)或多個(gè)），時(shí)間復(fù)雜度：O(N)帆啃，N為操作的field數(shù)量
  • HINCRBY：同INCRBY命令瞬女，對(duì)指定Hash中的一個(gè)field進(jìn)行INCRBY，時(shí)間復(fù)雜度O(1)

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

  • HGETALL：返回指定Hash中所有的field-value對(duì)努潘。返回結(jié)果為數(shù)組诽偷，數(shù)組中field和value交替出現(xiàn)坤学。時(shí)間復(fù)雜度O(N)
  • HKEYS/HVALS：返回指定Hash中所有的field/value，時(shí)間復(fù)雜度O(N)

上述三個(gè)命令都會(huì)對(duì)Hash進(jìn)行完整遍歷报慕，Hash中的field數(shù)量與命令的耗時(shí)線性相關(guān)深浮，對(duì)于尺寸不可預(yù)知的Hash，應(yīng)嚴(yán)格避免使用上面三個(gè)命令眠冈，而改為使用HSCAN命令進(jìn)行游標(biāo)式的遍歷飞苇，具體請(qǐng)見 https://redis.io/commands/scan

Set

Redis Set是無(wú)序的，不可重復(fù)的String集合蜗顽。

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

  • SADD：向指定Set中添加1個(gè)或多個(gè)member布卡，如果指定Set不存在，會(huì)自動(dòng)創(chuàng)建一個(gè)雇盖。時(shí)間復(fù)雜度O(N)忿等，N為添加的member個(gè)數(shù)
  • SREM：從指定Set中移除1個(gè)或多個(gè)member，時(shí)間復(fù)雜度O(N)崔挖，N為移除的member個(gè)數(shù)
  • SRANDMEMBER：從指定Set中隨機(jī)返回1個(gè)或多個(gè)member贸街，時(shí)間復(fù)雜度O(N)，N為返回的member個(gè)數(shù)
  • SPOP：從指定Set中隨機(jī)移除并返回count個(gè)member狸相，時(shí)間復(fù)雜度O(N)薛匪，N為移除的member個(gè)數(shù)
  • SCARD：返回指定Set中的member個(gè)數(shù)，時(shí)間復(fù)雜度O(1)
  • SISMEMBER：判斷指定的value是否存在于指定Set中卷哩，時(shí)間復(fù)雜度O(1)
  • SMOVE：將指定member從一個(gè)Set移至另一個(gè)Set

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

  • SMEMBERS：返回指定Hash中所有的member蛋辈，時(shí)間復(fù)雜度O(N)
  • SUNION/SUNIONSTORE：計(jì)算多個(gè)Set的并集并返回/存儲(chǔ)至另一個(gè)Set中，時(shí)間復(fù)雜度O(N)将谊，N為參與計(jì)算的所有集合的總member數(shù)
  • SINTER/SINTERSTORE：計(jì)算多個(gè)Set的交集并返回/存儲(chǔ)至另一個(gè)Set中，時(shí)間復(fù)雜度O(N)渐白，N為參與計(jì)算的所有集合的總member數(shù)
  • SDIFF/SDIFFSTORE：計(jì)算1個(gè)Set與1或多個(gè)Set的差集并返回/存儲(chǔ)至另一個(gè)Set中尊浓，時(shí)間復(fù)雜度O(N)，N為參與計(jì)算的所有集合的總member數(shù)

上述幾個(gè)命令涉及的計(jì)算量大纯衍，應(yīng)謹(jǐn)慎使用栋齿，特別是在參與計(jì)算的Set尺寸不可知的情況下，應(yīng)嚴(yán)格避免使用襟诸⊥叨拢可以考慮通過SSCAN命令遍歷獲取相關(guān)Set的全部member（具體請(qǐng)見 https://redis.io/commands/scan ），如果需要做并集/交集/差集計(jì)算歌亲，可以在客戶端進(jìn)行菇用，或在不服務(wù)實(shí)時(shí)查詢請(qǐng)求的Slave上進(jìn)行。

Sorted Set

Redis Sorted Set是有序的陷揪、不可重復(fù)的String集合惋鸥。Sorted Set中的每個(gè)元素都需要指派一個(gè)分?jǐn)?shù)(score)杂穷，Sorted Set會(huì)根據(jù)score對(duì)元素進(jìn)行升序排序。如果多個(gè)member擁有相同的score卦绣，則以字典序進(jìn)行升序排序耐量。

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

Sorted Set的主要命令：

  • ZADD：向指定Sorted Set中添加1個(gè)或多個(gè)member滤港，時(shí)間復(fù)雜度O(Mlog(N))廊蜒，M為添加的member數(shù)量，N為Sorted Set中的member數(shù)量
  • ZREM：從指定Sorted Set中刪除1個(gè)或多個(gè)member溅漾，時(shí)間復(fù)雜度O(Mlog(N))山叮，M為刪除的member數(shù)量，N為Sorted Set中的member數(shù)量
  • ZCOUNT：返回指定Sorted Set中指定score范圍內(nèi)的member數(shù)量樟凄，時(shí)間復(fù)雜度：O(log(N))
  • ZCARD：返回指定Sorted Set中的member數(shù)量聘芜，時(shí)間復(fù)雜度O(1)
  • ZSCORE：返回指定Sorted Set中指定member的score，時(shí)間復(fù)雜度O(1)
  • ZRANK/ZREVRANK：返回指定member在Sorted Set中的排名缝龄，ZRANK返回按升序排序的排名汰现，ZREVRANK則返回按降序排序的排名。時(shí)間復(fù)雜度O(log(N))
  • ZINCRBY：同INCRBY叔壤，對(duì)指定Sorted Set中的指定member的score進(jìn)行自增瞎饲，時(shí)間復(fù)雜度O(log(N))

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

  • ZRANGE/ZREVRANGE：返回指定Sorted Set中指定排名范圍內(nèi)的所有member，ZRANGE為按score升序排序炼绘，ZREVRANGE為按score降序排序嗅战，時(shí)間復(fù)雜度O(log(N)+M)，M為本次返回的member數(shù)
  • ZRANGEBYSCORE/ZREVRANGEBYSCORE：返回指定Sorted Set中指定score范圍內(nèi)的所有member俺亮，返回結(jié)果以升序/降序排序驮捍，min和max可以指定為-inf和+inf，代表返回所有的member脚曾。時(shí)間復(fù)雜度O(log(N)+M)
  • ZREMRANGEBYRANK/ZREMRANGEBYSCORE：移除Sorted Set中指定排名范圍/指定score范圍內(nèi)的所有member东且。時(shí)間復(fù)雜度O(log(N)+M)

上述幾個(gè)命令，應(yīng)盡量避免傳遞[0 -1]或[-inf +inf]這樣的參數(shù)本讥，來(lái)對(duì)Sorted Set做一次性的完整遍歷珊泳，特別是在Sorted Set的尺寸不可預(yù)知的情況下】椒校可以通過ZSCAN命令來(lái)進(jìn)行游標(biāo)式的遍歷（具體請(qǐng)見 https://redis.io/commands/scan ）色查，或通過LIMIT參數(shù)來(lái)限制返回member的數(shù)量（適用于ZRANGEBYSCORE和ZREVRANGEBYSCORE命令），以實(shí)現(xiàn)游標(biāo)式的遍歷撞芍。

Bitmap和HyperLogLog

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

Bitmap在Redis中不是一種實(shí)際的數(shù)據(jù)類型示惊，而是一種將String作為Bitmap使用的方法好港。可以理解為將String轉(zhuǎn)換為bit數(shù)組米罚。使用Bitmap來(lái)存儲(chǔ)true/false類型的簡(jiǎn)單數(shù)據(jù)極為節(jié)省空間钧汹。

HyperLogLogs是一種主要用于數(shù)量統(tǒng)計(jì)的數(shù)據(jù)結(jié)構(gòu)，它和Set類似录择，維護(hù)一個(gè)不可重復(fù)的String集合拔莱，但是HyperLogLogs并不維護(hù)具體的member內(nèi)容，只維護(hù)member的個(gè)數(shù)隘竭。也就是說(shuō)塘秦，HyperLogLogs只能用于計(jì)算一個(gè)集合中不重復(fù)的元素?cái)?shù)量，所以它比Set要節(jié)省很多內(nèi)存空間动看。

其他常用命令

  • EXISTS：判斷指定的key是否存在尊剔，返回1代表存在，0代表不存在菱皆，時(shí)間復(fù)雜度O(1)
  • DEL：刪除指定的key及其對(duì)應(yīng)的value须误，時(shí)間復(fù)雜度O(N)，N為刪除的key數(shù)量
  • EXPIRE/PEXPIRE：為一個(gè)key設(shè)置有效期仇轻，單位為秒或毫秒京痢，時(shí)間復(fù)雜度O(1)
  • TTL/PTTL：返回一個(gè)key剩余的有效時(shí)間，單位為秒或毫秒篷店，時(shí)間復(fù)雜度O(1)
  • RENAME/RENAMENX：將key重命名為newkey祭椰。使用RENAME時(shí)，如果newkey已經(jīng)存在疲陕，其值會(huì)被覆蓋方淤；使用RENAMENX時(shí)，如果newkey已經(jīng)存在蹄殃，則不會(huì)進(jìn)行任何操作臣淤，時(shí)間復(fù)雜度O(1)
  • TYPE：返回指定key的類型，string, list, set, zset, hash窃爷。時(shí)間復(fù)雜度O(1)
  • CONFIG GET：獲得Redis某配置項(xiàng)的當(dāng)前值，可以使用*通配符姓蜂，時(shí)間復(fù)雜度O(1)
  • CONFIG SET：為Redis某個(gè)配置項(xiàng)設(shè)置新值按厘，時(shí)間復(fù)雜度O(1)
  • CONFIG REWRITE：讓Redis重新加載redis.conf中的配置

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

Redis提供了將數(shù)據(jù)定期自動(dòng)持久化至硬盤的能力，包括RDB和AOF兩種方案钱慢，兩種方案分別有其長(zhǎng)處和短板逮京，可以配合起來(lái)同時(shí)運(yùn)行，確保數(shù)據(jù)的穩(wěn)定性束莫。

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

Redis的數(shù)據(jù)持久化機(jī)制是可以關(guān)閉的草描。如果你只把Redis作為緩存服務(wù)使用，Redis中存儲(chǔ)的所有數(shù)據(jù)都不是該數(shù)據(jù)的主體而僅僅是同步過來(lái)的備份策严，那么可以關(guān)閉Redis的數(shù)據(jù)持久化機(jī)制穗慕。
但通常來(lái)說(shuō)，仍然建議至少開啟RDB方式的數(shù)據(jù)持久化妻导，因?yàn)椋?/p>

  • RDB方式的持久化幾乎不損耗Redis本身的性能逛绵，在進(jìn)行RDB持久化時(shí)，Redis主進(jìn)程唯一需要做的事情就是fork出一個(gè)子進(jìn)程倔韭，所有持久化工作都由子進(jìn)程完成
  • Redis無(wú)論因?yàn)槭裁丛騝rash掉之后术浪，重啟時(shí)能夠自動(dòng)恢復(fù)到上一次RDB快照中記錄的數(shù)據(jù)。這省去了手工從其他數(shù)據(jù)源（如DB）同步數(shù)據(jù)的過程寿酌，而且要比其他任何的數(shù)據(jù)恢復(fù)方式都要快
  • 現(xiàn)在硬盤那么大胰苏，真的不缺那一點(diǎn)地方

RDB

采用RDB持久方式，Redis會(huì)定期保存數(shù)據(jù)快照至一個(gè)rbd文件中醇疼，并在啟動(dòng)時(shí)自動(dòng)加載rdb文件硕并，恢復(fù)之前保存的數(shù)據(jù)〗┫伲可以在配置文件中配置Redis進(jìn)行快照保存的時(shí)機(jī)：

save [seconds] [changes]

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

save 60 100

會(huì)讓Redis每60秒檢查一次數(shù)據(jù)變更情況辰如，如果發(fā)生了100次或以上的數(shù)據(jù)變更普监，則進(jìn)行RDB快照保存。
可以配置多條save指令琉兜，讓Redis執(zhí)行多級(jí)的快照保存策略凯正。
Redis默認(rèn)開啟RDB快照，默認(rèn)的RDB策略如下：

save 900 1
save 300 10
save 60 10000

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

RDB的優(yōu)點(diǎn)：

  • 對(duì)性能影響最小廊散。如前文所述，Redis在保存RDB快照時(shí)會(huì)fork出子進(jìn)程進(jìn)行梧疲，幾乎不影響Redis處理客戶端請(qǐng)求的效率允睹。
  • 每次快照會(huì)生成一個(gè)完整的數(shù)據(jù)快照文件，所以可以輔以其他手段保存多個(gè)時(shí)間點(diǎn)的快照（例如把每天0點(diǎn)的快照備份至其他存儲(chǔ)媒介中）幌氮，作為非崇允埽可靠的災(zāi)難恢復(fù)手段。
  • 使用RDB文件進(jìn)行數(shù)據(jù)恢復(fù)比使用AOF要快很多该互。

RDB的缺點(diǎn)：

  • 快照是定期生成的米者，所以在Redis crash時(shí)或多或少會(huì)丟失一部分?jǐn)?shù)據(jù)。
  • 如果數(shù)據(jù)集非常大且CPU不夠強(qiáng)（比如單核CPU），Redis在fork子進(jìn)程時(shí)可能會(huì)消耗相對(duì)較長(zhǎng)的時(shí)間（長(zhǎng)至1秒）蔓搞，影響這期間的客戶端請(qǐng)求胰丁。

AOF

采用AOF持久方式時(shí)，Redis會(huì)把每一個(gè)寫請(qǐng)求都記錄在一個(gè)日志文件里喂分。在Redis重啟時(shí)锦庸，會(huì)把AOF文件中記錄的所有寫操作順序執(zhí)行一遍，確保數(shù)據(jù)恢復(fù)到最新妻顶。

AOF默認(rèn)是關(guān)閉的酸员，如要開啟，進(jìn)行如下配置：

appendonly yes

AOF提供了三種fsync配置讳嘱，always/everysec/no幔嗦，通過配置項(xiàng)[appendfsync]指定：

  • appendfsync no：不進(jìn)行fsync，將flush文件的時(shí)機(jī)交給OS決定沥潭，速度最快
  • appendfsync always：每寫入一條日志就進(jìn)行一次fsync操作邀泉，數(shù)據(jù)安全性最高，但速度最慢
  • appendfsync everysec：折中的做法钝鸽，交由后臺(tái)線程每秒fsync一次

隨著AOF不斷地記錄寫操作日志汇恤，必定會(huì)出現(xiàn)一些無(wú)用的日志，例如某個(gè)時(shí)間點(diǎn)執(zhí)行了命令SET key1 "abc"拔恰，在之后某個(gè)時(shí)間點(diǎn)又執(zhí)行了SET key1 "bcd"夹厌，那么第一條命令很顯然是沒有用的歪泳。大量的無(wú)用日志會(huì)讓AOF文件過大，也會(huì)讓數(shù)據(jù)恢復(fù)的時(shí)間過長(zhǎng)。
所以Redis提供了AOF rewrite功能肄方，可以重寫AOF文件疾牲，只保留能夠把數(shù)據(jù)恢復(fù)到最新狀態(tài)的最小寫操作集变丧。
AOF rewrite可以通過BGREWRITEAOF命令觸發(fā)沙庐，也可以配置Redis定期自動(dòng)進(jìn)行：

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

上面兩行配置的含義是，Redis在每次AOF rewrite時(shí)咸这，會(huì)記錄完成rewrite后的AOF日志大小夷恍，當(dāng)AOF日志大小在該基礎(chǔ)上增長(zhǎng)了100%后，自動(dòng)進(jìn)行AOF rewrite媳维。同時(shí)如果增長(zhǎng)的大小沒有達(dá)到64mb酿雪，則不會(huì)進(jìn)行rewrite。

AOF的優(yōu)點(diǎn)：

  • 最安全侄刽，在啟用appendfsync always時(shí)执虹，任何已寫入的數(shù)據(jù)都不會(huì)丟失，使用在啟用appendfsync everysec也至多只會(huì)丟失1秒的數(shù)據(jù)唠梨。
  • AOF文件在發(fā)生斷電等問題時(shí)也不會(huì)損壞，即使出現(xiàn)了某條日志只寫入了一半的情況侥啤，也可以使用redis-check-aof工具輕松修復(fù)当叭。
  • AOF文件易讀茬故，可修改，在進(jìn)行了某些錯(cuò)誤的數(shù)據(jù)清除操作后蚁鳖，只要AOF文件沒有rewrite磺芭，就可以把AOF文件備份出來(lái)，把錯(cuò)誤的命令刪除醉箕，然后恢復(fù)數(shù)據(jù)钾腺。

AOF的缺點(diǎn)：

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

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

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

默認(rèn)情況下，在32位OS中讥裤，Redis最大使用3GB的內(nèi)存放棒，在64位OS中則沒有限制。

在使用Redis時(shí)己英，應(yīng)該對(duì)數(shù)據(jù)占用的最大空間有一個(gè)基本準(zhǔn)確的預(yù)估间螟，并為Redis設(shè)定最大使用的內(nèi)存。否則在64位OS中Redis會(huì)無(wú)限制地占用內(nèi)存（當(dāng)物理內(nèi)存被占滿后會(huì)使用swap空間）损肛，容易引發(fā)各種各樣的問題厢破。

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

maxmemory 100mb

在內(nèi)存占用達(dá)到了maxmemory后，再向Redis寫入數(shù)據(jù)時(shí)治拿，Redis會(huì)：

  • 根據(jù)配置的數(shù)據(jù)淘汰策略嘗試淘汰數(shù)據(jù)摩泪，釋放空間
  • 如果沒有數(shù)據(jù)可以淘汰，或者沒有配置數(shù)據(jù)淘汰策略劫谅，那么Redis會(huì)對(duì)所有寫請(qǐng)求返回錯(cuò)誤见坑，但讀請(qǐng)求仍然可以正常執(zhí)行

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

  • 如果采用了Redis的主從同步同波，主節(jié)點(diǎn)向從節(jié)點(diǎn)同步數(shù)據(jù)時(shí)鳄梅，會(huì)占用掉一部分內(nèi)存空間，如果maxmemory過于接近主機(jī)的可用內(nèi)存未檩，導(dǎo)致數(shù)據(jù)同步時(shí)內(nèi)存不足戴尸。所以設(shè)置的maxmemory不要過于接近主機(jī)可用的內(nèi)存，留出一部分預(yù)留用作主從同步冤狡。

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

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

  • volatile-lru：使用LRU算法進(jìn)行數(shù)據(jù)淘汰（淘汰上次使用時(shí)間最早的孙蒙，且使用次數(shù)最少的key），只淘汰設(shè)定了有效期的key
  • allkeys-lru：使用LRU算法進(jìn)行數(shù)據(jù)淘汰悲雳，所有的key都可以被淘汰
  • volatile-random：隨機(jī)淘汰數(shù)據(jù)挎峦，只淘汰設(shè)定了有效期的key
  • allkeys-random：隨機(jī)淘汰數(shù)據(jù)，所有的key都可以被淘汰
  • volatile-ttl：淘汰剩余有效期最短的key

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

一般來(lái)說(shuō)，推薦使用的策略是volatile-lru，并辨識(shí)Redis中保存的數(shù)據(jù)的重要性顿苇。對(duì)于那些重要的峭咒，絕對(duì)不能丟棄的數(shù)據(jù)（如配置類數(shù)據(jù)等），應(yīng)不設(shè)置有效期纪岁，這樣Redis就永遠(yuǎn)不會(huì)淘汰這些數(shù)據(jù)凑队。對(duì)于那些相對(duì)不是那么重要的，并且能夠熱加載的數(shù)據(jù)（比如緩存最近登錄的用戶信息幔翰，當(dāng)在Redis中找不到時(shí)漩氨，程序會(huì)去DB中讀取）遗增，可以設(shè)置上有效期叫惊，這樣在內(nèi)存不夠時(shí)Redis就會(huì)淘汰這部分?jǐn)?shù)據(jù)。

配置方法：

maxmemory-policy volatile-lru   #默認(rèn)是noeviction贡定，即不進(jìn)行數(shù)據(jù)淘汰

Pipelining

Pipelining

Redis提供許多批量操作的命令赋访，如MSET/MGET/HMSET/HMGET等等，這些命令存在的意義是減少維護(hù)網(wǎng)絡(luò)連接和傳輸數(shù)據(jù)所消耗的資源和時(shí)間缓待。
例如連續(xù)使用5次SET命令設(shè)置5個(gè)不同的key蚓耽，比起使用一次MSET命令設(shè)置5個(gè)不同的key，效果是一樣的旋炒，但前者會(huì)消耗更多的RTT(Round Trip Time)時(shí)長(zhǎng)步悠，永遠(yuǎn)應(yīng)優(yōu)先使用后者。

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

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

此時(shí)便可以使用Redis提供的pipelining功能來(lái)實(shí)現(xiàn)在一次交互中執(zhí)行多條命令。
使用pipelining時(shí)铣除，只需要從客戶端一次向Redis發(fā)送多條命令（以\r\n）分隔谚咬，Redis就會(huì)依次執(zhí)行這些命令，并且把每個(gè)命令的返回按順序組裝在一起一次返回尚粘，比如：

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

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

Pipelining的局限性

Pipelining只能用于執(zhí)行連續(xù)且無(wú)相關(guān)性的命令郎嫁，當(dāng)某個(gè)命令的生成需要依賴于前一個(gè)命令的返回時(shí)秉继，就無(wú)法使用Pipelining了。

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

事務(wù)與Scripting

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

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

> GET vCount
12384
> SET vCount 0
OK

如果在GET和SET命令之間插進(jìn)來(lái)一個(gè)INCR vCount杠茬，就會(huì)使客戶端拿到的vCount不準(zhǔn)確月褥。

Redis的事務(wù)可以確保復(fù)數(shù)命令執(zhí)行時(shí)的原子性。也就是說(shuō)Redis能夠保證：一個(gè)事務(wù)中的一組命令是絕對(duì)連續(xù)執(zhí)行的澈蝙，在這些命令執(zhí)行完成之前吓坚，絕對(duì)不會(huì)有來(lái)自于其他連接的其他命令插進(jìn)去執(zhí)行。

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

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

Redis在接收到MULTI命令后便會(huì)開啟一個(gè)事務(wù)灯荧，這之后的所有讀寫命令都會(huì)保存在隊(duì)列中但并不執(zhí)行，直到接收到EXEC命令后盐杂，Redis會(huì)把隊(duì)列中的所有命令連續(xù)順序執(zhí)行逗载，并以數(shù)組形式返回每個(gè)命令的返回結(jié)果。

可以使用DISCARD命令放棄當(dāng)前的事務(wù)链烈，將保存的命令隊(duì)列清空厉斟。

需要注意的是，Redis事務(wù)不支持回滾：
如果一個(gè)事務(wù)中的命令出現(xiàn)了語(yǔ)法錯(cuò)誤强衡，大部分客戶端驅(qū)動(dòng)會(huì)返回錯(cuò)誤擦秽，2.6.5版本以上的Redis也會(huì)在執(zhí)行EXEC時(shí)檢查隊(duì)列中的命令是否存在語(yǔ)法錯(cuò)誤，如果存在漩勤，則會(huì)自動(dòng)放棄事務(wù)并返回錯(cuò)誤感挥。
但如果一個(gè)事務(wù)中的命令有非語(yǔ)法類的錯(cuò)誤（比如對(duì)String執(zhí)行HSET操作），無(wú)論客戶端驅(qū)動(dòng)還是Redis都無(wú)法在真正執(zhí)行這條命令之前發(fā)現(xiàn)越败，所以事務(wù)中的所有命令仍然會(huì)被依次執(zhí)行触幼。在這種情況下，會(huì)出現(xiàn)一個(gè)事務(wù)中部分命令成功部分命令失敗的情況究飞，然而與RDBMS不同置谦，Redis不提供事務(wù)回滾的功能，所以只能通過其他方法進(jìn)行數(shù)據(jù)的回滾亿傅。

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

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

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

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

這一偽代碼執(zhí)行時(shí)葵擎，無(wú)法確保并發(fā)安全性谅阿，有可能多個(gè)客戶端都獲取到了"in stock"的狀態(tài)，導(dǎo)致一個(gè)庫(kù)存被售賣多次坪蚁。

使用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的機(jī)制是：在事務(wù)EXEC命令執(zhí)行時(shí)奔穿，Redis會(huì)檢查被WATCH的key，只有被WATCH的key從WATCH起始時(shí)至今沒有發(fā)生過變更敏晤，EXEC才會(huì)被執(zhí)行贱田。如果WATCH的key在WATCH命令到EXEC命令之間發(fā)生過變化嘴脾，則EXEC命令會(huì)返回失敗拇颅。

Scripting

通過EVAL與EVALSHA命令黄锤，可以讓Redis執(zhí)行LUA腳本负甸。這就類似于RDBMS的存儲(chǔ)過程一樣，可以把客戶端與Redis之間密集的讀/寫交互放在服務(wù)端進(jìn)行，避免過多的數(shù)據(jù)交互千绪，提升性能。

Scripting功能是作為事務(wù)功能的替代者誕生的辕狰，事務(wù)提供的所有能力Scripting都可以做到。Redis官方推薦使用LUA Script來(lái)代替事務(wù)，前者的效率和便利性都超過了事務(wù)环疼。

關(guān)于Scripting的具體使用等限，本文不做詳細(xì)介紹锰霜，請(qǐng)參考官方文檔 https://redis.io/commands/eval

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

盡管Redis是一個(gè)非车簧牛快速的內(nèi)存數(shù)據(jù)存儲(chǔ)媒介勇皇，也并不代表Redis不會(huì)產(chǎn)生性能問題着撩。
前文中提到過咖气，Redis采用單線程模型，所有的命令都是由一個(gè)線程串行執(zhí)行的钧椰，所以當(dāng)某個(gè)命令執(zhí)行耗時(shí)較長(zhǎng)時(shí)，會(huì)拖慢其后的所有命令寄锐，這使得Redis對(duì)每個(gè)任務(wù)的執(zhí)行效率更加敏感。

針對(duì)Redis的性能優(yōu)化磷杏，主要從下面幾個(gè)層面入手：

  • 最初的也是最重要的，確保沒有讓Redis執(zhí)行耗時(shí)長(zhǎng)的命令
  • 使用pipelining將連續(xù)執(zhí)行的命令組合執(zhí)行
  • 操作系統(tǒng)的Transparent huge pages功能必須關(guān)閉：
echo never > /sys/kernel/mm/transparent_hugepage/enabled
  • 如果在虛擬機(jī)中運(yùn)行Redis遥金，可能天然就有虛擬機(jī)環(huán)境帶來(lái)的固有延遲浴捆。可以通過./redis-cli --intrinsic-latency 100命令查看固有延遲稿械。同時(shí)如果對(duì)Redis的性能有較高要求的話选泻，應(yīng)盡可能在物理機(jī)上直接部署Redis。
  • 檢查數(shù)據(jù)持久化策略
  • 考慮引入讀寫分離機(jī)制

長(zhǎng)耗時(shí)命令

Redis絕大多數(shù)讀寫命令的時(shí)間復(fù)雜度都在O(1)到O(N)之間美莫，在文本和官方文檔中均對(duì)每個(gè)命令的時(shí)間復(fù)雜度有說(shuō)明滔金。

通常來(lái)說(shuō)，O(1)的命令是安全的茂嗓，O(N)命令在使用時(shí)需要注意，如果N的數(shù)量級(jí)不可預(yù)知科阎，則應(yīng)避免使用述吸。例如對(duì)一個(gè)field數(shù)未知的Hash數(shù)據(jù)執(zhí)行HGETALL/HKEYS/HVALS命令，通常來(lái)說(shuō)這些命令執(zhí)行的很快锣笨，但如果這個(gè)Hash中的field數(shù)量極多蝌矛，耗時(shí)就會(huì)成倍增長(zhǎng)。
又如使用SUNION對(duì)兩個(gè)Set執(zhí)行Union操作错英，或使用SORT對(duì)List/Set執(zhí)行排序操作等時(shí)入撒，都應(yīng)該嚴(yán)加注意。

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

  • 不要把List當(dāng)做列表使用椭岩，僅當(dāng)做隊(duì)列來(lái)使用
  • 通過機(jī)制嚴(yán)格控制Hash茅逮、Set、Sorted Set的大小
  • 可能的話判哥，將排序献雅、并集、交集等操作放在客戶端執(zhí)行
  • 絕對(duì)禁止使用KEYS命令
  • 避免一次性遍歷集合類型的所有成員塌计，而應(yīng)使用SCAN類的命令進(jìn)行分批的挺身，游標(biāo)式的遍歷

Redis提供了SCAN命令，可以對(duì)Redis中存儲(chǔ)的所有key進(jìn)行游標(biāo)式的遍歷锌仅，避免使用KEYS命令帶來(lái)的性能問題章钾。同時(shí)還有SSCAN/HSCAN/ZSCAN等命令墙贱，分別用于對(duì)Set/Hash/Sorted Set中的元素進(jìn)行游標(biāo)式遍歷。SCAN類命令的使用請(qǐng)參考官方文檔：https://redis.io/commands/scan

Redis提供了Slow Log功能贱傀，可以自動(dòng)記錄耗時(shí)較長(zhǎng)的命令惨撇。相關(guān)的配置參數(shù)有兩個(gè)：

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

使用SLOWLOG GET [number]命令窍箍，可以輸出最近進(jìn)入Slow Log的number條命令串纺。
使用SLOWLOG RESET命令，可以重置Slow Log

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

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

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

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

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

Redis在fork子進(jìn)程時(shí)需要將內(nèi)存分頁(yè)表拷貝至子進(jìn)程吁津，以占用了24GB內(nèi)存的Redis實(shí)例為例棚蓄，共需要拷貝24GB / 4kB * 8 = 48MB的數(shù)據(jù)。在使用單Xeon 2.27Ghz的物理機(jī)上碍脏，這一fork操作耗時(shí)216ms梭依。

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

Swap引發(fā)的延遲

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

/proc/<pid>/smaps文件中會(huì)保存進(jìn)程的swap記錄河闰，通過查看這個(gè)文件，能夠判斷Redis的延遲是否由Swap產(chǎn)生褥紫。如果這個(gè)文件中記錄了較大的Swap size淤击，則說(shuō)明延遲很有可能是Swap造成的。

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

當(dāng)同一秒內(nèi)有大量key過期時(shí)故源，也會(huì)引發(fā)Redis的延遲污抬。在使用時(shí)應(yīng)盡量將key的失效時(shí)間錯(cuò)開。

引入讀寫分離機(jī)制

Redis的主從復(fù)制能力可以實(shí)現(xiàn)一主多從的多節(jié)點(diǎn)架構(gòu)，在這一架構(gòu)下印机，主節(jié)點(diǎn)接收所有寫請(qǐng)求矢腻，并將數(shù)據(jù)同步給多個(gè)從節(jié)點(diǎn)。
在這一基礎(chǔ)上射赛，我們可以讓從節(jié)點(diǎn)提供對(duì)實(shí)時(shí)性要求不高的讀請(qǐng)求服務(wù)多柑，以減小主節(jié)點(diǎn)的壓力。
尤其是針對(duì)一些使用了長(zhǎng)耗時(shí)命令的統(tǒng)計(jì)類任務(wù)楣责，完全可以指定在一個(gè)或多個(gè)從節(jié)點(diǎn)上執(zhí)行竣灌，避免這些長(zhǎng)耗時(shí)命令影響其他請(qǐng)求的響應(yīng)。

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

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

主從復(fù)制

Redis支持一主多從的主從復(fù)制架構(gòu)初嘹。一個(gè)Master實(shí)例負(fù)責(zé)處理所有的寫請(qǐng)求，Master將寫操作同步至所有Slave沮趣。
借助Redis的主從復(fù)制屯烦，可以實(shí)現(xiàn)讀寫分離和高可用：

  • 實(shí)時(shí)性要求不是特別高的讀請(qǐng)求，可以在Slave上完成房铭，提升效率驻龟。特別是一些周期性執(zhí)行的統(tǒng)計(jì)任務(wù)，這些任務(wù)可能需要執(zhí)行一些長(zhǎng)耗時(shí)的Redis命令缸匪，可以專門規(guī)劃出1個(gè)或幾個(gè)Slave用于服務(wù)這些統(tǒng)計(jì)任務(wù)
  • 借助Redis Sentinel可以實(shí)現(xiàn)高可用翁狐，當(dāng)Master crash后，Redis Sentinel能夠自動(dòng)將一個(gè)Slave晉升為Master凌蔬，繼續(xù)提供服務(wù)

啟用主從復(fù)制非常簡(jiǎn)單谴蔑，只需要配置多個(gè)Redis實(shí)例，在作為Slave的Redis實(shí)例中配置：

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

當(dāng)Slave啟動(dòng)后龟梦，會(huì)從Master進(jìn)行一次冷啟動(dòng)數(shù)據(jù)同步，由Master觸發(fā)BGSAVE生成RDB文件推送給Slave進(jìn)行導(dǎo)入窃躲，導(dǎo)入完成后Master再將增量數(shù)據(jù)通過Redis Protocol同步給Slave计贰。之后主從之間的數(shù)據(jù)便一直以Redis Protocol進(jìn)行同步

使用Sentinel做自動(dòng)failover

Redis的主從復(fù)制功能本身只是做數(shù)據(jù)同步，并不提供監(jiān)控和自動(dòng)failover能力蒂窒，要通過主從復(fù)制功能來(lái)實(shí)現(xiàn)Redis的高可用躁倒，還需要引入一個(gè)組件：Redis Sentinel

Redis Sentinel是Redis官方開發(fā)的監(jiān)控組件，可以監(jiān)控Redis實(shí)例的狀態(tài)洒琢，通過Master節(jié)點(diǎn)自動(dòng)發(fā)現(xiàn)Slave節(jié)點(diǎn)秧秉，并在監(jiān)測(cè)到Master節(jié)點(diǎn)失效時(shí)選舉出一個(gè)新的Master，并向所有Redis實(shí)例推送新的主從配置衰抑。

Redis Sentinel需要至少部署3個(gè)實(shí)例才能形成選舉關(guān)系象迎。

關(guān)鍵配置：

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

另外需要注意的是，Redis Sentinel實(shí)現(xiàn)的自動(dòng)failover不是在同一個(gè)IP和端口上完成的汪厨，也就是說(shuō)自動(dòng)failover產(chǎn)生的新Master提供服務(wù)的IP和端口與之前的Master是不一樣的赃春，所以要實(shí)現(xiàn)HA，還要求客戶端必須支持Sentinel劫乱，能夠與Sentinel交互獲得新Master的信息才行织中。

集群分片

為何要做集群分片：

  • Redis中存儲(chǔ)的數(shù)據(jù)量大，一臺(tái)主機(jī)的物理內(nèi)存已經(jīng)無(wú)法容納
  • Redis的寫請(qǐng)求并發(fā)量大衷戈，一個(gè)Redis實(shí)例以無(wú)法承載

當(dāng)上述兩個(gè)問題出現(xiàn)時(shí)狭吼，就必須要對(duì)Redis進(jìn)行分片了。
Redis的分片方案有很多種脱惰，例如很多Redis的客戶端都自行實(shí)現(xiàn)了分片功能搏嗡，也有向Twemproxy這樣的以代理方式實(shí)現(xiàn)的Redis分片方案。然而首選的方案還應(yīng)該是Redis官方在3.0版本中推出的Redis Cluster分片方案拉一。

本文不會(huì)對(duì)Redis Cluster的具體安裝和部署細(xì)節(jié)進(jìn)行介紹采盒，重點(diǎn)介紹Redis Cluster帶來(lái)的好處與弊端。

Redis Cluster的能力

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

其中第三點(diǎn)是基于主從復(fù)制來(lái)實(shí)現(xiàn)的磅氨，Redis Cluster的每個(gè)數(shù)據(jù)分片都采用了主從復(fù)制的結(jié)構(gòu)，原理和前文所述的主從復(fù)制完全一致嫡纠，唯一的區(qū)別是省去了Redis Sentinel這一額外的組件烦租，由Redis Cluster負(fù)責(zé)進(jìn)行一個(gè)分片內(nèi)部的節(jié)點(diǎn)監(jiān)控和自動(dòng)failover。

Redis Cluster分片原理

Redis Cluster中共有16384個(gè)hash slot除盏，Redis會(huì)計(jì)算每個(gè)key的CRC16叉橱，將結(jié)果與16384取模，來(lái)決定該key存儲(chǔ)在哪一個(gè)hash slot中者蠕，同時(shí)需要指定Redis Cluster中每個(gè)數(shù)據(jù)分片負(fù)責(zé)的Slot數(shù)窃祝。Slot的分配在任何時(shí)間點(diǎn)都可以進(jìn)行重新分配。

客戶端在對(duì)key進(jìn)行讀寫操作時(shí)踱侣，可以連接Cluster中的任意一個(gè)分片粪小，如果操作的key不在此分片負(fù)責(zé)的Slot范圍內(nèi)，Redis Cluster會(huì)自動(dòng)將請(qǐng)求重定向到正確的分片上抡句。

hash tags

在基礎(chǔ)的分片原則上探膊，Redis還支持hash tags功能，以hash tags要求的格式明明的key待榔，將會(huì)確保進(jìn)入同一個(gè)Slot中逞壁。例如：{uiv}user:1000和{uiv}user:1001擁有同樣的hash tag {uiv}，會(huì)保存在同一個(gè)Slot中。

使用Redis Cluster時(shí)猾担，pipelining袭灯、事務(wù)和LUA Script功能涉及的key必須在同一個(gè)數(shù)據(jù)分片上，否則將會(huì)返回錯(cuò)誤绑嘹。如要在Redis Cluster中使用上述功能稽荧，就必須通過hash tags來(lái)確保一個(gè)pipeline或一個(gè)事務(wù)中操作的所有key都位于同一個(gè)Slot中。

有一些客戶端（如Redisson）實(shí)現(xiàn)了集群化的pipelining操作工腋，可以自動(dòng)將一個(gè)pipeline里的命令按key所在的分片進(jìn)行分組姨丈，分別發(fā)到不同的分片上執(zhí)行。但是Redis不支持跨分片的事務(wù)擅腰，事務(wù)和LUA Script還是必須遵循所有key在一個(gè)分片上的規(guī)則要求蟋恬。

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

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

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

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

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

并不是渗勘。

軟件架構(gòu)永遠(yuǎn)不是越復(fù)雜越好沐绒，復(fù)雜的架構(gòu)在帶來(lái)顯著好處的同時(shí)，一定也會(huì)帶來(lái)相應(yīng)的弊端旺坠。采用Redis Cluster的弊端包括：

  • 維護(hù)難度增加乔遮。在使用Redis Cluster時(shí)，需要維護(hù)的Redis實(shí)例數(shù)倍增取刃，需要監(jiān)控的主機(jī)數(shù)量也相應(yīng)增加蹋肮，數(shù)據(jù)備份/持久化的復(fù)雜度也會(huì)增加。同時(shí)在進(jìn)行分片的增減操作時(shí)璧疗，還需要進(jìn)行reshard操作坯辩，遠(yuǎn)比主從模式下增加一個(gè)Slave的復(fù)雜度要高。
  • 客戶端資源消耗增加崩侠。當(dāng)客戶端使用連接池時(shí)漆魔，需要為每一個(gè)數(shù)據(jù)分片維護(hù)一個(gè)連接池，客戶端同時(shí)需要保持的連接數(shù)成倍增多啦膜，加大了客戶端本身和操作系統(tǒng)資源的消耗。
  • 性能優(yōu)化難度增加淌喻。你可能需要在多個(gè)分片上查看Slow Log和Swap日志才能定位性能問題僧家。
  • 事務(wù)和LUA Script的使用成本增加。在Redis Cluster中使用事務(wù)和LUA Script特性有嚴(yán)格的限制條件裸删，事務(wù)和Script中操作的key必須位于同一個(gè)分片上八拱，這就使得在開發(fā)時(shí)必須對(duì)相應(yīng)場(chǎng)景下涉及的key進(jìn)行額外的規(guī)劃和規(guī)范要求。如果應(yīng)用的場(chǎng)景中大量涉及事務(wù)和Script的使用，如何在保證這兩個(gè)功能的正常運(yùn)作前提下把數(shù)據(jù)平均分到多個(gè)數(shù)據(jù)分片中就會(huì)成為難點(diǎn)肌稻。

所以說(shuō)清蚀，在主從復(fù)制和集群分片兩個(gè)方案中做出選擇時(shí)，應(yīng)該從應(yīng)用軟件的功能特性爹谭、數(shù)據(jù)和訪問量級(jí)枷邪、未來(lái)發(fā)展規(guī)劃等方面綜合考慮，只在確實(shí)有必要引入數(shù)據(jù)分片時(shí)再使用Redis Cluster诺凡。
下面是一些建議：

  1. 需要在Redis中存儲(chǔ)的數(shù)據(jù)有多大东揣？未來(lái)2年內(nèi)可能發(fā)展為多大？這些數(shù)據(jù)是否都需要長(zhǎng)期保存腹泌？是否可以使用LRU算法進(jìn)行非熱點(diǎn)數(shù)據(jù)的淘汰嘶卧？綜合考慮前面幾個(gè)因素，評(píng)估出Redis需要使用的物理內(nèi)存凉袱。
  2. 用于部署Redis的主機(jī)物理內(nèi)存有多大芥吟？有多少可以分配給Redis使用？對(duì)比(1)中的內(nèi)存需求評(píng)估专甩，是否足夠用钟鸵？
  3. Redis面臨的并發(fā)寫壓力會(huì)有多大？在不使用pipelining時(shí)配深，Redis的寫性能可以超過10萬(wàn)次/秒（更多的benchmark可以參考 https://redis.io/topics/benchmarks ）
  4. 在使用Redis時(shí)携添，是否會(huì)使用到pipelining和事務(wù)功能？使用的場(chǎng)景多不多篓叶？

綜合上面幾點(diǎn)考慮烈掠，如果單臺(tái)主機(jī)的可用物理內(nèi)存完全足以支撐對(duì)Redis的容量需求，且Redis面臨的并發(fā)寫壓力距離Benchmark值還尚有距離缸托，建議采用主從復(fù)制的架構(gòu)左敌，可以省去很多不必要的麻煩。同時(shí)俐镐，如果應(yīng)用中大量使用pipelining和事務(wù)矫限，也建議盡可能選擇主從復(fù)制架構(gòu)，可以減少設(shè)計(jì)和開發(fā)時(shí)的復(fù)雜度佩抹。

Redis Java客戶端的選擇

Redis的Java客戶端很多叼风，官方推薦的有三種：Jedis、Redisson和lettuce棍苹。

在這里對(duì)Jedis和Redisson進(jìn)行對(duì)比介紹

Jedis：

  • 輕量无宿，簡(jiǎn)潔，便于集成和改造
  • 支持連接池
  • 支持pipelining枢里、事務(wù)孽鸡、LUA Scripting蹂午、Redis Sentinel、Redis Cluster
  • 不支持讀寫分離彬碱，需要自己實(shí)現(xiàn)
  • 文檔差（真的很差豆胸，幾乎沒有……）

Redisson：

  • 基于Netty實(shí)現(xiàn)，采用非阻塞IO巷疼，性能高
  • 支持異步請(qǐng)求
  • 支持連接池
  • 支持pipelining晚胡、LUA Scripting、Redis Sentinel皮迟、Redis Cluster
  • 不支持事務(wù)搬泥，官方建議以LUA Scripting代替事務(wù)
  • 支持在Redis Cluster架構(gòu)下使用pipelining
  • 支持讀寫分離，支持讀負(fù)載均衡伏尼，在主從復(fù)制和Redis Cluster架構(gòu)下都可以使用
  • 內(nèi)建Tomcat Session Manager忿檩，為Tomcat 6/7/8提供了會(huì)話共享功能
  • 可以與Spring Session集成，實(shí)現(xiàn)基于Redis的會(huì)話共享
  • 文檔較豐富爆阶，有中文文檔

對(duì)于Jedis和Redisson的選擇燥透，同樣應(yīng)遵循前述的原理，盡管Jedis比起Redisson有各種各樣的不足辨图，但也應(yīng)該在需要使用Redisson的高級(jí)特性時(shí)再選用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

作者：kelgon
鏈接：http://www.reibang.com/p/2f14bc570563
來(lái)源：簡(jiǎn)書
著作權(quán)歸作者所有故河。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)吱韭，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 人面猴
    序言：七十年代末鱼的，一起剝皮案震驚了整個(gè)濱河市理盆，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌凑阶，老刑警劉巖猿规，帶你破解...
    沈念sama閱讀 207,248評(píng)論 6贊 481
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場(chǎng)離奇詭異宙橱，居然都是意外死亡姨俩，警方通過查閱死者的電腦和手機(jī)，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,681評(píng)論 2贊 381
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門师郑，熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái)环葵，“玉大人，你說(shuō)我怎么就攤上這事宝冕≌旁猓” “怎么了？”我有些...
    開封第一講書人閱讀 153,443評(píng)論 0贊 344
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵猬仁，是天一觀的道長(zhǎng)帝璧。 經(jīng)常有香客問我，道長(zhǎng)湿刽，這世上最難降的妖魔是什么的烁？ 我笑而不...
    開封第一講書人閱讀 55,475評(píng)論 1贊 279
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮诈闺，結(jié)果婚禮上渴庆，老公的妹妹穿的比我還像新娘。我一直安慰自己雅镊，他們只是感情好襟雷，可當(dāng)我...
    茶點(diǎn)故事閱讀 64,458評(píng)論 5贊 374
  • 惡毒庶女頂嫁案：這布局不是一般人想出來(lái)的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著仁烹，像睡著了一般耸弄。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上卓缰，一...
    開封第一講書人閱讀 49,185評(píng)論 1贊 284
  • 城市分裂傳說(shuō)
    那天计呈，我揣著相機(jī)與錄音，去河邊找鬼征唬。 笑死捌显，一個(gè)胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的总寒。 我是一名探鬼主播扶歪，決...
    沈念sama閱讀 38,451評(píng)論 3贊 401
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長(zhǎng)吁一口氣：“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼摄闸！你這毒婦竟也來(lái)了善镰？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 37,112評(píng)論 0贊 261
  • 萬(wàn)榮殺人案實(shí)錄
    序言：老撾萬(wàn)榮一對(duì)情侶失蹤贪薪，失蹤者是張志新（化名）和其女友劉穎媳禁，沒想到半個(gè)月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體画切，經(jīng)...
    沈念sama閱讀 43,609評(píng)論 1贊 300
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡竣稽，尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 36,083評(píng)論 2贊 325
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了霍弹。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片毫别。...
    茶點(diǎn)故事閱讀 38,163評(píng)論 1贊 334
  • 活死人
    序言：一個(gè)原本活蹦亂跳的男人離奇死亡，死狀恐怖典格，靈堂內(nèi)的尸體忽然破棺而出岛宦，到底是詐尸還是另有隱情，我是刑警寧澤耍缴，帶...
    沈念sama閱讀 33,803評(píng)論 4贊 323
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布砾肺，位于F島的核電站挽霉，受9級(jí)特大地震影響，放射性物質(zhì)發(fā)生泄漏变汪。R本人自食惡果不足惜侠坎，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,357評(píng)論 3贊 307
  • 男人毒藥：我在死后第九天來(lái)索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望裙盾。 院中可真熱鬧实胸，春花似錦、人聲如沸番官。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,357評(píng)論 0贊 19
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)徘熔。三九已至门躯，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間酷师，已是汗流浹背生音。 一陣腳步聲響...
    開封第一講書人閱讀 31,590評(píng)論 1贊 261
  • 情欲美人皮
    我被黑心中介騙來(lái)泰國(guó)打工， 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留窒升，地道東北人缀遍。 一個(gè)月前我還...
    沈念sama閱讀 45,636評(píng)論 2贊 355
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長(zhǎng)得像饱须，于是被迫代替她去往敵國(guó)和親域醇。 傳聞我的和親對(duì)象是個(gè)殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 42,925評(píng)論 2贊 344

推薦閱讀更多精彩內(nèi)容