美好只能封裝在記憶的信封之中，喜悅猶如彈指之間飛逝的花瓣。終究只屬于當下和日后的回憶。往事不能抹去，當下才是新的征程與起點。
網站最初通常不會存在高并發的情況，使用最簡單的LNMP架構即可滿足網站中的需求，但隨著網站運營時間的累加，用戶量的增多，網站在應對大量的用戶請求時。將會出現卡頓、5xx系列錯誤、頁面加載緩慢等問題。最初網站的流暢運行將隨風而逝，眼下就需要程序員解決網站因為并發而造成的一系列問題。
因為單一使用數據庫來保存數據的系統是面向于磁盤，磁盤讀/寫速度比較慢的問題而存在嚴重的性能弊端，一瞬間成千上萬的請求到來，需要系統在極短的時間內完成 成千上萬次的讀/寫操作，這個時候往往不是數據庫能夠承受的，極其容易造成數據庫系統癱瘓，最終導致服務宕機的嚴重生產問題。
為了克服上述的問題，Web項目通常會引入NoSQL技術，這是一種基于內存的數據庫，并且提供一定的持久化功能。
redis作為一款高性能的Key-Value的鍵值對緩存數據庫，因豐富的數據類型而廣泛應用于項目不同的應用場景。redis可以支持每秒十幾萬此的讀/寫操作，并且還支持集群、分布式、主從同步等配置，原則上可以無限擴展。
但多數情況下，絕大多數開發者只是單純用Redis做緩存的保留使用，對于其它的數據類型基本都避而不見，但是往往采用Redis其它的數據類型可以代替其應用業務中 需要數據庫提供的關系型數據。例如：投票、排行榜、粉絲統計、消息隊列、發布訂閱等等。這些場景的取代可以大幅度的提高網站的響應速度。
如果只是單純的接觸緩存還無妨，但往往實際場景中用到Redis的地方很多，關鍵是在于自身如何去接入Redis到網站中。
會使用，干嘛還要會用redis
1、使用最簡單，提升最緩慢
任何一門技術想快速入門，莫過于它的使用，因為這個過程中的，你的目的很明確，我就需要知道它大致的操作步驟、使用條件。入門后在是熟練操作的步驟，總結為自己的經驗內容。
但這樣往往有個問題，就是對于項目的業務場景分析不深刻，沒有根據業務的情況選擇合適的內容，而是萬能的套模板式的開發，久而久之就感覺像在做簡單的業務開發，沒有什么實質性的突破，感覺自己的提升非常的緩慢。
這就是所謂的認知偏見，在你意識中Redis只可用于緩存，那么任何的業務條件下都是用它按照set 、get的方式來解決實際問題，對于業務場景下面的過程就少了業務場景下結果的分析。但隨著業務快速的發展很快就會出現瓶頸問題。
例如:今日頭條的青云計劃中，每天中獎的名單會有100-1000個，同時還有分類的問題，一級、二級、三級，如果按照使用的方式可能就是根據你每個分類+ID值作為key，value就是固定長度標題+文章內容(也可分開設計key+value)。 雖然設置為緩存了，那如果需要展示的時候怎么好查詢呢？
如果設置的時候每個分類對應一條記錄對于一個key-->value，那你查詢就需要規則匹配，這樣很容易發生阻塞問題，同時每個分類下面的1 2 3三級的文章，如果在value里面設置對應的標識，取值出來還需要進行修改。費時又費力。
那如果把業務拆分成不同的分類、1 2 3級、標題。我們就可以用有序集合來確定分類名稱，對應的標題，等級，用Hash結構做文章內容存儲、發布時間、作者、瀏覽量等。這樣是不是就可以按照業務的組成來選擇對應的數據呢？
從而讓我們更好的去理解業務。對于redis的認識也更加深刻，思維上也不在是按照普通的方式，而是根據業務場景選擇合適的工具來做
2、好的方法可以節省時間
俗話說“工欲善其事，必先利其器”。好的數據類型就是我們的工具，如果在開始階段對業務的分析，決定了選擇什么好的數據類型，那么再去做的時候就可業務條件編寫即可。而不是在書寫的時候就是那緩存說話，這樣你會花費很多的時間去修改對應的數據存儲機構到Redis中。
因為普通的key->value的模式就像當與一對一的模式，如果你有其他的需求那么你知道在對應的value中做標記達到你需要的存儲結構。同時效率也會很低的。但往往絕大多數開發者都不會提前的構思，直接動手寫，如果有經驗的工程師還好，因為別人知道書寫的方向，但初學者就是會不斷的碰壁，碰壁之后自己也沒有任何的積累過程。后面遇到同樣的問題，開發效率也不會高到哪里去。
3、價值產生不一樣
任何一個人都是喜歡優秀的人，如果你做的事情都是滿大街都有的東西，沒得自己的方法與經驗。那你的價值如何體現呢？
比如：幾十年前的時候，通訊不發達，那時候有一個手機，可能是成功的人了。就在于絕大數人都沒有手機這個東西。“物以稀為貴”就是這個理
如果問到你對Redis的使用，張口閉口就是緩存，而不在理會其它的數據類型，用于解決業務場景中的問題，這樣的情況下如何證明自己熟練Redis呢？同時對于Redis的優化和高級、底層這些內容沒了解，如何應對難度的問題呢？
總是說自己不會，那有過深入的研究準備嗎？一切都停留在初級的階段不打破，何來提升。 因為這才是固之根本所在。
如何更好的使用Redis
一、數據結構不將就，好鋼用在刀刃上
使用好Redis的第一步，需要對Redis的數據方式有全新的認識。認識每個數據類型的結構特點。同數據結構的組成上對應到業務數據存儲上，在由業務數據特點對應到所適合的數據類型有那些。有時候選擇好工具后，會事半功倍。
以下就是Redis的5大基礎類型特點：
1、String 可以包含任何數據,比如jpg圖片或者序列化的對象,一個鍵最大能存儲512M。
常用場景：分布式session會話、計數器、接口限速、分布式鎖等。
特點：對于數字遞增處理、字符串處理都可以，因為它是Kye->Value關系的結構。就是相 當于對一個key的描述，前提是要找好key屬于要準備操作什么數據類型。
常用命令：
SET key value GET key MSET key1 value1 [key2 value2] MGET key1 key2 INCR key DECR key SETNX key value #只有key 不存在時，才設置key的值
2、Hash 鍵值對集合，即編程語言中的Map類型。適合存儲對象，并且可以像數據庫中update一個屬性一樣只修改某一項屬性值。
常用場景：存儲、讀取、修改用戶屬性、購物車等
特點：Hash的結構類似于與字典結構，有一個key指定名稱，value用于描述這個可以的信息，一般用于描述對象的基本信息。
例如：購物車里面商品ID、商品數量、用戶ID、銷量、關注等這些信息都算是購物車需要的信息結構。采用它靈活性是非常高的
常用命令：
HSET%20key%20field%20value HGET%20key%20field HGETALL%20key HMSET%20key%20field1%20value1%20[field2%20value2] HMGET%20key%20field1%20[filed2]
3、List 鏈表(雙向鏈表)。存儲數據的特點猶如一個有序列表的形式，由左、右邊可插入數據到其中。
常用場景：最新消息排行等功能、消息隊列、評論列表、令牌桶算法等。
特點：List結構關鍵部分它是一個雙向鏈表，可以雙向的添加信息到列表中，使用的時候在以出隊的方式取出，所以只要滿足操作的條件即可。同時列表也可做類似消息的排隊處理操作。
常用命令：
LPUSH key value1 [value2] #將一個或多個值插入到列表頭部 LPOP key #移出并獲取列表的第一個元素 RPUSH key value1 [value2] #在列表尾部添加一個或多個值 RPOP key #移除并獲取列表最后一個元素 LREM key count value #移除列表元素 LRANGE key start stop #獲取列表指定范圍內的元素
4、Set 由哈希表實現，用于存儲多個字符串的元素，但和列表不同的是集合中不允許有重復的元素，并且集合中的元素是無序的。
常用場景： 標簽、共同好友、共同好友等
特點: 集合的內部有hash表實現，這個很重要。也就是它的特別和hash的字典結構差不多，只不過它相當于內部沒有key的指定，直接是信息的存儲。把結果堆積在一起。
常用命令：
SADD key member1 [member2] #向集合添加一個或多個成員 SDIFF key1 [key2] #返回給定所有集合的差集 SINTER key1 [key2] #返回給定所有集合的交集 SUNION key1 [key2] #返回所有給定集合的并集 SISMEMBER key member #判斷 member 元素是否是集合 key 的成員 SMEMBERS key #返回集合中的所有成員 SREM key member1 [member2] # 移除集合中一個或多個成員
5、Sorted Set：有序集合。將Set中的元素增加一個權重參數score，元素按score有序排列。數據插入集合時，已經是進行天然排序。
常用場景：排行榜、帶權重的消息隊列、時間線等
特點：存儲結構特點像hash的結構，只不過是把hash內部的key變為了Score用于技術的分值。但是數據存儲結構還是一致的，后面選擇它的時候可以用于排行、權重這一塊的業務，內部有一個計數的選項來保持內容的結果。
常用命令：
ZADD key score1 member1 [score2 member2] #向有序集合添加一個或多個成員，或者更新已存在成員的分數 ZINCRBY key increment member #有序集合中對指定成員的分數加上增量 increment ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT] #通過分數范圍返回有序集合指定區間內的成員 ZINTERSTORE destination numkeys key [key …] #計算給定的一個或多個有序集的交集，并將結果集存儲在新的有序集合 key 中 ZUNIONSTORE destination numkeys key [key …] #計算給定的一個或多個有序集的并集，并存儲在新的 key 中
對于數據結構更多是需要明白每個數據類型的組成，當拿到業務情況時。首先拆解業務組成的屬性，從而用Redis的數據類型來代替原來需要MySQL結構化數據實現的業務，從而提升性能。同時應對一些情況特殊的場景，例如：秒殺用隊列的時候、分布式時采用session共享會話等等
二、提升緩存命中率
說到底Redis再好，它的本質就是用于緩存數據，如果請求沒有在Redis里面找到緩存的內容，那么同樣還是不能減輕數據的壓力。同時如果內存存儲一些冷數據也不能為那些高頻率使用網站的用戶提供服務。
所以提升緩存的命中率顯得異常重要。那么如何來提升緩存的命令率呢？
那我們可設想，既然緩存的數據是需要通過Key的方式獲取，那么我們在服務端進行key的監控，把那些不經常使用的key換成熱點數據的key。同時緩存是為了提供業務的快速訪問，但網站中熱點的業務并不是所有的業務都需要等等。
歸納起來就是每個請求應該在哪里去找到key? 這個key使用的頻率高嗎？這個key會受那些因素影響后而導致緩存的命中率降低呢？
以下是一些因素問題的影響：
1. 業務場景
緩存適合“讀多寫少”的業務場景，反之，使用緩存的意義不大，命中率會很低。緩存時間越長，命中率會越高。時效性要求越低，就越適合緩存。
2. 更新策略
緩存的粒度越小，命中率會越高。舉個實際的例子說明：
當緩存單個對象的時候（例如：單個用戶信息），只有當該對象對應的數據發生變化時，我們才需要更新緩存或者讓移除緩存。而當緩存一個集合的時候（例如：所有用戶數據），其中任何一個對象對應的數據發生變化時，都需要更新或移除緩存
3. 清理策略
對于持續運行的Redis服務器來說， 服務器需要定期對自身的資源和狀態進行必要的檢查和整理，有三種不同的刪除策略，立即刪除會短時間內占用大量cpu，惰性刪除會在一段時間內浪費內存，所以定時刪除是一個折中的辦法。
（1）立即清理。在設置鍵的過期時間時，創建一個回調事件，當過期時間達到時，由時間處理器自動執行鍵的刪除操作。
（2）惰性清理。鍵過期了就過期了，不管。當讀/寫一個已經過期的key時，會觸發惰性刪除策略，直接刪除掉這個過期key
（3）定期清理。每隔一段時間，對expires字典進行檢查，刪除里面的過期鍵。
4. 緩存容量
緩存的容量有限，則容易引起Redis自身的緩存被淘汰淘汰策略。
5. 緩存故障
緩存節點故障，也會引起緩存失效，所以業內比較典型的做法就是通過一致性Hash算法來均衡分布緩存，或者通過集群采用節點冗余的方式。
6、監控Redis緩存操作命令
首先可通過info命令來分析緩存的率是否滿足業務，如果太低那么就可以采用monitor命令或者第三方工具(如：redis-faina)分析操作key的訪問頻率，進而動態更改業務場景需要訪問key的類型。
三、優化服務器內存
內存可以說是服務器最寶貴的資源運行地，所以對于Redis使用過程中，應該來優化Redis的內存，從而使其發揮出更大的性能。
那這個Redis的內存應該如何優化呢? 首先存儲任何的緩存都是基于Redis的數據類型進行選擇，但Redis設置key的時候選擇對應的類型就顯得的很重要。設置key和value的時候也不要過長等
就應該從Redis緩存的組成結構，淘汰緩存上做到避免無用數據占用緩存、內存碎片、數據類型使用內存上等問題來做分析
如下一些常用的思路
Redis主進程的內存消耗：
- Redis自身使用的內存：消耗很少，3MB多點
- 對象內存
- 緩沖內存
- 內存碎片
3.1對象內存：所有key對象長度 + 所有value對象長度
- 每次創建鍵值對時，至少創建兩個類型對象：key對象、value對象，應該使用短鍵名
3.2緩沖內存：
- 每個客戶端的輸入、輸出緩沖內存：
- 輸入緩沖最大1G，超出則關閉該客戶端連接；
- 輸出緩沖：16KB的固定緩沖區、動態緩沖區，動態緩沖區可通過client-output-buffer-limit配置參數限制（根據客戶端類型normal、slave、pubsub，分開設置）
- client-output-buffer-limit normal 0 0 0
- client-output-buffer-limit slave 256mb 64mb 60 //超過256MB時，或者持續超過64MB達60秒，關閉連接
- client-output-buffer-limit pubsub 32mb 8mb 60
- 復制積壓緩沖內存：用于主從復制的部分復制，所有客戶端共享該緩沖區，默認1MB，可通過repl-backlog-size調整，適當調大，可有效避免全量復制；
- AOF緩沖內存：用于保存在AOF重寫期間的寫命令，便于重寫完畢后把緩沖的命令追加到AOF文件中；
3.3內存碎片：
- 當存儲的數據長短差異較大時，就容易出現大量內存碎片，應該盡可能地保持數據對齊或使用固定長度的字符串；
- 內存碎片只能通過完全重啟Redis來清除；
3.4內存回收策略：
- 為鍵設置過期屬性，Redis采用惰性刪除和定時任務刪除機制實現過期鍵的內存回收；
- 惰性刪除：在讀取鍵時才檢查是否過期
- 定時任務刪除：通過hz配置參數設置頻率，默認每秒10次；
- 內存溢出控制策略：共6中策略，通過maxmemory-policy配置參數控制，默認noeviction（不刪除，拒絕寫入，返回錯誤）
- LRU算法表示最近最少使用的，LFU算法表示最不常用的：
- ＃volatile-lru - >在設置了過期的key中，刪除最近最少使用的key，直到空間足夠為止
- ＃allkeys-lru - >從所有key里刪除最近最少使用的key，不管有沒設置過期，直到空間足夠為止
- ＃volatile-lfu - >在設置了過期的key中，刪除最少使用的key，直到空間足夠為止
- ＃allkeys-lfu - >從所有key里刪除最少使用的key，不管有沒設置過期，直到空間足夠為止
- ＃volatile-random - >刪除一個過期集合中的隨機key。
- ＃allkeys-random - >刪除一個隨機key，不管有沒設置過期。
- ＃volatile-ttl - >刪除即將過期的key（次TTL）
- ＃noviction - >不刪除，拒絕寫入，寫入操作時返回錯誤。
- maxmemory-samples 5 是說每次進行淘汰的時候，會隨機抽取5個key 從里面淘汰最少使用的（默認選項）
- 應避免內存溢出，因為在內存溢出且非noeviction策略時，會頻繁觸發回收內存的操作，影響Redis性能，若有從節點，還會把刪除命令同步給從節點；
- 對于只做緩存的場景下，可通過調小maxmemory，并執行一次命令，如果使用非noeviction策略，則會一次性回收到maxmemory指定的內存使用量，實現內存的快速回收，但會導致數據丟失和短暫阻塞
不單要使用，而是要會用。會用Redis可以幫助提升自己能力，展示自己的價值。很多時候應該先接觸在代入到實際的工作場景中去使用，考慮的時候先進行知識的搜捕。然后與實際的場景業務進行類比處理。更多是知與行的結合
