Redis入門--進階詳解

時間  2020-08-27
標籤 redis 入門 進階 詳解 欄目 Redis 简体版
原文   原文鏈接

Redis

NoSql入門和概述

入門概述

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

1.單機MySQL的美好年代
  • 在90年代，一個網站的訪問量通常都不大，用單個數據庫徹底能夠輕鬆應付,在那個時候，更多的都是靜態網頁，動態交互類型的網站很少
  • image-20200819133746031
  • 上述架構下，咱們來看看數據存儲的瓶頸是什麼？
    1. 數據量的總大小 一個機器放不下時
    2. 數據的索引（B+ Tree）一個機器的內存放不下時
    3. 訪問量(讀寫混合)一個實例不能承受
2.Memcached(緩存)＋MySQL＋垂直拆分
  • 後來，隨着訪問量的上升，幾乎大部分使用MySQL架構的網站在數據庫上都開始出現了性能問題，web程序再也不僅僅專一在功能上，同時也在追求性能。程序員們開始大量的使用緩存技術來緩解數據庫的壓力，優化數據庫的結構和索引。開始比較流行的是經過文件緩存來緩解數據庫壓力，可是當訪問量繼續增大的時候，多臺web機器經過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就天然的成爲一個很是時尚的技術產品
  • image-20200819135316004
  • Memcached做爲一個獨立的分佈式的緩存服務器，爲多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上，又發展了根據hash算法來進行多臺Memcached緩存服務的擴展，而後又出現了一致性hash來解決增長或減小緩存服務器致使從新hash帶來的大量緩存失效的弊端
3.MySQL主從讀寫分離
  • 因爲數據庫的寫入壓力增長，Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從複製技術來達到讀寫分離，以提升讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成爲這個時候的網站標配了
  • image-20200819140121843
4.分表分庫＋水平拆分＋mysql集羣

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

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

  • image-20200819141000786

5.MySQL的擴展性瓶頸
  • MySQL數據庫也常常存儲一些大文本字段，致使數據庫表很是的大，在作數據庫恢復的時候就致使很是的慢，不容易快速恢復數據庫。好比1000萬4KB大小的文本就接近40GB的大小，若是能把這些數據從MySQL省去，MySQL將變得很是的小。關係數據庫很強大，可是它並不能很好的應付全部的應用場景。MySQL的擴展性差（須要複雜的技術來實現），大數據下IO壓力大，表結構更改困難，正是當前使用MySQL的開發人員面臨的問題
6.今天系統是什麼樣子
  • image-20200819141451036
7.爲何要用NoSQL
  • 今天咱們能夠經過第三方平臺（如：Google,Facebook等）能夠很容易的訪問和抓取數據。用戶的我的信息，社交網絡，地理位置，用戶生成的數據和用戶操做日誌已經成倍的增長。咱們若是要對這些用戶數據進行挖掘，那SQL數據庫已經不適合這些應用了, NoSQL數據庫的發展也卻能很好的處理這些大的數據
  • image-20200819141649524

是什麼

  • NoSQL(NoSQL = Not Only SQL )，意即「不只僅是SQL」mysql

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

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

能幹嗎

易擴展
  • NoSQL數據庫種類繁多，可是一個共同的特色都是去掉關係數據庫的關係型特徵。數據之間無關係，這樣就很是容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力
大數據量高性能
  • NoSQL數據庫都具備很是高的讀寫性能，尤爲在大數據量下，一樣表現優秀，這得益於它的無關係性，數據庫的結構簡單
  • 通常MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，
    在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，
    是一種細粒度的Cache，因此NoSQL在這個層面上來講就要性能高不少
多樣靈活的數據模型
  • NoSQL無需事先爲要存儲的數據創建字段，隨時能夠存儲自定義的數據格式。而在關係數據庫裏，
    增刪字段是一件很是麻煩的事情。若是是很是大數據量的表，增長字段簡直就是一個噩夢
傳統RDBMS VS NOSQL

  • RDBMS vs NoSQLgithub

  • RDBMS NoSQL
    高度組織化結構化數據 表明着不只僅是SQL
    結構化查詢語言（SQL） 沒有聲明性查詢語言
    數據和關係都存儲在單獨的表中 沒有預約義的模式
    數據操縱語言，數據定義語言 鍵 - 值對存儲，列存儲，文檔存儲，圖形數據庫
    嚴格的一致性 最終一致性，而非ACID屬性
    基礎事務 非結構化和不可預知的數據
    CAP定理
    高性能，高可用性和可伸縮性

