Redis是?單進(jìn)程單線(xiàn)程?的，Redis利用隊(duì)列技術(shù)將并發(fā)訪(fǎng)問(wèn)變?yōu)榇性L(fǎng)問(wèn)，消除了傳統(tǒng)數(shù)據(jù)庫(kù)串行控制的開(kāi)銷(xiāo)。

Redis為什么是單線(xiàn)程的？

多線(xiàn)程處理會(huì)涉及到鎖，而且多線(xiàn)程處理會(huì)設(shè)計(jì)到線(xiàn)程切換而消耗CPU。因?yàn)镃PU不會(huì)Redis的瓶頸，Redis的瓶頸最有可能是機(jī)器內(nèi)存或者網(wǎng)絡(luò)帶寬。單線(xiàn)程無(wú)法發(fā)揮多核CPU性能，不過(guò)可以通過(guò)在單機(jī)開(kāi)啟Redis實(shí)例來(lái)解決。

Redis的優(yōu)勢(shì)

**速度快。**因?yàn)閿?shù)據(jù)存儲(chǔ)于內(nèi)存中，類(lèi)似于HashMap，HashMap的優(yōu)勢(shì)就是查找和操作的時(shí)間復(fù)雜度都是O(1)

支持豐富的數(shù)據(jù)類(lèi)型?，支持string，list，set，sorted set，hash

支持事務(wù)?，操作都是原子性，所謂的原子性就是對(duì)數(shù)據(jù)的更改要么全部執(zhí)行，要么全部不執(zhí)行

豐富的特性?：可用于緩存，消息，按key設(shè)置過(guò)期時(shí)間，過(guò)期后將會(huì)自動(dòng)刪除

Redis和memcached有哪些優(yōu)勢(shì)

memcached所有的值均是簡(jiǎn)單的字符串，Reids作為其替代者，支持更為豐富的數(shù)據(jù)類(lèi)型

Redis的速度比memcached快很多

Redis可以持久化其數(shù)據(jù)

Redis支持?jǐn)?shù)據(jù)的備份，即master/slave模式的數(shù)據(jù)備份

Redis key的過(guò)期時(shí)間和永久有效分別怎么設(shè)置？

EXPIRE 和 PERSIST 命令。

Redis 主要消耗什么物理資源？

內(nèi)存。

為什么Redis需要把所有數(shù)據(jù)放到內(nèi)存中？

Redis為了達(dá)到最快的讀寫(xiě)速度將數(shù)據(jù)都讀到內(nèi)存中，并通過(guò)異步的方式將數(shù)據(jù)寫(xiě)入磁盤(pán)。

所以redis具有快速和數(shù)據(jù)持久化的特征。如果不將數(shù)據(jù)放在內(nèi)存中，磁盤(pán)I/O速度為嚴(yán)重影響redis的性能。

在內(nèi)存越來(lái)越便宜的今天，redis將會(huì)越來(lái)越受歡迎。 如果設(shè)置了最大使用的內(nèi)存，則數(shù)據(jù)已有記錄數(shù)達(dá)到內(nèi)存限值后不能繼續(xù)插入新值。

說(shuō)說(shuō)Redis哈希槽的概念？

Redis集群沒(méi)有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384個(gè)哈希槽，每個(gè)key通過(guò)CRC16校驗(yàn)后對(duì)16384取模來(lái)決定放置哪個(gè)槽，集群的每個(gè)節(jié)點(diǎn)負(fù)責(zé)一部分hash槽。

Redis中的管道有什么用？

一次請(qǐng)求/響應(yīng)服務(wù)器能實(shí)現(xiàn)處理新的請(qǐng)求即使舊的請(qǐng)求還未被響應(yīng)。這樣就可以將多個(gè)命令發(fā)送到服務(wù)器，而不用等待回復(fù)，最后在一個(gè)步驟中讀取該答復(fù)。

這就是管道（pipelining），是一種幾十年來(lái)廣泛使用的技術(shù)。例如許多POP3協(xié)議已經(jīng)實(shí)現(xiàn)支持這個(gè)功能，大大加快了從服務(wù)器下載新郵件的過(guò)程。

