不積跬步，無以至千里；不積小流，無以成江海。
碼字不易，點贊再看。
絮叨
由於自己很懶，沒有做筆記的習慣，學過的東西、整理過的思路過一段時間就淡忘了，有用到的時候又要重新翻閱資料，既浪費了時間又浪費精力；痛定思痛之後，現決定把日常所學、所想、所經歷記錄下來，方便以後查閱，也希望可以幫助到需要的同學。
0202 新的一年新的開始，以後每週會不定期更新文章，希望自己可以堅持下去。
正文
Redis是現在各大互聯網中用的最常用的KV緩存，近幾年基本都是Redis的天下了，沒memcache什麼事了；
但是往往在選型的時候，我們不知道為什麼會選擇Redis
redis VS mc
當業務中有以下場景時，選Redis更合適
1. 複雜的數據結構
Redis有較豐富的數據結構（list set string hash zset），而memcache較單一隻有string類型；當業務有這樣一些特點的時候，value是哈希，列表，集合，有序集合這類複雜的數據結構時，選擇redis似乎會更加合適。
最典型場景：用戶訂單列表，用戶消息，帖子評論列表等。
2. 持久化
memcache無法滿足持久化需求，重啟後數據全部丟失；有持久化需求的只能選Redis。但是你的場景真的需要用Redis持久化功能麼
千萬不要指望把Redis當做數據庫用
redis的快照功能不能保證數據不丟失 redis的 AOF 和 RDB 會降低效率，並且不支持太大的數據量
不要期望redis的固化會比mysql做的好，用最正確的工具做各自擅長的事情，在選擇redis做固化的時候，先想一下這樣的設計是否合理。
緩存場景，開啟固化功能，優缺點
優點：redis掛了再重啟，能夠快速把熱數據恢復到內存中，不會瞬間將壓力壓到數據庫上，不需要cache預熱的過程。
缺點：redis掛了，如果數據庫中有數據修改，可能導致redis重啟後，數據庫與redis的數據不一致。
因此：一些允許不一致的業務場景，可以開啟redis固化功能。
3. 天然高可用
redis自身支持集群，實現主從複製，讀寫分離功能，
官方也提供哨兵(sentinal)的集群管理工具，實現主從監控，故障自動轉移，這一切，對客戶端是透明的，無需程序改動，也無需人工介入，
而memcache實現集群需要二次開發了
但是，針對只是用來做緩存的業務場景，真的需要高可用嗎
緩存場景，很多時候是允許cache miss的 緩存掛了，很多時候可以通過DB讀取
4.存儲容量上
memcache的value存儲，最大為1M，如果存儲的value很大，只能使用redis。
什麼時候傾向於memcache？
純KV，數據量非常大，併發量非常大的業務，使用memcache或許更適合。
這要從memcache與redis的底層實現機制差異說起。
1. 內存分配上
memcache使用預分配內存池的方式管理內存，能夠省去內存分配時間。redis則是臨時申請空間，可能導致碎片。
從這一點上，memcache會更快一些。
2. 虛擬內存
memcache把所有的數據存儲在物理內存裡。而redis有自己的VM機制，可能會刷盤影響性能
從這一點上，memcache根本不需要這些額外開銷
3. 網絡模型
Redis和memcache都是使用非阻塞的IO複用模型，但由於Redis還提供一些非KV存儲之外的排序，聚合功能，在執行這些功能時，複雜的CPU計算，會阻塞整個IO調度。
從這一點上，由於redis提供的功能較多，memcache會更快一些。
4. 線程模型
memcache使用多線程，主線程監聽，worker子線程接受請求，執行讀寫，這個過程中，可能存在鎖衝突。memcache使用CAS來進行解決併發問題。
redis使用單線程，雖無鎖衝突，但難以利用多核的特性提升整體吞吐量。浪費了機器性能，但是可以通過起多個實例；但是保證了數據按順序提交，提供了事務的功能，可以保證一串命令的原子性
從這一點上，memcache會快一些。
如果本文有任何錯誤，請批評指教，不勝感激 ！