去哪裏下

  • Redis
  • Memcache
  • Mongdb

怎麼玩

  • KV
  • Cache
  • Persistence
  • ......

3V＋3高

大數據時代的3V

  • 海量Volume
  • 多樣Variety
  • 實時Velocity

互聯網需求的3高

  • 高併發
  • 高可擴
  • 高性能

當下的NoSQL經典應用

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

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

  • 和咱們相關的，多數據源多數據類型的存儲問題image-20200819170618027
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方支付接口
  • 支付寶
7.總結大型互聯網應用(大數據、高併發、多樣數據類型)的難點和解決方案
  • 難點
    • 數據類型多樣性
    • 數據源多樣性和變化重構
    • 數據源改造而數據服務平臺不須要大面積重構
  • 解決辦法
    • EAI和統一數據平臺服務
    • 阿里、淘寶：UDSL
      • 是什麼image-20200820090726321
      • 什麼樣image-20200820091124556
        1. 映射
        2. API
        3. 熱點緩存
        4. ......

NoSQL數據模型簡介

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

傳統的關係型數據庫你如何設計？
  • ER圖(1:1/1:N/N:N,主外鍵等常見)image-20200820095922687
NoSQL你如何設計

  • 什麼是BSON：BSON（）是一種類json的一種二進制形式的存儲格式，簡稱Binary JSON，它和JSON同樣，支持內嵌的文檔對象和數組對象web

  • 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"}}],
      }
    ]
  }
}
二者對比，問題和難點
  • 爲何上述的狀況能夠用聚合模型來處理
    • 高併發的操做是不太建議有關聯查詢的，互聯網公司用冗餘數據來避免關聯查詢
    • 分佈式事務是支持不了太多的併發的
  • 啓發學生，想一想關係模型數據庫你如何查？若是按照咱們新設計的BSon，是否是查詢起來很可愛

聚合模型

  • KV鍵值對
  • BSON
  • 列族
    • 顧名思義，是按列存儲數據的。最大的特色是方便存儲結構化和半結構化數據，方便作數據壓縮，對針對某一列或者某幾列的查詢有很是大的IO優點image-20200820104717957
  • 圖形image-20200820104751889

NoSQL數據庫的四大分類

KV鍵值：典型介紹

  • 新浪：BerkeleyDB+redis
  • 美團：redis＋tair
  • 阿里、百度：memcache+redis

文檔型數據庫（bson格式比較多）：典型介紹

  • CouchDB
  • MongoDB
    • MongoDB 是一個基於分佈式文件存儲的數據庫。由 C++ 語言編寫。旨在爲 WEB 應用提供可擴展的高性能數據存儲解決方案
    • MongoDB 是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係數據庫的

列存儲數據庫

  • Cassandra、HBase
  • 分佈式文件系統

圖關係數據庫

  • 它不是放圖形的，放的是關係好比:朋友圈社交網絡、廣告推薦系統，社交網絡，推薦系統等。專一於構建關係圖譜
  • Neo4j,InfoGrid

四者對比

  • image-20200820111234007

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

傳統的ACID分別是什麼

  • A (Atomicity) 原子性
    原子性很容易理解，也就是說事務裏的全部操做要麼所有作完，要麼都不作，事務成功的條件是事務裏的全部操做都成功，只要有一個操做失敗，整個事務就失敗，須要回滾。好比銀行轉帳，從A帳戶轉100元至B帳戶，分爲兩個步驟：1）從A帳戶取100元；2）存入100元至B帳戶。這兩步要麼一塊兒完成，要麼一塊兒不完成，若是隻完成第一步，第二步失敗，錢會莫名其妙少了100元。
  • C (Consistency) 一致性
    一致性也比較容易理解，也就是說數據庫要一直處於一致的狀態，事務的運行不會改變數據庫本來的一致性約束。
  • I (Isolation) 獨立性
    所謂的獨立性是指併發的事務之間不會互相影響，若是一個事務要訪問的數據正在被另一個事務修改，只要另一個事務未提交，它所訪問的數據就不受未提交事務的影響。好比現有有個交易是從A帳戶轉100元至B帳戶，在這個交易還未完成的狀況下，若是此時B查詢本身的帳戶，是看不到新增長的100元的
  • D (Durability) 持久性
    持久性是指一旦事務提交後，它所作的修改將會永久的保存在數據庫上，即便出現宕機也不會丟失。

