Nosql概述

在介紹Redis之前，首先先要介紹Nosql的概念囱修。

互聯(lián)網(wǎng)架構(gòu)發(fā)展

在90年代的時候赎瑰，計算機訪問量一般不大，單個數(shù)據(jù)庫足以應付破镰，網(wǎng)頁更多的是靜態(tài)網(wǎng)頁餐曼，動態(tài)交互性。于是出現(xiàn)了下面的架構(gòu)

上述架構(gòu)在數(shù)據(jù)存儲的瓶頸有以下幾點：

1.數(shù)據(jù)量的總大小 一個機器放不下2.數(shù)據(jù)的索引（B+ Tree）一個機器的內(nèi)存放不下3.訪問量(讀寫混合)一個實例不能承受

后來鲜漩，隨著訪問量的上升源譬，幾乎大部分使用MySQL架構(gòu)的網(wǎng)站在數(shù)據(jù)庫上都開始出現(xiàn)了性能問題，web程序不再僅僅專注在功能上孕似，同時也在追求性能踩娘。程序員們開始大量的使用緩存技術來緩解數(shù)據(jù)庫的壓力，優(yōu)化數(shù)據(jù)庫的結(jié)構(gòu)和索引喉祭。開始比較流行的是通過文件緩存來緩解數(shù)據(jù)庫壓力霸饲，但是當訪問量繼續(xù)增大的時候，多臺web機器通過文件緩存不能共享臂拓，大量的小文件緩存也帶了了比較高的IO壓力厚脉。在這個時候，Memcached就自然的成為一個非常時尚的技術產(chǎn)品胶惰。

Memcached作為一個獨立的分布式的緩存服務器傻工，為多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上孵滞，又發(fā)展了根據(jù)hash算法來進行多臺Memcached緩存服務的擴展中捆，然后又出現(xiàn)了一致性hash來解決增加或減少緩存服務器導致重新hash帶來的大量緩存失效的弊端

由于數(shù)據(jù)庫的寫入壓力增加，Memcached只能緩解數(shù)據(jù)庫的讀取壓力坊饶。讀寫集中在一個數(shù)據(jù)庫上讓數(shù)據(jù)庫不堪重負泄伪，大部分網(wǎng)站開始使用主從復制技術來達到讀寫分離，以提高讀寫性能和讀庫的可擴展性匿级。Mysql的master-slave模式成為這個時候的網(wǎng)站標配了蟋滴。

在Memcached的高速緩存染厅，MySQL的主從復制，讀寫分離的基礎之上津函，這時MySQL主庫的寫壓力開始出現(xiàn)瓶頸肖粮，而數(shù)據(jù)量的持續(xù)猛增，由于MyISAM使用表鎖尔苦，在高并發(fā)下會出現(xiàn)嚴重的鎖問題涩馆，大量的高并發(fā)MySQL應用開始使用InnoDB引擎代替MyISAM。

同時允坚，開始流行使用分表分庫來緩解寫壓力和數(shù)據(jù)增長的擴展問題魂那。這個時候荠诬，分表分庫成了一個熱門技術鲜侥，是面試的熱門問題也是業(yè)界討論的熱門技術問題。也就在這個時候煤率，MySQL推出了還不太穩(wěn)定的表分區(qū)皿渗，這也給技術實力一般的公司帶來了希望斩芭。雖然MySQL推出了MySQL Cluster集群，但性能也不能很好滿足互聯(lián)網(wǎng)的要求乐疆，只是在高可靠性上提供了非常大的保證划乖。

MySQL數(shù)據(jù)庫也經(jīng)常存儲一些大文本字段，導致數(shù)據(jù)庫表非常的大挤土，在做數(shù)據(jù)庫恢復的時候就導致非常的慢琴庵，不容易快速恢復數(shù)據(jù)庫。比如1000萬4KB大小的文本就接近40GB的大小仰美，如果能把這些數(shù)據(jù)從MySQL省去迷殿，MySQL將變得非常的小。關系數(shù)據(jù)庫很強大咖杂，但是它并不能很好的應付所有的應用場景庆寺。MySQL的擴展性差（需要復雜的技術來實現(xiàn)），大數(shù)據(jù)下IO壓力大诉字，表結(jié)構(gòu)更改困難懦尝，正是當前使用MySQL的開發(fā)人員面臨的問題。

今天架構(gòu)是下面這個樣子：

為什么使用NoSQL ?

今天我們可以通過第三方平臺（如：Google,Facebook等）可以很容易的訪問和抓取數(shù)據(jù)壤圃。用戶的個人信息陵霉，社交網(wǎng)絡，地理位置伍绳，用戶生成的數(shù)據(jù)和用戶操作日志已經(jīng)成倍的增加踊挠。我們?nèi)绻獙@些用戶數(shù)據(jù)進行挖掘，那SQL數(shù)據(jù)庫已經(jīng)不適合這些應用了, NoSQL數(shù)據(jù)庫的發(fā)展也卻能很好的處理這些大的數(shù)據(jù)冲杀。

