一、redis的特性：單線程

由于是單線程，所以redis的命令執(zhí)行是串行而不是并行的，意味著同一時間內(nèi)redis只會執(zhí)行一個命令。

由于一次只能執(zhí)行一條命令，所以要拒絕長命令(就是運(yùn)行時間長的命令)，因為會引起后面的命令阻塞。長命令如：keys,flushall,flushdb,mutil/exec等。

單線程為什么這么快：因為redis是純內(nèi)純操作。

注意，這里的說redis單線程只是指redis執(zhí)行讀寫命令的時候是單線程。

redis在接收和處理讀寫請求的時候雖然使用的是單線程，但redis采用了多路復(fù)用技術(shù)來處理網(wǎng)絡(luò)IO（即用戶的讀寫請求），通過其內(nèi)置的eventloop事件循環(huán)機(jī)制監(jiān)聽多個讀寫事件，從而使得讀寫請求在單線程下也能并發(fā)執(zhí)行。

而后來為了能夠處理更高QPS的請求，redis6.0版本之后開始使用多線程接收和處理用戶的網(wǎng)絡(luò)IO請求，每個線程再使用多路復(fù)用技術(shù)，能夠極高的提升網(wǎng)絡(luò)IO的效率（對于redis而言，CPU和內(nèi)存IO不是其瓶頸，網(wǎng)絡(luò)IO才是）。不過在執(zhí)行讀寫操作依舊是單線程處理。

二、redis的五種數(shù)據(jù)結(jié)構(gòu)

1.字符串類型

字符串的key是字符串，value可以是字符串，數(shù)字，二進(jìn)制，json，但本質(zhì)上value也還是字符串。

單個value大小不能超過512M，但實際應(yīng)用中一般不會存超過100K的內(nèi)容。

字符串類型的使用場景：

• 緩存
• 計數(shù)器
• 分布式鎖
• 等等

常用命令：

get/set/del
incr/decr/incrby/decrby

關(guān)于 set setnx setxx 的區(qū)別
set 不管key是否存在都設(shè)置
setnx key不存在才設(shè)置，相當(dāng)于新增
set key value xx key存在才設(shè)置，相當(dāng)于修改

實戰(zhàn)場景1：記錄每一個用戶的訪問次數(shù)，或者記錄每一個商品的瀏覽次數(shù)。

方案：

• 鍵名： userid:pageview 或者 pageview:userid 如pageview:5
• 使用命令：incr

使用理由：每一個用戶訪問次數(shù)或者商品瀏覽次數(shù)的修改是很頻繁的，如果使用mysql這種文件系統(tǒng)頻繁修改會造成mysql壓力，效率也低。而使用redis的好處有二：使用內(nèi)存，很快；單線程，所以無競爭，數(shù)據(jù)不會被改亂

實戰(zhàn)場景2：緩存頻繁讀取，但是不常修改的信息，如用戶信息，視頻信息

方案：業(yè)務(wù)邏輯上：先從redis讀取，有就從redis讀??；沒有則從mysql讀取，并寫一份到redis中作為緩存，注意要設(shè)置過期時間。

鍵值設(shè)計上：一種是直接將用戶一條mysql記錄做序列化(serialize或json_encode)作為值，userInfo:userid 作為鍵名如：userInfo:1

另一種是以 表名:主鍵名:字段名:id值 作為鍵，字段值作為值。如 user:id:name:1 = "zbp"    

實戰(zhàn)場景3：分布式id生成器incr id

例如，mysql做了分布式，數(shù)據(jù)分?jǐn)偟矫恳粋€mysql服務(wù)器，在插入數(shù)據(jù)時，每一個mysql服務(wù)器的id要自增但卻不能相同。此時可以使用redis的incr來完成。原因是，redis是單線程，意味并發(fā)請求生成id時，生成的id不會重復(fù)。（單線程無競爭）

實戰(zhàn)場景4：限定某個ip特定時間內(nèi)的訪問次數(shù)使用 incr + setex