怎么理解Redis事務(wù)？

事務(wù)是一個(gè)單獨(dú)的隔離操作：事務(wù)中的所有命令都會(huì)序列化、按順序地執(zhí)行。事務(wù)在執(zhí)行的過(guò)程中，不會(huì)被其他客戶(hù)端發(fā)送來(lái)的命令請(qǐng)求所打斷。

事務(wù)是一個(gè)原子操作：事務(wù)中的命令要么全部被執(zhí)行，要么全部都不執(zhí)行。

Redis 事務(wù)相關(guān)的命令有哪幾個(gè)？

MULTI 、 EXEC 、 DISCARD 、 WATCH

Redis內(nèi)存回收機(jī)制

Redis的內(nèi)存回收主要圍繞以下兩個(gè)方面：

Redis過(guò)期策略?：刪除過(guò)期時(shí)間的key值

Redis淘汰策略?：內(nèi)存使用到達(dá)maxmemory上限時(shí)觸發(fā)內(nèi)存淘汰數(shù)據(jù)

Redis過(guò)期策略

Redis過(guò)期策略通常有以下三種：

定時(shí)過(guò)期每個(gè)設(shè)置過(guò)期時(shí)間的key都需要?jiǎng)?chuàng)建一個(gè)定時(shí)器，到過(guò)期時(shí)間就會(huì)立即清除。該策略可以立即清除過(guò)期的數(shù)據(jù)，對(duì)內(nèi)存很友好；但是會(huì)占用大量的CPU資源去處理過(guò)期的數(shù)據(jù)，從而影響緩存的響應(yīng)時(shí)間和吞吐量。

惰性過(guò)期只有當(dāng)訪(fǎng)問(wèn)一個(gè)key時(shí)，才會(huì)判斷該key是否已過(guò)期，過(guò)期則清除。該策略可以最大化地節(jié)省CPU資源，卻對(duì)內(nèi)存非常不友好。極端情況可能出現(xiàn)大量的過(guò)期key沒(méi)有再次被訪(fǎng)問(wèn)，從而不會(huì)被清除，占用大量?jī)?nèi)存。

定期過(guò)期每隔一定的時(shí)間，會(huì)掃描一定數(shù)量的數(shù)據(jù)庫(kù)的expires字典中一定數(shù)量的key，并清除其中已過(guò)期的key。該策略是前兩者的一個(gè)折中方案。通過(guò)調(diào)整定時(shí)掃描的時(shí)間間隔和每次掃描的限定耗時(shí)，可以在不同情況下使得CPU和內(nèi)存資源達(dá)到最優(yōu)的平衡效果。

Redis中同時(shí)使用了?惰性過(guò)期?和?定期過(guò)期?兩種過(guò)期策略。

Redis有哪幾種數(shù)據(jù)淘汰策略

在Redis中，允許用戶(hù)設(shè)置最大使用內(nèi)存大小 server.maxmemory ，當(dāng)Redis內(nèi)存數(shù)據(jù)集大小上升到一定大小的時(shí)候，就會(huì)執(zhí)行數(shù)據(jù)淘汰策略

volatile-lru?：從已設(shè)置過(guò)期的數(shù)據(jù)集中挑選最近最少使用的淘汰

volatile-ttl?：從已設(shè)置過(guò)期的數(shù)據(jù)集中挑選將要過(guò)期的數(shù)據(jù)淘汰

volatile-random?：從已設(shè)置過(guò)期的數(shù)據(jù)集中任意挑選數(shù)據(jù)淘汰

allkeys-lru?：從數(shù)據(jù)集中挑選最近最少使用的數(shù)據(jù)淘汰

allkeys-random?：從數(shù)據(jù)集中任意挑選數(shù)據(jù)淘汰

noenviction?：禁止淘汰數(shù)據(jù)

Redis支持哪幾種持久化方式

RDB持久化原理是將Redis在內(nèi)存中的數(shù)據(jù)記錄定時(shí)dump到磁盤(pán)上的RDB文件。 指定的時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫(xiě)入磁盤(pán)，實(shí)際操作過(guò)程是fork一個(gè)子進(jìn)程，先將數(shù)據(jù)集寫(xiě)入臨時(shí)文件，寫(xiě)入成功后，再替換之前的文件，用二進(jìn)制壓縮存儲(chǔ)。