Nosql是什么

NoSQL(NoSQL = Not Only SQL )效床，意即“不僅僅是SQL”睹酌，泛指非關系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起扁凛，傳統(tǒng)的關系數(shù)據(jù)庫在應付web2.0網(wǎng)站忍疾，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心闯传，暴露了很多難以克服的問題谨朝，而非關系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn)甥绿，尤其是大數(shù)據(jù)應用難題字币，包括超大規(guī)模數(shù)據(jù)的存儲。

（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數(shù)據(jù)）共缕。這些類型的數(shù)據(jù)存儲不需要固定的模式洗出，無需多余操作就可以橫向擴展。

Nosql能做什么

1.易擴展：NoSQL數(shù)據(jù)庫種類繁多图谷，但是一個共同的特點都是去掉關系數(shù)據(jù)庫的關系型特性翩活。數(shù)據(jù)之間無關系，這樣就非常容易擴展便贵。也無形之間菠镇，在架構(gòu)的層面上帶來了可擴展的能力。

2.大數(shù)據(jù)量高性能：NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能承璃，尤其在大數(shù)據(jù)量下利耍，同樣表現(xiàn)優(yōu)秀。這得益于它的無關系性盔粹，數(shù)據(jù)庫的結(jié)構(gòu)簡單隘梨。一般MySQL使用Query Cache，每次表的更新Cache就失效舷嗡，是一種大粒度的Cache轴猎，在針對web2.0的交互頻繁的應用，Cache性能不高进萄。而NoSQL的Cache是記錄級的捻脖，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了

3.多樣靈活的數(shù)據(jù)模型：NoSQL無需事先為要存儲的數(shù)據(jù)建立字段垮斯，隨時可以存儲自定義的數(shù)據(jù)格式郎仆。而在關系數(shù)據(jù)庫里，增刪字段是一件非常麻煩的事情兜蠕。如果是非常大數(shù)據(jù)量的表扰肌，增加字段簡直就是一個噩夢

4.傳統(tǒng)RDBMS VS NOSQL：

RDBMS

• 高度組織化結(jié)構(gòu)化數(shù)據(jù)

• 結(jié)構(gòu)化查詢語言（SQL）

• 數(shù)據(jù)和關系都存儲在單獨的表中。

• 數(shù)據(jù)操縱語言熊杨，數(shù)據(jù)定義語言

• 嚴格的一致性

• 基礎事務

NoSQL

• 代表著不僅僅是SQL

• 沒有聲明性查詢語言

• 沒有預定義的模式-鍵 - 值對存儲曙旭，列存儲盗舰，文檔存儲，圖形數(shù)據(jù)庫

• 最終一致性桂躏，而非ACID屬性

• 非結(jié)構(gòu)化和不可預知的數(shù)據(jù)

• CAP定理

• 高性能钻趋，高可用性和可伸縮性

Nosql數(shù)據(jù)模型簡介

KV鍵值

Bson（類似Json）

列族：顧名思義，是按列存儲數(shù)據(jù)的剂习。最大的特點是方便存儲結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)蛮位，方便做數(shù)據(jù)壓縮，對針對某一列或者某幾列的查詢有非常大的IO優(yōu)勢鳞绕。

圖

NoSQL數(shù)據(jù)庫的四大分類

KV鍵值：新浪：BerkeleyDB+redis失仁，美團：redis+tair，阿里们何、百度：memcache+redis

文檔型數(shù)據(jù)庫(bson格式比較多)：CouchDB萄焦，MongoDB。MongoDB 是一個基于分布式文件存儲的數(shù)據(jù)庫冤竹。由 C++ 語言編寫拂封。旨在為 WEB 應用提供可擴展的高性能數(shù)據(jù)存儲解決方案。MongoDB 是一個介于關系數(shù)據(jù)庫和非關系數(shù)據(jù)庫之間的產(chǎn)品鹦蠕，是非關系數(shù)據(jù)庫當中功能最豐富冒签，最像關系數(shù)據(jù)庫的。

列存儲數(shù)據(jù)庫：Cassandra, HBase片部，分布式文件系統(tǒng)

圖關系數(shù)據(jù)庫：社交網(wǎng)絡镣衡，推薦系統(tǒng)等。專注于構(gòu)建關系圖譜档悠，Neo4J, InfoGrid廊鸥。

CAP+Base

關系型數(shù)據(jù)庫遵循ACID規(guī)則

事務在英文中是transaction私沮，和現(xiàn)實世界中的交易很類似，它有如下四個特性：