CAP

  • C:Consistency（強一致性）
  • A:Availability（可用性）
  • P:Partition tolerance（分區容錯性）

CAP的三選二

  • CAP理論就是說在分佈式存儲系統中，最多隻能實現上面的兩點。而因爲當前的網絡硬件確定會出現延遲丟包等問題，因此分區容忍性是咱們必須須要實現的。因此咱們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點redis

  • C:強一致性 、A：高可用性 、P：分佈式容忍性算法

    • CA 傳統Oracle數據庫

    • AP 大多數網站架構的選擇

    • CP Redis、Mongodb

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

經典CAP圖

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

BASE

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

  • BASE實際上是下面三個術語的縮寫：

    • 基本可用（Basically Available）
    • 軟狀態（Soft state）
    • 最終一致（Eventually consistent）

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

分佈式＋集羣簡介

  • 分佈式系統（distributed system

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

  • 簡單來說：

    1. 分佈式：不一樣的多臺服務器上面部署不一樣的服務模塊（工程），他們之間經過Rpc/Rmi之間通訊和調用，對外提供服務和組內協做

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

Redis入門介紹

入門概述

是什麼

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

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

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

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

能幹嗎

  • 內存存儲和持久化：redis支持異步將內存中的數據寫到硬盤上，同時不影響繼續服務
  • 取最新N個數據的操做，如：能夠將最新的10條評論的ID放在Redis的List集合裏面
  • 模擬相似於HttpSession這種須要設定過時時間的功能
  • 發佈、訂閱消息系統
  • 定時器、計數器

去哪下

怎麼玩

  • 數據類型、基本操做和配置
  • 持久化和複製，RDB/AOF
  • 事務的控制
  • 複製
  • ......

Redis的安裝

下載redis到/opt目錄

  • 第三方軟件習慣放置於/opt目錄下

執行make、make install命令

  • 注意gcc版本

  • 詳細操做參考：升級gcc

Redis啓動

  • 進入默認安裝目錄 /usr/local/bin
  • redis-server redis.conf(自定義的conf文件)
  • redis-cli -p 6379

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

單進程

  • 單進程模型來處理客戶端的請求。對讀寫等事件的響應是經過對epoll函數的包裝來作到的。Redis的實際處理速度徹底依靠主進程的執行效率
  • Epoll是Linux內核爲處理大批量文件描述符而做了改進的epoll，是Linux下多路複用IO接口select/poll的加強版本，它能顯著提升程序在大量併發鏈接中只有少許活躍的狀況下的系統CPU利用率

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

  • 設置數據庫的數量，默認數據庫爲0，可使用SELECT 命令在鏈接上指定數據庫id
    databases 16

Select命令切換數據庫

  • select 0

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

keys列出庫中全部的key

  • keys *
  • keys k？ 相似模糊查找

FlushDb：清空當前庫

FlushALL：通殺全部庫

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

Redis索引都是從零開始

爲何默認端口是6379

Redis數據類型

Redis的五大數據類型

String(字符串)

  • string是redis最基本的類型，你能夠理解成與Memcached如出一轍的類型，一個key對應一個value
  • string類型是二進制安全的。意思是redis的string能夠包含任何數據。好比jpg圖片或者序列化的對象
  • string類型是Redis最基本的數據類型，一個redis中字符串value最多能夠是512M

Hash（哈希，相似java裏的Map）

  • Redis hash 是一個鍵值對集合
  • Redis hash是一個string類型的field和value的映射表，hash特別適合用於存儲對象
  • 相似Java裏面的Map<String,Object>

List(列表)

  • Redis 列表是簡單的字符串列表，按照插入順序排序，你能夠添加一個元素到列表的頭部（左邊）或尾部
  • 它的底層實際是個鏈表

Set(集合)

  • Redis的Set是string類型的無序無重複集合。它是經過HashTable實現實現的
  • 注意：new HashSet 底層至關於new HashMap(詳情查看JDK源碼)

Zset(sorted set :有序集合)

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

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

redis命令參考大全

Redis鍵（key）

經常使用

  • image-20200820165303078

