Redis數(shù)據(jù)庫特性分析

引 言

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

1 Redis簡介

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

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

2 Redis底層數(shù)據(jù)結構中的兩種 ：字符串和字典

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

2.1 字符串

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

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

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

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

(2) 對字符串進行 N次追加，必定需要對字符串進行 N次內(nèi)存重分配。

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

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

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

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

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

2.2 字典

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

(1) 哈希表的大小與節(jié)點數(shù)量，比率在 1 ：1 時，哈希表的性能最好；

(2) 如果節(jié)點數(shù)量比哈希表的大小要大很多的話，那么哈希表就會退化成多個鏈表，哈希表本身的性能優(yōu)勢便不復存在；

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

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

(1) 每次執(zhí)行一次添加、查找、刪除操作，rehash都會被執(zhí)行一次；

(2) 當Redis的服務器常規(guī)任務執(zhí)行時，rehash會被執(zhí)行。在規(guī)定的時間內(nèi)，盡可能地對數(shù)據(jù)庫字典中那些需要rehash 的字典進行 rehash，從而加速數(shù)據(jù)庫字典的rehash 進程。

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

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

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

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

4 Redis事務

4.1 一致性

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

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

4.2 隔離性

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

4.3 原子性

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

4.4 持久性

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

在單純的內(nèi)存模式下，事務肯定是不持久的 ；

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

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

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

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

結 語

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