1和橙、A (Atomicity) 原子性原子性很容易理解仔燕，也就是說事務里的所有操作要么全部做完，要么都不做胃碾，事務成功的條件是事務里的所有操作都成功涨享，只要有一個操作失敗筋搏，整個事務就失敗仆百，需要回滾。比如銀行轉(zhuǎn)賬奔脐，從A賬戶轉(zhuǎn)100元至B賬戶俄周，分為兩個步驟：1）從A賬戶取100元；2）存入100元至B賬戶髓迎。這兩步要么一起完成峦朗，要么一起不完成，如果只完成第一步排龄，第二步失敗波势，錢會莫名其妙少了100元。

2橄维、C (Consistency) 一致性一致性也比較容易理解尺铣，也就是說數(shù)據(jù)庫要一直處于一致的狀態(tài)，事務的運行不會改變數(shù)據(jù)庫原本的一致性約束争舞。

3凛忿、I (Isolation) 獨立性所謂的獨立性是指并發(fā)的事務之間不會互相影響，如果一個事務要訪問的數(shù)據(jù)正在被另外一個事務修改竞川，只要另外一個事務未提交店溢，它所訪問的數(shù)據(jù)就不受未提交事務的影響。比如現(xiàn)有有個交易是從A賬戶轉(zhuǎn)100元至B賬戶委乌，在這個交易還未完成的情況下床牧，如果此時B查詢自己的賬戶，是看不到新增加的100元的

4遭贸、D (Durability) 持久性持久性是指一旦事務提交后戈咳，它所做的修改將會永久的保存在數(shù)據(jù)庫上，即使出現(xiàn)宕機也不會丟失。

CAP的含義

C:Consistency（強一致性）

A:Availability（可用性）

P:Partition tolerance（分區(qū)容錯性）

CAP的的3進2

CAP理論就是說在分布式存儲系統(tǒng)中除秀，最多只能實現(xiàn)上面的兩點糯累。因此，根據(jù) CAP 原理將 NoSQL 數(shù)據(jù)庫分成了滿足 CA 原則册踩、滿足 CP 原則和滿足 AP 原則三 大類泳姐。而由于當前的網(wǎng)絡硬件肯定會出現(xiàn)延遲丟包等問題，所以分區(qū)容忍性是我們必須需要實現(xiàn)的暂吉。所以我們只能在一致性和可用性之間進行權(quán)衡胖秒，沒有NoSQL系統(tǒng)能同時保證這三點。

• CA - 單點集群慕的，滿足一致性阎肝，可用性的系統(tǒng)，通常在可擴展性上不太強大肮街。傳統(tǒng)Oracle數(shù)據(jù)庫

• CP - 滿足一致性风题，分區(qū)容忍必的系統(tǒng)，通常性能不是特別高嫉父。 Redis沛硅、Mongodb

• AP - 滿足可用性，分區(qū)容忍性的系統(tǒng)绕辖，通骋〖。可能對一致性要求低一些。大多數(shù)網(wǎng)站架構(gòu)的選擇

注意：分布式架構(gòu)的時候必須做出取舍仪际。一致性和可用性之間取一個平衡围小。多余大多數(shù)web應用，其實并不需要強一致性树碱。因此犧牲C換取P肯适，這是目前分布式數(shù)據(jù)庫產(chǎn)品的方向

一致性與可用性的決擇

對于web2.0網(wǎng)站來說，關系數(shù)據(jù)庫的很多主要特性卻往往無用武之地

• 數(shù)據(jù)庫事務一致性需求

很多web實時系統(tǒng)并不要求嚴格的數(shù)據(jù)庫事務赴恨，對讀一致性的要求很低疹娶， 有些場合對寫一致性要求并不高。允許實現(xiàn)最終一致性伦连。

• 數(shù)據(jù)庫的寫實時性和讀實時性需求

對關系數(shù)據(jù)庫來說雨饺，插入一條數(shù)據(jù)之后立刻查詢，是肯定可以讀出來這條數(shù)據(jù)的惑淳，但是對于很多web應用來說额港，并不要求這么高的實時性，比方說發(fā)一條消息之 后歧焦，過幾秒乃至十幾秒之后移斩，我的訂閱者才看到這條動態(tài)是完全可以接受的肚医。

• 對復雜的SQL查詢，特別是多表關聯(lián)查詢的需求

任何大數(shù)據(jù)量的web系統(tǒng)向瓷，都非常忌諱多個大表的關聯(lián)查詢肠套，以及復雜的數(shù)據(jù)分析類型的報表查詢，特別是SNS類型的網(wǎng)站猖任，從需求以及產(chǎn)品設計角 度你稚，就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢朱躺，以及單表的簡單條件分頁查詢刁赖，SQL的功能被極大的弱化了。

BASE的含義

