主要從0到1熟悉redis，之前也簡單的介紹過redis，但是根本不夠深入，這次深入的一起解析下這個redis。

（一）關系型數據庫&nosql

• 區別

nosql：Not Only SQL 的縮寫，是對不同于傳統的關系型數據庫的數據庫管理系統的統稱。
關系型數據：就是咱們可以通過標準的sql，進行查詢的一種數據庫。

復雜的查詢

在傳統的關系型數據庫中查詢一個復雜的業務需要寫很復雜的 sql 語句。很多傳統行業（電信，移動，聯通，電力，銀行）都是通過存儲過程來控制的，一個存儲過程比較大型的都是幾百頁很長。之前接觸過一個比較大的存儲過程有500多行。

伸縮性

在傳統的關系型數據庫業務增大系統需要擴容只能是縱向的形式擴展.操作性能也與遇到瓶頸。mysql為例，其實mysql是沒有集群的，它只是master和salve，只是主從的，并不是傳統意義的集群，只是讀寫分離（服務端，客戶端），寫永遠是master，讀是salve。操作性能也與遇到瓶頸。

遵循規則

• 傳統數據庫遵循 ACID 規則。（ A (Atomicity) 原子性，C (Consistency) 一致性，I (Isolation) 獨立性，D (Durability) 持久性）
• Nosql 一般為分布式而分布式一般遵循 CAP 定理（一致性(Consistency) (所有節點在同一時間具有相同的數據)， 可用性(Availability) (保證每個請求不管成功或者失敗都有響應) ，分隔容忍(Partition tolerance) (系統中任意信息的丟失或失敗不會影響系統的繼續運作)）

（二）NSQL分類

• 鍵值(Key-Value)存儲數據庫:

主要會使用到一個哈希表，這個表中有一個特定的鍵和一個指針指向特定的數據。Key/value模型對于IT系統來說的優勢在于簡單、易部署。但是如果DBA只對部分值進行查詢或更新的時候，Key/value就顯得效率低下了。[3] 舉例如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.

• 列存儲數據庫:
  用來應對分布式存儲的海量數據。鍵仍然存在，但是它們的特點是指向了多個列。這些列是由列家族來安排的。如：Cassandra, HBase, Riak.
• 文檔型數據庫:

來自于Lotus Notes辦公軟件的，而且它同第一種鍵值存儲相類似。該類型的數據模型是版本化的文檔，半結構化的文檔以特定的格式存儲，比如JSON。文檔型數據庫可 以看作是鍵值數據庫的升級版，允許之間嵌套鍵值。而且文檔型數據庫比鍵值數據庫的查詢效率更高。如：CouchDB, MongoDb. 國內也有文檔型數據庫SequoiaDB，已經開源。

• 圖形(Graph)數據庫:

同其他行列以及剛性結構的SQL數據庫不同，它是使用靈活的圖形模型，并且能夠擴展到多個服務器上。NoSQL數據庫沒有標準的查詢語言(SQL)，因此進行數據庫查詢需要制定數據模型。許多NoSQL數據庫都有REST式的數據接口或者查詢API。 如：Neo4J, InfoGrid, Infinite Graph.

• 試用場景
  1.數據模型比較簡單。
  2.需要靈活性更強的IT系統。
  3.對數據庫性能要求較高。
  4.不需要高度的數據一致性。
  5.對于給定key，比較容易映射復雜值的環境。

• NOSQL的集中數據庫

分類Examples舉例典型應用場景數據模型優點缺點

鍵值（key-value）	Key 指向 Value 的鍵值對，通常用hash table來實現
列存儲數據庫	Cassandra, HBase, Riak	分布式的文件系統	以列簇式存儲，將同一列數據存在一起	查找速度快，可擴展性強，更容易進行分布式擴展	功能相對局限
文檔型數據庫	CouchDB, MongoDb	Web應用（與Key-Value類似，Value是結構化的，不同的是數據庫能夠了解Value的內容）	Key-Value對應的鍵值對，Value為結構化數據	數據結構要求不嚴格，表結構可變，不需要像關系型數據庫一樣需要預先定義表結構	查詢性能不高，而且缺乏統一的查詢語法。
圖形(Graph)數據庫	Neo4J, InfoGrid, Infinite Graph	圖結構	利用圖結構相關算法。比如最短路徑尋址，N度關系查找等	利用圖結構相關算法。比如最短路徑尋址，N度關系查找等	很多時候需要對整個圖做計算才能得出需要的信息，而且這種結構不太好做分布式的集群方案。

（三）Redis

• 歷史

2008年，意大利一家創業公司Merzia推出一款基于MySQL的網站實時統計系統LLOOGG，然而產品上線沒多久，該公司的創始人Salvatore Sanfilippo就對MySQL的性能非常不滿意，于是親自操刀開發一款為LLOOGG量身定制的數據庫，也就是Redis的雛形。
LLOOGG.com是一個訪客信息追蹤網站，網站可以通過 JavaScript 腳本，將訪客的 IP 地址，所屬國家，閱覽器信息，被訪問頁面的地址等數據傳送給LLOOGG.com。然后LLOOGG.com會將這些瀏覽數據通過web頁面實時地展示給用戶，并儲存起最新的5至10000條瀏覽記錄以便進行查閱。隨著LLOOGG.com的用戶越來越多，LLOOGG為每個網站維護的瀏覽記錄列表變得越來越多，執行的插入和彈出操作也越來越多，由于當時使用的數據庫是MySQL，過度頻繁的磁盤I/O操作嚴重影響著系統的性能，這使得Salvatore Sanfilippo萌生出開發一款列表結構的內存型數據庫的想法，親自定做一個數據庫，并于2009年開發完成，這個就是Redis。短短幾年，用戶數據量猛增。國內如新浪微博、街旁和知乎等，國外如GitHub、暴雪等，都是Redis的用戶。Redis的代碼托管在GitHub上，開發十分活躍。

