Redis學習筆記

NoSql入門和概述

入門概述 

1 互聯網時代背景下 大機遇,爲何用nosql

 1單機MySQL的美好年代

在90年代,一個網站的訪問量通常都不大,用單個數據庫徹底能夠輕鬆應付。
在那個時候,更多的都是靜態網頁,動態交互類型的網站很少。html

 

上述架構下,咱們來看看數據存儲的瓶頸是什麼?
1.數據量的總大小 一個機器放不下時
2.數據的索引(B+ Tree)一個機器的內存放不下時
3.訪問量(讀寫混合)一個實例不能承受
 若是知足了上述1 or 3個,進化......java

2 Memcached(緩存)+MySQL+垂直拆分

後來,隨着訪問量的上升,幾乎大部分使用MySQL架構的網站在數據庫上都開始出現了性能問題,web程序再也不僅僅專一在功能上,同時也在追求性能。程序員們開始大量的使用緩存技術來緩解數據庫的壓力,優化數據庫的結構和索引。開始比較流行的是經過文件緩存來緩解數據庫壓力,可是當訪問量繼續增大的時候,多臺web機器經過文件緩存不能共享,大量的小文件緩存也帶了了比較高的IO壓力。在這個時候,Memcached就天然的成爲一個很是時尚的技術產品。node

 Memcached做爲一個獨立的分佈式的緩存服務器,爲多個web服務器提供了一個共享的高性能緩存服務,在Memcached服務器上,又發展了根據hash算法來進行多臺Memcached緩存服務的擴展,而後又出現了一致性hash來解決增長或減小緩存服務器致使從新hash帶來的大量緩存失效的弊端mysql

3 Mysql主從讀寫分離 

因爲數據庫的寫入壓力增長,Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負,大部分網站開始使用主從複製技術來達到讀寫分離,以提升讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成爲這個時候的網站標配了。linux

 4 分表分庫+水平拆分+mysql集羣 

 在Memcached的高速緩存,MySQL的主從複製,讀寫分離的基礎之上,這時MySQL主庫的寫壓力開始出現瓶頸,而數據量的持續猛增,因爲MyISAM使用表鎖,在高併發下會出現嚴重的鎖問題,大量的高併發MySQL應用開始使用InnoDB引擎代替MyISAM。c++


 同時,開始流行使用分表分庫來緩解寫壓力和數據增加的擴展問題。這個時候,分表分庫成了一個熱門技術,是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候,MySQL推出了還不太穩定的表分區,這也給技術實力通常的公司帶來了但願。雖然MySQL推出了MySQL Cluster集羣,但性能也不能很好知足互聯網的要求,只是在高可靠性上提供了很是大的保證。git

5 MySQL的擴展性瓶頸

MySQL數據庫也常常存儲一些大文本字段,致使數據庫表很是的大,在作數據庫恢復的時候就致使很是的慢,不容易快速恢復數據庫。好比1000萬4KB大小的文本就接近40GB的大小,若是能把這些數據從MySQL省去,MySQL將變得很是的小。關係數據庫很強大,可是它並不能很好的應付全部的應用場景。MySQL的擴展性差(須要複雜的技術來實現),大數據下IO壓力大,表結構更改困難,正是當前使用MySQL的開發人員面臨的問題。程序員

6 今天是什麼樣子??

7 爲何用NoSQL

 

爲何使用NoSQL ?github


今天咱們能夠經過第三方平臺(如:Google,Facebook等)能夠很容易的訪問和抓取數據。用戶的我的信息,社交網絡,地理位置,用戶生成的數據和用戶操做日誌已經成倍的增長。咱們若是要對這些用戶數據進行挖掘,那SQL數據庫已經不適合這些應用了, NoSQL數據庫的發展也卻能很好的處理這些大的數據。web

2 是什麼

NoSQL(NoSQL = Not Only SQL ),意即「不只僅是SQL」,
泛指非關係型的數據庫。隨着互聯網web2.0網站的興起,傳統的關係數據庫在應付web2.0網站,特別是超大規模和高併發的SNS類型的web2.0純動態網站已經顯得力不從心,暴露了不少難以克服的問題,而非關係型的數據庫則因爲其自己的特色獲得了很是迅速的發展。NoSQL數據庫的產生就是爲了解決大規模數據集合多重數據種類帶來的挑戰,尤爲是大數據應用難題,包括超大規模數據的存儲。


(例如谷歌或Facebook天天爲他們的用戶收集萬億比特的數據)。這些類型的數據存儲不須要固定的模式,無需多餘操做就能夠橫向擴展。

3 能幹嗎

易擴展

NoSQL數據庫種類繁多,可是一個共同的特色都是去掉關係數據庫的關係型特性。
數據之間無關係,這樣就很是容易擴展。也無形之間,在架構的層面上帶來了可擴展的能力。

大數據量高性能

NoSQL數據庫都具備很是高的讀寫性能,尤爲在大數據量下,一樣表現優秀。
這得益於它的無關係性,數據庫的結構簡單。
通常MySQL使用Query Cache,每次表的更新Cache就失效,是一種大粒度的Cache,
在針對web2.0的交互頻繁的應用,Cache性能不高。而NoSQL的Cache是記錄級的,
是一種細粒度的Cache,因此NoSQL在這個層面上來講就要性能高不少了

多樣靈活的數據模型

NoSQL無需事先爲要存儲的數據創建字段,隨時能夠存儲自定義的數據格式。而在關係數據庫裏,
增刪字段是一件很是麻煩的事情。若是是很是大數據量的表,增長字段簡直就是一個噩夢

傳統RDBMS VS NOSQL

 

RDBMS vs NoSQL


RDBMS
- 高度組織化結構化數據
- 結構化查詢語言(SQL)
- 數據和關係都存儲在單獨的表中。
- 數據操縱語言,數據定義語言
- 嚴格的一致性
- 基礎事務


NoSQL
- 表明着不只僅是SQL
- 沒有聲明性查詢語言
- 沒有預約義的模式
-鍵 - 值對存儲,列存儲,文檔存儲,圖形數據庫
- 最終一致性,而非ACID屬性
- 非結構化和不可預知的數據
- CAP定理
- 高性能,高可用性和可伸縮性

 

 

4 去哪下

Redis

memcache

Mongdb

5 怎麼玩

KV

Persistence

......

3V+3高 

大數據時代的3V 

海量Volume
多樣Variety
實時Velocity

 

互聯網需求的3高

高併發
高可擴
高性能

 

當下的NoSQL經典應用 

 當下的應用是sql和nosql一塊兒使用

阿里巴巴中文站商品信息如何存放

看看阿里巴巴中文網站首頁
以女裝/女包包爲例

架構發展歷程
演變過程
第5代
第5代架構使命
......
和咱們相關的,多數據源多數據類型的存儲問題

1 商品基本信息 

名稱、價格,出廠日期,生產廠商等

關係型數據庫:mysql/oracle目前淘寶在去O化(也即拿掉Oracle),
注意,淘寶內部用的Mysql是裏面的大牛本身改造過的

 

爲何去IOE

 2008年,王堅加盟阿里巴巴成爲集團首席架構師,即如今的首席技術官。這位前微軟亞洲研究院常務副院長被馬雲定位爲:將幫助阿里巴巴集團創建世界級的技術團隊,並負責集團技術架構以及基礎技術平臺搭建。
在加入阿里後,帶着技術基因和學者風範的王堅就在阿里巴巴集團提出了被稱爲「去IOE」(在IT建設過程當中,去除IBM小型機、Oracle數據庫及EMC存儲設備)的想法,並開始把雲計算的本質,植入阿里IT基因。
王堅這樣歸納「去IOE」運動和阿里雲之間的關係:「去IOE」完全改變了阿里集團IT架構的基礎,是阿里擁抱雲計算,產出計算服務的基礎。「去IOE」的本質是分佈化,讓隨處能夠買到的Commodity PC架構成爲可能,使雲計算可以落地的首要條件。
 

2 商品描述、詳情、評價信息(多文字類)

多文字信息描述類,IO讀寫性能變差

文檔數據庫MongDB中

 

3 商品的圖片

商品圖片展示類
分佈式的文件系統中

淘寶本身的TFS

Google的GFS

Hadoop的HDFS

 

4 商品的關鍵字

搜索引擎,淘寶內用

ISearch

 

5 商品的波段性的熱點高頻信息

內存數據庫

tair、Redis、Memcache

6 商品的交易、價格計算、積分累計

外部系統,外部第3方支付接口

支付寶

總結大型互聯網應用(大數據、高併發、
多樣數據類型)的難點和解決方案

難點

數據類型多樣性

數據源多樣性和變化重構

數據源改造而數據服務平臺不須要大面積重構

自由主題

給學生畫圖介紹EAI和統一數據平臺服務層

解決辦法
阿里、淘寶幹了什麼?UDSL

是什麼

 

什麼樣

映射

API

熱點緩存

......

 

 NoSQL數據模型簡介

以一個電商客戶、訂單、訂購
、地址模型來對比下關係型
數據庫和非關係型數據庫

傳統的關係型數據庫你如何設計?

ER圖(1:1/1:N/N:N,主外鍵等常見)

nosql你如何設計

什麼是BSON

BSON()是一種類json的一種二進制形式的存儲格式,簡稱Binary JSON,
它和JSON同樣,支持內嵌的文檔對象和數組對象

 

給學生用BSon畫出構建的數據模型