BASE就是為了解決關系數(shù)據(jù)庫強一致性引起的問題而引起的可用性降低而提出的解決方案长搀。

BASE其實是下面三個術語的縮寫： 基本可用（Basically Available） 軟狀態(tài)（Soft state） 最終一致（Eventually consistent）

它的思想是通過讓系統(tǒng)放松對某一時刻數(shù)據(jù)一致性的要求來換取系統(tǒng)整體伸縮性和性能上改觀宇弛。為什么這么說呢，緣由就在于大型系統(tǒng)往往由于地域分布和極高性能的要求源请，不可能采用分布式事務來完成這些指標枪芒，要想獲得這些指標，我們必須采用另外一種方式來完成巢钓，這里BASE就是解決這個問題的辦法

分布式系統(tǒng)

分布式系統(tǒng)（distributed system）由多臺計算機和通信的軟件組件通過計算機網(wǎng)絡連接（本地網(wǎng)絡或廣域網(wǎng)）組成病苗。分布式系統(tǒng)是建立在網(wǎng)絡之上的軟件系統(tǒng)。正是因為軟件的特性症汹，所以分布式系統(tǒng)具有高度的內(nèi)聚性和透明性。因此贷腕，網(wǎng)絡和分布式系統(tǒng)之間的區(qū)別更多的在于高層軟件（特別是操作系統(tǒng)）背镇，而不是硬件。分布式系統(tǒng)可以應用在在不同的平臺上如：Pc泽裳、工作站瞒斩、局域網(wǎng)和廣域網(wǎng)上等。

簡單來講：1分布式：不同的多臺服務器上面部署不同的服務模塊（工程）涮总，他們之間通過Rpc/Rmi之間通信和調(diào)用胸囱，對外提供服務和組內(nèi)協(xié)作。

2集群：不同的多臺服務器上面部署相同的服務模塊瀑梗，通過分布式調(diào)度軟件進行統(tǒng)一的調(diào)度烹笔，對外提供服務和訪問。

Redis

是什么——概念

Redis:REmote DIctionary Server(遠程字典服務器)是完全開源免費的抛丽，用C語言編寫的谤职，遵守BSD協(xié)議，是一個高性能的(key/value)分布式內(nèi)存數(shù)據(jù)庫亿鲜，基于內(nèi)存運行并支持持久化的NoSQL數(shù)據(jù)庫允蜈，是當前最熱門的NoSql數(shù)據(jù)庫之一,也被人們稱為數(shù)據(jù)結(jié)構(gòu)服務器

Redis 與其他 key - value 緩存產(chǎn)品有以下三個特點：