案例

  • keys *
  • exists key的名字，判斷某個key是否存在
  • move key db --->當前庫就沒有了，被移除了
  • expire key 秒鐘：爲給定的key設置過時時間
  • ttl key 查看還有多少秒過時，-1表示永不過時，-2表示已過時
  • type key 查看你的key是什麼類型

Redis字符串（String）

經常使用

  • image-20200820170745693
  • image-20200820170753026

單值單Value

案例

set/get/del/append/strlen
Incr/decr/incrby/decrby,必定要是數字才能進行加減
getrange/setrange
  • getrange:獲取指定區間範圍內的值，相似between......and的關係image-20200820171427145
  • setrange設置指定區間範圍內的值，格式是setrange key值 具體值image-20200820171437617
setex(set with expire)鍵秒值/setnx(set if not exist)
  • setex:設置帶過時時間的key，動態設置
  • setex 鍵 秒值 真實值
    • image-20200820171828050
  • setnx:只有在 key 不存在時設置 key 的值
    • image-20200820171915018
mset/mget/msetnx
  • mset:同時設置一個或多個 key-value 對image-20200820173029642
  • mget:獲取全部(一個或多個)給定 key 的值image-20200820173040024
  • msetnx:同時設置一個或多個 key-value 對，當且僅當全部給定 key 都不存在image-20200820173052240
getset(先get再set)
  • getset:將給定 key 的值設爲 value ，並返回 key 的舊值(old value),簡單一句話，先get而後當即setimage-20200820173346485

Redis列表（List)

經常使用

  • image-20200821092422433
  • image-20200821092433593

單值多Value

案例

lpush(列表頭部)/rpush(尾部)/lrange
lpop/rpop
  • image-20200821094109630
lindex，按照索引下標得到元素(從上到下)
llen
lrem key 刪N個value
  • 從left往right刪除2個值等於v1的元素，返回的值爲實際刪除的數量
  • LREM list3 0 值，表示刪除所有給定的值。零個就是所有值
ltrim key 開始index 結束index，截取指定範圍的值後再賦值給key
rpoplpush 源列表 目的列表
lset key index value
linsert key before/after 值1 值2
性能總結

  • 它是一個字符串鏈表，left、right均可以插入添加；若是鍵不存在，建立新的鏈表；若是鍵已存在，新增內容；若是值全移除，對應的鍵也就消失了。

  • 鏈表的操做不管是頭和尾效率都極高，但假如是對中間元素進行操做，效率就很慘淡了。

Redis集合（Set)

經常使用

  • image-20200821100807572

單值多Value

案例

sadd/smembers/sismember
  • image-20200821101118880
scard，獲取集合裏面的元素個數
  • image-20200821101210932
srem key value 刪除集合中元素
srandmember key 某個整數(隨機出幾個數)
spop key 隨機出棧
smove key1 key2 在key1裏某個值 做用是將key1裏的某個值賦給key2
數學集合類
  1. 差集：sdiff 在第一個set裏面而不在後面任何一個set裏面的項
  2. 交集：sinter
  3. 並集：sunion

Redis哈希（Hash)

經常使用

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

案例

hset/hget/hmset/hmget/hgetall/hdel(*)
  • image-20200821103636188
hlen
hexists key 在key裏面的某個值的key
hkeys/hvals
  • image-20200821103904313
hincrby/hincrbyfloat
  • image-20200821104104363
hsetnx
  • 不存在賦值，存在了無效

Redis有序集合Zset(sorted set)

經常使用

  • image-20200821104609766
  • image-20200821104617462

區別set

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

案例

zadd/zrange
  • image-20200821105020090
