Redis數據庫特性分析

馬豫星

摘 要：Redis是一款開源的、網絡化的、基于內存的、可進行數據持久化的Key-Value存儲系統。詳細介紹了redis數據庫底層數據結構、數據庫的持久化方式、數據庫事務特性以及隱藏在設計之中的一些考量。闡明了Redis高效性的原因在于其精簡高效的底層數據結構設計以及對具有高消耗的功能進行分散處理。

關鍵詞：數據庫；Redis；NoSQL；分散處理

中圖分類號：TP316 文獻標識碼：A 文章編號：2095-1302（2015）03-00-02

0 引 言

隨著互聯網的發展以及Web 2.0的興起，超大規模以及高并發的純動態型網站日漸成為主流，由于SNS類網站在數據存取過程中有著實時性等剛性需求的原因，致使關系型數據庫越來越不足以勝任，這使得目前NoSQL數據庫慢慢成了人們所關注的焦點，并大有成為取代關系型數據庫而成為未來主流數據存儲模式的趨勢。當前NoSQL數據庫很多，大部分都是開源的，其中比較知名的有：MemcacheDB、Redis、Tokyo Cabinet、Flare、MongoDB、CouchDB、Cassandra、Voldemort等。本文主要介紹Redis，這是一款足以滿足海量讀寫需求基于Key-Value數據存儲方式的高性能NoSQL數據庫。

1 Redis簡介

Redis是一款開源的、網絡化的、基于內存的、可進行數據持久化的Key-Value存儲系統。它的數據模型建立在外層，類似于其它結構化存儲系統，是通過Key映射Value的方式來建立字典以保存數據，有別于其它結構化存儲系統的是，它支持多類型存儲，包括String、List、Set、Sort set和Hash等，你可以在這些數據類型上做很多原子性操作。

在操作方面，Redis基于TCP協議的特性使得它可以通過管道的方式進行數據操作，Redis本身提供了一個可連接Server的客戶端，通過客戶端，可方便地進行數據存取操作。

2 Redis底層數據結構中的兩種：字符串和字典

在Redis的內部， 數據結構類型值由高效的數據結構和算法進行支持， 并且在Redis 自身的構建當中，也大量用到了這些數據結構。

2.1 字符串

SDS（Simple Dynamic String，簡單動態字符串）是Redis底層所使用的字符串表示，幾乎所有的Redis模塊中都用了SDS。用SDS取代C默認的char*類型。

因為char*類型的功能單一，抽象層次低，并且不能高效地支持一些Redis常用的操作，所以在Redis程序內部，絕大部分情況下都會使用SDS而不是char*來表示字符串。

在C語言中，字符串可以用一個＼0結尾的char數組來表示。但是，它并不能高效地支持長度計算和追加這兩種操作：

（1）計算字符串長度的復雜度為θ（N）。

（2）對字符串進行N次追加，必定需要對字符串進行N次內存重分配。

在Redis內部，字符串的追加和長度計算很常見，這兩個簡單的操作不應該成為性能的瓶頸。

另外，Redis除了處理C字符串之外，還需要處理單純的字節數組，以及服務器協議等內容，所以為了方便起見，Redis的字符串表示還應該是二進制安全的：程序不應對字符串里面保存的數據做任何假設，數據可以是以＼0結尾的C字符串，也可以是單純的字節數組，或者其他格式的數據。

考慮到這兩個原因，Redis使用SDS類型替換了C語言的默認字符串表示：SDS既可高效地實現追加和長度計算，同時是二進制安全的。

值得一提的是，在Redis最初的設計中就加入了統計信息：

在設計SDS的時候，在內部使用了zmalloc與zfree來動態使用內存，并記錄占有內存大小，方便計算Redis的性能。

2.2 字典

實現字典的方法有很多種：為了兼顧高效和簡單性，Redis使用了哈希表。在實現哈希表時，有一個問題就是采用何種策略來解決碰撞問題。對于使用鏈地址法來解決碰撞問題的哈希表來說，哈希表的性能取決于哈希表大小與保存節點數量之間的比率：

（1）哈希表的大小與節點數量，比率在1：1時，哈希表的性能最好；

（2）如果節點數量比哈希表的大小要大很多的話，那么哈希表就會退化成多個鏈表，哈希表本身的性能優勢便不復存在；