• Redis支持數(shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保持在磁盤中，重啟的時候可以再次加載進行使用

• Redis不僅僅支持簡單的key-value類型的數(shù)據(jù)饶套，同時還提供list漩蟆，set，zset妓蛮，hash等數(shù)據(jù)結(jié)構(gòu)的存儲

• Redis支持數(shù)據(jù)的備份爆安，即master-slave模式的數(shù)據(jù)備份

能做啥

• 內(nèi)存存儲和持久化：redis支持異步將內(nèi)存中的數(shù)據(jù)寫到硬盤上，同時不影響繼續(xù)服務

• 取最新N個數(shù)據(jù)的操作仔引，如：可以將最新的10條評論的ID放在Redis的List集合里面

• 模擬類似于HttpSession這種需要設定過期時間的功能

• 發(fā)布扔仓、訂閱消息系統(tǒng)

• 定時器、計數(shù)器

安裝——基于Linux

1. 下載獲得redis-XXX.tar.gz后將它放入我們的Linux目錄/opt

2. /opt目錄下咖耘，解壓命令:tar -zxvf redis-XXX.tar.gz

3. 進入目錄:cd redis-XXX

4. 在redis-XXX目錄下執(zhí)行make命令

5. 如果make完成后繼續(xù)執(zhí)行make install

6. 查看默認安裝目錄：usr/local/bin

7. 修改redis.conf文件將里面的daemonize no 改成 yes翘簇，讓服務在后臺啟動

8. 將默認的redis.conf拷貝到自己定義好的一個路徑下，比如/myconf

9. /usr/local/bin目錄下運行redis-server儿倒，運行拷貝出存放了自定義conf文件目錄下的redis.conf文件

10. 啟動redis客戶端：redis-cli -p 6379

11. 測試連通性：輸入ping 返回 PONG 測試成功

12. 單實例關閉：redis-cli shutdown版保；多實例關閉，指定端口關閉:redis-cli -p 6379 shutdown

雜項知識

• Redis 是單進程

• 默認16個數(shù)據(jù)庫夫否，初始默認使用零號庫（Redis索引都是從零開始）彻犁，統(tǒng)一密碼管理，16個庫都是同樣密碼凰慈，要么都OK要么一個也連接不上

• select命令切換數(shù)據(jù)庫 select 2切換到標號為2的庫

• dbsize查看當前數(shù)據(jù)庫的key的數(shù)量

• flushdb：清空當前庫

• Flushall：清空全部庫

Redis數(shù)據(jù)類型

Redis支持5大數(shù)據(jù)類型：

• string（字符串）

  string 是Redis的基本類型汞幢，一個key對應一個Value，String是二進制安全的微谓，及時說Redis的String可以包含任何數(shù)據(jù)森篷，比如jpg圖片或者序列化的對象，一個Redis中字符串value最多是512M

• hash（哈希豺型，類似java里的Map）

  Redis hash是一個鍵值對集合仲智，是一個string類型的field和value的映射表，特別適合用于存儲對象姻氨，類似于Java里面的Map<String,Object>

• list（列表）

  Redis List 是簡單的字符串列表钓辆，按照插入的順序排序，可以添加一個元素到列表的頭部或者尾部肴焊，底層其實是一個鏈表

• set（集合）

  是String類型的無序集合前联，通過HashTable實現(xiàn)

• zset(sorted set：有序集合)

  和set一樣也是String類型元素的集合，且不允許重復的成員抖韩。不同的是每個元素都會關聯(lián)一個double類型的分數(shù)蛀恩。redis正是通過分數(shù)來為集合中的成員進行從小到大的排序。zset的成員是唯一的茂浮，但分數(shù)score卻可以重復双谆。

每種數(shù)據(jù)類型相關命令請參考http://redisdoc.com/本文不再贅述

Redis配置文件

配置文件放在解壓目錄中redis.conf

• 開頭：配置文件開頭定義了一些基本度量單位壳咕，只支持bytes不支持bit，對大小寫不敏感

• INCLUDE：Redis可以作為總閘顽馋，包含一些其他的配置文件

• NETWORK：配置一些網(wǎng)絡參數(shù)谓厘，如設置有效監(jiān)聽的客戶端連接地址，監(jiān)聽端口等

  • tcp-backlog：backlog其實是一個鏈接隊列寸谜，backlog隊列總和=未完成三次握手隊列+已完成三次握手隊列

    在高并發(fā)的環(huán)境下你需要一個高backlog值來避免慢客戶端鏈接問題竟稳。Linux內(nèi)核會將這個值減小到/proc/sys/net/core/somaxconn的值，所以需要確保提高somaxconn和tcp_max_syn_backlog兩個值來達到目標效果

  • tcp-keepalive：間隔多長時間進行keepalive檢測熊痴，從Redis3.2.1之后默認值為300此前為60

  (不同版本Redis配置文件結(jié)構(gòu)不一樣他爸，老版本沒有此分類，原來放在GENERAL里面)

• GENERAL：

  • daemonize 后臺啟動

  • loglevel 設置日志級別果善，級別越高日志越多越詳細

  • logfile 日志文件

  • databases 默認Redis數(shù)據(jù)庫數(shù)量——16個

• SNAPSHOTTING：RDB的持久化配置將Redis數(shù)據(jù)庫保存在磁盤上诊笤，詳見本文持久化部分

• REPLICATION：設置主從復制

• SECURITY：訪問密碼的查看、設置和取消巾陕。默認Redis是沒有密碼的讨跟，因為它相信安裝環(huán)境Linux是安全的

• LIMITS：對Redis進行一些限制，如最大連接客戶端數(shù)量鄙煤，使用內(nèi)存等

• APPEND ONLY MODE：Redis AOF持久化的一些配置晾匠，詳見本文持久化部分

Redis持久化

Redis 有兩種持久化技術RDB和AOF

http://redisdoc.com/topic/persistence.html 推薦參考官方文檔

RDB(Redis DataBase)

在指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤，也就是Snapshot梯刚，它恢復時是將快照文件直接讀到內(nèi)存里凉馆。

Redis會單獨創(chuàng)建（fork）一個子進程來進行持久化，會先將數(shù)據(jù)寫入到一個臨時文件中乾巧，待持久化過程都結(jié)束了句喜，再用這個臨時文件替換上次持久化好的文件。整個過程中沟于，主進程是不進行任何IO操作的，這就確保了極高的性能如果需要進行大規(guī)模數(shù)據(jù)的恢復植康，且對于數(shù)據(jù)恢復的完整性不是非常敏感旷太，那RDB方式要比AOF方式更加的高效。RDB的缺點是最后一次持久化后的數(shù)據(jù)可能丟失销睁。

Fork：fork的作用是復制一個與當前進程一樣的進程供璧。新進程的所有數(shù)據(jù)（變量、環(huán)境變量冻记、程序計數(shù)器等）數(shù)值都和原進程一致睡毒，但是是一個全新的進程，并作為原進程的子進程冗栗。

RDB 保存的是dump.rdb文件

如何觸發(fā)RDB快照

• Save命令：save時只管保存演顾，其它不管供搀，全部阻塞

• bgsave命令：Redis會在后臺異步進行快照操作，快照同時還可以響應客戶端請求钠至「鹋埃可以通過lastsave命令獲取最后一次成功執(zhí)行快照的時間

• flushall命令：也會產(chǎn)生dump.rdb文件，但里面是空的棉钧，無意義

RDB默認配置觸發(fā)是：

• 1分鐘改了1萬次

• 5分鐘改了10次

• 15分鐘改了1次

如何恢復

將備份文件 (dump.rdb) 移動到 redis 安裝目錄并啟動服務即可

如何停止

停止RDB保存規(guī)則的方法：redis-cli config set save ""

AOF(Append Only File)

以日志的形式來記錄每個寫操作屿脐，將Redis執(zhí)行過的所有寫指令記錄下來(讀操作不記錄)，只許追加文件但不可以改寫文件宪卿，redis啟動之初會讀取該文件重新構(gòu)建數(shù)據(jù)的诵，換言之，redis重啟的話就根據(jù)日志文件的內(nèi)容將寫指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復工作佑钾。

Aof保存的是appendonly.aof文件

如何啟動AOF

修改默認的appendonly no西疤，改為yes

AOF損壞修復

redis-check-aof --fix進行修復

rewrite

AOF采用文件追加方式，文件會越來越大為避免出現(xiàn)此種情況次绘，新增了重寫機制,當AOF文件的大小超過所設定的閾值時瘪阁，Redis就會啟動AOF文件的內(nèi)容壓縮，只保留可以恢復數(shù)據(jù)的最小指令集.可以使用命令bgrewriteaof

• 重寫原理

  AOF文件持續(xù)增長而過大時邮偎，會fork出一條新進程來將文件重寫(也是先寫臨時文件最后再rename)管跺，遍歷新進程的內(nèi)存中數(shù)據(jù)，每條記錄有一條的Set語句禾进。重寫aof文件的操作豁跑，并沒有讀取舊的aof文件，而是將整個內(nèi)存中的數(shù)據(jù)庫內(nèi)容用命令的方式重寫了一個新的aof文件泻云，這點和快照有點類似

• 觸發(fā)機制

  Redis會記錄上次重寫時的AOF大小艇拍，默認配置是當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發(fā)

總結(jié)

RDB持久化方式能夠在指定的時間間隔能對你的數(shù)據(jù)進行快照存儲

AOF持久化方式記錄每次對服務器寫的操作,當服務器重啟的時候會重新執(zhí)行這些命令來恢復原始的數(shù)據(jù),AOF命令以redis協(xié)議追加保存每次寫的操作到文件末尾.Redis還能對AOF文件進行后臺重寫,使得AOF文件的體積不至于過大

只做緩存：如果你只希望你的數(shù)據(jù)在服務器運行的時候存在,你也可以不使用任何持久化方式.

同時開啟兩種持久化方式：

• 在這種情況下,當redis重啟的時候會優(yōu)先載入AOF文件來恢復原始的數(shù)據(jù),因為在通常情況下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整.

• RDB的數(shù)據(jù)不實時，同時使用兩者時服務器重啟也只會找AOF文件宠纯。那要不要只使用AOF呢卸夕？作者建議不要，因為RDB更適合用于備份數(shù)據(jù)庫(AOF在不斷變化不好備份)婆瓜，快速重啟快集，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段廉白。

性能建議：

因為RDB文件只用做后備用途个初，建議只在Slave上持久化RDB文件，

如果使用AOF猴蹂，好處是最惡劣的情況下只會丟失不超過2秒的數(shù)據(jù)院溺，代價是持續(xù)的IO，AOF 的Rewrite過程中產(chǎn)生的新數(shù)據(jù)寫到新文件造成的阻塞幾乎是不可避免的磅轻，應盡量減少rewrite的頻率珍逸，默認重寫基礎大小是64M太小逐虚，可以根據(jù)需求設置GB級別的寫入大小。

如果不使用AOF弄息，僅適用Master-Slave Replication實現(xiàn)高可用也可以痊班，能省掉一大筆的IO，代價是如果M和S同時掛掉摹量，會丟失十幾分鐘的數(shù)據(jù)涤伐，啟動腳本只要比較兩個RDB的文件載入較新的。新浪微博選用這種架構(gòu)

Redis的事務

事務流程

• 開啟：以MULTI開始一個事務

• 入隊：將多個命令入隊到事務中缨称，接到這些命令并不會立即執(zhí)行凝果，而是放到等待執(zhí)行的事務隊列里面

• 執(zhí)行：由EXEC命令觸發(fā)事務

事務執(zhí)行分類

• 正常執(zhí)行

• 放棄事務：DISCARD放棄事務執(zhí)行

• 全體連坐：有一個錯誤全部失敗

• 冤頭債主：誰有錯誰不執(zhí)行，不影響其他的語句

• watch監(jiān)控

watch監(jiān)控

• 樂觀鎖：

  樂觀鎖(Optimistic Lock), 顧名思義睦尽，就是很樂觀器净，每次去拿數(shù)據(jù)的時候都認為別人不會修改，所以不會上鎖当凡，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數(shù)據(jù)山害，可以使用版本號等機制判斷是否修改。樂觀鎖適用于多讀的應用類型沿量，這樣可以提高吞吐量浪慌，樂觀鎖策略:提交版本必須大于記錄當前版本才能執(zhí)行更新

• 悲觀鎖：

  悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀朴则，每次去拿數(shù)據(jù)的時候都認為別人會修改权纤，所以每次在拿數(shù)據(jù)的時候都會上鎖，這樣別人想拿這個數(shù)據(jù)就會block直到它拿到鎖乌妒。傳統(tǒng)的關系型數(shù)據(jù)庫里邊就用到了很多這種鎖機制汹想，比如行鎖，表鎖等撤蚊，讀鎖古掏，寫鎖等，都是在做操作之前先上鎖

Watch指令侦啸，類似樂觀鎖冗茸，事務提交時，如果Key的值已被別的客戶端改變匹中，比如某個list已被別的客戶端push/pop過了，整個事務隊列都不會被執(zhí)行

通過WATCH命令在事務執(zhí)行之前監(jiān)控了多個Keys豪诲，倘若在WATCH之后有任何Key的值發(fā)生了變化顶捷，EXEC命令執(zhí)行的事務都將被放棄，同時返回Nullmulti-bulk應答以通知調(diào)用者事務執(zhí)行失敗

Redis事務特性

• 單獨的隔離操作：事務中的所有命令都會序列化屎篱、按順序地執(zhí)行服赎。事務在執(zhí)行的過程中葵蒂，不會被其他客戶端發(fā)送來的命令請求所打斷。

• 沒有隔離級別的概念：隊列中的命令沒有提交之前都不會實際的被執(zhí)行重虑，因為事務提交前任何指令都不會被實際執(zhí)行践付，也就不存在”事務內(nèi)的查詢要看到事務里的更新，在事務外查詢不能看到”這個讓人萬分頭痛的問題

• 不保證原子性：redis同一個事務中如果有一條命令執(zhí)行失敗缺厉，其后的命令仍然會被執(zhí)行永高，沒有回滾

Redis的發(fā)布和訂閱

進程間的一種消息通信模式：發(fā)送者(pub)發(fā)送消息，訂閱者(sub)接收消息提针。

一次訂閱多個：SUBSCRIBE c1 c2 c3（可以使用通配符命爬，例如SUBSCRIBE news*）

消息發(fā)布 ：PUBLISH c2 helloworld

一般企業(yè)中發(fā)布消息中間件不會使用Redis去做，了解即可

Redis的復制

也就是我們所說的主從復制辐脖，主機數(shù)據(jù)更新后根據(jù)配置和策略饲宛，自動同步到備機的master/slaver機制，Master以寫為主嗜价，Slave以讀為主

可以做什么：讀寫分離艇抠，容災備份

使用

遵循配從(庫)不配主(庫)的原則

• 從庫配置：slaveof 主庫IP 主庫端口

  每次與master斷開之后，都需要重新連接久锥，除非你配置進redis.conf文件(使用info replication 可以查看當先信息)

  需要修改的配置：

  拷貝多個redis.conf文件開啟daemonize yespid文件名字指定端口log文件名字dump.rdb名字

• 常用配置結(jié)構(gòu)

  • 一主二仆：一個Master兩個Slave家淤，主機掛掉之后，剩下的機器還是slave狀態(tài)奴拦，主機復活之后維持原來的主機地位媒鼓，從機掛掉，除非是寫過配置文件错妖，否則不會恢復從機的身份绿鸣。

  • 薪火相傳：上一個Slave可以是下一個slave的Master，Slave同樣可以接收其他slaves的連接和同步請求暂氯，那么該slave作為了鏈條中下一個的master,可以有效減輕master的寫壓力

  • 反客為主：SLAVEOF no one潮模，使當前數(shù)據(jù)庫停止與其他數(shù)據(jù)庫的同步，轉(zhuǎn)成主數(shù)據(jù)庫

Redis復制原理

slave啟動成功連接到master后會發(fā)送一個sync命令痴施。Master接到命令啟動后臺的存盤進程擎厢，同時收集所有接收到的用于修改數(shù)據(jù)集命令，在后臺進程執(zhí)行完畢之后辣吃，master將傳送整個數(shù)據(jù)文件到slave,以完成一次完全同步

全量復制：而slave服務在接收到數(shù)據(jù)庫文件數(shù)據(jù)后动遭，將其存盤并加載到內(nèi)存中。增量復制：Master繼續(xù)將新的所有收集到的修改命令依次傳給slave,完成同步但是只要是重新連接master,一次完全同步（全量復制)將被自動執(zhí)行