zrangebyscore key 開始score 結束score
  • withscores
  • ( 不包含
  • Limit 做用是返回限制 limit 開始下標步 多少步
  • image-20200821105407685
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
  • image-20200821110223102
zrevrangebyscore key 結束score 開始score
  • zrevrangebyscore zset1 90 60 withscores 分數是反着來的

解析配置文件redis.conf

Units單位

  • image-20200821112126413
  • 配置大小單位,開頭定義了一些基本的度量單位，只支持bytes，不支持bit
  • 對大小寫不敏感

INCLUDES包含

  • 能夠經過includes包含，redis.conf能夠做爲總閘，包含其餘

GENERAL通用

Daemonize 守護線程方式啓動

Pidfile

Port

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

  • debug (development/testing)
  • verbose
  • notice (production probably)
  • warning

Logfile

Syslog-enabled

Syslog-ident

Syslog-facility

Databases

SNAPSHOTTING快照(*)

Save

  • 格式： save 秒鐘 寫操做的次數

    • RDB是整個內存的壓縮過的Snapshot，RDB的數據結構，能夠配置複合的快照觸發條件，

    • 默認是1分鐘內改了1萬次，或5分鐘內改了10次，或15分鐘內改了1次

    • save 900 1

    • save 300 5

    • save 60 10000

  • 禁用

    • 若是想禁用RDB持久化的策略，只要不設置任何save指令，或者給save傳入一個空字符串參數也能夠
    • save 「 」

Stop-writes-on-bgsave-error

  • 若是保存出錯 中止寫操做的意思

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

rdbcompression

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

rdbchecksum

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

dbfilename

dir

  • 獲取目錄：config get dir

REPLICATION複製

SECURITY安全

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

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
    • LRU算法：leastest recently use 最近最少使用
    • Volatile-lru：使用LRU算法移除key，只對設置了過時時間的鍵
    • Allkeys-lru ：使用LRU算法移除key
    • Volatile-random ：在過時集合中移除隨機的key，只對設置了過時時間的鍵
    • Allkeys-random ：移除隨機的key
    • Volatile-ttl ：移除那些TTL值最小的key，即那些最近要過時的key
    • Noeviction ：不進行移除，針對寫操做，只是返回錯誤信息
  • Maxmemory-samples
    • 設置樣本數量，LRU算法和最小TTL算法都並不是是精確的算法，而是估算值，因此你能夠設置樣本的大小，redis默認會檢查這麼多個key並選擇其中LRU的那個

APPEND ONLY MODE追加(*)

appendonly

appendfilename

Appendfsync

  • image-20200825112928988

  • 三種策略

    • 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 命令在鏈接上指定數據庫id
      databases 16
    9. 指定在多長時間內，有多少次更新操做，就將數據同步到數據文件，能夠多個條件配合
      save
      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
    14. 當master服務設置了密碼保護時，slav服務鏈接master的密碼
      masterauth
    15. 設置Redis鏈接密碼，若是配置了鏈接密碼，客戶端在鏈接Redis時須要經過AUTH 命令提供密碼，默認關閉
      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
    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

Redis持久化(*)

整體介紹

官網

RDB（Redis DataBase）

是什麼

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

Fork

  • Fork的做用是複製一個與當前進程同樣的進程，新進程的多有數據（變量、環境變量、程序計數器等）數值都和原進程一致，可是是一個全新的進程，並做爲原進程的子進程

Rdb 保存的是dump.rdb文件

  • save 命令 迅速備份 快速生成rdb文件

配置文件的位置（參照解析配置文件的快照）

如何觸發RDB快照

配置文件默認的快照配置
  • 默認是1分鐘內改了1萬次，或5分鐘內改了10次，或15分鐘內改了1次
  • save 900 1
  • save 300 5
  • save 60 10000
命令save或者是bgsave
  • 均可以迅速 馬上生成dump.rdb文件
  • Save：save時只管保存，其它無論，所有阻塞
  • BGSAVE：Redis會在後臺異步進行快照操做，快照同時還能夠響應客戶端請求。能夠經過lastsave
    命令獲取最後一次成功執行快照的時間
執行flushall命令，也會產生dump.rdb文件，但裏面是空的，無心義

如何恢復

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

優點

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

劣勢

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

如何中止

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

小總結

  • image-20200824163646437

AOF（Append Only File）

官網

是什麼

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

AOF保存的是appendonly.aof文件

配置位置

  • image-20200824165305534

  • 看法析配置文件---APPEND ONLY MODE追加

AOF啓動/修復/恢復

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

  • 啓動：設置Yes,修改默認的appendonly no，改成yes

  • 備份被寫壞的AOF文件

  • 修復：Redis-check-aof --fix aof文件 進行修復

  • 恢復：重啓redis而後從新加載

Rewrite

是什麼

  • image-20200825145521166

  • 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相同

小總結

  • image-20200825150532205

總結(Which one)

官網建議

  • image-20200825150754530

比較：

  • RDB持久化方式可以在指定的時間間隔能對你的數據進行快照存儲

  • AOF持久化方式記錄每次對服務器寫的操做,當服務器重啓的時候會從新執行這些命令來恢復原始的數據,AOF命令以redis協議追加保存每次寫的操做到文件末尾，Redis還能對AOF文件進行後臺重寫,使得AOF文件的體積不至於過大

  • 只作緩存：若是你只但願你的數據在服務器運行的時候存在,你也能夠不使用任何持久化方式.

同時開啓兩種持久化方式

  • 在這種狀況下,當redis重啓的時候會優先載入AOF文件來恢復原始的數據,由於在一般狀況下AOF文件保存的數據集要比RDB文件保存的數據集要完整
  • RDB的數據不實時，同時使用二者時服務器重啓也只會找AOF文件。那要不要只使用AOF呢？做者建議不要，由於RDB更適合用於備份數據庫(AOF在不斷變化很差備份)，快速重啓，並且不會有AOF可能潛在的bug，留着做爲一個萬一的手段。

性能建議

  • 由於RDB文件只用做後備用途，建議只在Slave上持久化RDB文件，並且只要15分鐘備份一次就夠了，只保留save 900 1這條規則。
  • 若是Enalbe AOF，好處是在最惡劣狀況下也只會丟失不超過兩秒數據，啓動腳本較簡單隻load本身的AOF文件就能夠了。代價一是帶來了持續的IO，二是AOF rewrite的最後將rewrite過程當中產生的新數據寫到新文件形成的阻塞幾乎是不可避免的。只要硬盤許可，應該儘可能減小AOF rewrite的頻率，AOF重寫的基礎大小默認值64M過小了，能夠設到5G以上。默認超過原大小100%大小時重寫能夠改到適當的數值。
  • 若是不Enable AOF ，僅靠Master-Slave Replication 實現高可用性也能夠。能省掉一大筆IO也減小了rewrite時帶來的系統波動。代價是若是Master/Slave同時倒掉，會丟失十幾分鐘的數據，啓動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個。新浪微博就選用了這種架構

Redis的事務

是什麼

官網

概述

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

能幹嗎

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

怎麼玩

  • image-20200825152828326

經常使用命令

  • image-20200825154559232

Case1：正常執行

  • image-20200825160149485

Case2：放棄事務

  • image-20200825160247490

Case3：全體連坐

  • image-20200825160548308

Case4：冤頭債主

  • 即便錯了，可是加入進隊列了queued ，而不是像case3在運行時直接報錯並無加入隊列

  • image-20200825161143350

Case5：watch監控

悲觀鎖/樂觀鎖/CAS(Check And Set)
  • 悲觀鎖
    • 悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿數據的時候都認爲別人會修改，因此每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關係型數據庫裏邊就用到了不少這種鎖機制，好比行鎖，表鎖等，讀鎖，寫鎖等，都是在作操做以前先上鎖
  • 樂觀鎖
    • 樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿數據的時候都認爲別人不會修改，因此不會上鎖，可是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可使用版本號等機制。樂觀鎖適用於多讀的應用類型，這樣能夠提升吞吐量
    • 樂觀鎖策略:提交版本必須大於記錄當前版本才能執行更新
  • CAS
初始化信用卡可用餘額和欠額
  • image-20200825163006942
無加塞篡改，先監控再開啓multi，保證兩筆金額變更在同一個事務內
  • image-20200825163528898
有加塞篡改
  • 監控了key，若是key被修改了，後面一個事務的執行失效
  • image-20200825164416433
unwatch

  • 取消監控

  • image-20200825164449923

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

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

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

3階段

開啓

  • 以MULTI開始一個事務

入隊

  • 將多個命令入隊到事務中，接到這些命令並不會當即執行，而是放到等待執行的事務隊列裏面

執行

  • 執行：由EXEC命令觸發事務

3特性

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

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

  • 不保證原子性：redis同一個事務中若是有一條命令執行失敗，其後的命令仍然會被執行，沒有回滾---部分支持事務

Redis的發佈和訂閱

是什麼

概述

  • 進程間的一種消息通訊模式：發送者(pub)發送消息，訂閱者(sub)接收消息

訂閱/發佈消息圖

  • image-20200825170025577

命令

  • image-20200825171423258

案例

先訂閱後發佈後才能收到消息

操做

1.1.能夠一次性訂閱多個，SUBSCRIBE c1 c2 c3
1.2 消息發佈，PUBLISH c2 hello-redis
2.1 訂閱多個，通配符， PSUBSCRIBE new
2.2 收取消息， PUBLISH new1 redis2015

image-20200825172439405

Redis的複製(Master/Slave)

是什麼

官網

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

能幹嗎

讀寫分離

容災恢復

怎麼玩

1.配從(庫)不配主(庫)

2.從庫配置：slaveof 主庫IP 主庫端口

  • 每次與master斷開以後，都須要從新鏈接，除非你配置進redis.conf文件
  • Info replication

3.修改配置文件細節操做

3.1 拷貝多個redis.conf文件
  • image-20200826091338977
3.2 開啓daemonize yes
  • image-20200826091353854
3.3 Pid文件名字
3.4 指定端口
3.5 Log文件名字
  • image-20200826091407130
3.6 Dump.rdb名字
  • image-20200826091437126

4.經常使用3招

一主二僕

  • Init

    • info replication 查看信息

    • image-20200826093819448

  • 一個Master兩個Slave

    • image-20200826102020559

  • 日誌查看

    • 主機日誌image-20200826102345554
    • 從機日誌image-20200826102358780
    • info replicationimage-20200826102406629

  • 主從問題演示

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

      答：切入點複製，不須要從頭複製

    • 2.從機是否能夠寫？set能否？

      答：從機只讀，不可set

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

      答：原地待命，不上位

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

      答：能夠順利複製

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

      答：恢復後，會取消以前的主從設置，變爲master。 從新slaveof便可

薪火相傳

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

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

  • Slaveof 新主庫IP 新主庫端口

反客爲主
  • SLAVEOF no one
    • 使當前數據庫中止與其餘數據庫的同步，轉成主數據庫

複製原理

複製流程
  1. Slave啓動成功鏈接到master後會發送一個sync命令
  2. Master接到命令啓動後臺的存盤進程，同時收集全部接收到的用於修改數據集命令，在後臺進程執行完畢以後，master將傳送整個數據文件到slave,以完成一次徹底同步
  3. 全量複製：而slave服務在接收到數據庫文件數據後，將其存盤並加載到內存中
  4. 增量複製：Master繼續將新的全部收集到的修改命令依次傳給slave,完成同步
  5. 可是隻要是從新鏈接master,一次徹底同步（全量複製)將被自動執行