AOF（append only file）持久化原理是將Redis的操作日志以追加的方式寫(xiě)入文件。 以日志的形式記錄服務(wù)器所處理的每一個(gè)寫(xiě)、刪除操作，查詢(xún)操作不會(huì)記錄，以文本的方式記錄，可以打開(kāi)文件看到詳細(xì)的操作記錄。當(dāng)服務(wù)器重啟的時(shí)候會(huì)重新執(zhí)行這些命令來(lái)恢復(fù)原始的數(shù)據(jù)。AOF命令以Reids協(xié)議追加保存每次寫(xiě)的操作到文件末尾。Redis還能對(duì)AOF文件進(jìn)行后臺(tái)重寫(xiě)，使得AOF文件的體積不至于過(guò)大。

Redis兩種持久化方式優(yōu)缺點(diǎn)？

RDB持久化

優(yōu)點(diǎn)：RDB文件緊湊，體積小，網(wǎng)絡(luò)傳輸快，適合全量復(fù)制；恢復(fù)速度比AOF快很多。當(dāng)然，與AOF相比，RDB最重要的優(yōu)點(diǎn)之一是對(duì)性能的影響相對(duì)較小

缺點(diǎn)：RDB文件的致命缺點(diǎn)在與其數(shù)據(jù)快照的持久化方式?jīng)Q定了必然做不到實(shí)時(shí)持久化，而在數(shù)據(jù)越來(lái)越重要的今天，數(shù)據(jù)的大量丟失很多時(shí)候是無(wú)法接受的，因此AOF持久化稱(chēng)為主流。此外，RDB文件需要滿(mǎn)足特定格式，兼容性差。

AOF持久化與RDB持久化相對(duì)應(yīng),AOF的優(yōu)點(diǎn)在于支持秒級(jí)持久化、兼容性好，缺點(diǎn)是文件大，恢復(fù)速度慢，對(duì)性能影響大

如何選擇Redis持久化方式策略？

在介紹持久化策略之前，首先要明白無(wú)論是RDB還是AOF，持久化的開(kāi)啟都是要付出性能方面的代價(jià)的。對(duì)比RDB持久化，一方面是bdsave在進(jìn)行fork操作時(shí)Redis主進(jìn)程會(huì)阻塞，另一方面，子進(jìn)程向硬盤(pán)寫(xiě)數(shù)據(jù)也會(huì)帶來(lái)IO壓力；對(duì)于A(yíng)OF持久化，向硬盤(pán)寫(xiě)數(shù)據(jù)的頻率大大提高（everysec策略下為秒級(jí)），IO壓力更大，設(shè)置可能造成AOF追加阻塞文件。此外，AOF文件的重寫(xiě)與RDB的basave類(lèi)似，會(huì)有fork時(shí)的阻塞和子進(jìn)程的IO壓力問(wèn)題。相對(duì)來(lái)說(shuō)，由于A(yíng)OF向硬盤(pán)中寫(xiě)數(shù)據(jù)的頻率更高，因此對(duì)Redis主進(jìn)程性能的影響會(huì)更大。

在實(shí)際生產(chǎn)環(huán)境中，根據(jù)數(shù)據(jù)量、應(yīng)用對(duì)數(shù)據(jù)的安全要求、預(yù)算限制等不同情況，會(huì)有各種各樣的持久化策略；如完全不使用任何持久化，使用RDB或AOF一種，或同事開(kāi)啟RDB和AOF持久化等。此外，持久化的選擇必須與Redis的主從策略一起考慮，因?yàn)橹鲝膹?fù)制與持久化同樣具有數(shù)據(jù)備份的功能，而且主機(jī)master和從機(jī)slave可以獨(dú)立的選擇持久化方案。

為什么要做Redis分區(qū)？

