redis 數(shù)據(jù)結構
string 字符串，可以存字符串、整數(shù)、浮點數(shù)，可以對字符串局部進行操作，可以對整數(shù)和浮點數(shù)自增、自減 set、del、get、incr、decr、incrby、decrby、incrbyfloat | append、getrange、setrange、getbit、setbit、bitcount、bitop
list 鏈表，可以從兩端push或pop元素，讀取單個或多個元素，查找或移除元素，操作包括 lpus、rpush、 lpop、 rpop、 lrange 、lindex、ltrim、blpop、brpop、rpoplpush、brpoplpush
set 無序集合，可以檢查一個元素是否在集合中，計算交集、并集、差集 sadd、srem、smembers、sismember、sinter、sinterstore、sdiff、sdiffstore、sunion、sunionstore
hset 獲取所有的鍵值對 hset、hdel、hget、hgetall、hmget、hmset、hdel、hlen、hexists、hkeys、hvals、hincrby、hincrbyfloat
zset 有序集合，字符串member和浮點分數(shù)值之間的映射，元素的順序由分值大小決定 zadd、zrange、zrevrange、zrangebyscore、zrem 、zcard、zcount、zscore、zincrby、zrank、zrevrank、zremrangebyrank、zremrangebyscore
發(fā)布和訂閱 redis 本身支持發(fā)布和訂閱模式，但是如果客戶端斷開連接后重連，那么在這期間的一些消息可能會丟失。
6.事務 。將多個命令作為一個事務來處理，multi 開啟事務，exec提交事務
- 自動刪除。 只能為整個結構來設置超時時間，不能為里面的條目來設置超時時間。
redis 如何持久化？
有兩種方法可以持久化，快照和AOF
快照的開關是配置 save 選項，比如 save 60 10 表示從上一次創(chuàng)建快照開始60s內(nèi)有10次寫操作就會觸發(fā)一次快照保存，也可以使用save或者bgsave來保存，兩者的區(qū)別是save是在前臺進程中保存快照，會停止接收命令請求，知道保存完成。bgsave是創(chuàng)建一個后臺進程來完成保存工作，但是會占用更過的內(nèi)存。當使用shutdown來關閉redis的時候也會觸發(fā)快照保存。當一個redis連接主服務器并發(fā)送sync開始復制的時候，如果主服務器不是剛剛保存過快照，那么也會觸發(fā)一次保存。
快照保存的缺點是什么？
1、當系統(tǒng)崩潰，從上次快照保存之后的所有數(shù)據(jù)將會丟失。
2、當數(shù)據(jù)量過大時，使用bgsave創(chuàng)建子進程的時間會變長，到時系統(tǒng)停頓。當數(shù)據(jù)量大是使用save反而比使用bgsave要更快，因為他占用更少的內(nèi)存，并且不需要創(chuàng)建子進程。
AOF的原理是什么？
AOF將寫命令都保存到文件里去，redis只要從頭把AOF文件中的命令執(zhí)行一遍就能恢復所有的數(shù)據(jù)
如何啟用AOF
將appendonly設為yes，就可以開啟aof，設為no就可以關閉aof
如何空中aof的頻率？
使用appendfsync可以通知同步的頻率，always 是指每一個寫命令都要保存到aof文件中，這樣會大大減少數(shù)據(jù)丟失的可能，但是會極大的降低系統(tǒng)的吞吐，everysec 每秒鐘同步一次，既可以減低數(shù)據(jù)丟失風險也可以提高吞吐量，no 意思是讓操作系統(tǒng)來決定什么時候同步。
aof有什么缺點，如何解決？
aof生成的文件往往會比dump文件大很多，這樣在恢復數(shù)據(jù)的時候需要花很長時間。采用的應對措施有:使用bgrewriteaof命名來移除aof文件中冗余的命令，減少文件的體積。也可以在配置文件里配置
auto-rewrite-aof-percentage 100 意思當文件從上一次重寫之后體積增大一倍
auto-rewrite-aof-min-size 64m 意思是文件體積超過64m
同時使用上面2條命令意思同時滿足才會觸發(fā)重寫aof
如何做到運行中來查看和調(diào)整redis的參數(shù)？
查看使用 config get max 形似的命令
修改使用 config set appendonly yes 來設置
默認修改后不會更改配置文件，如果想同時修改配置文件可以使用 config rewrite
redis 復制
為什么要配置主從復制？在什么情況下需要配置主從復制？
單機的處理能力有限，需要增加多臺redis服務器來響應用戶的請求
redis 主從復制的過程是怎么樣？有什么注意事項？
1、從服務器發(fā)送sync命名
2、服務器收到sync命名后出發(fā)bgsave保存快照，并使用緩沖區(qū)來保存bgsave之后所有的命令
3、向從服務器發(fā)送快照文件，發(fā)送期間繼續(xù)使用緩存區(qū)保存命令
redis 能不能做主-主復制？能不能做主從鏈？
redis不支持主-主復制，可以做主從鏈
如何配置redis，使得redis具有最高的安全性？
復制+aof，復制可以保存數(shù)據(jù)多副本，aof可以使得丟失數(shù)據(jù)可能性最小
redis 發(fā)布和訂閱模式是怎么樣的？有哪些缺點？解決方法怎樣的？
什么是redis中的流水線？
當執(zhí)行多個命令的時候，為了提交命令的執(zhí)行效率，可以將多個提交到redis中的命令放到一個隊列中，然后一次性的提交給redis執(zhí)行，這種技術就是流水線
redis 事務是怎么操作的？watch、unwatch、discard是什么意思
如何構建非流水線事務？
使用客戶端來實現(xiàn)。
如何使用發(fā)布訂閱模式？
使用publish和subscrible來實現(xiàn)。
redis 如何實現(xiàn)加鎖機制？
1、使用watch、multi、exec 使用事務的形式實現(xiàn)
使用watch來監(jiān)控需要操作的key，利用事務來保證操作期間沒有其他線程更改監(jiān)控的值，如果有改動，事務回滾，然后在超時時間范圍內(nèi)重試
2、使用自定義鎖的形式
使用setnx（不存在則添加），如果添加成功則說明或得到了鎖，如果失敗說明沒有獲取到鎖，在獲取鎖的過程中采用使用超時機制，防止當前線程崩潰后，鎖無法釋放的問題。釋放鎖的過程首先watch key，獲取值看與之前的值是否相同，如果相同，就把這個key刪掉，相當于釋放鎖，如果不同，說明這個所已經(jīng)被別人拿到了就不在刪除key，返回。
使用第一中方法在大量操作情況下，會使得整體的競爭非常激烈，導致整體的吞吐量下降，采用第2種方法可以降低競爭，提高吞吐量。
如何使用redis來實現(xiàn)信號量？
信號量是只可以控制同時訪問統(tǒng)一資源的客戶端數(shù)量。利用string的incr命令，每個客戶端來獲取信號量的時候，首先取一個號，然后將客戶端id作為成員，這個號作為分值存入有序集合中。然后利用zrank來得到這個成員的排名，如果在信號量的范圍之內(nèi)，則獲取到了這個鎖，如果超出了信號量的范圍則獲取失敗，同時從有序集合中刪除這個成員。當釋放信號量的時候，從有序集合中刪除即可。為了防止客戶端獲取信號量然后崩潰或者長時間沒有釋放的情況，在獲取信號量的同時，使用一個有序集合來保存客戶端id和時間戳，對于超時的時間的成員從這連個有序集合中同時刪除。
redis內(nèi)存優(yōu)化
當列表、集合、散列、有序集合中元素個數(shù)不多、每個元素占用的空間也不大的時候，redis使用更省內(nèi)存的方式來存儲。
比如對于集合、散列、有序集合采用一種壓縮列表編碼，對于集合，如果集合的成員可以解釋為十進制數(shù)字并且在有符號整數(shù)表示的范圍內(nèi)，集合會采用整數(shù)數(shù)組的形式來存儲集合，這種存儲方式被稱為整數(shù)集合。
存在的問題：
1、當元素的數(shù)量超過設置的個數(shù)的上限或者元素的大小超過了設置的大小，那么redis會轉(zhuǎn)化為普通的結構來存儲，從而使得內(nèi)存變大。
2、當壓縮列表或者整數(shù)集合的體積變得非常大時，操作這些集合的速度變的很慢
解決方案：
保持元素個數(shù)在2000以內(nèi)，大小不超過64k，既可以充分利用內(nèi)存優(yōu)化，也可以保證操作速度
redis 分片
為什么要分片？
一方面是為了提高負載能力，一方面分片之后可以充分的利用內(nèi)存優(yōu)化。