• 官網

Redis 是一個開源的使用 ANSI C 語言編寫、遵守 BSD 協議、支持網絡、可基于內存亦可持久化的日志型、Key-Value 數據庫，并提供多種語言的 API。
它通常被稱為數據結構服務器，因為值（value）可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等類型。
Github 源碼：https://github.com/antirez/redis
Redis 官網：https://redis.io/

• 總結

完全開源免費的、高性能的 key-value 數據庫.支持數據持久化、支持多種數據結構存儲。可能老鐵都有感覺，系統比較慢，不是cpu和內存的問題，硬盤是機械的，如果換個固態效果很明顯。為什么mac本那么快，新的mac本都是固態硬盤的。辦公室有個機械硬盤的imac慢的一筆。
redis數據的存儲：內存
mysql數據的村塾：硬盤

• 適用場景

適用場景：存儲緩存、投票、會話 session、排行榜（如果是mysql，要使用order by，group by 才可以查詢的到）、計數器、發布訂閱等。

• Redis 單機版

在一臺機器部署了redis應用。

存在的問題

1.內存容量有限（redis本身是存儲在內存里面，硬件機器本身的內容容量是有限，往redis存儲的量可能很大，就會出現內存容量的問題）
2.處理能力有限（一個人干活跟二個人干活的區別。跟內存的限制相似，類似網絡不好，能力就收到限制）
3.無法高可用（一旦請求量上去，可能存在系統掛掉，掛掉其他的調用系統就無法調用了）

• Redis 多機版

注意：
主從（主庫掛了不能寫了，影響業務）
從庫（從庫掛了寫讀不受到影響，會降低處理能力）

特性

復制（Replication）擴展系統對于讀的能力

哨兵(Sentinel) 為服務器提供高可用特性，減少故障停機出現

集群(Cluster) 擴展內存容量，增加機器，提高性能讀寫能力和存儲以及提供高可用特性。 人多力量大，合理化的分工，分工明確，效率增加。

• 復制

Redis 的復制（replication）功能允許用戶根據一個 Redis 服務器來創建任意多個該服務器的復制品，其中被復制的服務器為主服務器（master），而通過復制創建出來的服務器復制品則為從服務器（slave）。 只要主從服務器之間的網絡連接正常，主從服務器兩者會具有相同的數據，主服務器就會一直將發生在自己身上的數據更新同步 給從服務器，從而一直保證主從服務器的數據相同。

特點

master/slave 角色

master/slave 數據相同

降低 master 讀壓力在轉交從庫

缺點：無法保證高可用，沒有解決 master 寫的壓力

• 哨兵（不是個應用程序，redis的閹割版）

Redis sentinel 是一個分布式系統中監控 redis 主從服務器，并在主服務器下線時自動進行故障轉移。理解成：哨兵理解成太監，master皇帝，slave是妃子。

1.監控（Monitoring ）：

Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。

2.提醒（Notification ）：

當被監控的某個 Redis 服務器出現問題時， Sentinel 可以通過 API向管理員或者其他應用程序發送通知。

3.自動故障遷移（Automatic failover ）：

當一個主服務器不能正常工作時， Sentinel會開始一次自動故障遷移操作。

特點

保證高可用

監控各個節點

自動故障遷移

缺點：主從模式，切換需要時間丟數據沒有解決 master 寫的壓力。

• 集群（proxy ）

之前的情況都是有個proxy層，類型先過個nginx的代碼。通過proxy層進行轉向。負載均衡，分片來使用的。需要指定master。

Twemproxy 是一個 Twitter 開源的一個 redis 和 memcache 快速/輕量級代理服務器。
Twemproxy 是一個快速的單線程代理程序，支持 Memcached ASCII 協議和 redis 協議。

特點

多種 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins。

支持失敗節點自動刪除。

后端 Sharding 分片邏輯對業務透明，業務方的讀寫方式和操作單個 Redis 一致。

缺點

增加了新的 proxy，需要維護其高可用。

failover 邏輯需要自己實現，其本身不能支持故障的自動轉移可擴展性差，進行擴縮容都需要手動干預。

• 集群（直連）

Redis 3.0的最重要特征是對Redis集群的支持，此外，該版本相對于2.8版本在性能、穩定性等方面都有了重大提高。類似zookeeper是通過選舉來的。master自動指定的。

特點

無中心架構（不存在哪個節點影響性能瓶頸），少了 proxy 層。

數據按照 slot 存儲分布在多個節點，節點間數據共享，可動態調整數據分布。

可擴展性，可線性擴展到 1000 個節點，節點可動態添加或刪除。

高可用性，部分節點不可用時，集群仍可用。通過增加 Slave 做備份數據副本

實現故障自動 failover，節點之間通過 gossip 協議交換狀態信息，用投票機制完成 Slave
到 Master 的角色提升。

缺點

資源隔離性較差，容易出現相互影響的情況，通過上邊的圖也是可以看到的，redis之前的關系很復雜。

數據通過異步復制,不保證數據的強一致性。

最低要求三主三從，不適合小公司。

• 自研型

國美：Gcache
京東：JimDB

PS：這次主要說說redis集群的理論，下次一起實踐下。

總結

以上是生活随笔為你收集整理的软件架构-Nosql之redis的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。