哨兵模式

反客為主的自動版神得，能夠后臺監(jiān)控主機是否故障厘惦，如果故障了根據(jù)投票數(shù)自動將從庫轉(zhuǎn)換為主庫

使用

• 新建sentinel.conf文件

• 填寫內(nèi)容： sentinel monitor 被監(jiān)控數(shù)據(jù)庫名字(自己起名字) 127.0.0.1 6379 1（1表示主機掛掉后salve投票看讓誰接替成為主機，得票數(shù)多少后成為主機）

• 啟動 redis-sentinel sentinel.conf 哨兵開始監(jiān)控主機哩簿，主機掛掉選取主機宵蕉，原主機重新啟動之后將會變成Slave

一組sentinel能同時監(jiān)控多個Master

復制的缺點

由于所有的寫操作都是先在Master上操作酝静，然后同步更新到Slave上，所以從Master同步到Slave機器有一定的延遲羡玛，當系統(tǒng)很繁忙的時候别智，延遲問題會更加嚴重，Slave機器數(shù)量的增加也會使這個問題更加嚴重稼稿。

問題

• Redis和Memcache區(qū)別對比薄榛？如何選擇這兩個技術？

  區(qū)別：

  1） Redis和Memcache都是將數(shù)據(jù)存放在內(nèi)存中渺杉，都是內(nèi)存數(shù)據(jù)庫蛇数。不過memcache還可用于緩存其他東西，例如圖片是越、視頻等等耳舅。

  2）Redis不僅僅支持簡單的k/v類型的數(shù)據(jù)，同時還提供list倚评，set浦徊，hash等數(shù)據(jù)結(jié)構(gòu)的存儲。

  3）虛擬內(nèi)存--Redis當物理內(nèi)存用完時天梧，可以將一些很久沒用到的value 交換到磁盤

  4）過期策略--memcache在set時就指定盔性，例如set key1 0 0 8,即永不過期。Redis可以通過例如expire 設定呢岗，例如expire name 10

  5）分布式--設定memcache集群冕香，利用magent做一主多從;redis可以做一主多從。都可以一主一從

  6）存儲數(shù)據(jù)安全--memcache掛掉后后豫，數(shù)據(jù)沒了悉尾；redis可以定期保存到磁盤（持久化）

  7）災難恢復--memcache掛掉后纵散，數(shù)據(jù)不可恢復; redis數(shù)據(jù)丟失后可以通過aof恢復

  8）Redis支持數(shù)據(jù)的備份逗威，即master-slave模式的數(shù)據(jù)備份。

  選型：

  若是簡單的存取key-value這樣的數(shù)據(jù)用memcache好一些

  若是要支持數(shù)據(jù)持久化哈垢，多數(shù)據(jù)類型(如集合早龟、散列之類的)惫霸，用列表類型做隊列之類的高級應用，就用redis

