一線互聯網公司Redis使用精髓，你必須要掌握這4點！

先來看一下這些Redis面試題你會幾道？

1、什么是 Redis？簡述它的優缺點？
2、Redis 與 memcached 相比有哪些優勢？
3、Redis 支持哪幾種數據類型？
4、Redis 主要消耗什么物理資源？
5、Redis 有哪幾種數據淘汰策略？
6、Redis 官方為什么不提供 Windows 版本？
7、一個字符串類型的值能存儲最大容量是多少？
8、為什么 Redis 需要把所有數據放到內存中？
9、Redis 集群方案應該怎么做？都有哪些方案？
10、Redis 集群方案什么情況下會導致整個集群不可用？
11、MySQL 里有 2000w 數據，redis 中只存 20w 的數據，如何保證 redis 中的數據都是熱點數據？
12、Redis 有哪些適合的場景？
13、Redis 支持的 Java 客戶端都有哪些？官方推薦用哪個？
14、Redis 和 Redisson 有什么關系？
15、Jedis 與 Redisson 對比有什么優缺點？
16、說說 Redis 哈希槽的概念？
17、Redis 集群的主從復制模型是怎樣的？
18、Redis 集群會有寫操作丟失嗎？為什么？
19、Redis 集群如何選擇數據庫？
20、Redis 如何做內存優化？

了解Redis

Redis是一種基于鍵值對(Key-Value)的NoSQL數據庫，Redis的Value可以由String，hash，list，set，zset，Bitmaps，HyperLogLog等多種數據結構和算法組成。Redis還提供了鍵過期，發布訂閱，事務，Lua腳本，哨兵，Cluster等功能。Redis執行命令的速度非常快，根據官方給的性能可以達到10w+qps。那么本文主要介紹到底Redis快在哪里，主要有以下幾點：

開發語言

現在我們都用高級語言來編程，比如Java、python等。也許你會覺得C語言很古老，但是它真的很有用，畢竟unix系統就是用C實現的，所以C語言是非常貼近操作系統的語言。Redis就是用C語言開發的，所以執行會比較快。
另外多說一句，大學生們好好學C，會讓你更好的理解計算機操作系統。別覺得學了高級語言就可以不用關注底層，欠的債總歸要還的。此處推薦一本比較難啃的書《深入理解計算系統》。

純內存訪問

Redis將所有數據放在內存中，非數據同步正常工作中，是不需要從磁盤讀取數據的，0次IO。內存響應時間大約為100納秒，這是Redis速度快的重要基礎。先看看CPU的速度：

拿我的電腦來說，主頻是3.1G，也就是說每秒可以執行3.1*10^9個指令。所以說CPU看世界是非常非常慢的，內存比它慢百倍，磁盤比他慢百萬倍，你說快不快？
借了一張《深入理解計算機系統》的圖，展示了一個典型的存儲器層次結構，在L0層，CPU可以在一個時鐘周期訪問到，基于SRAM的高速緩存春續期，可以在幾個CPU時鐘周期訪問到，然后是基于DRAM的主存，可以在幾十到幾百個時鐘周期訪問到他們。

單線程

第一，單線程簡化算法的實現，并發的數據結構實現不但困難且測試也麻煩。第二，單線程避免了線程切換以及加鎖釋放鎖帶來的消耗，對于服務端開發來說，鎖和線程切換通常是性能殺手。當然了，單線程也會有它的缺點，也是Redis的噩夢：阻塞。如果執行一個命令過長，那么會造成其他命令的阻塞，對于Redis是十分致命的，所以Redis是面向快速執行場景的數據庫。
除了Redis之外，Node.js也是單線程，Nginx也是單線程，但他們都是服務器高性能的典范。

非阻塞多路I/O復用機制

在這之前先要說一下傳統的阻塞I/O是如何工作的：當使用read或者write對某一文件描述符（File Descriptor FD）進行讀寫的時候，如果數據沒有收到，那么該線程會被掛起，直到收到數據。阻塞模型雖然易于理解，但是在需要處理多個客戶端任務的時候，不會使用阻塞模型。

I/O多路復用實際上是指多個連接的管理可以在同一進程。多路是指網絡連接，復用只是同一個線程。在網絡服務中，I/O多路復用起的作用是一次性把多個連接的事件通知業務代碼處理，處理的方式由業務代碼來決定。在I/O多路復用模型中，最重要的函數調用就是I/O 多路復用函數，該方法能同時監控多個文件描述符（fd）的讀寫情況，當其中的某些fd可讀/寫時，該方法就會返回可讀/寫的fd個數。

Redis使用epoll作為I/O多路復用技術的實現，再加上Redis自身的事件處理模型將epoll的read、write、close等都轉換成事件，不在網絡I/O上浪費過多的時間。實現對多個FD讀寫的監控，提高性能。

舉個形象的例子吧。比如一個tcp服務器處理20個客戶端socket。A方案：順序處理，如果第一個socket因為網卡讀數據處理慢了，一阻塞后面都玩蛋去。B方案：每個socket請求都創建一個分身子進程來處理，不說每個進程消耗大量系統資源，光是進程切換就夠操作系統累的了。C方案**（I/O復用模型，epoll）：將用戶socket對應的fd注冊進epoll（實際上服務器和操作系統之間傳遞的不是socket的fd而是fd_set的數據結構），然后epoll只告訴哪些需要讀/寫的socket，只需要處理那些活躍的、有變化的socket fd的就好了。這樣，整個過程只在調用epoll的時候才會阻塞，收發客戶消息是不會阻塞的。

最后

歡迎大家一起交流，喜歡文章記得點個贊喲，感謝支持！