{
 "customer":{
   "id":1136,
   "name":"Z3",
   "billingAddress":[{"city":"beijing"}],
   "orders":[
    {
      "id":17,
      "customerId":1136,
      "orderItems":[{"productId":27,"price":77.5,"productName":"thinking in java"}],
      "shippingAddress":[{"city":"beijing"}]
      "orderPayment":[{"ccinfo":"111-222-333","txnid":"asdfadcd334","billingAddress":{"city":"beijing"}}],
      }
    ]
  }
}
View Code

二者對比,問題和難點

爲何上述的狀況能夠用聚合模型來處理
高併發的操做是不太建議有關聯查詢的,
互聯網公司用冗餘數據來避免關聯查詢
分佈式事務是支持不了太多的併發的

 

 

聚合模型

KV鍵值

bson

列族

顧名思義,是按列存儲數據的。最大的特色是方便存儲結構化和半結構化數據,方便作數據壓縮,
對針對某一列或者某幾列的查詢有很是大的IO優點。

 

圖形

 

 NoSQL數據庫的四大分類

KV鍵值:典型介紹

新浪:BerkeleyDB+redis

美團:redis+tair

阿里、百度:memcache+redis

 

文檔型數據庫(bson格式比較多):典型介紹

CouchDB

MongoDB

MongoDB 是一個基於分佈式文件存儲的數據庫。由 C++ 語言編寫。旨在爲 WEB 應用提供可擴展的高性能數據存儲解決方案。


MongoDB 是一個介於關係數據庫和非關係數據庫之間的產品,是非關係數據庫當中功能最豐富,最像關係數據庫的。

 

列存儲數據庫

Cassandra, HBase

分佈式文件系統

圖關係數據庫

社交網絡,推薦系統等。專一於構建關係圖譜

Neo4J, InfoGrid

四者對比 

 

在分佈式數據庫中CAP原理CAP+BASE 

 傳統的ACID分別是什麼

A (Atomicity) 原子性
C (Consistency) 一致性
I (Isolation) 獨立性
D (Durability) 持久性

 

 CAP 

C:Consistency(強一致性)
A:Availability(可用性)
P:Partition tolerance(分區容錯性)

 

 CAP的3進2

CAP理論就是說在分佈式存儲系統中,最多隻能實現上面的兩點。
而因爲當前的網絡硬件確定會出現延遲丟包等問題,因此


分區容忍性是咱們必須須要實現的。


因此咱們只能在一致性和可用性之間進行權衡,沒有NoSQL系統能同時保證這三點。
=======================================================================================================================
C:強一致性 A:高可用性 P:分佈式容忍性
 CA 傳統Oracle數據庫


 AP 大多數網站架構的選擇


 CP Redis、Mongodb


 注意:分佈式架構的時候必須作出取捨。
一致性和可用性之間取一個平衡。多餘大多數web應用,其實並不須要強一致性。
所以犧牲C換取P,這是目前分佈式數據庫產品的方向
=======================================================================================================================
一致性與可用性的決擇


對於web2.0網站來講,關係數據庫的不少主要特性卻每每無用武之地


數據庫事務一致性需求 
  不少web實時系統並不要求嚴格的數據庫事務,對讀一致性的要求很低, 有些場合對寫一致性要求並不高。容許實現最終一致性。


數據庫的寫實時性和讀實時性需求
  對關係數據庫來講,插入一條數據以後馬上查詢,是確定能夠讀出來這條數據的,可是對於不少web應用來講,並不要求這麼高的實時性,比方說發一條消息之 後,過幾秒乃至十幾秒以後,個人訂閱者纔看到這條動態是徹底能夠接受的。


對複雜的SQL查詢,特別是多表關聯查詢的需求 
  任何大數據量的web系統,都很是忌諱多個大表的關聯查詢,以及複雜的數據分析類型的報表查詢,特別是SNS類型的網站,從需求以及產品設計角 度,就避免了這種狀況的產生。每每更多的只是單表的主鍵查詢,以及單表的簡單條件分頁查詢,SQL的功能被極大的弱化了。
View Code

 經典CAP圖 

 CAP理論的核心是:一個分佈式系統不可能同時很好的知足一致性,可用性和分區容錯性這三個需求,
最多隻能同時較好的知足兩個。
所以,根據 CAP 原理將 NoSQL 數據庫分紅了知足 CA 原則、知足 CP 原則和知足 AP 原則三 大類:
CA - 單點集羣,知足一致性,可用性的系統,一般在可擴展性上不太強大。
CP - 知足一致性,分區容忍必的系統,一般性能不是特別高。
AP - 知足可用性,分區容忍性的系統,一般可能對一致性要求低一些。
View Code

 

 BASE

BASE就是爲了解決關係數據庫強一致性引發的問題而引發的可用性下降而提出的解決方案。


BASE實際上是下面三個術語的縮寫:
    基本可用(Basically Available)
    軟狀態(Soft state)
    最終一致(Eventually consistent)


它的思想是經過讓系統放鬆對某一時刻數據一致性的要求來換取系統總體伸縮性和性能上改觀。爲何這麼說呢,原因就在於大型系統每每因爲地域分佈和極高性能的要求,不可能採用分佈式事務來完成這些指標,要想得到這些指標,咱們必須採用另一種方式來完成,這裏BASE就是解決這個問題的辦法
View Code

 

 分佈式+集羣簡介

分佈式系統


分佈式系統(distributed system)
 由多臺計算機和通訊的軟件組件經過計算機網絡鏈接(本地網絡或廣域網)組成。分佈式系統是創建在網絡之上的軟件系統。正是由於軟件的特性,因此分佈式系統具備高度的內聚性和透明性。所以,網絡和分佈式系統之間的區別更多的在於高層軟件(特別是操做系統),而不是硬件。分佈式系統能夠應用在在不一樣的平臺上如:Pc、工做站、局域網和廣域網上等。














簡單來說:
1分佈式:不一樣的多臺服務器上面部署不一樣的服務模塊(工程),他們之間經過Rpc/Rmi之間通訊和調用,對外提供服務和組內協做。


2集羣:不一樣的多臺服務器上面部署相同的服務模塊,經過分佈式調度軟件進行統一的調度,對外提供服務和訪問。
 
View Code

Redis入門介紹

入門概述 

1是什麼

Redis:REmote DIctionary Server(遠程字典服務器)

 

是徹底開源免費的,用C語言編寫的,遵照BSD協議,
是一個高性能的(key/value)分佈式內存數據庫,基於內存運行
並支持持久化的NoSQL數據庫,是當前最熱門的NoSql數據庫之一,
也被人們稱爲數據結構服務器

 

Redis 與其餘 key - value 緩存產品有如下三個特色

Redis支持數據的持久化,能夠將內存中的數據保持在磁盤中,重啓的時候能夠再次加載進行使用
Redis不只僅支持簡單的key-value類型的數據,同時還提供list,set,zset,hash等數據結構的存儲
Redis支持數據的備份,即master-slave模式的數據備份

 

2 能幹嗎

內存存儲和持久化:redis支持異步將內存中的數據寫到硬盤上,同時不影響繼續服務

 

取最新N個數據的操做,如:能夠將最新的10條評論的ID放在Redis的List集合裏面

 

模擬相似於HttpSession這種須要設定過時時間的功能

 

發佈、訂閱消息系統

 

定時器、計數器

 

3 去哪下

http://redis.io/

http://www.redis.cn/

4 怎麼玩

數據類型、基本操做和配置

持久化和複製,RDB/AOF

事務的控制

複製

......

VMWare+VMTools千里之行始於足下

VMWare虛擬機的安裝

CentOS或者RedHad5的安裝

如何查看本身的linux是32位仍是64位

getconf LONG_BIT
返回是多少就是幾位

 

1、啓動 redis 服務

[root@MyLinux bin]# ./redis-server redis.conf
2、使用客戶端鏈接服務

[root@MyLinux bin]# ./redis-cli -h 192.168.25.128 -p 6379
3、如何關閉服務端

[root@MyLinux bin]# ./redis-cli shutdown
4、如何退出客戶端的鏈接

192.168.25.128:6379> exit
5、helloworld

192.168.25.128:6379> set str helloworld
 6、取值

192.168.25.128:6379> get str
7、返回值

"helloworld"
View Code

 

 

假如出現了不支持虛擬化的問題

 

個人筆記本cpu是64位的,操做系統也是64位的,問題應該如虛擬機右下角提示所說,

是「宿主機BIOS設置中的硬件虛擬化被禁用了。」
須要打開筆記本BIOS中的IVT對虛擬化的支持。
找到菜單「Security」–「System Security」,
將Virtualization Technology(VTx)和Virtualization Technology DirectedI/O(VTd)設置爲 Enabled。
保存並退出BIOS設置,重啓電腦,

 

 VMTools的安裝

 設置共享目錄

上述環境都OK後開始進行Redis的服務器安裝配置

 

 

Redis的安裝

 Windows版安裝

Window 下安裝
下載地址:https://github.com/dmajkic/redis/downloads
下載到的Redis支持32bit和64bit。根據本身實際狀況選擇,將64bit的內容cp到自定義盤符安裝目錄取名redis。 如 C:\reids
打開一個cmd窗口 使用cd命令切換目錄到 C:\redis 運行 redis-server.exe redis.conf 。
若是想方便的話,能夠把redis的路徑加到系統的環境變量裏,這樣就免得再輸路徑了,後面的那個redis.conf能夠省略,
若是省略,會啓用默認的。輸入以後,會顯示以下界面:

這時候另啓一個cmd窗口,原來的不要關閉,否則就沒法訪問服務端了。
切換到redis目錄下運行 redis-cli.exe -h 127.0.0.1 -p 6379 。
設置鍵值對 set myKey abc
取出鍵值對 get myKey
View Code  

重要提示:  

因爲企業裏面作Redis開發,99%都是Linux版的運用和安裝,
幾乎不會涉及到Windows版,上一步的講解只是爲了知識的完整性,
Windows版不做爲重點,同窗能夠下去本身玩,企業實戰就認一個版:Linux

Linux版安裝

1.下載得到redis-3.0.4.tar.gz後將它放入咱們的Linux目錄/opt

2./opt目錄下,解壓命令:tar -zxvf redis-3.0.4.tar.gz

3.解壓完成後出現文件夾:redis-3.0.4

4.進入目錄:cd redis-3.0.4

5.在redis-3.0.4目錄下執行make命令

運行make命令時故
意出現的錯誤解析:

安裝gcc:

能上網:yum install gcc-c++

不上網:

 

二次make

jemalloc/jemalloc.h:沒有那個文件或目錄

Redis Test(能夠不用執行)

下載TCL的網址:
http://www.linuxfromscratch.org/blfs/view/cvs/general/tcl.html
安裝TCL

 

 

6.若是make完成後繼續執行make install

 

7.查看默認安裝目錄:usr/local/bin

redis-benchmark:性能測試工具,能夠在本身本子運行,看看本身本子性能如何,服務啓動起來後執行

8.redis-check-aof:修復有問題的AOF文件,rdb和aof後面講

9.redis-check-dump:修復有問題的dump.rdb文件

redis-cli:客戶端,操做入口

redis-sentinel:redis集羣使用

redis-server:Redis服務器啓動命令

 

10.啓動

修改redis.conf文件將裏面的daemonize no 改爲 yes,讓服務在後臺啓動

將默認的redis.conf拷貝到本身定義好的一個路徑下,好比/myconf

啓動

連通測試

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

 

 

11.永遠的helloworld

 

12.關閉

單實例關閉:redis-cli shutdown

多實例關閉,指定端口關閉:redis-cli -p 6379 shutdown

Redis啓動後雜項基礎知識講解

 

單進程 

 select命令切換數據庫

默認16個數據庫,相似數組下表從零開始,初始默認使用零號庫

設置數據庫的數量,默認數據庫爲0,能夠使用SELECT <dbid>命令在鏈接上指定數據庫id
  databases 16

 

 dbsize查看當前數據庫的key的數量

 flushdb:清空當前庫

Flushall;通殺所有庫 

 統一密碼管理,16個庫都是一樣密碼,要麼都OK要麼一個也鏈接不上

 Redis索引都是從零開始

 爲何默認端口是6379

 

Redis數據類型

 Redis的五大數據類型

string(字符串)

String(字符串)


string是redis最基本的類型,你能夠理解成與Memcached如出一轍的類型,一個key對應一個value。


string類型是二進制安全的。意思是redis的string能夠包含任何數據。好比jpg圖片或者序列化的對象 。


string類型是Redis最基本的數據類型,一個redis中字符串value最多能夠是512M

 

hash(哈希,相似java裏的Map)

Hash(哈希)
Redis hash 是一個鍵值對集合。
Redis hash是一個string類型的field和value的映射表,hash特別適合用於存儲對象。


相似Java裏面的Map<String,Object>

 

list(列表)

List(列表)
Redis 列表是簡單的字符串列表,按照插入順序排序。你能夠添加一個元素導列表的頭部(左邊)或者尾部(右邊)。
它的底層實際是個鏈表

set(集合)

Set(集合)
Redis的Set是string類型的無序集合。它是經過HashTable實現實現的,

 

zset(sorted set:有序集合)

zset(sorted set:有序集合)
Redis zset 和 set 同樣也是string類型元素的集合,且不容許重複的成員。
不一樣的是每一個元素都會關聯一個double類型的分數。
redis正是經過分數來爲集合中的成員進行從小到大的排序。zset的成員是惟一的,但分數(score)卻能夠重複。

 

 

哪裏去得到redis常見數據類型操做命令

http://redisdoc.com/

 

Redis 鍵(key)

經常使用

案例

 keys *

 exists key的名字,判斷某個key是否存在

 move key db   --->當前庫就沒有了,被移除了

 expire key 秒鐘:爲給定的key設置過時時間

 ttl key 查看還有多少秒過時,-1表示永不過時,-2表示已過時

 type key 查看你的key是什麼類型

 

 

 

Redis字符串(String)

經常使用

單值單value

 

案例

 getrange/setrange

getrange:獲取指定區間範圍內的值,相似between......and的關係
從零到負一表示所有

setrange設置指定區間範圍內的值,格式是setrange key值 具體值

 

 setex(set with expire)鍵秒值/setnx(set if not exist)

setex:設置帶過時時間的key,動態設置。
setex 鍵 秒值 真實值

setnx:只有在 key 不存在時設置 key 的值。

 

 mset/mget/msetnx

mset:同時設置一個或多個 key-value 對。


mget:獲取全部(一個或多個)給定 key 的值。


msetnx:同時設置一個或多個 key-value 對,當且僅當全部給定 key 都不存在。
 

 

 getset(先get再set)

getset:將給定 key 的值設爲 value ,並返回 key 的舊值(old value)。
簡單一句話,先get而後當即set

 

 

Redis列表(List)

經常使用

單值多value

案例

 lpush/rpush/lrange

 lpop/rpop

 lindex,按照索引下標得到元素(從上到下)

經過索引獲取列表中的元素 lindex key index

 

 llen

 lrem key 刪N個value

 * 從left往right刪除2個值等於v1的元素,返回的值爲實際刪除的數量
 *  LREM list3 0 值,表示刪除所有給定的值。零個就是所有值

 

 ltrim key 開始index 結束index,截取指定範圍的值後再賦值給key

ltrim:截取指定索引區間的元素,格式是ltrim list的key 起始索引 結束索引

 rpoplpush 源列表 目的列表

移除列表的最後一個元素,並將該元素添加到另外一個列表並返回

 

 lset key index value

 linsert key  before/after 值1 值2

在list某個已有值的先後再添加具體值

性能總結

它是一個字符串鏈表,left、right均可以插入添加;
若是鍵不存在,建立新的鏈表;
若是鍵已存在,新增內容;
若是值全移除,對應的鍵也就消失了。
鏈表的操做不管是頭和尾效率都極高,但假如是對中間元素進行操做,效率就很慘淡了。

 

 

 

Redis集合(Set)

經常使用

單值多value

案例

 sadd/smembers/sismember

 

 scard,獲取集合裏面的元素個數

獲取集合裏面的元素個數

 

 srem key value 刪除集合中元素

 srandmember key 某個整數(隨機出幾個數)

 *   從set集合裏面隨機取出2個
 *   若是超過最大數量就所有取出,
 *   若是寫的值是負數,好比-3 ,表示須要取出3個,可是可能會有重複值。

 

 spop key 隨機出棧

 smove key1 key2 在key1裏某個值      做用是將key1裏的某個值賦給key2

 

 數學集合類

差集:sdiff

在第一個set裏面而不在後面任何一個set裏面的項

 

交集:sinter

並集:sunion

Redis哈希(Hash)

 經常使用

KV模式不變,但V是一個鍵值對 

案例

  hset/hget/hmset/hmget/hgetall/hdel

 hlen

 hexists key 在key裏面的某個值的key

 hkeys/hvals

 hincrby/hincrbyfloat

 hsetnx

不存在賦值,存在了無效。

Redis有序集合Zset(sorted set)

多說一句 

在set基礎上,加一個score值。
以前set是k1 v1 v2 v3,
如今zset是k1 score1 v1 score2 v2

 

經常使用

 

案例

 zadd/zrange   withscores

 zrem key 某score下對應的value值,做用是刪除元素

刪除元素,格式是zrem zset的key 項的值,項的值能夠是多個

zrem key score某個對應值,能夠是多個值

 

 zcard/zcount key score區間/zrank key values值,做用是得到下標值/zscore key 對應值,得到分數

zcard :獲取集合中元素個數

zcount :獲取分數區間內元素個數,zcount key 開始分數區間 結束分數區間

zrank: 獲取value在zset中的下標位置

zscore:按照值得到對應的分數

 

 zrevrank key values值,做用是逆序得到下標值

正序、逆序得到下標索引值

 zrevrange

 zrevrangebyscore  key 結束score 開始score

zrevrangebyscore zset1 90 60 withscores    分數是反着來的

解析配置文件 redis.conf

它在哪

地址

 

爲何我將它拷貝出來單獨執行?

 

units單位

 

INCLUDES包含

 

GENERAL通用

daemonize

pidfile

port

tcp-backlog

tcp-backlog
設置tcp的backlog,backlog實際上是一個鏈接隊列,backlog隊列總和=未完成三次握手隊列 + 已經完成三次握手隊列。
在高併發環境下你須要一個高backlog值來避免慢客戶端鏈接問題。注意Linux內核會將這個值減少到/proc/sys/net/core/somaxconn的值,因此須要確認增大somaxconn和tcp_max_syn_backlog兩個值
來達到想要的效果

timeout

bind 

tcp-keepalive

單位爲秒,若是設置爲0,則不會進行Keepalive檢測,建議設置成60 

loglevel

logfile

syslog-enabled

是否把日誌輸出到syslog中

syslog-ident

指定syslog裏的日誌標誌

syslog-facility

指定syslog設備,值能夠是USER或LOCAL0-LOCAL7

