Redis應用情境

1.  MySql+Memcached架構的問題

　　實際MySQL是適合進行海量資料存放區的，通過Memcached將熱點資料載入到cache，加速訪問，很多公司都曾經使用過這樣的架構，但隨著業務資料量的不斷增加，和訪問量的持續增長，我們遇到了很多問題：

　　1.MySQL需要不斷進行拆庫拆表，Memcached也需不斷跟著擴容，擴容和維護工作佔據大量開發時間。

　　2.Memcached與MySQL資料庫資料一致性問題。

　　3.Memcached資料命中率低或down機，大量訪問直接穿透到DB，MySQL無法支撐。

　　4.跨機房cache同步問題。

　　眾多NoSQL百花齊放，如何選擇

　　最近幾年，業界不斷湧現出很多各種各樣的NoSQL產品，那麼如何才能正確地使用好這些產品，最大化地發揮其長處，是我們需要深入研究和思考的問題，實際歸根結底最重要的是瞭解這些產品的定位，並且瞭解到每款產品的tradeoffs，在實際應用中做到揚長避短，總體上這些NoSQL主要用於解決以下幾種問題

　　1.少量資料存放區，高速讀寫訪問。此類產品通過資料全部in-momery 的方式來保證高速訪問，同時提供資料落地的功能，實際這正是Redis最主要的適用情境。

　　2.海量資料存放區，分布式系統支援，資料一致性保證，方便的叢集節點添加/刪除。

　　3.這方面最具代表性的是dynamo和bigtable 2篇論文所闡述的思路。前者是一個完全無中心的設計，節點之間通過gossip方式傳遞叢集資訊，資料保證最終一致性，後者是一個中心化的方案設計，通過類似一個分布式鎖服務來保證強一致性,資料寫入先寫記憶體和redo log，然後定期compat歸併到磁碟上，將隨機寫最佳化為順序寫，提高寫入效能。

　　4.Schema free，auto-sharding等。比如目前常見的一些文檔資料庫都是支援schema-free的，直接儲存json格式資料，並且支援auto-sharding等功能，比如mongodb。

　　面對這些不同類型的NoSQL產品,我們需要根據我們的業務情境選擇最合適的產品。

Redis最適合所有資料in-momory的情境，雖然Redis也提供持久化功能，但實際更多的是一個disk-backed的功能，跟傳統意義上的持久化有比較大的差別，那麼可能大家就會有疑問，似乎Redis更像一個加強版的Memcached，那麼何時使用Memcached,何時使用Redis呢?

如果簡單地比較Redis與Memcached的區別，大多數都會得到以下觀點：

1 、Redis不僅僅支援簡單的k/v類型的資料，同時還提供list，set，zset，hash等資料結構的儲存。

2 、Redis支援資料的備份，即master-slave模式的資料備份。

3 、Redis支援資料的持久化，可以將記憶體中的資料保持在磁碟中，重啟的時候可以再次載入進行使用。

2.  Redis常用資料類型

Redis最為常用的資料類型主要有以下：

String

Hash

List

Set

Sorted set

pub/sub

Transactions

在具體描述這幾種資料類型之前，我們先通過一張圖瞭解下Redis內部記憶體管理中是如何描述這些不同資料類型的：

首先Redis內部使用一個redisObject對象來表示所有的key和value,redisObject最主要的資訊如所示：

type代表一個value對象具體是何種資料類型，

encoding是不同資料類型在redis內部的儲存方式，

比如：type=string代表value儲存的是一個一般字元串，那麼對應的encoding可以是raw或者是int,如果是int則代表實際redis內部是按數值型類儲存和表示這個字串的，當然前提是這個字串本身可以用數值表示，比如:"123" "456"這樣的字串。

這裡需要特殊說明一下vm欄位，只有開啟了Redis的虛擬記憶體功能，此欄位才會真正的分配記憶體，該功能預設是關閉狀態的，該功能會在後面具體描述。通過我們可以發現Redis使用redisObject來表示所有的key/value資料是比較浪費記憶體的，當然這些記憶體管理成本的付出主要也是為了給Redis不同資料類型提供一個統一的管理介面，實際作者也提供了多種方法協助我們盡量節省記憶體使用量，我們隨後會具體討論。

推薦閱讀：

Ubuntu 12.10下安裝Redis（圖文詳解）+ Jedis串連Redis

Redis系列-安裝部署維護篇

CentOS 6.3安裝Redis

更多詳情見請繼續閱讀下一頁的精彩內容：

1 2 3 下一頁