分區(qū)可以讓Redis管理更大的內(nèi)存，Redis將可以使用所有機(jī)器的內(nèi)存。如果沒(méi)有分區(qū)，你最多只能使用一臺(tái)機(jī)器的內(nèi)存。分區(qū)使Redis的計(jì)算能力通過(guò)簡(jiǎn)單地增加計(jì)算機(jī)得到成倍提升,Redis的網(wǎng)絡(luò)帶寬也會(huì)隨著計(jì)算機(jī)和網(wǎng)卡的增加而成倍增長(zhǎng)。

Redis集群的主從復(fù)制模型是怎樣的？

為了是在部分節(jié)點(diǎn)失敗或者大部分節(jié)點(diǎn)無(wú)法通信的情況下集群仍然可用，所以集群是用了主從復(fù)制模型，每個(gè)節(jié)點(diǎn)都會(huì)有N-1個(gè)復(fù)制品

Redis集群會(huì)有寫(xiě)操作丟失嗎？為什么？

Redis并不能保證數(shù)據(jù)強(qiáng)一致性，這意味著在實(shí)際中集群在特定的條件下可能會(huì)丟失寫(xiě)操作

Redis集群之間是如何復(fù)制的

異步復(fù)制。

Redis如何做內(nèi)存優(yōu)化

盡可能使用散列表（hashes），散列表（是說(shuō)列表里面存儲(chǔ)的數(shù)少）使用的內(nèi)存非常小，所以你應(yīng)該盡可能的將你的數(shù)據(jù)模型抽象到一個(gè)散列表里面，比如你的web系統(tǒng)中有一個(gè)用戶(hù)對(duì)象，不要為這個(gè)用戶(hù)的名稱(chēng)，姓氏，郵箱，密碼設(shè)置單獨(dú)的key，而是應(yīng)該把這個(gè)用戶(hù)所有信息存儲(chǔ)到一張散列表中。

Redis常用的使用場(chǎng)景

Session共享（單點(diǎn)登錄）

頁(yè)面緩存

隊(duì)列

排行榜/計(jì)算器

發(fā)布/訂閱

Redis有哪些架構(gòu)模式？講講各自的特點(diǎn)？

單機(jī)版

特點(diǎn)：簡(jiǎn)單

存在問(wèn)題：

內(nèi)存容量有限

處理能力有限

無(wú)法高可用

主從復(fù)制

Redis的復(fù)制（replication）功能允許用戶(hù)根據(jù)一個(gè)Redis服務(wù)器來(lái)創(chuàng)建任意多個(gè)該服務(wù)器的復(fù)制品，其中被復(fù)制的服務(wù)器為主服務(wù)器（master），而通過(guò)復(fù)制創(chuàng)建出來(lái)的服務(wù)器復(fù)制品則為從服務(wù)器（slave）。主要主從服務(wù)器之間的網(wǎng)絡(luò)連接正常，主從服務(wù)器兩者會(huì)具有相同的數(shù)據(jù)，主服務(wù)器就會(huì)一直將發(fā)生在自己身上的數(shù)據(jù)更新同步給從服務(wù)器，從而一直保證主從服務(wù)器的數(shù)據(jù)相同。

問(wèn)題：

無(wú)法保證高可用

沒(méi)有解決master寫(xiě)的壓力

哨兵

Redis sentinel 是一個(gè)分布式系統(tǒng)中監(jiān)控 redis 主從服務(wù)器，并在主服務(wù)器下線(xiàn)時(shí)自動(dòng)進(jìn)行故障轉(zhuǎn)移。其中三個(gè)特性：

監(jiān)控（Monitoring）： Sentinel 會(huì)不斷地檢查你的主服務(wù)器和從服務(wù)器是否運(yùn)作正常。

提醒（Notification）： 當(dāng)被監(jiān)控的某個(gè) Redis 服務(wù)器出現(xiàn)問(wèn)題時(shí)， Sentinel 可以通過(guò) API 向管理員或者其他應(yīng)用程序發(fā)送通知。

自動(dòng)故障遷移（Automatic failover）： 當(dāng)一個(gè)主服務(wù)器不能正常工作時(shí)， Sentinel 會(huì)開(kāi)始一次自動(dòng)故障遷移操作。

特點(diǎn)：

保證高可用

監(jiān)控各個(gè)節(jié)點(diǎn)

自動(dòng)故障遷移

缺點(diǎn)：