databases

 

SNAPSHOTTING快照

Save

stop-writes-on-bgsave-error

若是配置成no,表示你不在意數據不一致或者有其餘的手段發現和控制

 

 rdbcompression

rdbcompression:對於存儲到磁盤中的快照,能夠設置是否進行壓縮存儲。若是是的話,redis會採用
LZF算法進行壓縮。若是你不想消耗CPU來進行壓縮的話,能夠設置爲關閉此功能

 

 rdbchecksum

rdbchecksum:在存儲快照後,還可讓redis使用CRC64算法來進行數據校驗,可是這樣作會增長大約
10%的性能消耗,若是但願獲取到最大的性能提高,能夠關閉此功能

 

 dbfilename

 dir

REPLICATION複製

 

SECURITY安全

訪問密碼的查看、設置和取消

 

查看:

config get requirepass

 

修改:

config set  requirepass 「123456

 

登入:

auth 123456

 

 

LIMITS限制

maxclients

設置redis同時能夠與多少個客戶端進行鏈接。默認狀況下爲10000個客戶端。當你
沒法設置進程文件句柄限制時,redis會設置爲當前的文件句柄限制值減去32,由於redis會爲自
身內部處理邏輯留一些句柄出來。若是達到了此限制,redis則會拒絕新的鏈接請求,而且向這
些鏈接請求方發出「max number of clients reached」以做迴應。

maxmemory

設置redis能夠使用的內存量。一旦到達內存使用上限,redis將會試圖移除內部數據,移除規則能夠經過maxmemory-policy來指定。若是redis沒法根據移除規則來移除內存中的數據,或者設置了「不容許移除」,
那麼redis則會針對那些須要申請內存的指令返回錯誤信息,好比SET、LPUSH等。


可是對於無內存申請的指令,仍然會正常響應,好比GET等。若是你的redis是主redis(說明你的redis有從redis),那麼在設置內存使用上限時,須要在系統中留出一些內存空間給同步隊列緩存,只有在你設置的是「不移除」的狀況下,纔不用考慮這個因素

 