例如限定某ip在10秒內(nèi)訪問api的次數(shù)不能超過1000次

<?php

$r=new Redis();
$r->connect($RedisHost,$RedisPort);
$redis_key = "arts_api|".$_SERVER["REMOTE_ADDR"];

if(!$r->exists($redis_key)){
  $r->setex($redis_key,10,"1");
}else{
  $r->incr($redis_key);
 
  //判斷是否超過規(guī)定次數(shù)
  if($r->get($redis_key)>1000){
    die("訪問過快");
  }
 
}

?>

實戰(zhàn)場景5:分布式session

我們知道,session是以文件的形式保存在服務(wù)器中的; 如果你的應(yīng)用做了負(fù)載均衡,將網(wǎng)站的項目放在多個服務(wù)器上,當(dāng)用戶在服務(wù)器A上進(jìn)行登陸,session文件會寫在A服務(wù)器;當(dāng)用戶跳轉(zhuǎn)頁面時,請求被分配到B服務(wù)器上的時候,就找不到這個session文件,用戶就要重新登陸

如果想要多個服務(wù)器共享一個session,可以將session存放在redis中,redis可以獨(dú)立與所有負(fù)載均衡服務(wù)器,也可以放在其中一臺負(fù)載均衡服務(wù)器上;但是所有應(yīng)用所在的服務(wù)器連接的都是同一個redis服務(wù)器。

實現(xiàn)如下，以PHP為例：

設(shè)置php.ini 文件中的session.save_handle 和session.save_path

session.save_handler = Redis
session.save_path =  "tcp://47.94.203.119:6379"     # 大部分情況下,使用的都是遠(yuǎn)程redis,因為redis要為多個應(yīng)用服務(wù)

如果為redis已經(jīng)添加了auth權(quán)限（requirpass），session.save_path項則應(yīng)該這樣寫

session.save_path =  "tcp://47.94.203.119:6379?persistent=1&database=10&auth=myredisG506"

使用redis存儲session信息：

/**
 * 將session存儲在redis中
 */
session_start();
echo session_id();
echo "<br>";
$_SESSION['age'] = 26;
$_SESSION['name'] = 'xiaobudiu';
$_SESSION['sex'] = 'man';
var_dump($_SESSION);

此時session_id依舊存在cookie中。

redis中的key為 PHPREDIS_SESSION:session_id。

當(dāng)用戶跳轉(zhuǎn)頁面的時候，php內(nèi)部會先根據(jù)session_id()獲取cookie的session_id，再根據(jù)session_id獲取到redis中的key再根據(jù)key獲取value。

所以redis的session是通過cookie中的session_id得知 調(diào)用$_SESSION['name']是要獲取張三的用戶名而不是李四的用戶名。

如果關(guān)閉瀏覽器,cookie會失效,再打開瀏覽器的時候,session_id就不見了; 這個時候,雖然redis還保存這張三的session。

但是php已經(jīng)無法獲取到這個session。

所以張三再登陸的時候，會重新生成一個session。此時張三的session會有兩個，一個是正在使用的，一個是已經(jīng)失效的。失效的session不會一直放在redis中占用內(nèi)存,php自動給這個redis的可以設(shè)置了過期時間。你也可以給session手動設(shè)置過期時間,通過ini_set('session.gc_maxlifetime',$lifetime)。（如果是文件的形式存儲的session，php會定時清理失效的session文件，失效的session就是在瀏覽器cookie中找不到session_id的session）

我們可以封裝一個session類,這個session類在原基礎(chǔ)上多了可以對session中的某個屬性設(shè)置過期時間

封裝session類：

class Session
{

  function __construct($lifetime = 3600)
{
    //初始化設(shè)置session會話存活時間,如果redis中的key存在超過3600秒,會自動執(zhí)行session_destory(),具體表現(xiàn)為key被刪除
    ini_set('session.gc_maxlifetime',$lifetime);
  }

