在我們以前寫代碼 ，會把緩存代碼和業務代碼寫在一個方法裡。
帥傑是我們公司的一個高級開發人員，我交給他的活他都按時完成，但是他有一個毛病，就是槓精。
「我就這麼寫了，怎麼了。
我不給你抬槓，你那麼寫我不會說你錯。」 帥傑原話。
在程序設計的過程中，最頭疼的不是業務代碼的編寫，也不是邏輯代碼的處理，更不是算法的設計。最難的就是能夠寫出一套容易擴展，易維護的產品代碼。
話不多說，先上帥傑寫的代碼
分析下這段代碼。
帥傑想的是前端想要我的一塊數據，我先從緩存裡取，如果緩存裡沒有，我就去資料庫裡查詢。這段代碼沒有問題，而且寫的還可以。
但為什麼我要說呢。原因當然是不夠優雅呀。我們系統那麼多查詢方法，我們每個方法都向帥傑這麼寫，那還不亂了套了。
得改。
然後我想到的就是結合springaop 和註解的形式幫助帥傑把代碼解耦下。
定義註解類：
定義redis切面類
業務代碼改造
帥傑當時就抬槓，你這也沒有省代碼，怎麼代碼還比以前更多了呢。
那我們來看我們整個系統省了多少代碼，我們有上萬個查詢接口，每個接口省10行代碼，我們省了多少行？省了多少內存空間？
帥傑明白了。
那麼這些底層是怎麼實現的呢
Aop參照我寫的其他文章，這裡不做解答，
註解的底層：
從反編譯的信息來看，註解繼承了java.lang.annotation.Annotation
這個類是被動的元數據，永遠不會有主動行為，調用者可以通過反射獲得這個元數據根據它採取行動。實際就是一些鍵值對，通過解析取出這些鍵值對。
那麼redis redis底層是什麼樣的？
看過redis源碼的人知道redis是用c語言寫的，（5.0之前）是一個單線程I/o寫入，io返回的，基於內存的nosql資料庫。這篇是寫Java的，想要讓我帶你看源碼的可以關注本公眾號，後期會有相關文章帶你走進redis源碼。
如果關機，內存數據會沒有，但是你重啟之後，redis的數據還會存在，這個就是redis數據的持久化。
Rdb：首先redis進來的是rdb，剛安裝就有rdb機制。定時把內存當中的數據寫入磁碟。生成持久化文件，開機再把磁碟文件恢復到內存。原理是什麼呢？
Redis會單獨創建一個與當前進程程一模一樣的子進程進行持久化
這個子進程的所有數據（環境變量，程序計數器，變量等）都和原進程一模一樣。會先講一個數據寫入到一個臨時文件，待持久化結束了，在用這個臨時文件替換上一次的持久化的文件，整個過程中，主進程不進行一次io操作。性能是不是很高？Shutdown後，如果沒有開啟aof 會觸發配置文件中默認的快照配置。
當你執行命令save或bgsave，save只管保存，其他不管，全部阻塞，bgsave，redis會在後臺異步進行快照操作，同時可以響應客戶端的請求。使用主進程持久化，客戶端不會得到即時數據。
打開redis安裝路徑，找到redis.conf
我們shutdown一下
發現在這個路徑下確實多了一個dump.rdb
文件，說明redis在關的時候進行了一次持久化操作。
試著寫入幾個key set下。我們換個地方啟動下，發現這幾條數據是沒有的？原因是redis在不同目錄啟動會有不同的工作空間，類似你的eclipse。所以我們會把redis配置文件的dir寫死。
我們的配置文件中寫道。
Save 900 1
Save 300 100
Save 60 10000
900秒內有一次更改觸發一次rdb操作
300秒 100次更改，60秒，一萬次更改都會觸發rdb操作
你用flushall 命令 也會rdb操作，但是你會清空原來的rdb文件，類似linux rm-rf/*
意外宕機不觸發rdb機制。
Rdb單機環境可以關閉，集群環境關不了。
把rdb文件刪了，會不會再次觸發rdb操作？
只要正常save 或者重啟redis rdb會自動生成。
但隨著線上業務增加，redis的數據會越來越大，在用這種方法會出現錯誤，不能把內存中的數據保存到rdb文件中，這時需要只要做以下幾步，就可以恢復rdb文件了：
進入到redis埠，info查看配置信息
進入redis埠 執行 config set dir /data/redis/
執行 save
Aof
是將redis的操作日誌以追加的方式寫入文件，讀操作是不做記錄的。
觸發機制，根據配置文件的 no always everysec
分別代表等作業系統進行緩存數據同步到磁碟。Awlays同步持久化，每次發生數據變化後，立即記錄到磁碟。
Everysec 每秒同步一次 可能會丟失數據
Aof重寫機制：當aof 文件增加到一定大小後，redis會調用bgrewriteaof 對日誌進行重寫，還有就是aof文件大小的增長率大於改配置的時候自動開啟重寫。
redis用途:首先第一個就是緩存，redis解決冪等，生成分布式系統唯一主鍵，實現分布式隊列，點讚，統計網站訪問量等。
Redis集群搭建以及要注意什麼問題，會在以後的文章更新。
好的，本篇先寫到這裡。我們下篇見。