哨兵模式(Sentinel)

是什麼

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

使用步驟

1.調整結構，6379帶着80、81
2.新建sentinel.conf文件，名字毫不能錯
3.配置哨兵,填寫內容
  • sentinel monitor 被監控數據庫名字(本身起名字) 127.0.0.1 6379 1image-20200826114111819
  • 上面最後一個數字1，表示主機掛掉後salve投票看讓誰接替成爲主機，得票數多少後成爲主機
4.啓動哨兵

  • Redis-sentinel /opt/redis-6.0.6/sentinel.conf

  • image-20200826131456634

5.正常主從演示
6.原有的master掛了
7.投票新選
  • 哨兵監控到原有的主節點失效，自動投票選舉新主節點image-20200826131717334
8.從新主從繼續開工,info replication查看
  • image-20200826131754157
9.問題：若是以前的master重啓回來，會不會雙master衝突？
  • 不會
  • 保持新選舉的master，原先宕機的master，會變成新master的子節點
  • image-20200826131904566

一組sentinel能同時監控多個Master

複製的缺點

複製延時

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

Redis的Java客戶端Jedis

Jedis官網

基礎用法

高級用法

Jedis經常使用API

測試連通性

  • image-20200826134620655

5+1

一個key
五大數據類型
  • image-20200826134659501
  • image-20200826134718606
  • image-20200826134800726