Redis保證當上述比率達到一定值時，會執行rehash操作，即對哈希表進行擴容或縮減。當擴容時，是以空間換取時間，當縮減時是以時間換空間。由此可以看出Redis對時間和空間的高效利用率。當然，rehash操作一般是漸進方式執行的。因為其中涉及到對整個哈希表的遷移，如果數據量很大，那么勢必會影響系統的性能。

Redis使用了兩種漸進式的rehash方式：

（1）每次執行一次添加、查找、刪除操作，rehash都會被執行一次；

（2）當Redis的服務器常規任務執行時，rehash會被執行。在規定的時間內，盡可能地對數據庫字典中那些需要rehash的字典進行rehash，從而加速數據庫字典的rehash進程。

3 Redis的持久化方式：RDB與AOF

在運行情況下，Redis以數據結構的形式將數據維持在內存中，為了讓這些數據在Redis重啟之后仍然可用，Redis分別提供了RDB和AOF兩種持久化模式。

RDB將數據庫的快照以二進制的方式保存到磁盤中。在Redis運行時，RDB程序將當前內存中的數據庫快照保存到磁盤文件中，在Redis重啟動時，RDB程序可以通過載入RDB文件來還原數據庫的狀態。

AOF則以協議文本的方式，將所有對數據庫進行過寫入的命令（及其參數）記錄到AOF文件，以此達到記錄數據庫狀態的目的。AOF更像是歷史記錄，記錄所有運行過的命令。但是AOF文件就會隨著時間持續增長，進而占據整個磁盤。為此，Redis設計了AOF重寫機制，通過開啟新線程，掃描數據庫數據，將其轉化為Redis命令，存入臨時的AOF文件。當掃描完后，用臨時文件代替AOF文件。這樣一來，AOF文件中記錄的命令就是最簡潔的，因而不會占據很多空間。

4 Redis事務

4.1 一致性

Redis的一致性問題可以分為兩部分來討論：入隊錯誤、執行錯誤。

在命令入隊的過程中，如果客戶端向服務器發送了錯誤的命令，Redis會拒絕執行事務，并返回失敗信息。如果命令在事務執行的過程中發生錯誤，那么Redis只會將錯誤包含在事務的結果中，這不會引起事務中斷或整個失敗，不會影響已執行事務命令的結果，也不會影響后面要執行的事務命令，所以它對事務的一致性也沒有影響。

4.2 隔離性

Redis是單進程程序，并且它保證在執行事務時，不會對事務進行中斷，事務可以運行直到執行完所有事務隊列中的命令為止。因此，Redis的事務是總是帶有隔離性的。

4.3 原子性

在上述一致性的介紹中，可以看出在事務隊列中，即使有命令執行錯誤，該事務也會執行完，符合原子性的要求。

4.4 持久性

因為事務不過是用隊列包裹起了一組Redis命令，并沒有提供任何額外的持久性功能，所以事務的持久性由Redis所使用的持久化模式決定：

在單純的內存模式下，事務肯定是不持久的；

在RDB模式下，服務器可能在事務執行之后、RDB文件更新之前的這段時間失敗，所以RDB模式下的Redis事務也是不持久的；

在AOF的“總是SYNC”模式下，事務的每條命令在執行成功之后，都會立即調用 fsync 或 fdatasync 將事務數據寫入到AOF文件。但是，這種保存是由后臺線程進行的，主線程不會阻塞直到保存成功，所以從命令執行成功到數據保存到硬盤之間，還是有一段非常小的間隔，所以這種模式下的事務也是不持久的；

其他AOF模式也和“總是 SYNC”模式類似，所以它們都是不持久的；

綜上所述，Redis事務滿足原子性、一致性、隔離性，不滿足持久性。

5 結 語

本文詳細介紹了Redis數據庫數據結構、事務、持久化等特性，為讀者深入理解Redis提供了幫助。

參考文獻

[1] 李子驊.Redis入門指南[M].北京：人民郵電出版社，2013.

[2] 黃健宏.Redis設計與實現[M].北京：機械工業出版社，2014.

[3] 皮雄軍.NoSQL數據庫技術實戰[M].北京：清華大學出版社，2015.

[4] Shashank Tiwari.深入NoSQL[M].北京：人民郵電出版社， 2012.

[5] 徐小威.非關系型數據庫數據恢復技術研究[D].杭州，杭州電子科技大學，2014.