c語言執行redis,c語言執行順序

本文目錄一覽：

• 1、4、Redis高性能的根本原理
• 2、redis是使用c語言開發的么
• 3、四個大點，搞懂 Redis 到底快在哪裡？

4、Redis高性能的根本原理

內存的讀寫速度很快

Epoll 模型

常用的五大Redis的數據結構，及他們各自的底層實現結構

string hash list set sortset(zset)

string 的底層實現是 簡單動態字元串（SDS -simple dynamic string）

hash 的底層實現是 hash表 或則 壓縮列表（ziplist）

list 的底層實現是 雙向列表（quicklist） 或者 壓縮列表

set 的底層實現是 hash表（hashtable） 或者 整數數組

sortset(zset) 的底層實現是 壓縮列表 或者 跳錶

各個數據結構的底層實現概覽

value是 string 類型的時候分為三種情況

（1）、當設置的值是整數類型的時候，redis底層會將 string 類型轉化為 int 來存儲

（2）、設置的值小於等於44個位元組的時候，使用的編碼是 embstr

（3）、設置的值大於44個位元組的時候，使用的編碼是 raw

redis是用C語言編寫的，在C語言中 string 類型是用字元數組 char[] 來實現的。redis實現字元串的底層並沒有直接使用C語言中的字元數組的形式，而是進行了改造，構造出了一種SDS的數據結構

list的底層使用 快速雙向鏈表quicklist 或者 壓縮鏈表ziplist 來實現的。

list的底層並沒有使用傳統的雙向鏈表的結構是因為

（1）、雙向鏈表需要有一個 前指針 和 後指針 ，每個指針佔用的空間分別都是8byte， 佔用內存 比較多

（2）、雙向鏈表所通用的一個問題是會形成很多的 內存碎片

壓縮鏈表 ziplist 結構是

快速雙向鏈表 quicklist 結構

hash的底層實現為 hashtable 或者 ziplist 。

hashtable的底層實現

當數據量比較小或者單個元素的時候，底層使用的是ziplist存儲，具體可以通過配置來制定

1、 hashtable 是無序的 ziplist 是有序的

2、在能使用 hash 的情況下優先使用 hash ，不要使用 String ，因為使用太多的 String ，則會創建出過多的 key ,當 key 大量的時候，就會容易發生 hash碰撞 ，所以就需要頻繁的 rehash ，每次 rehash 就會創建2倍的內存，造成內存浪費

hash的底層實現為 整數數組intset 或者 hashtable 。

當set都為整數的時候，set的底層實現都是使用 intset 結構實現

如果set中存在字元串的值，則使用 hashtable 來實現

intset 是有序的， hashtable 是無序的

sortset 底層使用 壓縮列表ziplist 或 跳錶skiplist 的結構實現

當數據量小的情況下，使用 ziplist 實現，當數據量大的情況下使用 ziplist 實現，具體可以通過配置設置

默認設置下的底層結構

skiplist 的底層實現

查找對應元素的時候，先從最高的索引層找，例如找c 150，則先從L1找，L1的指針指向b，查看b120小於150，則繼續往後找，b的指針指向null，則向下一層找，向下一層b的指針指向c，查看c的score為150，所以找到對應的元素c

1、

redis是使用c語言開發的么

Redis（Remote Dictionary Server )，即遠程字典服務，是一個開源的使用ANSI C語言編寫、支持網路、可基於內存亦可持久化的日誌型、Key-Value資料庫。

四個大點，搞懂 Redis 到底快在哪裡？

現在我們都用高級語言來編程，比如Java、python等。也許你會覺得C語言很古老，但是它真的很有用，畢竟unix系統就是用C實現的，所以C語言是非常貼近操作系統的語言。Redis就是用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是如何工作的：當使用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的時候才會阻塞，收發客戶消息是不會阻塞的。

:-D 搜索微信號（ID： 芋道源碼 ），可以獲得各種 Java 源碼解析、原理講解、面試題、學習指南。

:-D 並且，回復【 書籍 】後，可以領取筆者推薦的各種 Java 從入門到架構的 100 本書籍。

:-D 並且，回復【 技術群 】後，可以加入專門討論 Java、後端、架構的技術群。