  /**
  * 設(shè)置當(dāng)前會話session的key-value
  * @param String $name  session name
  * @param Mixed $data  session data
  * @param Int  $expire 有效時間(秒)
  */
  function set($name, $data, $expire = 600)  # session中的單獨(dú)的某個鍵也可以設(shè)置過期時間,很靈活
{
    $session_data = array();
    $session_data['data'] = $data;
    $session_data['expire'] = time()+$expire;
    $_SESSION[$name] = $session_data;
  }

  /**
  * 讀取當(dāng)前會話session中的key-value
  * @param String $name session name
  * @return Mixed
  */
  function get($name)
{
    if(isset($_SESSION[$name])) {
      if($_SESSION[$name]['expire'] > time()) {
        return $_SESSION[$name]['data'];
      }else{
        self::clear($name);
      }
    }
    return false;
  }

  /**
  * 清除當(dāng)前session會話中的某一key-value
  * @param String $name session name
  */
  function clear($name)
{
    unset($_SESSION[$name]);
  }

  /**
  * 刪除當(dāng)前session_id對應(yīng)的session文件（清空當(dāng)前session會話存儲,在redis中的表現(xiàn)為刪掉一個session的key,在文件形式session中表現(xiàn)為刪除一個session文件）
  */
  function destroy()
{
    session_destroy();
  }

}

在一個會話生命周期中,一個redis的key存著這個會話的$_SESSION所有信息包括 $_SESSION['name'],["age"]等。

redis存session比文件存session的優(yōu)勢在: 前者可以做分布式session,后者不行;前者是純內(nèi)存操作,更快,后者是文件IO操作。

我們可以看一下一個key里面的內(nèi)容：

get PHPREDIS_SESSION:6mmndoqm87st2s75ntlsvbp25q

得到：

"name|a:2:{s:4:\"data\";s:3:\"zbp\";s:6:\"expire\";i:1584351986;}age|a:2:{s:4:\"data\";i:18;s:6:\"expire\";i:1584351986;}job|a:2:{s:4:\"data\";s:10:\"programmer\";s:6:\"expire\";i:1584351986;}"

是一堆序列化的內(nèi)容。所以這種方式相比于使用hash結(jié)構(gòu)來存的效率更低。

因為這種方式取其中一個字段name就要將整個key獲取出來,而且序列化和反序列化也要消耗性能。

題外話:在網(wǎng)站分布多臺機(jī)器的時候,要做session分布式才可以跨機(jī)器獲取session; 如果我們不用session,改用純cookie代替session,將用戶信息都存到cookie中,這樣無論用戶訪問到哪臺機(jī)器都無所謂,反正都可以在瀏覽器中獲取用戶信息。

但是這真的是一種很好的解決分布式session的方式嗎？

本人有時候也會做做爬蟲，知道有些頁面必須登陸后才能訪問，如果將用戶信息存在cookie，爬蟲完全可以偽造一份用戶的cookie來訪問用戶的隱私頁面。所以使用cookie會帶來這樣的安全問題。

或者你的cookie是在瀏覽器可視的，而使用session，只有session_id在瀏覽器是可視的,用戶具體信息在服務(wù)端中你是看不到的。

mget/mset 批量操作：

n次get命令花費(fèi)的時間 = n次網(wǎng)絡(luò)時間+n次命令時間

一次mget命令獲取n個key的時間 = 1次網(wǎng)絡(luò)時間+n次命令時間 尤其是客戶端(php/Python)和redis服務(wù)端不在同一主機(jī)上，網(wǎng)絡(luò)時間就會比較長。

所以盡量用mget，但是mget不要獲取太多key，否則要傳輸?shù)臄?shù)據(jù)過大對網(wǎng)絡(luò)開銷和性能都有負(fù)擔(dān)。 

2. 哈希類型

相關(guān)命令如下：

hget/hset/hdel/hgetall
hexists/hlen
hmget/hmset

實戰(zhàn)場景1：記錄每一個用戶的訪問次數(shù)

