今天寫了乙個很簡單的限制頻率的問題。採用了mc來快取東西，由於需要快取乙個月，我選擇了，設定時間為86400*31.試了半天發現一直設定不成功。於是有了此文紀念我那懵逼的半個多小時。
後面查了資料發現memcache我們使用的set方式有效時間是有限制的，2592000秒（30天）,多一秒都不行。超過這個時間都無法get到任何東西。
1.memcache其實是支援的可以使用memcache裡面的add來進行設定有效時間。
$mem->add($key,$value,0,time()+60*24*3600)2.改用redis進行時間的設定
setex函式mc兩個原則：1.懶刪除：獲取時候才進行刪除
2.lru原則（least recently used）:記憶體空間滿了，會把最近最少使用快取刪除掉，不管是否過期
redis1，定時刪除沒設定過期時間的資料，即使記憶體空間滿了，也不會刪除，只會將其從記憶體移至硬碟。
什麼是定時刪除？顧名思義，就是我定個時間，到點就刪除，有什麼好處呢，對記憶體是最友好的，可以保證過期鍵會被盡快的刪除掉，記憶體被盡早的釋放出來，但是硬幣都有兩面啊，記憶體友好了，cup時間呢，到點就刪除到點就刪除，cup不幹別的事了，光做刪除過期鍵操作了，不現實，並且伺服器還要建立大量的定時器，來實現定時刪除，如果記憶體現在並不缺少，有空閒的記憶體，而這個時候有大量的命令請求在等待伺服器處理，那麼伺服器也應該優先把cup時間給處理客戶端請求上，而不是刪除過期鍵上。
所以定時刪除不是乙個完美的策略。
2，懶惰刪除
同樣，什麼是懶惰刪除，懶惰，懶得做刪除操作，逼不得已我是不會去刪除過期鍵的，懶到家了。
那麼什麼時候是逼不得已的時候呢，客戶端現在取這個資料了，這個key已經過期了，明顯不能返回給客戶端，這個時候也就是懶到家的時候了，不刪不行啊，客戶端那邊不願意啊，可以看出，這個策略對記憶體是極不好的，沒有建設節約型社會，但是cup時間是最友好的，不會輕易動用cup時間去刪除過期鍵。
3，定期刪除
定期？比定時時間長一點，不會時刻的去檢查過期鍵，刪除過期鍵，定期刪除，是每隔一段時間檢查一次資料庫，刪除裡面的過期鍵，很明顯定期刪除是定時刪除和懶惰刪除的乙個折中。
那麼redis中採用什麼過期刪除策略呢？
redis時間上採用了惰性刪除和定期刪除兩種策略配合使用，可以更好的使cup時間和記憶體區的平衡
本文討論redis的過期鍵刪除策略就不能不提aof和rdb兩種備份策略對過期鍵的處理
首先說一下rdb
我們知道伺服器啟動的時候如果開啟了rdb功能，伺服器會對rdb檔案進行載入
這裡分兩種情況
1，主伺服器模式，會被檔案中的鍵進行檢查，過期的鍵忽略，所以過期鍵對主伺服器不會造成影響，
2，從伺服器模式，無論過期不過期全部載入資料庫中，不過主伺服器在進行資料同步的時候，從伺服器的資料會被清空，所以一般來說，對從伺服器來說也不會造成影響
然後是aof
記住一點，在執行aof重寫的時候，過期鍵不會被儲存到重寫後的aof檔案中，所以過期鍵不會對aof造成影響。
還有就是主從複製的時候
主刪除乙個過期鍵，會顯示的告訴從
從在執行客戶端傳送的讀命令時，即使是過期鍵也不會刪除過期鍵，而是像處理未過期鍵一樣處理，從只有介紹到主的del命令才會刪除。
python 踩坑系列之遲繫結
將函式體和函式呼叫關聯起來，就叫繫結 在程式執行之前 也就是編譯和鏈結時 執行的繫結是早繫結，遲繫結 late binding 是發生在執行時。def outer return lambda x x i for i in range 3 f1,f2,f3 outer print f1 1 print...
spring boot踩的坑系列（二）
1 匯入css js檔案和一般的匯入方法不一樣，spring boot中如果使用了thymeleaf模板，則必須使用thymeleaf模板的方法來匯入資源，即src全部為th src，還需要新增 括號內為資源的路徑。2 實現跨專案的跳轉 在頁面中設定超連結到本專案中的控制端，再通過控制端跳轉到另乙個...
python 踩坑系列之巢狀列表建立
初始化列表有很多方法，其中之一可以通過 來初始化 a 3 print a 通過這個方法獲取了乙個包含三個空list的巢狀列表，下面對這個列表進行修改 print a 1 1 1 通過輸出，我們發現我們只是修改了a 0 為什麼a裡的子列表全部都被修改了，接下來通過內建函式id來檢視一下a的子元素的記憶...