• Redis的持久化機制是什么葱弟？各自的優(yōu)缺點壹店？

  redis提供兩種持久化機制RDB和AOF機制。

  1）RDB持久化方式：

  是指用數(shù)據(jù)集快照的方式記錄redis數(shù)據(jù)庫的所有鍵值對芝加。

  優(yōu)點：

  1.只有一個文件dump.rdb茫打，方便持久化。

  2.容災性好，一個文件可以保存到安全的磁盤老赤。

  3.性能最大化，fork子進程來完成寫操作制市，讓主進程繼續(xù)處理命令抬旺，所以是IO最大化。

  4.相對于數(shù)據(jù)集大時祥楣，比AOF的啟動效率更高开财。

  缺點：

  1.數(shù)據(jù)安全性低。

  2）AOF持久化方式：

  是指所有的命令行記錄以redis命令請求協(xié)議的格式保存為aof文件误褪。

  優(yōu)點：

  1.數(shù)據(jù)安全责鳍，aof持久化可以配置appendfsync屬性，有always兽间，每進行一次命令操作就記錄到aof文件中一次历葛。

  2.通過append模式寫文件，即使中途服務器宕機嘀略，可以通過redis-check-aof工具解決數(shù)據(jù)一致性問題恤溶。

  3.AOF機制的rewrite模式。

  缺點：

  1.文件會比RDB形式的文件大帜羊。

  2.數(shù)據(jù)集大的時候咒程，比rdb啟動效率低。