Redis簡介、數據類型應用場景

1. Redis簡介

Redis，一個開源的 key-value，內存中的數據結構存儲系統，它能夠用做數據庫、緩存和消息中間件。 它支持多種類型的數據結構，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets）。Redis 使用C語言開發，支持的客戶端語言也很是豐富，如C、C#、C++、Object-C、PHP、Python、 Java、Perl、Lua等。Redis 支持 master-slave（主-從）模式應用，支持數據的持久化，能夠將內存中的數據村春在硬盤中，重啓、斷電的時候並不會丟失數據。

2. Redis經常使用的數據類型

• String
  經常使用命令：set/get/getset/mset/mget/setex/setnx/incr/decr/incrby/decrby/strlen/append
  應用場景：String 最經常使用的一種數據類型，普通的key/value存儲均可以歸爲此類。

• Hashes
  經常使用命令：hset/hget/hmset/hmget/hsetnx/hexists/hdel/hgetall/hkeys
  應用場景：存儲一個學生信息對象數據，字段包括：id、姓名、班級、年齡等，經過 id 能夠獲取/修改任意的字段。

• Lists
  經常使用命令：lindex/lset/lrem/lange/llen/lpop/lpush/rpop/rpush/lpushx/rpushx
  應用場景：關注列表、粉絲列表、隊列。

• Sets
  經常使用命令：sadd/scard/spop/srem/smove/sdiff/sinter/sunion/smembers/sismember
  應用場景：Sets 雖也是提供一個與 Lists 相似的列表功能，可是 Sets 是會自動排序、去重的，當須要存儲一個列表數據，又不但願有重複數據時，Sets 是一個很好的選擇，還能夠取交集、並集、差集，能夠應用到好友推薦、共同好友列表等，利用惟一性，能夠統計訪問網站的全部獨立 IP。

• Sorted Sets
  經常使用命令：zadd/zcard/zcount/zrem/zscore/zrank/zrevrank/zrange/zrevrange/zrangebyscore/zrevrangebyscore
  應用場景：Sorted Sets 是根據 score 來排序的，而且是不重複的，能夠應用於積分排行榜等。

3. Redis持久化
如下摘自連接描述
Redis雖然是基於內存的存儲系統，可是它自己是支持內存數據的持久化的，並且提供兩種主要的持久化策略：RDB快照和AOF日誌。

• RDB快照

Redis支持將當前數據的快照存成一個數據文件的持久化機制，即RDB快照。這種方法是很是好理解的，可是一個持續寫入的數據庫如何生成快照呢？Redis藉助了fork命令的copy on write機制。在生成快照時，將當前進程fork出一個子進程，而後在子進程中循環全部的數據，將數據寫成爲RDB文件。
咱們能夠經過Redis的save指令來配置RDB快照生成的時機，好比你能夠配置當10分鐘之內有100次寫入就生成快照，也能夠配置當1小時內有 1000次寫入就生成快照，也能夠多個規則一塊兒實施。這些規則的定義就在Redis的配置文件中，你也能夠經過Redis的CONFIG SET命令在Redis運行時設置規則，不須要重啓Redis。

Redis的RDB文件不會壞掉，由於其寫操做是在一個新進程中進行的，當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件 中，而後經過原子性rename系統調用將臨時文件重命名爲RDB文件，這樣在任什麼時候候出現故障，Redis的RDB文件都老是可用的。同時，Redis 的RDB文件也是Redis主從同步內部實現中的一環。

可是，咱們能夠很明顯的看到，RDB有他的不足，就是一旦數據庫出現問題，那麼咱們的RDB文件中保存的數據並非全新的，從上次RDB文件生成到 Redis停機這段時間的數據所有丟掉了。在某些業務下，這是能夠忍受的，咱們也推薦這些業務使用RDB的方式進行持久化，由於開啓RDB的代價並不高。 可是對於另一些對數據安全性要求極高的應用，沒法容忍數據丟失的應用，RDB就無能爲力了，因此Redis引入了另外一個重要的持久化機制：AOF日誌。

• AOF日誌

AOF日誌的全稱是append only file，從名字上咱們就能看出來，它是一個追加寫入的日誌文件。與通常數據庫的binlog不一樣的是，AOF文件是可識別的純文本，它的內容就是一個個 的Redis標準命令。固然，並非發送發Redis的全部命令都要記錄到AOF日誌裏面，只有那些會致使數據發生修改的命令纔會追加到AOF文件。那麼 每一條修改數據的命令都生成一條日誌，那麼AOF文件是否是會很大？答案是確定的，AOF文件會愈來愈大，因此Redis又提供了一個功能，叫作AOF rewrite。其功能就是從新生成一份AOF文件，新的AOF文件中一條記錄的操做只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的屢次操 做。其生成過程和RDB相似，也是fork一個進程，直接遍歷數據，寫入新的AOF臨時文件。在寫入新文件的過程當中，全部的寫操做日誌仍是會寫到原來老的 AOF文件中，同時還會記錄在內存緩衝區中。當重完操做完成後，會將全部緩衝區中的日誌一次性寫入到臨時文件中。而後調用原子性的rename命令用新的 AOF文件取代老的AOF文件。

AOF是一個寫文件操做，其目的是將操做日誌寫到磁盤上，因此它也一樣會遇到咱們上面說的寫操做的5個流程。那麼寫AOF的操做安全性又有多高呢。實際上 這是能夠設置的，在Redis中對AOF調用write(2)寫入後，什麼時候再調用fsync將其寫到磁盤上，經過appendfsync選項來控制，下面 appendfsync的三個設置項，安全強度逐漸變強。

1）appendfsync no

當設置appendfsync爲no的時候，Redis不會主動調用fsync去將AOF日誌內容同步到磁盤，因此這一切就徹底依賴於操做系統的調試了。對大多數Linux操做系統，是每30秒進行一次fsync，將緩衝區中的數據寫到磁盤上。

2）appendfsync everysec

當設置appendfsync爲everysec的時候，Redis會默認每隔一秒進行一次fsync調用，將緩衝區中的數據寫到磁盤。可是當這一次的 fsync調用時長超過1秒時。Redis會採起延遲fsync的策略，再等一秒鐘。也就是在兩秒後再進行fsync，這一次的fsync就無論會執行多 長時間都會進行。這時候因爲在fsync時文件描述符會被阻塞，因此當前的寫操做就會阻塞。因此結論就是，在絕大多數狀況下，Redis會每隔一秒進行一 次fsync。在最壞的狀況下，兩秒鐘會進行一次fsync操做。這一操做在大多數數據庫系統中被稱爲group commit，就是組合屢次寫操做的數據，一次性將日誌寫到磁盤。

3）appednfsync always

當設置appendfsync爲always時，每一次寫操做都會調用一次fsync，這時數據是最安全的，固然，因爲每次都會執行fsync，因此其性能也會受到影響。