a、string（字串）
是key-value結構
value可以是字串，整數，浮點型
主要應用與常規的key-value的快取（這也是redis常見的使用）
b、list（鍊錶）
鍊錶中每乙個節點都可以是乙個字串，並且節點中的內容可以重複，從鍊錶的兩端進行出隊或入隊操作
主要應用：
a、訊息佇列
b、關注佇列，粉絲佇列等
c、hash（雜湊）
包含鍵值對的雜湊表，鍵值不能重複
應用場景：
由於自身的特點，可以用於儲存擁有多個特徵的實體型別（如使用者），可以用於修改某乙個屬性
d、set（集合）
是乙個無序集合，集合中每乙個元素都是唯一的
主要應用：
a、共同好友，共同喜好等玩家資訊的儲存
b、統計**訪問ip或者防止重複登陸等
c、好友推薦（好友推薦時，根據tag求交集，大於某個閾值就可以推薦）
主要應用於與好友相關的內容
e、zset（有序集合）
是乙個有序集合，字串成員(member)與浮點數分值(score)之間的有序對映，元素的排列順序由分值的大小決定。元素帶有權值
主要應用：
a、排行榜
b、帶有權重的訊息佇列（可以處理優先順序高的訊息）
redis主要有兩種持久化化機制：快照和aof機制
快照：對一段時間的記憶體中的redis資料快照到磁碟中，不會影響現有redis對外提供服務
主要問題：
a、由於是每隔一段時間啟動一次持久化，因此在時間間隔中的資料有可能會丟失；
b、在某個時間間隔中資料量過大的時候可能會影響伺服器對外服務的效能
aof：redis的每乙個寫命令都會被追加寫到檔案中，當redis重啟時根據檔案中的內容將redis的資料從新構建
主要的問題：
a、aof產生的檔案過大，有可能會出現就只是從檔案中讀取資料恢復redis的工程就會非常長，導致服務重啟過程非常耗時
目前redis中的持久化方案：
二者共同使用，使用快照持久化之前的資料，aof持久化的時兩次快照之間的資料
首先redis是對記憶體操作，有天生的速度優勢，在更多的時候是作為快取。但是相對於準備的資料庫（mysql， mongodb）等是使用磁碟的來說，redis的空間太小了。
原因：a、記憶體空間和磁碟空間的問題（大小，成本）
b、不利於擴充套件，redis是key-value結構，不能像mysql那樣可以設定聯合主鍵等（關聯查詢）
c、沒有像mysql那樣的事務
d、redis服務如果斷電後很有可能會丟失資料（致命）
主要有三點：效能，成本，可靠性
redis本身就是key-value，redis中的hash可以理解為value中又是乙個key-value
redis中的基礎資料結構dict：dict是維護了key和value的對映
dict的本質就是解決演算法中的查詢問題，兩種解決方式：雜湊表和平衡樹
dict使用的雜湊表的演算法：採用拉鍊法解決衝突，並在裝載因子（load factor）超過預定值時自動擴充套件記憶體，引發重雜湊（rehashing）。
redis中的dict的重雜湊（增量式重雜湊）：在需要擴充套件記憶體時避免一次性對所有key進行重雜湊，而是將重雜湊操作分散到對於dict的各個增刪改查的操作中去。每次都只會操作一小部分。
Redis 面試常見問題
redis常見問題 為什麼使用redis 效能和併發 分布式鎖還有其他中介軟體可以代替 使用redis有什麼缺點 單執行緒的redis問什麼這麼快 redis的資料型別，以及每種資料型別的使用場景 redis 的過期策略以及記憶體淘汰機制 redis 採用定期刪除 惰性刪除策略 採用定期刪除 惰性刪...
redis面試常見問題
系統哪些場景用到了快取？商品的資訊，其實變動不大，一般一天更新一次，但是訪問量又比較大 加快取後，利用快取提高了效能 如果後續資料變化後，系統修改了資料庫的同時，更新下快取就ok了 快取如何實現高併發 先查快取，如果快取有資料，查快取，沒有快取查資料庫，這樣可能可以將每秒4000個 請求的高併發 降...
面試 Redis面試常見問題總結
redis採用的是基於記憶體的採用的是單程序單執行緒模型的kv資料庫，由c語言編寫。官方提供的資料是可以達到100000 的qps。這個資料不比採用單程序多執行緒的同樣基於記憶體的kv資料庫memcached差。redis快的主要原因是 完全基於記憶體 資料結構簡單，對資料操作也簡單 使用多路 i ...