maxmemory-policy

 (1volatile-lru:使用LRU算法移除key,只對設置了過時時間的鍵
(2)allkeys-lru:使用LRU算法移除key
(3volatile-random:在過時集合中移除隨機的key,只對設置了過時時間的鍵
(4)allkeys-random:移除隨機的key
(5volatile-ttl:移除那些TTL值最小的key,即那些最近要過時的key
(6)noeviction:不進行移除。針對寫操做,只是返回錯誤信息

 

maxmemory-samples

設置樣本數量,LRU算法和最小TTL算法都並不是是精確的算法,而是估算值,因此你能夠設置樣本的大小,
redis默認會檢查這麼多個key並選擇其中LRU的那個

 

APPEND ONLY MODE追加

 appendonly

 appendfilename

appendfsync

always:同步持久化 每次發生數據變動會被當即記錄到磁盤  性能較差但數據完整性比較好

everysec:出廠默認推薦,異步操做,每秒記錄   若是一秒內宕機,有數據丟失

no

 

 

no-appendfsync-on-rewrite:重寫時是否能夠運用Appendfsync,用默認no便可,保證數據安全性。

 

auto-aof-rewrite-min-size:設置重寫的基準值

 

auto-aof-rewrite-percentage:設置重寫的基準值

 

 常見配置redis.conf介紹

參數說明
redis.conf 配置項說明以下:
1. Redis默認不是以守護進程的方式運行,能夠經過該配置項修改,使用yes啓用守護進程
  daemonize no
2. 當Redis以守護進程方式運行時,Redis默認會把pid寫入/var/run/redis.pid文件,能夠經過pidfile指定
  pidfile /var/run/redis.pid
3. 指定Redis監聽端口,默認端口爲6379,做者在本身的一篇博文中解釋了爲何選用6379做爲默認端口,由於6379在手機按鍵上MERZ對應的號碼,而MERZ取自意大利歌女Alessia Merz的名字
  port 6379
4. 綁定的主機地址
  bind 127.0.0.1
5.當 客戶端閒置多長時間後關閉鏈接,若是指定爲0,表示關閉該功能
  timeout 300
6. 指定日誌記錄級別,Redis總共支持四個級別:debug、verbose、notice、warning,默認爲verbose
  loglevel verbose
7. 日誌記錄方式,默認爲標準輸出,若是配置Redis爲守護進程方式運行,而這裏又配置爲日誌記錄方式爲標準輸出,則日誌將會發送給/dev/null
  logfile stdout
8. 設置數據庫的數量,默認數據庫爲0,能夠使用SELECT <dbid>命令在鏈接上指定數據庫id
  databases 16
9. 指定在多長時間內,有多少次更新操做,就將數據同步到數據文件,能夠多個條件配合
  save <seconds> <changes>
  Redis默認配置文件中提供了三個條件:
  save 900 1
  save 300 10
  save 60 10000
  分別表示900秒(15分鐘)內有1個更改,300秒(5分鐘)內有10個更改以及60秒內有10000個更改。
 
10. 指定存儲至本地數據庫時是否壓縮數據,默認爲yes,Redis採用LZF壓縮,若是爲了節省CPU時間,能夠關閉該選項,但會致使數據庫文件變的巨大
  rdbcompression yes
11. 指定本地數據庫文件名,默認值爲dump.rdb
  dbfilename dump.rdb
12. 指定本地數據庫存放目錄
  dir ./
13. 設置當本機爲slav服務時,設置master服務的IP地址及端口,在Redis啓動時,它會自動從master進行數據同步
  slaveof <masterip> <masterport>
14. 當master服務設置了密碼保護時,slav服務鏈接master的密碼
  masterauth <master-password>
15. 設置Redis鏈接密碼,若是配置了鏈接密碼,客戶端在鏈接Redis時須要經過AUTH <password>命令提供密碼,默認關閉
  requirepass foobared
16. 設置同一時間最大客戶端鏈接數,默認無限制,Redis能夠同時打開的客戶端鏈接數爲Redis進程能夠打開的最大文件描述符數,若是設置 maxclients 0,表示不做限制。當客戶端鏈接數到達限制時,Redis會關閉新的鏈接並向客戶端返回max number of clients reached錯誤信息
  maxclients 128
17. 指定Redis最大內存限制,Redis在啓動時會把數據加載到內存中,達到最大內存後,Redis會先嚐試清除已到期或即將到期的Key,當此方法處理 後,仍然到達最大內存設置,將沒法再進行寫入操做,但仍然能夠進行讀取操做。Redis新的vm機制,會把Key存放內存,Value會存放在swap區
  maxmemory <bytes>
18. 指定是否在每次更新操做後進行日誌記錄,Redis在默認狀況下是異步的把數據寫入磁盤,若是不開啓,可能會在斷電時致使一段時間內的數據丟失。由於 redis自己同步數據文件是按上面save條件來同步的,因此有的數據會在一段時間內只存在於內存中。默認爲no
  appendonly no
19. 指定更新日誌文件名,默認爲appendonly.aof
   appendfilename appendonly.aof
20. 指定更新日誌條件,共有3個可選值: 
  no:表示等操做系統進行數據緩存同步到磁盤(快) 
  always:表示每次更新操做後手動調用fsync()將數據寫到磁盤(慢,安全) 
  everysec:表示每秒同步一次(折衷,默認值)
  appendfsync everysec
 
21. 指定是否啓用虛擬內存機制,默認值爲no,簡單的介紹一下,VM機制將數據分頁存放,由Redis將訪問量較少的頁即冷數據swap到磁盤上,訪問多的頁面由磁盤自動換出到內存中(在後面的文章我會仔細分析Redis的VM機制)
   vm-enabled no
22. 虛擬內存文件路徑,默認值爲/tmp/redis.swap,不可多個Redis實例共享
   vm-swap-file /tmp/redis.swap
23. 將全部大於vm-max-memory的數據存入虛擬內存,不管vm-max-memory設置多小,全部索引數據都是內存存儲的(Redis的索引數據 就是keys),也就是說,當vm-max-memory設置爲0的時候,實際上是全部value都存在於磁盤。默認值爲0
   vm-max-memory 0
24. Redis swap文件分紅了不少的page,一個對象能夠保存在多個page上面,但一個page上不能被多個對象共享,vm-page-size是要根據存儲的 數據大小來設定的,做者建議若是存儲不少小對象,page大小最好設置爲32或者64bytes;若是存儲很大大對象,則能夠使用更大的page,若是不 肯定,就使用默認值
   vm-page-size 32
25. 設置swap文件中的page數量,因爲頁表(一種表示頁面空閒或使用的bitmap)是在放在內存中的,,在磁盤上每8個pages將消耗1byte的內存。
   vm-pages 134217728
26. 設置訪問swap文件的線程數,最好不要超過機器的核數,若是設置爲0,那麼全部對swap文件的操做都是串行的,可能會形成比較長時間的延遲。默認值爲4
   vm-max-threads 4
27. 設置在向客戶端應答時,是否把較小的包合併爲一個包發送,默認爲開啓
  glueoutputbuf yes
28. 指定在超過必定的數量或者最大的元素超過某一臨界值時,採用一種特殊的哈希算法
  hash-max-zipmap-entries 64
  hash-max-zipmap-value 512
29. 指定是否激活重置哈希,默認爲開啓(後面在介紹Redis的哈希算法時具體介紹)
  activerehashing yes
30. 指定包含其它的配置文件,能夠在同一主機上多個Redis實例之間使用同一份配置文件,而同時各個實例又擁有本身的特定配置文件
  include /path/to/local.conf
View Code

 

redis的持久化

整體介紹

 

RDB(Redis DataBase)

是什麼:

在指定的時間間隔內將內存中的數據集快照寫入磁盤,
也就是行話講的Snapshot快照,它恢復時是將快照文件直接讀到內存裏
Redis會單首創建(fork)一個子進程來進行持久化,會先將數據寫入到
一個臨時文件中,待持久化過程都結束了,再用這個臨時文件替換上次持久化好的文件。
整個過程當中,主進程是不進行任何IO操做的,這就確保了極高的性能
若是須要進行大規模數據的恢復,且對於數據恢復的完整性不是很是敏感,那RDB方
式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的數據可能丟失。

Fork

fork的做用是複製一個與當前進程同樣的進程。新進程的全部數據(變量、環境變量、程序計數器等)
數值都和原進程一致,可是是一個全新的進程,並做爲原進程的子進程

rdb 保存的是dump.rdb文件

配置位置

如何觸發RDB快照

配置文件中默認的快照配置

冷拷貝後從新使用

能夠cp dump.rdb dump_new.rdb

 

命令save或者是bgsave

BGSAVE:Redis會在後臺異步進行快照操做,
快照同時還能夠響應客戶端請求。能夠經過lastsave
命令獲取最後一次成功執行快照的時間

 

執行flushall命令,也會產生dump.rdb文件,但裏面是空的,無心義

 

如何恢復

將備份文件 (dump.rdb) 移動到 redis 安裝目錄並啓動服務便可

 

CONFIG GET dir獲取目錄

 

優點

適合大規模的數據恢復
對數據完整性和一致性要求不高

劣勢

在必定間隔時間作一次備份,因此若是redis意外down掉的話,就
會丟失最後一次快照後的全部修改
fork的時候,內存中的數據被克隆了一份,大體2倍的膨脹性須要考慮

如何中止

動態全部中止RDB保存規則的方法:redis-cli config set save ""

 

小總結

 

 

AOF(Append Only File)

是什麼:

以日誌的形式來記錄每一個寫操做,將Redis執行過的全部寫指令記錄下來(讀操做不記錄),
只許追加文件但不能夠改寫文件,redis啓動之初會讀取該文件從新構建數據,換言之,redis
重啓的話就根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工做

Aof保存的是appendonly.aof文件

 配置位置

 AOF啓動/修復/恢復

 正常恢復

 啓動:設置Yes異常恢復 

修改默認的appendonly no,改成yes 
將有數據的aof文件複製一份保存到對應目錄(config get dir)
恢復:重啓redis而後從新加載

 

異常恢復

備份被寫壞的AOF文件
修復:redis-check-aof --fix進行修復
恢復:重啓redis而後從新加載

rewrite

是什麼:

AOF採用文件追加方式,文件會愈來愈大爲避免出現此種狀況,新增了重寫機制,
當AOF文件的大小超過所設定的閾值時,Redis就會啓動AOF文件的內容壓縮,
只保留能夠恢復數據的最小指令集.能夠使用命令bgrewriteaof

重寫原理

AOF文件持續增加而過大時,會fork出一條新進程來將文件重寫(也是先寫臨時文件最後再rename),
遍歷新進程的內存中數據,每條記錄有一條的Set語句。重寫aof文件的操做,並無讀取舊的aof文件,
而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件,這點和快照有點相似

觸發機制

Redis會記錄上次重寫時的AOF大小,默認配置是當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發

優點

每修改同步:appendfsync always   同步持久化 每次發生數據變動會被當即記錄到磁盤  性能較差但數據完整性比較好

每秒同步:appendfsync everysec    異步操做,每秒記錄   若是一秒內宕機,有數據丟失

不一樣步:appendfsync no   從不一樣步

劣勢

相同數據集的數據而言aof文件要遠大於rdb文件,恢復速度慢於rdb
aof運行效率要慢於rdb,每秒同步策略效率較好,不一樣步效率和rdb相同

 

 

總結(Which one)

 

 

Redis的事務

是什麼

能夠一次執行多個命令,本質是一組命令的集合。一個事務中的
全部命令都會序列化,按順序地串行化執行而不會被其它命令插入,不準加塞

 

能幹嗎

一個隊列中,一次性、順序性、排他性的執行一系列命令

 

怎麼玩

經常使用命令

case1:正常執行

Case2:放棄事務

Case3:全體連坐

Case4:冤頭債主

Case5:watch監控

 

悲觀鎖/樂觀鎖/CAS(Check And Set)

悲觀鎖

悲觀鎖(Pessimistic Lock), 顧名思義,就是很悲觀,每次去拿數據的時候都認爲別人會修改,
因此每次在拿數據的時候都會上鎖,這樣別人想拿這個數據就會block直到它拿到鎖。
傳統的關係型數據庫裏邊就用到了不少這種鎖機制,
好比行鎖,表鎖等,讀鎖,寫鎖等,都是在作操做以前先上鎖

 

樂觀鎖

樂觀鎖(Optimistic Lock), 顧名思義,就是很樂觀,每次去拿數據的時候都認爲別人不會修改,因此不會上鎖,可是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據,能夠使用版本號等機制。樂觀鎖適用於多讀的應用類型,這樣能夠提升吞吐量,

樂觀鎖策略:提交版本必須大於記錄當前版本才能執行更新

 

CAS

 

初始化信用卡可用餘額和欠額

無加塞篡改:

先監控再開啓multi,
保證兩筆金額變更在同一個事務內

有加塞篡改:

監控了key,若是key被修改了,後面一個事務的執行失效

 unwatch:

一旦執行了exec以前加的監控鎖都會被取消掉了

小結:

Watch指令,相似樂觀鎖,事務提交時,若是Key的值已被別的客戶端改變,
好比某個list已被別的客戶端push/pop過了,整個事務隊列都不會被執行

經過WATCH命令在事務執行以前監控了多個Keys,假若在WATCH以後有任何Key的值發生了變化,
EXEC命令執行的事務都將被放棄,同時返回Nullmulti-bulk應答以通知調用者事務執行失敗

 

3階段

開啓:以MULTI開始一個事務
入隊:將多個命令入隊到事務中,接到這些命令並不會當即執行,而是放到等待執行的事務隊列裏面

 

執行:由EXEC命令觸發事務

 

 

單獨的隔離操做:事務中的全部命令都會序列化、按順序地執行。事務在執行的過程當中,不會被其餘客戶端發送來的命令請求所打斷。

 

3特性

沒有隔離級別的概念:隊列中的命令沒有提交以前都不會實際的被執行,由於事務提交前任何指令都不會被實際執行,
也就不存在」事務內的查詢要看到事務裏的更新,在事務外查詢不能看到」這個讓人萬分頭痛的問題

 

不保證原子性:redis同一個事務中若是有一條命令執行失敗,其後的命令仍然會被執行,沒有回滾

 

 

Redis的發佈訂閱

是什麼

進程間的一種消息通訊模式:發送者(pub)發送消息,訂閱者(sub)接收消息。

 

 訂閱/發佈消息圖:

命令

案列

先訂閱後發佈後才能收到消息,
1 能夠一次性訂閱多個,SUBSCRIBE c1 c2 c3


2 消息發佈,PUBLISH c2 hello-redis
===========================================================================================================
3 訂閱多個,通配符*, PSUBSCRIBE new*
4 收取消息, PUBLISH new1 redis2015
View Code

 

Redis的複製(Master/Slave)

是什麼

行話:也就是咱們所說的主從複製,主機數據更新後根據配置和策略,
自動同步到備機的master/slaver機制,Master以寫爲主,Slave以讀爲主

能幹嗎

讀寫分離
容災恢復
配從(庫)不配主(庫)

 

怎麼玩

從庫配置:slaveof 主庫IP 主庫端口:
每次與master斷開以後,都須要從新鏈接,除非你配置進redis.conf文件


info replication

 

 

修改配置文件細節操做:
info replication
拷貝多個redis.conf文件
開啓daemonize yes
pid文件名字
指定端口
log文件名字
dump.rdb名字

 

經常使用3招

一主二僕

Init
一個Master兩個Slave
日誌查看
主從問題演示:

1 切入點問題?slave一、slave2是從頭開始複製仍是從切入點開始複製?好比從k4進來,那以前的123是否也能夠複製

2 從機是否能夠寫?set能否?

3 主機shutdown後狀況如何?從機是上位仍是原地待命

4 主機又回來了後,主機新增記錄,從機還可否順利複製?

5 其中一臺從機down後狀況如何?依照原有它能跟上大部隊嗎?

 

薪火相傳

上一個Slave能夠是下一個slave的Master,Slave一樣能夠接收其餘
slaves的鏈接和同步請求,那麼該slave做爲了鏈條中下一個的master,
能夠有效減輕master的寫壓力


中途變動轉向:會清除以前的數據,從新創建拷貝最新的


slaveof 新主庫IP 新主庫端口

 

反客爲主

SLAVEOF no one
使當前數據庫中止與其餘數據庫的同步,轉成主數據庫

 

 

複製原理

slave啓動成功鏈接到master後會發送一個sync命令

 

Master接到命令啓動後臺的存盤進程,同時收集全部接收到的用於修改數據集命令,
在後臺進程執行完畢以後,master將傳送整個數據文件到slave,以完成一次徹底同步

 

 

全量複製:而slave服務在接收到數據庫文件數據後,將其存盤並加載到內存中。

 

 

增量複製:Master繼續將新的全部收集到的修改命令依次傳給slave,完成同步

 

 

可是隻要是從新鏈接master,一次徹底同步(全量複製)將被自動執行

 

 

 

哨兵模式(sentinel)

是什麼

反客爲主的自動版,可以後臺監控主機是否故障,若是故障了根據投票數自動將從庫轉換爲主庫

怎麼玩(使用步驟)

調整結構,6379帶着80、81

 

自定義的/myredis目錄下新建sentinel.conf文件,名字毫不能錯

 

配置哨兵,填寫內容:
 sentinel monitor 被監控數據庫名字(本身起名字) 127.0.0.1 6379 1

上面最後一個數字1,表示主機掛掉後salve投票看讓誰接替成爲主機,得票數多少後成爲主機
啓動哨兵:
redis-sentinel /myredis/sentinel.conf 
上述目錄依照各自的實際狀況配置,可能目錄不一樣

正常主從演示

原有的master掛了
投票新選
從新主從繼續開工,info replication查查看
問題:若是以前的master重啓回來,會不會雙master衝突?

 

 

複製的缺點

複製延時

因爲全部的寫操做都是先在Master上操做,而後同步更新到Slave上,因此從Master同步到Slave機器有必定的延遲,當系統很繁忙的時候,延遲問題會更加嚴重,Slave機器數量的增長也會使這個問題更加嚴重。

Redis的Java客戶端Jedis

安裝JDK

 tar -zxvf jdk-7u67-linux-i586.tar.gz
 vi /etc/profile
重啓一次Centos
編碼驗證

 

安裝eclipse

 

Jedis所須要的jar包

commons-pool-1.6.jar
jedis-2.1.0.jar

 

 

Jedis經常使用操做

前提是你已經把redis的端口放到了防火牆計劃中,

 /sbin/iptables -I INPUT -p tcp --dport 6379 -j ACCEPT

 /etc/rc.d/init.d/iptables save
1
2
3
更改redis.conf 文件

bind 127.0.0.1

protected-mode yes
1
2
3
更改成

# bind 127.0.0.1

protected-mode no
1
2
3
而後重啓redis, 
前提是你如今已經運行着redis呢 
關閉redis

# redis-cli shutdown
1
redis-cli是你的安裝路徑, 即 make install的時候, 你會指定一個路徑, 
重啓redis

redis-server /opt/local/redis/redis-4.0.6/redis.conf
1
redis-server 一樣也是安裝路徑下的. 
這樣設置外網訪問就成功了.
設置外網訪問

 

測試連通性

public class Demo01 {
  public static void main(String[] args) {
    //鏈接本地的 Redis 服務
    Jedis jedis = new Jedis("127.0.0.1",6379);
    //查看服務是否運行,打出pong表示OK
    System.out.println("connection is OK==========>: "+jedis.ping());
  }
}

5+1

一個key
五大數據類型

事務提交

平常:
package com.atguigu.redis.test;


import redis.clients.jedis.Jedis;
import redis.clients.jedis.Response;
import redis.clients.jedis.Transaction;


public class Test03 
{
  public static void main(String[] args) 
  {
     Jedis jedis new Jedis("127.0.0.1",6379);
     
     //監控key,若是該動了事務就被放棄
     /*3
     jedis.watch("serialNum");
     jedis.set("serialNum","s#####################");
     jedis.unwatch();*/
     
     Transaction transaction = jedis.multi();//被看成一個命令進行執行
     Response<String> response = transaction.get("serialNum");
     transaction.set("serialNum","s002");
     response = transaction.get("serialNum");
     transaction.lpush("list3","a");
     transaction.lpush("list3","b");
     transaction.lpush("list3","c");
     
     transaction.exec();
     //2 transaction.discard();
     System.out.println("serialNum***********"+response.get());
          
  }
}

 

加鎖

public class TestTransaction {


  public boolean transMethod() {
     Jedis jedis new Jedis("127.0.0.1", 6379);
     int balance;// 可用餘額
     int debt;// 欠額
     int amtToSubtract = 10;// 實刷額度


     jedis.watch("balance");
     //jedis.set("balance","5");//此句不應出現,講課方便。模擬其餘程序已經修改了該條目
     balance = Integer.parseInt(jedis.get("balance"));
     if (balance < amtToSubtract) {
       jedis.unwatch();
       System.out.println("modify");
       return false;
     } else {
       System.out.println("***********transaction");
       Transaction transaction = jedis.multi();
       transaction.decrBy("balance", amtToSubtract);
       transaction.incrBy("debt", amtToSubtract);
       transaction.exec();
       balance = Integer.parseInt(jedis.get("balance"));
       debt = Integer.parseInt(jedis.get("debt"));


       System.out.println("*******" + balance);
       System.out.println("*******" + debt);
       return true;
     }
  }


  /**
   * 通俗點講,watch命令就是標記一個鍵,若是標記了一個鍵, 在提交事務前若是該鍵被別人修改過,那事務就會失敗,這種狀況一般能夠在程序中
   * 從新再嘗試一次。
   * 首先標記了鍵balance,而後檢查餘額是否足夠,不足就取消標記,並不作扣減; 足夠的話,就啓動事務進行更新操做,
   * 若是在此期間鍵balance被其它人修改, 那在提交事務(執行exec)時就會報錯, 程序中一般能夠捕獲這類錯誤再從新執行一次,直到成功。
   */
  public static void main(String[] args) {
     TestTransaction test new TestTransaction();
     boolean retValue = test.transMethod();
     System.out.println("main retValue-------: " + retValue);
  }
}

 

 

主從複製

主寫

從讀

JedisPool

獲取Jedis實例須要從JedisPool中獲取

 

用完Jedis實例須要返還給JedisPool
若是Jedis在使用過程當中出錯,則也須要還給JedisPool

 

 

案例見代碼:

package com.atguigu.redis.test;


import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;


public class JedisPoolUtil {
  
 private static volatile JedisPool jedisPool = null;//被volatile修飾的變量不會被本地線程緩存,對該變量的讀寫都是直接操做共享內存。
  
  private JedisPoolUtil() {}
  
  public static JedisPool getJedisPoolInstance()
 {
     if(null == jedisPool)
    {
       synchronized (JedisPoolUtil.class)
      {
          if(null == jedisPool)
         {
           JedisPoolConfig poolConfig new JedisPoolConfig();
           poolConfig.setMaxActive(1000);
           poolConfig.setMaxIdle(32);
           poolConfig.setMaxWait(100*1000);
           poolConfig.setTestOnBorrow(true);
            
            jedisPool new JedisPool(poolConfig,"127.0.0.1");
         }
      }
    }
     return jedisPool;
 }
  
  public static void release(JedisPool jedisPool,Jedis jedis)
 {
     if(null != jedis)
    {
      jedisPool.returnResourceObject(jedis);
    }
 }
}
 
JedisPoolUtil
package com.atguigu.redis.test;


import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;


public class Test01 {
  public static void main(String[] args) {
     JedisPool jedisPool = JedisPoolUtil.getJedisPoolInstance();
     Jedis jedis null;
     
     try 
     {
       jedis = jedisPool.getResource();
       jedis.set("k18","v183");
       
     } catch (Exception e) {
       e.printStackTrace();
     }finally{
       JedisPoolUtil.release(jedisPool, jedis);
     }
  }
}
 
Demo5
jedisPool.getResource();

配置總結all

JedisPool的配置參數大部分是由JedisPoolConfig的對應項來賦值的。


maxActive:控制一個pool可分配多少個jedis實例,經過pool.getResource()來獲取;若是賦值爲-1,則表示不限制;若是pool已經分配了maxActive個jedis實例,則此時pool的狀態爲exhausted。
maxIdle:控制一個pool最多有多少個狀態爲idle(空閒)的jedis實例;
whenExhaustedAction:表示當pool中的jedis實例都被allocated完時,pool要採起的操做;默認有三種。
 WHEN_EXHAUSTED_FAIL --> 表示無jedis實例時,直接拋出NoSuchElementException;
 WHEN_EXHAUSTED_BLOCK --> 則表示阻塞住,或者達到maxWait時拋出JedisConnectionException;
 WHEN_EXHAUSTED_GROW --> 則表示新建一個jedis實例,也就說設置的maxActive無用;
maxWait:表示當borrow一個jedis實例時,最大的等待時間,若是超過等待時間,則直接拋JedisConnectionException;
testOnBorrow:得到一個jedis實例的時候是否檢查鏈接可用性(ping());若是爲true,則獲得的jedis實例均是可用的;


testOnReturn:return 一個jedis實例給pool時,是否檢查鏈接可用性(ping());


testWhileIdle:若是爲true,表示有一個idle object evitor線程對idle object進行掃描,若是validate失敗,此object會被從pool中drop掉;這一項只有在timeBetweenEvictionRunsMillis大於0時纔有意義;


timeBetweenEvictionRunsMillis:表示idle object evitor兩次掃描之間要sleep的毫秒數;


numTestsPerEvictionRun:表示idle object evitor每次掃描的最多的對象數;


minEvictableIdleTimeMillis:表示一個對象至少停留在idle狀態的最短期,而後才能被idle object evitor掃描並驅逐;這一項只有在timeBetweenEvictionRunsMillis大於0時纔有意義;


softMinEvictableIdleTimeMillis:在minEvictableIdleTimeMillis基礎上,加入了至少minIdle個對象已經在pool裏面了。若是爲-1,evicted不會根據idle time驅逐任何對象。若是minEvictableIdleTimeMillis>0,則此項設置無心義,且只有在timeBetweenEvictionRunsMillis大於0時纔有意義;


lifo:borrowObject返回對象時,是採用DEFAULT_LIFO(last in first out,即相似cache的最頻繁使用隊列),若是爲False,則表示FIFO隊列;


==================================================================================================================
其中JedisPoolConfig對一些參數的默認設置以下:
testWhileIdle=true
minEvictableIdleTimeMills=60000
timeBetweenEvictionRunsMillis=30000
numTestsPerEvictionRun=-1
View Code

 

timeout
客戶端超過多少秒空閒後關閉(0是禁止此功能),若是小於0啓動失敗
tcp-keepalive
用於檢測tcp鏈接是否還存活,建議設置300(單位是秒),若是小於0啓動失敗
protected-mode
當設置爲yes後,若是沒有經過bind設置address以及沒有設置password,那麼redis只接受來loopback address 127.0.0.1和::1的鏈接和unix domain socket
port
制定監聽端口(若是設置0,redis不會在tcp socket監聽,若是設置小於0或者大於65535啓動失敗)
tcp-backlog
tcp監聽隊列長度,若是大於/proc/sys/net/core/somaxconn,會取/proc/sys/net/core/somaxconn的值,因此調高此值的時候應該關注/proc/sys/net/ipv4/tcp_max_syn_backlog和/proc/sys/net/core/somaxconn的值
若是小於0啓動失敗
bind
綁定網絡接口,默認接受來自全部網絡接口的鏈接
能夠綁定多個,最多同時綁定16個
unixsocket
制定用於監聽l鏈接的unix socket的路徑,沒有默認值
unixsocketperm
unixsocket path的權限,不能大於777
save
1 save 900 1 格式
在900秒內有1個key改變了則執行save
2 save "" 格式
以前的save 配置無效
dir
數據庫存儲的目錄,必須是有效而且存在的目錄
loglevel
日誌級別,取值範圍debug,verbose,notice,warning
logfile
日誌文件名
always-show-logo
老是顯示logo
syslog-enabled
啓用寫入日誌到system logger
syslog-ident
syslog的identity
syslog-facility
syslog的facility,取值範圍,user,local0-local7
databases
database數量,若是小於1則啓動失敗
include
加載其餘配置文件
maxclients
同時最大的鏈接數,默認10000,若是小於1啓動失敗
maxmemory
最大使用內存,超過則觸發內存策略
maxmemory-policy
取值範圍
1 volatile-lru 在設置了過時的key中經過lfu算法查找key淘汰
2 volatile-lfu 在全部key中經過lru算法查找key淘汰
3 volatile-random 在設置了過時的key中隨機查找key淘汰
4 volatile-ttl 最近要超時的key淘汰
5 allkeys-lru 全部key經過lru算法查找key淘汰
6 allkeys-lfu 全部key經過lfu算法查找key淘汰
7 allkeys-random 全部key隨機查找key淘汰
8 noeviction 不淘汰,對於寫操做返回錯誤
maxmemory-samples
lru,lfu會對這個數量的key進行檢查,設置太高會消耗cpu,若是小於0則啓動失敗
proto-max-bulk-len
批量請求的大小限制
client-query-buffer-limit
客戶端查詢緩存大小限制,若是multi/exec 大能夠考慮調節
lfu-log-factor
小於0則啓動失敗
lfu-decay-time
小於0則啓動失敗
slaveof/replicaof
配置主機複製的主ip和端口
replicaof ip port
repl-ping-slave-period/repl-ping-replica-period
從發給主的心跳週期,若是小於0則啓動失敗
repl-timeout
多少秒沒收到心跳的響應認爲超時,最好設置的比 repl-ping-slave-period/repl-ping-replica-period大
若是小於0則啓動失敗
repl-disable-tcp-nodelay
是否禁用tcp-nodelay,若是設置yes,會致使主從同步有40ms滯後(linux默認),若是no,則主從同步更及時
repl-diskless-sync
以往主從複製是生成rdb文件,而後傳輸給從節點,配置成yes後能夠不進行寫磁盤直接進行復制,適用於磁盤慢網絡帶寬大的場景
repl-diskless-sync-delay
讓主節點等待更多從節點來同時複製,設置太小,複製時來的從節點必須等待下一次rdb transfer
單位秒,若是小於0則啓動失敗
repl-backlog-size
複製積壓大小,解決複製過程當中從節點重連後不須要full sync,這個值越大,那麼從節點斷開到重連的時間就能夠更長
repl-backlog-ttl
複製積壓的生命期,超過多長時間從節點還沒重連,則釋放內存
masterauth
主從複製的認證
slave-serve-stale-data/replica-serve-stale-data
默認yes
當從節點和主節點的鏈接斷開或者複製正在進行中
設置yes,那麼繼續提供服務
設置no,那麼返回sync with master in progress
slave-read-only/replica-read-only
配置從節點是否只讀,可是配置的修改仍是能夠的
slave-ignore-maxmemory/replica-ignore-maxmemory
從節點是否忽略maxmemory配置,默認yes
rdbcompression
壓縮string 對象,可是會消耗cpu,能夠設置爲no
rdbchecksum
是否檢查rdbchecksum,默認yes,能夠設置no
activerehashing
默認每1秒10次消耗1ms來作rehashing來釋放內存,會增長請求的延時,若是你對延時敏感,則設置no,默認yes
lazyfree-lazy-eviction
默認no,那麼redis是同步釋放內存,也就是中止完成其餘請求來作釋放內存操做,若是遇到key複雜度很大時(0(n))的會增長請求延時
若是yes,那麼則先刪除dict中的key,而後把釋放內存的任務提交給後臺線程作
lazyfree-lazy-expire
默認no,那麼redis是同步刪除過時key,也就是中止完成其餘請求來作刪除過時key,若是遇到key複雜度很大時(0(n))的會增長請求延時
若是yes,把刪除key的任務提交給後臺線程作
lazyfree_lazy_server-del
默認no,那麼redis是同步刪除key,也就是中止完成其餘請求來作刪除key,若是遇到key複雜度很大時(0(n))的會增長請求延時
若是yes,那麼則先刪除dict中的key,而後把刪除key的任務提交給後臺線程作(若是key很小則暫時不刪除,只是減小了引用)
slave-lazy-flush/replica-lazy-flush
默認no,那麼redis是同步清空數據庫,也就是中止完成其餘請求來作清空數據庫,若是遇到數據庫很大會增長請求延時
若是yes,那麼則新建dict等數據結構,而後把清空數據庫提交給後臺線程作
activedefrag
若是你遇到內存碎片的問題,那麼設置爲yes,默認no
daemonize
是否以守護進程運行,默認no
hash-max-ziplist-entries
hash中的項數量小於或等於這個值使用ziplist
超過這個值使用hash
dynamic-hz
設置yes,則根據客戶端鏈接數能夠自動調節hz
hz
調節可讓redis再空閒時間更多的作一些任務(如關閉超時客戶端等)
appendonly
是否開啓aof
appendfilename
aof文件名
no-appendfsync-on-rewrite
設置yes後,若是有保存的進程在執行,則不執行aof的appendfsync策略的fsync
appendfsync
執行fynsc的策略
取值範圍:
1 everysec 每秒執行sync
2 always 等到下次執行beforeslee時執行fsync
3 no 不執行fsync
設置always每每比較影響性能,可是數據丟失的風險最低
通常推薦設置everysec
auto-aof-rewrite-percentage
相對於上次aof文件大小的增加百分好比果超過這個值,則重寫aof
auto-aof-rewrite-min-size
自動重寫aof文件的最小大小,比 auto-aof-rewrite-percentage優先級高
aof-rewrite-incremental-fsync
設置yes,則每32mb 執行fsync一次(增量式,避免一次性大寫入致使的延時)
設置no,則一次性fsync
rdb-save-incremental-fsync
設置yes,則每32mb 執行fsync一次(增量式,避免一次性大寫入致使的延時)
設置no,則一次性fsync
aof-load-truncated
加入aof文件被截斷了
1 設置yes,redis能夠啓動而且顯示日誌告知這個信息
2 設置no,redis啓動失敗,顯示錯誤
aof-use-rdb-preamble
aof前部分用rdb,後面保存時緩存的命令仍是用aof格式
優勢:保存和恢復更快
設置yes開啓
requirepass
用於在客戶端執行命令前,要求執行 auth password
pidfile
存儲redis pid的文件,redis啓動後建立,退出後刪除
dbfilename
rdb文件名
active_defrag_threshold_upper
開啓內存碎片整理的最小內存碎片百分比
小於0或者大於1000則啓動失敗
active_defrag_threshold_upper
內存碎片百分比超過這個值,則使用active-defrag-cycle-max
小於0或者大於1000則啓動失敗
active-defrag-ignore-bytes
開啓內存碎片整理的最小內存碎片字節數
若是小於等於0則啓動失敗
active-defrag-cycle-max
最小努力cpu百分比,用來作內存碎片整理
若是小於1或者大於99則啓動失敗
active-defrag-cycle-min
最大努力cpu百分比,用來作內存碎片整理
若是小於1或者大於99則啓動失敗
active-defrag-max-scan-fields
用於主動的內存碎片整理的set/hash/zset/list 中的最大數量的項
若是小於1,啓動失敗
hash-max-ziplist-value
hash 中的項大小小於或等於這個值使用ziplist
超過這個值使用hash
stream-node-max-bytes
stream 的最大內存開銷字節數
stream-node-max-entries
stream 的最大項數量
list-max-ziplist-size
負值表示節點大小
-5 每一個list節點大小不能超過64 Kb
-4 每一個list節點大小不能超過32 Kb
-3 每一個list節點大小不能超過16 Kb
-2 每一個list節點大小不能超過8 Kb
-1 每一個list節點大小不能超過4 Kb
推薦-1,-2
正值表示節點數量
知足設置的值,則使用ziplist表示,節約內存
超過設置的值,則使用普通list
list-compress-depth
不壓縮quicklist 距離首尾節點小於等於這個值的ziplist節點
默認首尾節點不壓縮,
設置爲1
head->next->...->prev->tail
不壓縮next,prev,以此類推
0表示都不壓縮
set-max-intset-entries
當set 的元素數量小於這個值且元素能夠用int64範圍的整型表示時,使用inset,節約內存
大於或者元素沒法用int64範圍的整型表示時用set表示
zset-max-ziplist-entries
當sorted set 的元素數量小於這個值時,使用ziplist,節約內存
大於這個值zset表示
zset-max-ziplist-value
當sorted set 的元素大小小於這個值時,使用ziplist,節約內存
大於這個值zser表示
hll-sparse-max-bytes
大於這個值,hyperloglog使用稠密結構
小於等於這個值,使用稀疏結構
大於16000無心義,建議設置3000
rename-command
重命名命令,建議重命名一些敏感的命令(如flushall,flushdb)
cluster-enabled
開啓集羣模式
cluster-config-file
集羣配置文件名
cluster-announce-ip
集羣的節點的彙報ip,防止nat
cluster-announce-port
集羣的節點的彙報port,防止nat
cluster-announce-bus-port
集羣的節點的彙報bus-port,防止nat
cluster-require-full-coverage
默認若是不是全部slot已經分配到節點,那麼集羣沒法提供服務
設置爲no,則能夠提供服務
cluster-node-timeout
認爲集羣節點失效狀態的時間
若是小於0則啓動失敗
cluster-migration-barrier
當存在孤立主節點後(沒有從節點),其餘從節點會遷移做爲這個孤立的主節點的從節點(前提是這個從節點以前的主節點至少還有這個數額個從節點)
不建議設置爲0
想禁用能夠設置一個很是大的值
若是小於0則啓動失敗
cluster-slave-validity-factor
若是從節點和master距離上一次通訊超過 (node-timeout * replica-validity-factor) + repl-ping-replica-period時間,則沒有資格失效轉移爲master
若是小於0則啓動失敗
cluster-slave-no-failover/cluster-replica-no-failover
在主節點失效期間,從節點不容許對master失效轉移
取值yes,no
lua-time-limit
lua腳本的最大執行時間,超過這個時間後,恢復客戶端的查詢錯誤
0或者負數則無限制
slowlog-log-slower-than
執行命令大於這個值計入慢日誌
若是設置爲0,則全部命令所有記錄慢日誌
單位毫秒
latency-monitor-threshold
爲了收集可能致使延時的數據根源,redis延時監控系統在運行時會採樣一些操做
經過 LATENCY命令 能夠打印一些圖樣和獲取一些報告
這個系統僅僅記錄那個執行時間大於或等於經過latency-monitor-threshold配置來指定的
當設置爲0時這個監控系統關閉
單位毫秒
slowlog-max-len
最大的慢日誌條數,這個會佔用內存的
能夠經過slowlog reset來釋放內存
能夠經過slowlog len來查看當前條數
client-output-buffer-limit
0則無限制
格式client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
client-output-buffer達到hard limit或者保持超過soft limit 持續sof seconds則斷開鏈接
class 分爲3種
1 normal 普通客戶端包裹monitor客戶端
2 replica 從節點
2 pubsub 至少pubsub一個channel或者pattern的客戶端
stop-writes-on-bgsave-error
basave錯誤後是否中止接受寫請求
slave-priority/replica-priority
當master不在工做後,從節點提高爲master的優先級,0則不會提高爲master
越小優先級越高
slave-announce-ip/replica-announce-ip
從節點上報給master的本身ip,防止nat問題
slave-announce-port/replica-announce-port
從節點上報給master的本身port,防止nat問題
min-slaves-to-write
最少從節點數,不知足min-slaves-to-write個 低於min-slaves-max-lag/min-replicas-max-lag時間的從節點,master不在接受寫請求
若是小於0則啓動失敗
默認0,也就是禁用狀態
min-slaves-max-lag/min-replicas-max-lag
最大從節點的落後時間,不知足min-slaves-to-write個 低於這個時間的從節點,master不在接受寫請求
若是小於0則啓動失敗
notify-keyspace-events
取值範圍(能夠多個一塊兒)
K     Keyspace events, published with keyspace@<db> prefix.
E     Keyevent events, published with keyevent@<db> prefix.
g     Generic commands (non-type specific) like DEL, EXPIRE, RENAME,
$    String commands
l     List commands
s     Set commands
h     Hash commands
z     Sorted set commands
x     Expired events (events generated every time a key expires)
e     Evicted events (events generated when a key is evicted for maxmemory)
A     Alias for  g$lshzxe , so that the "AKE" string means all the events.
supervised
默認no
supervised no - 沒有監督互動
supervised upstart - 經過將Redis置於SIGSTOP模式來啓動信號
supervised systemd - signal systemd將READY = 1寫入$ NOTIFY_SOCKET
supervised auto - 檢測upstart或systemd方法基於 UPSTART_JOB或NOTIFY_SOCKET環境變量
sentinel monitor
格式sentinel monitor <master-name> <ip> <redis-port> <quorum>
如sentinel monitor mymaster 127.0.0.1 6379 2
告知sentinel監控這個ip和redis-port端口的redis,當至少達到quorum數量的sentinel贊成才認爲他客觀離線(O_DOWN)
sentinel down-after-milliseconds
格式sentinel down-after-milliseconds <master-name> <milliseconds>
附屬的從節點或者sentinel和他超過milliseconds時間沒有達到,則主觀離線(S_DOWN)
sentinel failover-timeout
格式 sentinel failover-timeout <master-name> <milliseconds>
用在不少方面:
1 距離被一個給定的Sentiel對同一個master進行過failedover的上一次的時間是此設置值的2倍
2 從從節點根據sentinel當前配置複製一個錯誤的主節點到複製新的主節點的時間須要的時間(從sentinel檢測到配置錯誤起計算)
3 取消一個在進行中可是尚未產生配置變化(slave of no one尚未被提高的從節點確認)的failover須要的時間
4  進行中的failover等待全部從節點 從新配置爲新master的從節點的最大時間.然而 雖然在這個時間後全部從節點將被sentinel從新配置,但並非指定的正確的parallel-syncs 過程
sentinel parallel-syncs
格式 sentinel parallel-syncs <master-name> <numreplicas>
制定多少個從節點能夠在failover期間同時配置到新的主節點.若是你用從節點服務查詢,那麼使用一個較低的值來避免全部的從節點都不可達,切好此時他們在和主節點同步
sentinel notification-script
格式  sentinel notification-script <master-name> <script-path>
對任何生成的在WARNING 級別的sentinel 事件會調用這通知腳本(例如sdown,odown等)
這個腳本應該經過email,sms等其餘消息系統通知系統管理員監控的redis系統有錯
調用這個腳本帶有2個參數,第一個是事件類型,第二個是事件描述
若是這個選項設置的話這個腳本必須存在
sentinel client-reconfig-script
格式sentinel client-reconfig-script <master-name> <script-path>
當主節點因爲failover改變,一個腳本能夠執行,用於執行通知客戶端配置改變了主節點在不一樣地址的特定應用的任務。
下面的參數將傳遞給這個腳本
<master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
state當前老是failover
role不是leader就是observer
從from-ip,from-port,to-ip,to-port 用於和舊主節點和被選舉的節點(當前主節點)通訊的地址
這個腳本是能夠被屢次調用的
auth-pass
格式  sentinel auth-pass <master-name> <password>
設置用於和主節點以及從節點通訊的密碼.若是在監控redis實例中有密碼的話是有用的
注意這個主節點密碼一樣用於從節點,因此給主節點和從節點實例設置不一樣的密碼是不可能的
而後你能夠擁有不開啓認證的redis實例和須要認證的redis實例混合(只要須要密碼的redis實例密碼設置同樣)
由於當認證關閉時,auth 命令將在redis實例中無效
SENTINEL rename-command
如 SENTINEL rename-command mymaster CONFIG GUESSME
有時,redis服務 有些sentinel工做正常須要的命令,重命名爲猜不到的字符串.一般是在提供者提供redis做爲服務並且不但願客戶從新配置在管理員控制檯外修改配置的場景中的config,slaveof,
在這個狀況,告訴sentinel使用不一樣的命令名字而不是常規的是可能的.
sentinel announce-ip
格式 sentinel announce-ip <ip>
在nat環境下是有用的
sentinel announce-port
格式sentinel announce-port <port>
在nat環境下是有用的
sentinel deny-scripts-reconfig
格式sentinel deny-scripts-reconfig yes
默認sentinel set 在運行期是不能改變notification-script和 client-reconfig-script .
這個避免一些細小的安全問題,在這裏客戶端能夠設置腳本爲任何東西並且觸發一個failover用於讓這個程序執行

做者:wwq1988
連接:https://www.jianshu.com/p/85115435fd24
來源:簡書
簡書著做權歸做者全部,任何形式的轉載都請聯繫做者得到受權並註明出處。
redis 配置總結
相關文章
相關標籤/搜索