事務提交

平常
  • image-20200826135550088
加鎖

  • 通俗點講，watch命令就是標記一個鍵，若是標記了一個鍵， 在提交事務前若是該鍵被別人修改過，那事務就會失敗，這種狀況一般能夠在程序中從新再嘗試一次

    • 首先標記了鍵balance，而後檢查餘額是否足夠，不足就取消標記，並不作扣減； 足夠的話，就啓動事務進行更新操做
    • 若是在此期間鍵balance被其它人修改， 那在提交事務（執行exec）時就會報錯， 程序中一般能夠捕獲這類錯誤再從新執行一次，直到成功

  • image-20200826135626627

主從複製

  1. 6379,6380啓動，先各自先獨立

  2. 主寫

  3. 從讀

  4. image-20200826135752167

JedisPool

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

用完Jedis實例須要返還給JedisPool

若是Jedis在使用過程當中出錯，則也須要還給JedisPool

案例

JedisPoolUtil
  • image-20200826141642380
JedisPool.getResource()
  • image-20200826141553090

配置總結all

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

  1. maxActive：控制一個pool可分配多少個jedis實例，經過pool.getResource()來獲取；若是賦值爲-1，則表示不限制；若是pool已經分配了maxActive個jedis實例，則此時pool的狀態爲exhausted

  2. maxIdle：控制一個pool最多有多少個狀態爲idle(空閒)的jedis實例

  3. whenExhaustedAction：表示當pool中的jedis實例都被allocated完時，pool要採起的操做；

    默認有三種：

    • WHEN_EXHAUSTED_FAIL：表示無jedis實例時，直接拋出NoSuchElementException
    • WHEN_EXHAUSTED_BLOC：則表示阻塞住，或者達到maxWait時拋出JedisConnectionException；
    • WHEN_EXHAUSTED_GROW：則表示新建一個jedis實例，也就說設置的maxActive無用；

  4. maxWait：表示當borrow一個jedis實例時，最大的等待時間，若是超過等待時間，則直接拋JedisConnectionException；

  5. testOnBorrow：得到一個jedis實例的時候是否檢查鏈接可用性（ping()）；若是爲true，則獲得的jedis實例均是可用的；

  6. testOnReturn：return 一個jedis實例給pool時，是否檢查鏈接可用性（ping()）

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

  8. timeBetweenEvictionRunsMillis：表示idle object evitor兩次掃描之間要sleep的毫秒數；

  9. numTestsPerEvictionRun：表示idle object evitor每次掃描的最多的對象數；

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

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

  12. lifo：borrowObject返回對象時，是採用DEFAULT_LIFO（last in first out，即相似cache的最頻繁使用隊列），若是爲False，則表示FIFO隊列；

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

