㈠ Redis持久化的方式有哪些優缺點分別是什麼
持久化的目的主要是做災難恢復，數據恢復。由於Redis的數據全都放在內存裡面，如果Redis掛了，沒有配置持久化的話，重啟的時候數據會全部丟失。
突然間，大量的請求過來，緩存全都無法命中，造成緩存雪崩，mysql無法承載大量的請求，造成整個系統崩潰。如果把Redis持久化做好，即使Redis故障了，也能夠立即重啟，對外提供服務。
Redis持久化分為兩種：
AOF持久化配置：
在Redis的配置文件中存在三種同步方式，它們分別是：
RDB的優缺點：
AOF的優缺點：
RDB和AOF如何選擇？
rdb是Redis DataBase縮寫
功能核心函數rdbSave(生成RDB文件)和rdbLoad（從文件載入內存）兩個函數
Aof是Append-only file縮寫
每當執行伺服器(定時)任務或者函數時flushAppendOnlyFile 函數都會被調用， 這個函數執行以下兩個工作
aof寫入保存：
WRITE：根據條件，將 aof_buf 中的緩存寫入到 AOF 文件
SAVE：根據條件，調用 fsync 或 fdatasync 函數，將 AOF 文件保存到磁碟中。
存儲結構:
內容是redis通訊協議(RESP )格式的命令文本存儲。
比較：
1、aof文件比rdb更新頻率高，優先使用aof還原數據。
2、aof比rdb更安全也更大
3、rdb性能比aof好
4、如果兩個都配了優先載入AOF
㈡ 用redis存儲session，要用session_set_save_handler()函數
把你執行的代碼貼出來
你不會直接執行的write吧，那樣redis都沒連接。你的redis都沒連接，後面的操作當然不會有效
㈢ 三分鍾讀懂redis資料庫
redis是一個key-value存儲系統。和Memcached類似，它支持存儲的value類型相對更多，包括string(字元串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash（哈希類型）。這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎上，redis支持各種不同方式的排序。與memcached一樣，為了保證效率，數據都是緩存在內存中。區別的是redis會周期性的把更新的數據寫入磁碟或者把修改操作寫入追加的記錄文件，並且在此基礎上實現了master-slave(主從)同步。
1. 使用Redis有哪些好處？
(1) 速度快，因為數據存在內存中，類似於HashMap，HashMap的優勢就是查找和操作的時間復雜度都是O(1)
(2) 支持豐富數據類型，支持string，list，set，sorted set，hash
(3) 支持事務，操作都是原子性，所謂的原子性就是對數據的更改要麼全部執行，要麼全部不執行
(4) 豐富的特性：可用於緩存，消息，按key設置過期時間，過期後將會自動刪除
2. redis相比memcached有哪些優勢？
(1) memcached所有的值均是簡單的字元串，redis作為其替代者，支持更為豐富的數據類型
(2) redis的速度比memcached快很多
(3) redis可以持久化其數據
3. redis常見性能問題和解決方案：
(1) Master最好不要做任何持久化工作，如RDB內存快照和AOF日誌文件
(2) 如果數據比較重要，某個Slave開啟AOF備份數據，策略設置為每秒同步一次
(3) 為了主從復制的速度和連接的穩定性，Master和Slave最好在同一個區域網內
(4) 盡量避免在壓力很大的主庫上增加從庫
(5) 主從復制不要用圖狀結構，用單向鏈表結構更為穩定，即：Master <- Slave1 <- Slave2 <- Slave3...
這樣的結構方便解決單點故障問題，實現Slave對Master的替換。如果Master掛了，可以立刻啟用Slave1做Master，其他不變。
4. MySQL里有2000w數據，redis中只存20w的數據，如何保證redis中的數據都是熱點數據
相關知識：redis 內存數據集大小上升到一定大小的時候，就會施行數據淘汰策略。redis 提供 6種數據淘汰策略：
voltile-lru：從已設置過期時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰
volatile-ttl：從已設置過期時間的數據集（server.db[i].expires）中挑選將要過期的數據淘汰
volatile-random：從已設置過期時間的數據集（server.db[i].expires）中任意選擇數據淘汰
allkeys-lru：從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰
allkeys-random：從數據集（server.db[i].dict）中任意選擇數據淘汰
no-enviction（驅逐）：禁止驅逐數據
相關推薦：《Python視頻教程》
5. Memcache與Redis的區別都有哪些？
1)、存儲方式
Memecache把數據全部存在內存之中，斷電後會掛掉，數據不能超過內存大小。
Redis有部份存在硬碟上，這樣能保證數據的持久性。
2)、數據支持類型
Memcache對數據類型支持相對簡單。
Redis有復雜的數據類型。
3），value大小
redis最大可以達到1GB，而memcache只有1MB
6. Redis 常見的性能問題都有哪些？如何解決？
1).Master寫內存快照，save命令調度rdbSave函數，會阻塞主線程的工作，當快照比較大時對性能影響是非常大的，會間斷性暫停服務，所以Master最好不要寫內存快照。
2).Master AOF持久化，如果不重寫AOF文件，這個持久化方式對性能的影響是最小的，但是AOF文件會不斷增大，AOF文件過大會影響Master重啟的恢復速度。Master最好不要做任何持久化工作，包括內存快照和AOF日誌文件，特別是不要啟用內存快照做持久化,如果數據比較關鍵，某個Slave開啟AOF備份數據，策略為每秒同步一次。
3).Master調用BGREWRITEAOF重寫AOF文件，AOF在重寫的時候會佔大量的CPU和內存資源，導致服務load過高，出現短暫服務暫停現象。
4). Redis主從復制的性能問題，為了主從復制的速度和連接的穩定性，Slave和Master最好在同一個區域網內
7. redis 最適合的場景
Redis最適合所有數據in-momory的場景，雖然Redis也提供持久化功能，但實際更多的是一個disk-backed的功能，跟傳統意義上的持久化有比較大的差別，那麼可能大家就會有疑問，似乎Redis更像一個加強版的Memcached，那麼何時使用Memcached,何時使用Redis呢?
如果簡單地比較Redis與Memcached的區別，大多數都會得到以下觀點：
1.Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。
2.Redis支持數據的備份，即master-slave模式的數據備份。
3.Redis支持數據的持久化，可以將內存中的數據保持在磁碟中，重啟的時候可以再次載入進行使用。
（1）會話緩存（Session Cache）
最常用的一種使用Redis的情景是會話緩存（session cache）。用Redis緩存會話比其他存儲（如Memcached）的優勢在於：Redis提供持久化。當維護一個不是嚴格要求一致性的緩存時，如果用戶的購物車信息全部丟失，大部分人都會不高興的，現在，他們還會這樣嗎？
幸運的是，隨著 Redis 這些年的改進，很容易找到怎麼恰當的使用Redis來緩存會話的文檔。甚至廣為人知的商業平台Magento也提供Redis的插件。
（2）全頁緩存（FPC）
除基本的會話token之外，Redis還提供很簡便的FPC平台。回到一致性問題，即使重啟了Redis實例，因為有磁碟的持久化，用戶也不會看到頁面載入速度的下降，這是一個極大改進，類似PHP本地FPC。
再次以Magento為例，Magento提供一個插件來使用Redis作為全頁緩存後端。
此外，對WordPress的用戶來說，Pantheon有一個非常好的插件 wp-redis，這個插件能幫助你以最快速度載入你曾瀏覽過的頁面。
（3）隊列
Reids在內存存儲引擎領域的一大優點是提供 list 和 set 操作，這使得Redis能作為一個很好的消息隊列平台來使用。Redis作為隊列使用的操作，就類似於本地程序語言（如Python）對 list 的 push/pop 操作。
如果你快速的在Google中搜索「Redis queues」，你馬上就能找到大量的開源項目，這些項目的目的就是利用Redis創建非常好的後端工具，以滿足各種隊列需求。例如，Celery有一個後台就是使用Redis作為broker，你可以從這里去查看。
（4）排行榜/計數器
Redis在內存中對數字進行遞增或遞減的操作實現的非常好。集合（Set）和有序集合（Sorted Set）也使得我們在執行這些操作的時候變的非常簡單，Redis只是正好提供了這兩種數據結構。所以，我們要從排序集合中獲取到排名最靠前的10個用戶–我們稱之為「user_scores」，我們只需要像下面一樣執行即可：
當然，這是假定你是根據你用戶的分數做遞增的排序。如果你想返回用戶及用戶的分數，你需要這樣執行：
ZRANGE user_scores 0 10 WITHSCORES
Agora Games就是一個很好的例子，用Ruby實現的，它的排行榜就是使用Redis來存儲數據的，你可以在這里看到。
（5）發布/訂閱
最後（但肯定不是最不重要的）是Redis的發布/訂閱功能。發布/訂閱的使用場景確實非常多。我已看見人們在社交網路連接中使用，還可作為基於發布/訂閱的腳本觸發器，甚至用Redis的發布/訂閱功能來建立聊天系統！（不，這是真的，你可以去核實）。
㈣ php不使用第三方工具,如何設計緩存
結論：可自行設計，或使用內置APCu緩存。
1 - 第三方緩存
常用的第三方緩存工具，一般是指redis，memcached，以及雲服務商提供的緩存服務。基本不脫離此二類范圍。
用法非常直觀，我們不做深入的介紹了。可在官方手冊內查看。
4 - 寫在最後
本文簡要說明了PHP內緩存數據可能使用的方法。我們推薦使用成熟的類庫或擴展，不要重復造輪子。
㈤ python怎樣清除redis緩存
想要查看一個db下有多少key,在Redis-cli中輸入 keys * 即可
如果想刪除某個key 可以使用del 命令 例如： del key delkey（你要刪除的key的名稱）
那麼Python如何來查看呢？
[cpp] view plain
# coding=utf-8
'''
Created on 2015-9-8
@author: kwsy
'''
import redis
pool=redis.ConnectionPool(host='192.168.1.126',port=6379,db=0)
r = redis.StrictRedis(connection_pool=pool)
keys = r.keys()
print type(keys)
print keys
keys的type是 list ，所有的key將存入這個list作為結果返回
如果想返回特定形式的key,可以在keys()函數中添加參數，例如keys = r.keys("finger*") 那麼將只返回以finger開頭的key
key的刪除也非常簡單
[cpp] view plain
# coding=utf-8
'''
Created on 2015-9-8
@author: kwsy
'''
import redis
pool=redis.ConnectionPool(host='192.168.1.126',port=6379,db=0)
r = redis.StrictRedis(connection_pool=pool)
r.delete("del1","del2")
我這里是同時刪掉兩個key
㈥ Flask-Cache 怎麼緩存動態內容
看了一下 Flask-Cache 的文檔，比如：
from flask import Flask
from flask.ext.cache import Cache
app = Flask(__name__)
# Check Configuring Flask-Cache section for more details
cache = Cache(app,config={'CACHE_TYPE': 'simple'})
cache = Cache(config={'CACHE_TYPE': 'simple'})
# cache = Cache(app, config={'CACHE_TYPE': 'redis'})
app = Flask(__name__)
cache.init_app(app)
然後緩存視圖函數：
@cache.cached(timeout=50)
def index():
return render_template('index.html')
兩個疑問：
1 、如果這個視圖函數 index()是動態的內容，比如是用戶的 Newsfeed 聚合頁，這個 cache 是緩存每一個用戶的 index 內容嗎？
2 、文檔里簡單提到，在 config 里（ Werkzeug 0.7 以上版本即可），可以把 CACHE_TYPE 的 simple 改用 redis 來代替，這個 redis 的緩存數據，可以通過 SQLAlchemy 從 MySQL 載入部分需要緩存的數據嗎？
原鏈接：
http://www.pythondoc.com/flask-cache/index.html#flask.ext.cache.Cache.memoize
http://stackoverflow.com/questions/24589123/how-to-cache-sql-alchemy-calls-with-flask-cache-and-redis
㈦ redis怎麼緩存sql數據
利用redis做緩存伺服器來緩解資料庫查詢壓力是非常有效也是非常有必要的， 當用戶第一次點擊頁面的時候查詢資料庫， 然後將查詢結果緩存在redis伺服器中，緩存時間隨你的數據改變時間而定，這樣可大大降低資料庫壓力；下面是具體函數方法；
public function getSqlVal(){
//獲取參數列表,這個參數隨你需求而定，一般可能需要傳入dbname，查詢方式如fetchAll，查詢語句等
$argv = func_get_args();
//假設這里現在只傳入dbName和sql語句
$dbName = $argv[0];
$sql = $argv[1];
//現在把這個參數列表轉成md5之後作為存redis的key值
$md5SqlKey = MD5(serialize($argv));
//下面通過一個redis函數來進行存取數據
$res = getRedisData($md5SqlKey);
//如果取到數據，說明已經緩存在redis伺服器中， 直接取數據就好， 如果沒有數據， 則再去資料庫查詢數據，再講查詢的數據存在redis伺服器中
if(!empty($res)) {
return $res;
}
//後面是查詢資料庫操作,查詢結果返回在$res中
getRedisData($md5SqlKey,$res); //講返回結果存在redis中
return $res;
}
public function getSqlVal(){
//獲取參數列表,這個參數隨你需求而定，一般可能需要傳入dbname，查詢方式如fetchAll，查詢語句等
$argv = func_get_args();
//假設這里現在只傳入dbName和sql語句
$dbName = $argv[0];
$sql = $argv[1];
//現在把這個參數列表轉成md5之後作為存redis的key值
$md5SqlKey = MD5(serialize($argv));
//下面通過一個redis函數來進行存取數據
$res = getRedisData($md5SqlKey);
//如果取到數據，說明已經緩存在redis伺服器中， 直接取數據就好， 如果沒有數據， 則再去資料庫查詢數據，再講查詢的數據存在redis伺服器中
if(!empty($res)) {
return $res;
}
//後面是查詢資料庫操作,查詢結果返回在$res中
getRedisData($md5SqlKey,$res); //講返回結果存在redis中
return $res;
}
㈧ redis主要解決了什麼問題
Redis 常見的性能問題和解決方法
1.Master寫內存快照
save命令調度rdbSave函數，會阻塞主線程的工作，當快照比較大時對性能影響是非常大的，會間斷性暫停服務，所以Master最好不要寫內存快照。
2.Master AOF持久化
如果不重寫AOF文件，這個持久化方式對性能的影響是最小的，但是AOF文件會不斷增大，AOF文件過大會影響Master重啟的恢復速度。
3.Master調用BGREWRITEAOF
Master調用BGREWRITEAOF重寫AOF文件，AOF在重寫的時候會佔大量的CPU和內存資源，導致服務load過高，出現短暫服務暫停現象。
下面是我的一個實際項目的情況，大概情況是這樣的：一個Master，4個Slave，沒有Sharding機制，僅是讀寫分離，Master負責寫入操作和AOF日誌備份，AOF文件大概5G，Slave負責讀操作，當Master調用BGREWRITEAOF時，Master和Slave負載會突然陡增，Master的寫入請求基本上都不響應了，持續了大概5分鍾，Slave的讀請求過也半無法及時響應，Master和Slave的伺服器負載圖如下：
Master Server load：
上面的情況本來不會也不應該發生的，是因為以前Master的這個機器是Slave，在上面有一個shell定時任務在每天的上午10點調用BGREWRITEAOF重寫AOF文件，後來由於Master機器down了，就把備份的這個Slave切成Master了，但是這個定時任務忘記刪除了，就導致了上面悲劇情況的發生，原因還是找了幾天才找到的。
將no-appendfsync-on-rewrite的配置設為yes可以緩解這個問題，設置為yes表示rewrite期間對新寫操作不fsync，暫時存在內存中，等rewrite完成後再寫入。最好是不開啟Master的AOF備份功能。
4.Redis主從復制的性能問題
第一次Slave向Master同步的實現是：Slave向Master發出同步請求，Master先mp出rdb文件，然後將rdb文件全量傳輸給slave，然後Master把緩存的命令轉發給Slave，初次同步完成。第二次以及以後的同步實現是：Master將變數的快照直接實時依次發送給各個Slave。不管什麼原因導致Slave和Master斷開重連都會重復以上過程。Redis的主從復制是建立在內存快照的持久化基礎上，只要有Slave就一定會有內存快照發生。雖然Redis宣稱主從復制無阻塞，但由於Redis使用單線程服務，如果Master快照文件比較大，那麼第一次全量傳輸會耗費比較長時間，且文件傳輸過程中Master可能無法提供服務，也就是說服務會中斷，對於關鍵服務，這個後果也是很可怕的。
以上1.2.3.4根本問題的原因都離不開系統io瓶頸問題，也就是硬碟讀寫速度不夠快，主進程 fsync()/write() 操作被阻塞。
5.單點故障問題
由於目前Redis的主從復制還不夠成熟，所以存在明顯的單點故障問題，這個目前只能自己做方案解決，如：主動復制，Proxy實現Slave對Master的替換等，這個也是Redis作者目前比較優先的任務之一，作者的解決方案思路簡單優雅，詳情可見 Redis Sentinel design draft
總結
Master最好不要做任何持久化工作，包括內存快照和AOF日誌文件，特別是不要啟用內存快照做持久化。
如果數據比較關鍵，某個Slave開啟AOF備份數據，策略為每秒同步一次。
為了主從復制的速度和連接的穩定性，Slave和Master最好在同一個區域網內。
盡量避免在壓力較大的主庫上增加從庫
為了Master的穩定性，主從復制不要用圖狀結構，用單向鏈表結構更穩定，即主從關系為：Master<–Slave1<–Slave2<–Slave3…….，這樣的結構也方便解決單點故障問題，實現Slave對Master的替換，也即，如果Master掛了，可以立馬啟用Slave1做Master，其他不變。