主從模式，切換需要時(shí)間，會(huì)丟數(shù)據(jù)

沒(méi)有解決master寫(xiě)的壓力

集群（proxy型）

Twemproxy 是一個(gè) Twitter 開(kāi)源的一個(gè) redis 和 memcache 快速/輕量級(jí)代理服務(wù)器； Twemproxy 是一個(gè)快速的單線(xiàn)程代理程序，支持 Memcached ASCII 協(xié)議和 redis 協(xié)議。

特點(diǎn)：

多種 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins

支持失敗節(jié)點(diǎn)自動(dòng)刪除

后端 Sharding 分片邏輯對(duì)業(yè)務(wù)透明，業(yè)務(wù)方的讀寫(xiě)方式和操作單個(gè) Redis 一致

缺點(diǎn)：

增加了新的 proxy，需要維護(hù)其高可用。

failover 邏輯需要自己實(shí)現(xiàn)，其本身不能支持故障的自動(dòng)轉(zhuǎn)移可擴(kuò)展性差，進(jìn)行擴(kuò)縮容都需要手動(dòng)干預(yù)

集群（直連型）

從redis 3.0之后版本支持redis-cluster集群，Redis-Cluster采用無(wú)中心結(jié)構(gòu)，每個(gè)節(jié)點(diǎn)保存數(shù)據(jù)和整個(gè)集群狀態(tài),每個(gè)節(jié)點(diǎn)都和其他所有節(jié)點(diǎn)連接。

特點(diǎn)：

無(wú)中心架構(gòu)（不存在哪個(gè)節(jié)點(diǎn)影響性能瓶頸），少了 proxy 層。

數(shù)據(jù)按照 slot 存儲(chǔ)分布在多個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)間數(shù)據(jù)共享，可動(dòng)態(tài)調(diào)整數(shù)據(jù)分布。

可擴(kuò)展性，可線(xiàn)性擴(kuò)展到 1000 個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)可動(dòng)態(tài)添加或刪除。

高可用性，部分節(jié)點(diǎn)不可用時(shí)，集群仍可用。通過(guò)增加 Slave 做備份數(shù)據(jù)副本

實(shí)現(xiàn)故障自動(dòng) failover，節(jié)點(diǎn)之間通過(guò) gossip 協(xié)議交換狀態(tài)信息，用投票機(jī)制完成 Slave到 Master的角色提升。

缺點(diǎn)：

資源隔離性較差，容易出現(xiàn)相互影響的情況。

數(shù)據(jù)通過(guò)異步復(fù)制,不保證數(shù)據(jù)的強(qiáng)一致性

使用過(guò)Redis分布式鎖嗎，它是怎么實(shí)現(xiàn)的？

先拿setnx來(lái)爭(zhēng)搶鎖，搶到之后，再用expire給鎖加一個(gè)過(guò)期時(shí)間防止鎖忘記了釋放。 如果在setnx之后執(zhí)行expire之前進(jìn)程意外crash或者要重啟維護(hù)了，那會(huì)怎么樣？ set指令有非常復(fù)雜的參數(shù)，這個(gè)應(yīng)該是可以同時(shí)把setnx和expire合成一條指令來(lái)用的！

使用過(guò) Redis 做異步隊(duì)列么，你是怎么用的？有什么缺點(diǎn)？

般使用 list 結(jié)構(gòu)作為隊(duì)列，rpush 生產(chǎn)消息，lpop 消費(fèi)消息。當(dāng) lpop 沒(méi)有消息的時(shí)候，要適當(dāng) sleep一會(huì)再重試。

缺點(diǎn)：

在消費(fèi)者下線(xiàn)的情況下，生產(chǎn)的消息會(huì)丟失，得使用專(zhuān)業(yè)的消息隊(duì)列如 rabbitmq 等。

能不能生產(chǎn)一次消費(fèi)多次呢？

使用 pub/sub 主題訂閱者模式，可以實(shí)現(xiàn) 1:N 的消息隊(duì)列。

什么是緩存穿透？如何避免？

緩存穿透