方案： 

鍵名： user:1:info  

字段名：pageview

使用命令：hincrby

和單純使用字符串類型進(jìn)行記錄不同，這里可以將用戶訪問次數(shù)也放到用戶信息中作為一個整體，user:1:info中還存儲著name,email,age之類的信息

hgetall/hvals/hkeys

PS:慎用hgetall，因為hgetall會獲取一個hash key中的所有字段，這是一個長命令，而redis是單線程，會阻塞住后面的命令的執(zhí)行。

字符串和哈希類型對比：這里我們以“將一個用戶的信息存為redis字符串和哈?！白鳛楸葘?。

字符串存儲方式：

• 方案1： 鍵名 user:1:info  值 序列化后的用戶對象
• 方案2： 鍵名 user:1:字段名   值 字段值

哈希存儲方式：

方案3： 鍵名 user:1:info  值 用戶數(shù)據(jù)

方案1的優(yōu)點(diǎn)是設(shè)計簡單，可節(jié)省內(nèi)存（相對于方案2），缺點(diǎn)一是如果要修改用戶對象中的某個屬性要將整個用戶對象從redis中取出來，二是要對數(shù)據(jù)進(jìn)行序列化和反序列化也會產(chǎn)生一定CPU開銷。

方案2的優(yōu)點(diǎn)是可以單獨(dú)更新用戶的屬性，無需將這個用戶所有屬性取出。

缺點(diǎn)一是單個用戶的數(shù)據(jù)是分散的不利于管理，二是占用內(nèi)存，方案1一個用戶的數(shù)據(jù)用一個key就可以保存，方案2一個用戶的數(shù)據(jù)要多個key才可以保存。

方案3的優(yōu)點(diǎn)：直觀，節(jié)省空間，可以單獨(dú)更新hash中的某個屬性缺點(diǎn)：ttl不好控制

3.列表類型

列表本質(zhì)是一個有序的，元素可重復(fù)的隊列

添加元素命令：

rpush/lpush
rpush c b a   # cba,插入方向<-,即從右往左
lpush c b a   # abc，插入方向->，從左往右
linsert  # 在一個元素前或后插入元素

刪除元素命令：

lpop/rpop   #彈出
lrem        #刪除
ltrim   # 修剪列表返回一個子列表，會影響原列表

查詢元素命令：

lrange  # 按照范圍查詢列表返回一個子列表
lindex  # 按索引取
llen    # 列表長度
改
lset    # 修改某索引的值為新值

實戰(zhàn)場景1：微博中的時間軸功能（文章按時間排序，還可以做分頁）

方案：做一個列表用于存放某個用戶的所有微博id，key為 weiboList:user:1,值為微博id。

做一個哈希，里面放微博的內(nèi)容。

該用戶新增一個微博就會忘列表中l(wèi)pop一個微博id，查詢的時候使用lrange即可，分頁也可以使用lrange。

blpop/brpop     # 是lpop和rpop的阻塞版

當(dāng)列表長度不為空時，lpop和blpop效果一樣。

當(dāng)列表長度為空，lpop會立刻返回nil，而blpop會等待，直到有元素進(jìn)入列表，blpop就會執(zhí)行彈出。

它的應(yīng)用場景就是消息隊列。

小結(jié)：

• 用列表實現(xiàn)棧：lpush+lpop = stack
• 用列表實現(xiàn)隊列：lpush+rpop = queue
• 用列表實現(xiàn)固定集合: lpush+ltrim = capped collection
• 用列表實現(xiàn)消息隊列：lpush+brpop = message queue

4.集合類型

集合的特點(diǎn)是無序性和確定性（不重復(fù)）。

新增元素命令
sadd


刪除元素命令
srem
scard #個數(shù)
sismember   #是否存在
srandmember # 隨機(jī)選n個元素
spop    # 隨機(jī)彈出元素，影響原集合
smembers    # 返回所有元素，要慎用，不要獲取內(nèi)容較大的集合

