在90年代,一個網站的訪問量通常都不大,用單個數據庫徹底能夠輕鬆應付。
在那個時候,更多的都是靜態網頁,動態交互類型的網站很少。html
上述架構下,咱們來看看數據存儲的瓶頸是什麼?
1.數據量的總大小 一個機器放不下時
2.數據的索引(B+ Tree)一個機器的內存放不下時
3.訪問量(讀寫混合)一個實例不能承受
若是知足了上述1 or 3個,進化......java
後來,隨着訪問量的上升,幾乎大部分使用MySQL架構的網站在數據庫上都開始出現了性能問題,web程序再也不僅僅專一在功能上,同時也在追求性能。程序員們開始大量的使用緩存技術來緩解數據庫的壓力,優化數據庫的結構和索引。開始比較流行的是經過文件緩存來緩解數據庫壓力,可是當訪問量繼續增大的時候,多臺web機器經過文件緩存不能共享,大量的小文件緩存也帶了了比較高的IO壓力。在這個時候,Memcached就天然的成爲一個很是時尚的技術產品。node
Memcached做爲一個獨立的分佈式的緩存服務器,爲多個web服務器提供了一個共享的高性能緩存服務,在Memcached服務器上,又發展了根據hash算法來進行多臺Memcached緩存服務的擴展,而後又出現了一致性hash來解決增長或減小緩存服務器致使從新hash帶來的大量緩存失效的弊端mysql
因爲數據庫的寫入壓力增長,Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負,大部分網站開始使用主從複製技術來達到讀寫分離,以提升讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成爲這個時候的網站標配了。linux
在Memcached的高速緩存,MySQL的主從複製,讀寫分離的基礎之上,這時MySQL主庫的寫壓力開始出現瓶頸,而數據量的持續猛增,因爲MyISAM使用表鎖,在高併發下會出現嚴重的鎖問題,大量的高併發MySQL應用開始使用InnoDB引擎代替MyISAM。c++
同時,開始流行使用分表分庫來緩解寫壓力和數據增加的擴展問題。這個時候,分表分庫成了一個熱門技術,是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候,MySQL推出了還不太穩定的表分區,這也給技術實力通常的公司帶來了但願。雖然MySQL推出了MySQL Cluster集羣,但性能也不能很好知足互聯網的要求,只是在高可靠性上提供了很是大的保證。git
MySQL數據庫也常常存儲一些大文本字段,致使數據庫表很是的大,在作數據庫恢復的時候就致使很是的慢,不容易快速恢復數據庫。好比1000萬4KB大小的文本就接近40GB的大小,若是能把這些數據從MySQL省去,MySQL將變得很是的小。關係數據庫很強大,可是它並不能很好的應付全部的應用場景。MySQL的擴展性差(須要複雜的技術來實現),大數據下IO壓力大,表結構更改困難,正是當前使用MySQL的開發人員面臨的問題。程序員
爲何使用NoSQL ?github
今天咱們能夠經過第三方平臺(如:Google,Facebook等)能夠很容易的訪問和抓取數據。用戶的我的信息,社交網絡,地理位置,用戶生成的數據和用戶操做日誌已經成倍的增長。咱們若是要對這些用戶數據進行挖掘,那SQL數據庫已經不適合這些應用了, NoSQL數據庫的發展也卻能很好的處理這些大的數據。web
NoSQL(NoSQL = Not Only SQL ),意即「不只僅是SQL」,
泛指非關係型的數據庫。隨着互聯網web2.0網站的興起,傳統的關係數據庫在應付web2.0網站,特別是超大規模和高併發的SNS類型的web2.0純動態網站已經顯得力不從心,暴露了不少難以克服的問題,而非關係型的數據庫則因爲其自己的特色獲得了很是迅速的發展。NoSQL數據庫的產生就是爲了解決大規模數據集合多重數據種類帶來的挑戰,尤爲是大數據應用難題,包括超大規模數據的存儲。
(例如谷歌或Facebook天天爲他們的用戶收集萬億比特的數據)。這些類型的數據存儲不須要固定的模式,無需多餘操做就能夠橫向擴展。
NoSQL數據庫種類繁多,可是一個共同的特色都是去掉關係數據庫的關係型特性。
數據之間無關係,這樣就很是容易擴展。也無形之間,在架構的層面上帶來了可擴展的能力。
NoSQL數據庫都具備很是高的讀寫性能,尤爲在大數據量下,一樣表現優秀。
這得益於它的無關係性,數據庫的結構簡單。
通常MySQL使用Query Cache,每次表的更新Cache就失效,是一種大粒度的Cache,
在針對web2.0的交互頻繁的應用,Cache性能不高。而NoSQL的Cache是記錄級的,
是一種細粒度的Cache,因此NoSQL在這個層面上來講就要性能高不少了
NoSQL無需事先爲要存儲的數據創建字段,隨時能夠存儲自定義的數據格式。而在關係數據庫裏,
增刪字段是一件很是麻煩的事情。若是是很是大數據量的表,增長字段簡直就是一個噩夢
RDBMS vs NoSQL
RDBMS
- 高度組織化結構化數據
- 結構化查詢語言(SQL)
- 數據和關係都存儲在單獨的表中。
- 數據操縱語言,數據定義語言
- 嚴格的一致性
- 基礎事務
NoSQL
- 表明着不只僅是SQL
- 沒有聲明性查詢語言
- 沒有預約義的模式
-鍵 - 值對存儲,列存儲,文檔存儲,圖形數據庫
- 最終一致性,而非ACID屬性
- 非結構化和不可預知的數據
- CAP定理
- 高性能,高可用性和可伸縮性
KV
Persistence
......
海量Volume
多樣Variety
實時Velocity
高併發
高可擴
高性能
關係型數據庫:mysql/oracle目前淘寶在去O化(也即拿掉Oracle),
注意,淘寶內部用的Mysql是裏面的大牛本身改造過的
2008年,王堅加盟阿里巴巴成爲集團首席架構師,即如今的首席技術官。這位前微軟亞洲研究院常務副院長被馬雲定位爲:將幫助阿里巴巴集團創建世界級的技術團隊,並負責集團技術架構以及基礎技術平臺搭建。
在加入阿里後,帶着技術基因和學者風範的王堅就在阿里巴巴集團提出了被稱爲「去IOE」(在IT建設過程當中,去除IBM小型機、Oracle數據庫及EMC存儲設備)的想法,並開始把雲計算的本質,植入阿里IT基因。
王堅這樣歸納「去IOE」運動和阿里雲之間的關係:「去IOE」完全改變了阿里集團IT架構的基礎,是阿里擁抱雲計算,產出計算服務的基礎。「去IOE」的本質是分佈化,讓隨處能夠買到的Commodity PC架構成爲可能,使雲計算可以落地的首要條件。
多文字信息描述類,IO讀寫性能變差
文檔數據庫MongDB中
淘寶本身的TFS
Google的GFS
Hadoop的HDFS
搜索引擎,淘寶內用
ISearch
內存數據庫
tair、Redis、Memcache
外部系統,外部第3方支付接口
支付寶
數據類型多樣性
數據源多樣性和變化重構
數據源改造而數據服務平臺不須要大面積重構
給學生畫圖介紹EAI和統一數據平臺服務層
是什麼
什麼樣
映射
API
熱點緩存
......
ER圖(1:1/1:N/N:N,主外鍵等常見)
什麼是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"}}], } ] } }
高併發的操做是不太建議有關聯查詢的,
互聯網公司用冗餘數據來避免關聯查詢
分佈式事務是支持不了太多的併發的
KV鍵值
bson
列族
顧名思義,是按列存儲數據的。最大的特色是方便存儲結構化和半結構化數據,方便作數據壓縮,
對針對某一列或者某幾列的查詢有很是大的IO優點。
圖形
新浪:BerkeleyDB+redis
美團:redis+tair
阿里、百度:memcache+redis
CouchDB
MongoDB
MongoDB 是一個基於分佈式文件存儲的數據庫。由 C++ 語言編寫。旨在爲 WEB 應用提供可擴展的高性能數據存儲解決方案。
MongoDB 是一個介於關係數據庫和非關係數據庫之間的產品,是非關係數據庫當中功能最豐富,最像關係數據庫的。
Cassandra, HBase
分佈式文件系統
社交網絡,推薦系統等。專一於構建關係圖譜
Neo4J, InfoGrid
A (Atomicity) 原子性
C (Consistency) 一致性
I (Isolation) 獨立性
D (Durability) 持久性
C:Consistency(強一致性)
A:Availability(可用性)
P:Partition tolerance(分區容錯性)
CAP理論就是說在分佈式存儲系統中,最多隻能實現上面的兩點。 而因爲當前的網絡硬件確定會出現延遲丟包等問題,因此 分區容忍性是咱們必須須要實現的。 因此咱們只能在一致性和可用性之間進行權衡,沒有NoSQL系統能同時保證這三點。 ======================================================================================================================= C:強一致性 A:高可用性 P:分佈式容忍性 CA 傳統Oracle數據庫 AP 大多數網站架構的選擇 CP Redis、Mongodb 注意:分佈式架構的時候必須作出取捨。 一致性和可用性之間取一個平衡。多餘大多數web應用,其實並不須要強一致性。 所以犧牲C換取P,這是目前分佈式數據庫產品的方向 ======================================================================================================================= 一致性與可用性的決擇 對於web2.0網站來講,關係數據庫的不少主要特性卻每每無用武之地 數據庫事務一致性需求 不少web實時系統並不要求嚴格的數據庫事務,對讀一致性的要求很低, 有些場合對寫一致性要求並不高。容許實現最終一致性。 數據庫的寫實時性和讀實時性需求 對關係數據庫來講,插入一條數據以後馬上查詢,是確定能夠讀出來這條數據的,可是對於不少web應用來講,並不要求這麼高的實時性,比方說發一條消息之 後,過幾秒乃至十幾秒以後,個人訂閱者纔看到這條動態是徹底能夠接受的。 對複雜的SQL查詢,特別是多表關聯查詢的需求 任何大數據量的web系統,都很是忌諱多個大表的關聯查詢,以及複雜的數據分析類型的報表查詢,特別是SNS類型的網站,從需求以及產品設計角 度,就避免了這種狀況的產生。每每更多的只是單表的主鍵查詢,以及單表的簡單條件分頁查詢,SQL的功能被極大的弱化了。
CAP理論的核心是:一個分佈式系統不可能同時很好的知足一致性,可用性和分區容錯性這三個需求, 最多隻能同時較好的知足兩個。 所以,根據 CAP 原理將 NoSQL 數據庫分紅了知足 CA 原則、知足 CP 原則和知足 AP 原則三 大類: CA - 單點集羣,知足一致性,可用性的系統,一般在可擴展性上不太強大。 CP - 知足一致性,分區容忍必的系統,一般性能不是特別高。 AP - 知足可用性,分區容忍性的系統,一般可能對一致性要求低一些。
BASE就是爲了解決關係數據庫強一致性引發的問題而引發的可用性下降而提出的解決方案。
BASE實際上是下面三個術語的縮寫:
基本可用(Basically Available)
軟狀態(Soft state)
最終一致(Eventually consistent)
它的思想是經過讓系統放鬆對某一時刻數據一致性的要求來換取系統總體伸縮性和性能上改觀。爲何這麼說呢,原因就在於大型系統每每因爲地域分佈和極高性能的要求,不可能採用分佈式事務來完成這些指標,要想得到這些指標,咱們必須採用另一種方式來完成,這裏BASE就是解決這個問題的辦法
分佈式系統 分佈式系統(distributed system) 由多臺計算機和通訊的軟件組件經過計算機網絡鏈接(本地網絡或廣域網)組成。分佈式系統是創建在網絡之上的軟件系統。正是由於軟件的特性,因此分佈式系統具備高度的內聚性和透明性。所以,網絡和分佈式系統之間的區別更多的在於高層軟件(特別是操做系統),而不是硬件。分佈式系統能夠應用在在不一樣的平臺上如:Pc、工做站、局域網和廣域網上等。 簡單來說: 1分佈式:不一樣的多臺服務器上面部署不一樣的服務模塊(工程),他們之間經過Rpc/Rmi之間通訊和調用,對外提供服務和組內協做。 2集羣:不一樣的多臺服務器上面部署相同的服務模塊,經過分佈式調度軟件進行統一的調度,對外提供服務和訪問。
Redis:REmote DIctionary Server(遠程字典服務器)
是徹底開源免費的,用C語言編寫的,遵照BSD協議,
是一個高性能的(key/value)分佈式內存數據庫,基於內存運行
並支持持久化的NoSQL數據庫,是當前最熱門的NoSql數據庫之一,
也被人們稱爲數據結構服務器
Redis 與其餘 key - value 緩存產品有如下三個特色
Redis支持數據的持久化,能夠將內存中的數據保持在磁盤中,重啓的時候能夠再次加載進行使用
Redis不只僅支持簡單的key-value類型的數據,同時還提供list,set,zset,hash等數據結構的存儲
Redis支持數據的備份,即master-slave模式的數據備份
內存存儲和持久化:redis支持異步將內存中的數據寫到硬盤上,同時不影響繼續服務
取最新N個數據的操做,如:能夠將最新的10條評論的ID放在Redis的List集合裏面
模擬相似於HttpSession這種須要設定過時時間的功能
發佈、訂閱消息系統
定時器、計數器
數據類型、基本操做和配置
持久化和複製,RDB/AOF
事務的控制
複製
......
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"
個人筆記本cpu是64位的,操做系統也是64位的,問題應該如虛擬機右下角提示所說, 是「宿主機BIOS設置中的硬件虛擬化被禁用了。」 須要打開筆記本BIOS中的IVT對虛擬化的支持。 找到菜單「Security」–「System Security」, 將Virtualization Technology(VTx)和Virtualization Technology DirectedI/O(VTd)設置爲 Enabled。 保存並退出BIOS設置,重啓電腦,
上述環境都OK後開始進行Redis的服務器安裝配置
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
因爲企業裏面作Redis開發,99%都是Linux版的運用和安裝, 幾乎不會涉及到Windows版,上一步的講解只是爲了知識的完整性, Windows版不做爲重點,同窗能夠下去本身玩,企業實戰就認一個版: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
默認16個數據庫,相似數組下表從零開始,初始默認使用零號庫
設置數據庫的數量,默認數據庫爲0,能夠使用SELECT <dbid>命令在鏈接上指定數據庫id databases 16
String(字符串)
string是redis最基本的類型,你能夠理解成與Memcached如出一轍的類型,一個key對應一個value。
string類型是二進制安全的。意思是redis的string能夠包含任何數據。好比jpg圖片或者序列化的對象 。
string類型是Redis最基本的數據類型,一個redis中字符串value最多能夠是512M
Hash(哈希) Redis hash 是一個鍵值對集合。 Redis hash是一個string類型的field和value的映射表,hash特別適合用於存儲對象。 相似Java裏面的Map<String,Object>
List(列表)
Redis 列表是簡單的字符串列表,按照插入順序排序。你能夠添加一個元素導列表的頭部(左邊)或者尾部(右邊)。
它的底層實際是個鏈表
Set(集合)
Redis的Set是string類型的無序集合。它是經過HashTable實現實現的,
zset(sorted set:有序集合) Redis zset 和 set 同樣也是string類型元素的集合,且不容許重複的成員。 不一樣的是每一個元素都會關聯一個double類型的分數。 redis正是經過分數來爲集合中的成員進行從小到大的排序。zset的成員是惟一的,但分數(score)卻能夠重複。
keys *
exists key的名字,判斷某個key是否存在
move key db --->當前庫就沒有了,被移除了
expire key 秒鐘:爲給定的key設置過時時間
ttl key 查看還有多少秒過時,-1表示永不過時,-2表示已過時
type key 查看你的key是什麼類型
單值單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
單值多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均可以插入添加;
若是鍵不存在,建立新的鏈表;
若是鍵已存在,新增內容;
若是值全移除,對應的鍵也就消失了。
鏈表的操做不管是頭和尾效率都極高,但假如是對中間元素進行操做,效率就很慘淡了。
單值多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
KV模式不變,但V是一個鍵值對
hlen
hexists key 在key裏面的某個值的key
hkeys/hvals
hincrby/hincrbyfloat
hsetnx
不存在賦值,存在了無效。
在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 分數是反着來的
地址
爲何我將它拷貝出來單獨執行?
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
Save
stop-writes-on-bgsave-error
若是配置成no,表示你不在意數據不一致或者有其餘的手段發現和控制
rdbcompression
rdbcompression:對於存儲到磁盤中的快照,能夠設置是否進行壓縮存儲。若是是的話,redis會採用
LZF算法進行壓縮。若是你不想消耗CPU來進行壓縮的話,能夠設置爲關閉此功能
rdbchecksum
rdbchecksum:在存儲快照後,還可讓redis使用CRC64算法來進行數據校驗,可是這樣作會增長大約 10%的性能消耗,若是但願獲取到最大的性能提高,能夠關閉此功能
dbfilename
dir
訪問密碼的查看、設置和取消
查看:
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
(1)volatile-lru:使用LRU算法移除key,只對設置了過時時間的鍵 (2)allkeys-lru:使用LRU算法移除key (3)volatile-random:在過時集合中移除隨機的key,只對設置了過時時間的鍵 (4)allkeys-random:移除隨機的key (5)volatile-ttl:移除那些TTL值最小的key,即那些最近要過時的key (6)noeviction:不進行移除。針對寫操做,只是返回錯誤信息
maxmemory-samples
設置樣本數量,LRU算法和最小TTL算法都並不是是精確的算法,而是估算值,因此你能夠設置樣本的大小,
redis默認會檢查這麼多個key並選擇其中LRU的那個
appendonly
appendfilename
appendfsync
always:同步持久化 每次發生數據變動會被當即記錄到磁盤 性能較差但數據完整性比較好
everysec:出廠默認推薦,異步操做,每秒記錄 若是一秒內宕機,有數據丟失
no
no-appendfsync-on-rewrite:重寫時是否能夠運用Appendfsync,用默認no便可,保證數據安全性。
auto-aof-rewrite-min-size:設置重寫的基準值
auto-aof-rewrite-percentage:設置重寫的基準值
參數說明 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
在指定的時間間隔內將內存中的數據集快照寫入磁盤,
也就是行話講的Snapshot快照,它恢復時是將快照文件直接讀到內存裏
Redis會單首創建(fork)一個子進程來進行持久化,會先將數據寫入到
一個臨時文件中,待持久化過程都結束了,再用這個臨時文件替換上次持久化好的文件。
整個過程當中,主進程是不進行任何IO操做的,這就確保了極高的性能
若是須要進行大規模數據的恢復,且對於數據恢復的完整性不是很是敏感,那RDB方
式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的數據可能丟失。
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 ""
小總結
以日誌的形式來記錄每一個寫操做,將Redis執行過的全部寫指令記錄下來(讀操做不記錄),
只許追加文件但不能夠改寫文件,redis啓動之初會讀取該文件從新構建數據,換言之,redis
重啓的話就根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工做
正常恢復
啓動:設置Yes異常恢復
修改默認的appendonly no,改成yes
將有數據的aof文件複製一份保存到對應目錄(config get dir)
恢復:重啓redis而後從新加載
異常恢復
備份被寫壞的AOF文件
修復:redis-check-aof --fix進行修復
恢復:重啓redis而後從新加載
是什麼:
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相同
能夠一次執行多個命令,本質是一組命令的集合。一個事務中的
全部命令都會序列化,按順序地串行化執行而不會被其它命令插入,不準加塞
一個隊列中,一次性、順序性、排他性的執行一系列命令
悲觀鎖(Pessimistic Lock), 顧名思義,就是很悲觀,每次去拿數據的時候都認爲別人會修改,
因此每次在拿數據的時候都會上鎖,這樣別人想拿這個數據就會block直到它拿到鎖。
傳統的關係型數據庫裏邊就用到了不少這種鎖機制,
好比行鎖,表鎖等,讀鎖,寫鎖等,都是在作操做以前先上鎖
樂觀鎖(Optimistic Lock), 顧名思義,就是很樂觀,每次去拿數據的時候都認爲別人不會修改,因此不會上鎖,可是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據,能夠使用版本號等機制。樂觀鎖適用於多讀的應用類型,這樣能夠提升吞吐量,
樂觀鎖策略:提交版本必須大於記錄當前版本才能執行更新
無加塞篡改:
先監控再開啓multi,
保證兩筆金額變更在同一個事務內
有加塞篡改:
監控了key,若是key被修改了,後面一個事務的執行失效
unwatch:
一旦執行了exec以前加的監控鎖都會被取消掉了
小結:
Watch指令,相似樂觀鎖,事務提交時,若是Key的值已被別的客戶端改變, 好比某個list已被別的客戶端push/pop過了,整個事務隊列都不會被執行 經過WATCH命令在事務執行以前監控了多個Keys,假若在WATCH以後有任何Key的值發生了變化, EXEC命令執行的事務都將被放棄,同時返回Nullmulti-bulk應答以通知調用者事務執行失敗
開啓:以MULTI開始一個事務
入隊:將多個命令入隊到事務中,接到這些命令並不會當即執行,而是放到等待執行的事務隊列裏面
執行:由EXEC命令觸發事務
單獨的隔離操做:事務中的全部命令都會序列化、按順序地執行。事務在執行的過程當中,不會被其餘客戶端發送來的命令請求所打斷。
沒有隔離級別的概念:隊列中的命令沒有提交以前都不會實際的被執行,由於事務提交前任何指令都不會被實際執行,
也就不存在」事務內的查詢要看到事務裏的更新,在事務外查詢不能看到」這個讓人萬分頭痛的問題
不保證原子性:redis同一個事務中若是有一條命令執行失敗,其後的命令仍然會被執行,沒有回滾
進程間的一種消息通訊模式:發送者(pub)發送消息,訂閱者(sub)接收消息。
先訂閱後發佈後才能收到消息, 1 能夠一次性訂閱多個,SUBSCRIBE c1 c2 c3 2 消息發佈,PUBLISH c2 hello-redis =========================================================================================================== 3 訂閱多個,通配符*, PSUBSCRIBE new* 4 收取消息, PUBLISH new1 redis2015
行話:也就是咱們所說的主從複製,主機數據更新後根據配置和策略,
自動同步到備機的master/slaver機制,Master以寫爲主,Slave以讀爲主
讀寫分離
容災恢復
配從(庫)不配主(庫)
從庫配置:slaveof 主庫IP 主庫端口:
每次與master斷開以後,都須要從新鏈接,除非你配置進redis.conf文件
info replication
修改配置文件細節操做:
info replication
拷貝多個redis.conf文件
開啓daemonize yes
pid文件名字
指定端口
log文件名字
dump.rdb名字
一主二僕
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,一次徹底同步(全量複製)將被自動執行
反客爲主的自動版,可以後臺監控主機是否故障,若是故障了根據投票數自動將從庫轉換爲主庫
調整結構,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機器數量的增長也會使這個問題更加嚴重。
tar -zxvf jdk-7u67-linux-i586.tar.gz vi /etc/profile 重啓一次Centos 編碼驗證
commons-pool-1.6.jar jedis-2.1.0.jar
前提是你已經把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); } }
主寫
從讀
獲取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); } } }
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); } } }
jedisPool.getResource();
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
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 來源:簡書 簡書著做權歸做者全部,任何形式的轉載都請聯繫做者得到受權並註明出處。