一般的緩存系統(tǒng)，都是按照key去緩存查詢(xún)，如果不存在對(duì)應(yīng)的value，就應(yīng)該去后端系統(tǒng)查找（比如DB）。一些惡意的請(qǐng)求會(huì)故意查詢(xún)不存在的key,請(qǐng)求量很大，就會(huì)對(duì)后端系統(tǒng)造成很大的壓力。這就叫做緩存穿透。

如何避免？

對(duì)查詢(xún)結(jié)果為空的情況也進(jìn)行緩存，緩存時(shí)間設(shè)置短一點(diǎn)，或者該key對(duì)應(yīng)的數(shù)據(jù)insert了之后清理緩存。

對(duì)一定不存在的key進(jìn)行過(guò)濾?？梢园阉械目赡艽嬖诘膋ey放到一個(gè)大的Bitmap中，查詢(xún)時(shí)通過(guò)該bitmap過(guò)濾。

什么是緩存雪崩？何如避免？

緩存雪崩當(dāng)緩存服務(wù)器重啟或者大量緩存集中在某一個(gè)時(shí)間段失效，這樣在失效的時(shí)候，會(huì)給后端系統(tǒng)帶來(lái)很大壓力，導(dǎo)致系統(tǒng)崩潰。

如何避免？

在緩存失效后，通過(guò)加鎖或者隊(duì)列來(lái)控制讀數(shù)據(jù)庫(kù)寫(xiě)緩存的線(xiàn)程數(shù)量。比如對(duì)某個(gè)key只允許一個(gè)線(xiàn)程查詢(xún)數(shù)據(jù)和寫(xiě)緩存，其他線(xiàn)程等待。

做二級(jí)緩存，A1為原始緩存，A2為拷貝緩存，A1失效時(shí)，可以訪(fǎng)問(wèn)A2，A1緩存失效時(shí)間設(shè)置為短期，A2設(shè)置為長(zhǎng)期 3：不同的key，設(shè)置不同的過(guò)期時(shí)間，讓緩存失效的時(shí)間點(diǎn)盡量均勻

緩存并發(fā)

這里的并發(fā)指的是多個(gè)redis的client同時(shí)set key引起的并發(fā)問(wèn)題。其實(shí)redis自身就是單線(xiàn)程操作，多個(gè)client并發(fā)操作，按照先到先執(zhí)行的原則，先到的先執(zhí)行，其余的阻塞。當(dāng)然，另外的解決方案是把redis.set操作放在隊(duì)列中使其串行化，必須的一個(gè)一個(gè)執(zhí)行。

緩存預(yù)熱

緩存預(yù)熱就是系統(tǒng)上線(xiàn)后，將相關(guān)的緩存數(shù)據(jù)直接加載到緩存系統(tǒng)。

這樣就可以避免在用戶(hù)請(qǐng)求的時(shí)候，先查詢(xún)數(shù)據(jù)庫(kù)，然后再將數(shù)據(jù)緩存的問(wèn)題！用戶(hù)直接查詢(xún)事先被預(yù)熱的緩存數(shù)據(jù)！

解決思路：

直接寫(xiě)個(gè)緩存刷新頁(yè)面，上線(xiàn)時(shí)手工操作下；

數(shù)據(jù)量不大，可以在項(xiàng)目啟動(dòng)的時(shí)候自動(dòng)進(jìn)行加載；

目的就是在系統(tǒng)上線(xiàn)前，將數(shù)據(jù)加載到緩存中。

Redis回收進(jìn)程如何工作的？

客戶(hù)端執(zhí)行數(shù)據(jù)寫(xiě)入操作

redis server接收到寫(xiě)入操作之后，檢查maxmemory的限制，如果超過(guò)了限制，那么就根據(jù)對(duì)應(yīng)的policy清理掉部分?jǐn)?shù)據(jù)

寫(xiě)入操作完成執(zhí)行。

Redis是單線(xiàn)程的，如何提高多核CPU的利用率？

可以在同一個(gè)服務(wù)器部署多個(gè)Redis的實(shí)例，并把他們當(dāng)作不同的服務(wù)器來(lái)使用，在某些時(shí)候，無(wú)論如何一個(gè)服務(wù)器是不夠的， 所以，如果你想使用多個(gè)CPU，你可以考慮一下分片（shard）。