Redis集羣(簡略)

是什麼

  • Redis集羣實現了對Redis的水平擴容，即啓動N個redis節點，將整個數據庫分佈存儲在這N個節點中，每一個節點存儲總數據的1/N
  • Redis集羣經過分區(partition)來提供必定程度的可用性(availability):即便集羣中有一部分節點失效或者沒法進行通信，集羣也能夠繼續處理命令請求

集羣配置

redis cluster配置修改

  • cluster-enabled yes 打開集羣模式
  • cluster-config-file node-6379.conf 設定節點配置文件名
  • cluster-node-timeout 15000 設定節點失聯時間，超過該時間（毫秒），集羣自動進行主從切換

整合redis實例

  • cd /opt/redis-6.0.6/src
  • ./redis-trib.rb create --replicas 1 xxx:6379 xxx:6380 xxx:6381

集羣分配規則

  • 一個集羣至少要有三個節點
  • 選項 --replicas 1 表示咱們但願爲集羣中的每一個主節點建立一個從節點
  • 分配原則儘可能保證每一個主數據庫運行在不一樣的IP地址，每一個從庫和主庫再也不一個IP地址上

什麼是slots

  • 一個Redis集羣包含16384個插槽（hash slot），數據庫中每一個鍵都屬於這16384個插槽的其中一個，集羣使用公式CRC16(key) % 16384 來計算鍵key屬於哪一個槽，其中CRC16(key)用於計算鍵key的CRC16校驗和

  • 集羣中的每一個節點負責處理一部分插槽，舉個例子，若是一個集羣能夠有主節點，其中：

    • 節點A負責處理0至5500號插槽
    • 節點B負責處理5501號至11000號插槽
    • 節點C負責處理11001號至16383號插槽

集羣經常使用指令

  • 集羣模式下啓動客戶端： redis-cli -c -p 6379
  • 查看集羣信息 ：cluster nodes
  • 計算鍵key應該被放置在哪一個槽上： CLUSTER KEYSLOT
  • 返回槽slot目前包含的鍵值對數量：CLUSTER COUNTKEYSINSLOT
  • 返回count個slot槽中的鍵：CLUSTER GETKEYSINSLOT
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程