實戰(zhàn)場景1：抽獎

使用spop即可，利用的是它的無序性和不重復(fù)。

實戰(zhàn)場景2：贊，踩，收藏功能等。

方案： 每一個用戶做一個收藏的集合，每個收藏的集合存放用戶收藏過的文章id或者商品id。

鍵名： set:userCol:用戶id

值：文章id

如果使用mysql實現(xiàn)，需要建立多對多關(guān)系，要建中間表。

實戰(zhàn)場景3：給文章添加標(biāo)簽

方案： 要創(chuàng)建兩種集合，以文章id為鍵名放標(biāo)簽的集合，以標(biāo)簽id為鍵名放文章的集合。創(chuàng)建兩種集合是因為我們會查詢某標(biāo)簽下有什么文章，也會查詢某文章下有什么標(biāo)簽

鍵名： article:1:tags    值：tag的id

鍵名： tag:1:users        值：user的id

而且這兩個集合創(chuàng)建時要放在一個事務(wù)中進(jìn)行。

sdiff/sinter/sunion     # 交集并集差集

實戰(zhàn)場景4：共同好友

5.有序集合

有序集合的特點(diǎn)是 有序，無重復(fù)值，相關(guān)命令如下：

zadd key score element
zrem
zscore      # 獲取分?jǐn)?shù)
zincrby     # 增加減少分?jǐn)?shù)
zcard       # 元素個數(shù)
zrange      # 按下標(biāo)范圍獲取元素，加上withscores會按分?jǐn)?shù)排序
zrangebyscore   # 按照分?jǐn)?shù)范圍獲取元素
zcount      # 按分?jǐn)?shù)范圍計算元素個數(shù)
zremrangebyrank     # 刪除指定下標(biāo)范圍的元素
zremrangebyscore

實戰(zhàn)場景1：排行榜

實戰(zhàn)場景2：延時隊列

最后強(qiáng)調(diào)一下，要慎用hgetall，原因如下：

當(dāng)一個hash的字段數(shù)很多，存儲的內(nèi)容很多時，處理hgetall請求會花費(fèi)較長時間；而redis是單線程，同一時間只能處理一個操作，所以后面的操作都要等待hgetall處理完畢才能處理，很影響效率和性能。

還有一種情況：列表或者集合中存了很多哈希的鍵名。

通過 lrange 0 -1 或者 smembers 這樣的命令取出列表或者集合中所有鍵名再通過hgetall取出大量的hash，而每個hash中又有大量的字段。這種情況下性能會急劇下降，而且占用大量內(nèi)存，甚至?xí)斐慑礄C(jī)。

下面總結(jié)時間復(fù)雜度為n的命令：

String類型：

• MSET、MSETNX、MGET

List類型：

• LPUSH、RPUSH、LRANGE、LINDEX、LSET、LINSERT
• LINDEX、LSET、LINSERT 這三個命令謹(jǐn)慎使用

Hash類型：

• HDEL、HGETALL、HKEYS/HVALS
• HGETALL、HKEYS/HVALS 謹(jǐn)慎使用

Set類型：

• SADD、SREM、SRANDMEMBER、SPOP、
• SMEMBERS、SUNION/SUNIONSTORE、SINTER/SINTERSTORE、SDIFF/SDIFFSTORE
• Set類型的第二行命令謹(jǐn)慎使用。

Sorted Set類型：

• ZADD、ZREM、
• ZRANGE/ZREVRANGE、ZRANGEBYSCORE/ZREVRANGEBYSCORE、ZREMRANGEBYRANK/ZREMRANGEBYSCORE
• Sorted Set的第二行時間復(fù)雜度 O(log(N)+M)，需要謹(jǐn)慎使用

其他常用命令：

• DEL、KEYS
• KEYS 命令謹(jǐn)慎使用

基本上，設(shè)置多個值或者獲取多個值的命令其時間復(fù)雜度為n。時間復(fù)雜度越高，執(zhí)行命令消耗的時間越長。