修改配置不重啟Redis會(huì)實(shí)時(shí)生效嗎？

針對(duì)運(yùn)行實(shí)例，有許多配置選項(xiàng)可以通過(guò) CONFIG SET 命令進(jìn)行修改，而無(wú)需執(zhí)行任何形式的重啟。 從 Redis 2.2 開(kāi)始，可以從 AOF 切換到 RDB 的快照持久性或其他方式而不需要重啟 Redis。檢索 CONFIG GET * 命令獲取更多信息。 但偶爾重新啟動(dòng)是必須的，如為升級(jí) Redis 程序到新的版本，或者當(dāng)你需要修改某些目前 CONFIG 命令還不支持的配置參數(shù)的時(shí)候。

Redis的內(nèi)存用完了會(huì)發(fā)生什么？

如果達(dá)到設(shè)置的上限，Redis的寫(xiě)命令會(huì)返回錯(cuò)誤信息（但是讀命令還可以正常返回。）或者你可以將Redis當(dāng)緩存來(lái)使用配置淘汰機(jī)制，當(dāng)Redis達(dá)到內(nèi)存上限時(shí)會(huì)沖刷掉舊的內(nèi)容。

分布式Redis是前期做還是后期規(guī)模上來(lái)了再做好？為什么？

既然Redis是如此的輕量（單實(shí)例只使用1M內(nèi)存）,為防止以后的擴(kuò)容，最好的辦法就是一開(kāi)始就啟動(dòng)較多實(shí)例。即便你只有一臺(tái)服務(wù)器，你也可以一開(kāi)始就讓Redis以分布式的方式運(yùn)行，使用分區(qū)，在同一臺(tái)服務(wù)器上啟動(dòng)多個(gè)實(shí)例。一開(kāi)始就多設(shè)置幾個(gè)Redis實(shí)例，例如32或者64個(gè)實(shí)例，對(duì)大多數(shù)用戶(hù)來(lái)說(shuō)這操作起來(lái)可能比較麻煩，但是從長(zhǎng)久來(lái)看做這點(diǎn)犧牲是值得的。這樣的話(huà)，當(dāng)你的數(shù)據(jù)不斷增長(zhǎng)，需要更多的Redis服務(wù)器時(shí)，你需要做的就是僅僅將Redis實(shí)例從一臺(tái)服務(wù)遷移到另外一臺(tái)服務(wù)器而已（而不用考慮重新分區(qū)的問(wèn)題）。一旦你添加了另一臺(tái)服務(wù)器，你需要將你一半的Redis實(shí)例從第一臺(tái)機(jī)器遷移到第二臺(tái)機(jī)器。

Redis與其他key-value存儲(chǔ)有什么不同？

Redis有著更為復(fù)雜的數(shù)據(jù)結(jié)構(gòu)并且提供對(duì)他們的原子性操作，這是一個(gè)不同于其他數(shù)據(jù)庫(kù)的進(jìn)化路徑。Redis的數(shù)據(jù)類(lèi)型都是基于基本數(shù)據(jù)結(jié)構(gòu)的同時(shí)對(duì)程序員透明，無(wú)需進(jìn)行額外的抽象。Redis運(yùn)行在內(nèi)存中但是可以持久化到磁盤(pán)，所以在對(duì)不同數(shù)據(jù)集進(jìn)行高速讀寫(xiě)時(shí)需要權(quán)衡內(nèi)存，應(yīng)為數(shù)據(jù)量不能大于硬件內(nèi)存。在內(nèi)存數(shù)據(jù)庫(kù)方面的另一個(gè)優(yōu)點(diǎn)是， 相比在磁盤(pán)上相同的復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，在內(nèi)存中操作起來(lái)非常簡(jiǎn)單，這樣Redis可以做很多內(nèi)部復(fù)雜性很強(qiáng)的事情。 同時(shí)，在磁盤(pán)格式方面他們是緊湊的以追加的方式產(chǎn)生的，因?yàn)樗麄儾⒉恍枰M(jìn)行隨機(jī)訪(fǎng)問(wèn)。

關(guān)注獲得更多分享