什么是Redis和Memcached####
如果想做一名合格的程序員緩存是離不開的愧膀，我在日常的工作中也用到過Redis和Memcached兩種緩存，與其說緩存彪杉，Redis定位是NoSql的DB毅往，而Memcached則是一個KV的DB。但是二者都能充當緩存的角色派近，我們實際使用也以這二者居多攀唯。
什么場景會用到####
用到緩存的場景方方面面，因為他們的定位也不只是緩存渴丸，也可以用來做實際的數(shù)據(jù)存儲侯嘀。在實際的開發(fā)中，因為業(yè)務上的需求谱轨，二者也都用過戒幔，下面是我使用的場景。
1.利用Memcached存儲郵件連接的加密串土童，用于進行郵箱驗證
2.利用Memcached存儲手機驗證碼诗茎，一些網(wǎng)頁上加密用的key等
3.利用Redis做業(yè)務層的數(shù)據(jù)緩存，這樣可以擋掉一部分請求献汗，避免請求打到DB敢订，對DB造成影響。
4.利用Redis做Session的存儲罢吃，對一些用戶的身份和狀態(tài)進行校驗楚午。
5.利用Redis做一些計算數(shù)據(jù)，例如數(shù)據(jù)從Storm/Spark進行計算刃麸，對計算結(jié)果進行存儲醒叁，在請求時校驗請求，屏蔽掉惡意的訪問泊业，如:爬蟲
由于業(yè)務的需要和API的便捷性把沼，后面將Memcached換成了Redis，不是因為Memcached不好吁伺，是因為是在拒絕不了Redis方便的Api接口饮睬。
API的風格和數(shù)據(jù)類型####
說道API，真心想吐槽Memcached的API是在太屎了篮奄，大大降低開發(fā)效率捆愁。前期開發(fā)的時候是采用Memcached的割去，但是，后期我果斷換掉了使用Memcached的業(yè)務昼丑，因為代碼可讀性實在太低呻逆，反觀Redis，提供了豐富的接口和數(shù)據(jù)類型菩帝，基本能滿足所有的使用場景咖城，同時支持SuB/Pub，擴展性很好呼奢。具體API和數(shù)據(jù)類型的區(qū)別有下面幾點：
1.Memcached的基本數(shù)據(jù)類型是String宜雀，而Redis除了String之外還支持List、Set握础、ZSet和Hash等數(shù)據(jù)類型辐董。
2.API上Memcached只支持基本的add del等，但是Redis針對不同的數(shù)據(jù)結(jié)構(gòu)提供了豐富的API禀综，也內(nèi)置實現(xiàn)了一些隊列简烘、發(fā)布/訂閱的API。
架構(gòu)上的異同####
上面都是使用上的不同菇存，下面看下架構(gòu)上的不同夸研，也正是因為架構(gòu)的不同，使得二者有同時存在的必要依鸥。
首先亥至，Redis架構(gòu)上采用單線程的模式，而Memcached采用的是多線程的贱迟。這是決定二者使用場景的重要因素姐扮。
1.從資源上講，由于Redis是單線程模式衣吠，也就是說Redis只使用單核處理（for子進程這種操作例外）茶敏，因為當前的CPU基本都是多核CPU，那么Redis不會和其他進程進行計算資源的爭搶缚俏，或者說爭搶的概率比較低惊搏。對于一臺機器上多個Redis實例這無疑是一件好事，大家各司其職忧换，互不影響恬惯。但是Memcached不一樣，多線程處理的模式亚茬，使得Memcached和其他的進程有大量的CPU爭搶酪耳。這對性能是大大不利的。
2.從處理模型上講刹缝，Redis因為是單線程處理模式碗暗，也就意味著需要保證處理速度足夠快颈将，才能保證效率。這也和Redis的設計理念不謀而合言疗，Redis利用單線程的原因就是晴圾，它認為處理相當?shù)难杆伲瑔尉€程不用進行各種鎖操作洲守，純內(nèi)存的操作也能保證處理的速度可以保證疑务。但是這樣存在問題，那就是如果操作的文件塊較大梗醇，那么后面的請求可能會排隊，這樣就會導致請求大量的超時撒蟀。所以Redis比較適合處理速度比較快叙谨，數(shù)據(jù)操作開銷比較小的場景，而由于Memcached是多線程模式保屯，所以手负，對于計算開銷，和數(shù)據(jù)存取開銷比較大的場景可以考慮使用Memcached姑尺。
總結(jié)####
對于API風格實在不友好的Memcached竟终，我真是無法忍受，以至于我把所有需要緩存的場景全都換成了Redis切蟋。這可能也是我個人的習慣的選擇统捶。總之柄粹，上面是我對Redis和Memcached的一點點看法喘鸟，歡迎批評指正。
