精华内容
下载资源
问答
  • redis知识架构

    2019-11-05 19:37:38
  • ​ 之前几讲都是在铺垫各种redis replication的原理和知识,包括主从复制、读写分离,但我们怎么去使用,怎么去搭建主从复制、读写分离的环境呢? ​ 一主一从,往主节点去写,在从节点去读,可以读到,主从架构就...
    接上节文章,本节主要讲解在项目中,如何部署redis replication的读写分离架构
    

    4.5. 在项目中部署redis replication的读写分离架构

    ​ 之前几讲都是在铺垫各种redis replication的原理和知识,包括主从复制、读写分离,但我们怎么去使用,怎么去搭建主从复制、读写分离的环境呢?

    ​ 一主一从,往主节点去写,在从节点去读,可以读到,主从架构就搭建成功了。

    4.5.1.启用复制,部署slave node

    配置主从复制,redis 默认就是主库,只需要配置从库。配置方法:
    

    1.修改配置文件(永久生效,但需要重起服务才能生效)

    在redis.conf(根据上文redis安装部署,配置文件是redis_6379)配置文件中配置主master的ip:post, 即可完成主从复制的目的。

    slaveof 192.168.92.120 6379
    

    2.命令行配置:(马上生效,不需要重启服务,一旦重起服务失效)也可以使用slaveof命令

    命令行设置,设置从库:

    192.168.92.120 :6379> slaveof  192.168.4.51 6351 	
    

    4.5.2.强制读写分离

    基于主从复制架构,实现读写分离

    redis slave node只读,默认开启,slave-read-only

    在这里插入图片描述

    开启了只读的redis slave node,会拒绝所有的写操作,这样可以强制搭建成读写分离的架构

    4.5.3.集群安全认证

    master上启用安全认证:requirepass

     requirepass foobared
    

    slave的配置文件中配置master连接认证:masterauth

    masterauth futurecloud
    

    如下redis.conf slaveof 配置:

    slaveof 192.168.92.120 6379
    
    # If the master is password protected (using the "requirepass" configuration
    # directive below) it is possible to tell the slave to authenticate before
    # starting the replication synchronization process, otherwise the master will
    # refuse the slave request.
    #
    masterauth futurecloud
    

    4.5.4.读写分离架构的测试

    先启动主节点,cache01上的redis实例
    再启动从节点,cache02上的redis实例

    刚才我调试了一下,redis slave node一直说没法连接到主节点的6379的端口

    在搭建生产环境的集群的时候,不要忘记修改一个配置,bind

    bind 127.0.0.1 -> 本地开发调试模式,就只能127.0.0.1本地才能访问到6379的端口
    

    每个redis.conf中的bind .

    bind 127.0.0.1 -> bind自己的ip地址
    

    在每个节点上都打开6379端口

    iptables -A INPUT -ptcp --dport  6379 -j ACCEPT
    
    redis-cli -h ipaddr
    info replication
    

    在主上写,在从上读,如下,配置好cache02作为redis 的slave后,启动cache02上的redis,cache01上的redis作为master,自动将数据复制到cache02上:

    [root@cache02 redis-4.0.1]# redis-cli -a futurecloud shutdown
    [root@cache02 redis-4.0.1]# service redis start
    Starting Redis server...
    [root@cache02 redis-4.0.1]# 7720:C 24 Apr 23:02:11.953 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
    7720:C 24 Apr 23:02:11.953 # Redis version=4.0.1, bits=64, commit=00000000, modified=0, pid=7720, just started
    7720:C 24 Apr 23:02:11.953 # Configuration loaded
    
    [root@cache02 redis-4.0.1]# 
    [root@cache02 redis-4.0.1]# ps -ef|grep redis
    root       7721      1  0 23:02 ?        00:00:00 /usr/local/redis-4.0.1/bin/redis-server 0.0.0.0:6379
    root       7728   2576  0 23:02 pts/0    00:00:00 grep --color=auto redis
    [root@cache02 redis-4.0.1]# 
    [root@cache02 redis-4.0.1]# 
    [root@cache02 redis-4.0.1]# redis-cli -a futurecloud 
    127.0.0.1:6379> get k1
    "value1"
    127.0.0.1:6379> get k2
    "value2"
    127.0.0.1:6379> get k3
    "value3"
    127.0.0.1:6379> get k4
    "v4"
    127.0.0.1:6379> 
    

    4.5.5. redis replication架构进行QPS压测以及水平扩容

    对以上搭建好的redis做压测,检测搭建的redis replication的性能和QPS。
    
    我们使用redis自己提供的redis-benchmark压测工具。
    

    1、对redis读写分离架构进行压测,单实例写QPS+单实例读QPS

    redis-3.2.8/src

    ./redis-benchmark -h 192.168.92.120
    
    -c <clients>       Number of parallel connections (default 50)
    -n <requests>      Total number of requests (default 100000)
    -d <size>          Data size of SET/GET value in bytes (default 2)
    

    根据自己的业务,配置高峰期的访问量,一般在高峰期,瞬时最大用户量会达到10万+。

    -c 100000,-n 10000000,-d 50
    
    
    ====== PING_INLINE ======
      100000 requests completed in 1.28 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    99.78% <= 1 milliseconds
    99.93% <= 2 milliseconds
    99.97% <= 3 milliseconds
    100.00% <= 3 milliseconds
    78308.54 requests per second
    
    ====== PING_BULK ======
      100000 requests completed in 1.30 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    99.87% <= 1 milliseconds
    100.00% <= 1 milliseconds
    76804.91 requests per second
    
    ====== SET ======
      100000 requests completed in 2.50 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    5.95% <= 1 milliseconds
    99.63% <= 2 milliseconds
    99.93% <= 3 milliseconds
    99.99% <= 4 milliseconds
    100.00% <= 4 milliseconds
    40032.03 requests per second
    
    ====== GET ======
      100000 requests completed in 1.30 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    99.73% <= 1 milliseconds
    100.00% <= 2 milliseconds
    100.00% <= 2 milliseconds
    76628.35 requests per second
    
    ====== INCR ======
      100000 requests completed in 1.90 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    80.92% <= 1 milliseconds
    99.81% <= 2 milliseconds
    99.95% <= 3 milliseconds
    99.96% <= 4 milliseconds
    99.97% <= 5 milliseconds
    100.00% <= 6 milliseconds
    52548.61 requests per second
    
    ====== LPUSH ======
      100000 requests completed in 2.58 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    3.76% <= 1 milliseconds
    99.61% <= 2 milliseconds
    99.93% <= 3 milliseconds
    100.00% <= 3 milliseconds
    38684.72 requests per second
    
    ====== RPUSH ======
      100000 requests completed in 2.47 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    6.87% <= 1 milliseconds
    99.69% <= 2 milliseconds
    99.87% <= 3 milliseconds
    99.99% <= 4 milliseconds
    100.00% <= 4 milliseconds
    40469.45 requests per second
    
    ====== LPOP ======
      100000 requests completed in 2.26 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    28.39% <= 1 milliseconds
    99.83% <= 2 milliseconds
    100.00% <= 2 milliseconds
    44306.60 requests per second
    
    ====== RPOP ======
      100000 requests completed in 2.18 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    36.08% <= 1 milliseconds
    99.75% <= 2 milliseconds
    100.00% <= 2 milliseconds
    45871.56 requests per second
    
    ====== SADD ======
      100000 requests completed in 1.23 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    99.94% <= 1 milliseconds
    100.00% <= 2 milliseconds
    100.00% <= 2 milliseconds
    81168.83 requests per second
    
    ====== SPOP ======
      100000 requests completed in 1.28 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    99.80% <= 1 milliseconds
    99.96% <= 2 milliseconds
    99.96% <= 3 milliseconds
    99.97% <= 5 milliseconds
    100.00% <= 5 milliseconds
    78369.91 requests per second
    
    ====== LPUSH (needed to benchmark LRANGE) ======
      100000 requests completed in 2.47 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    15.29% <= 1 milliseconds
    99.64% <= 2 milliseconds
    99.94% <= 3 milliseconds
    100.00% <= 3 milliseconds
    40420.37 requests per second
    
    ====== LRANGE_100 (first 100 elements) ======
      100000 requests completed in 3.69 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    30.86% <= 1 milliseconds
    96.99% <= 2 milliseconds
    99.94% <= 3 milliseconds
    99.99% <= 4 milliseconds
    100.00% <= 4 milliseconds
    27085.59 requests per second
    
    ====== LRANGE_300 (first 300 elements) ======
      100000 requests completed in 10.22 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    0.03% <= 1 milliseconds
    5.90% <= 2 milliseconds
    90.68% <= 3 milliseconds
    95.46% <= 4 milliseconds
    97.67% <= 5 milliseconds
    99.12% <= 6 milliseconds
    99.98% <= 7 milliseconds
    100.00% <= 7 milliseconds
    9784.74 requests per second
    
    ====== LRANGE_500 (first 450 elements) ======
      100000 requests completed in 14.71 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    0.00% <= 1 milliseconds
    0.07% <= 2 milliseconds
    1.59% <= 3 milliseconds
    89.26% <= 4 milliseconds
    97.90% <= 5 milliseconds
    99.24% <= 6 milliseconds
    99.73% <= 7 milliseconds
    99.89% <= 8 milliseconds
    99.96% <= 9 milliseconds
    99.99% <= 10 milliseconds
    100.00% <= 10 milliseconds
    6799.48 requests per second
    
    ====== LRANGE_600 (first 600 elements) ======
      100000 requests completed in 18.56 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    0.00% <= 2 milliseconds
    0.23% <= 3 milliseconds
    1.75% <= 4 milliseconds
    91.17% <= 5 milliseconds
    98.16% <= 6 milliseconds
    99.04% <= 7 milliseconds
    99.83% <= 8 milliseconds
    99.95% <= 9 milliseconds
    99.98% <= 10 milliseconds
    100.00% <= 10 milliseconds
    5387.35 requests per second
    
    ====== MSET (10 keys) ======
      100000 requests completed in 4.02 seconds
      50 parallel clients
      3 bytes payload
      keep alive: 1
    
    0.01% <= 1 milliseconds
    53.22% <= 2 milliseconds
    99.12% <= 3 milliseconds
    99.55% <= 4 milliseconds
    99.70% <= 5 milliseconds
    99.90% <= 6 milliseconds
    99.95% <= 7 milliseconds
    100.00% <= 8 milliseconds
    24869.44 requests per second
    
    使用4核4G内存搭建的专用集群,redis单个节点读请求QPS在5万左右,两个redis从节点,所有的读请求打到两台机器上去,承载整个集群读QPS在10万+。
    

    4.6. redis replication怎么做到高可用性

    什么是99.99%高可用?
    
    系统架构上必须要保证99.99%的高可用性。
    
    99.99%的公式:系统可用的时间 / 系统故障的时间
    
    如在一年365天时间内,系统能保证99.99%的时间都可以对外提供服务,那就是高可用性。
    
    redis replication架构,当master node挂掉,就不能对外提供写业务,没有了数据,就不能同步数据到slave node,从而导致不能提供读业务,此时就会出现大量的请求到数据库,从而出现缓存雪崩现象,严重情况整个系统就处于瘫痪。
    

    使用哨兵sentinel cluster 实现 redis replication 高可用,具体讲解请看下篇文章。

    展开全文
  • 8. 【Redis主从架构】哨兵基础知识 文章目录8. 【Redis主从架构】哨兵基础知识1. 哨兵介绍1.1 哨兵主要功能2 哨兵集群2.1 哨兵集群工作原理3. 哨兵的核心知识4. 为什么redis哨兵集群只有2个节点无法正常工作4. 经典...

    8. 【Redis主从架构】哨兵基础知识

    1. 哨兵介绍

    sentinal, 中文名是哨兵,哨兵是redis集群架构中非常重要的一个组件

    1.1 哨兵主要功能

    • (1)集群监控,负责监控redis master 和 slave 进程是否正常工作。
    • (2)消息通知,如果某个redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员
    • (3)故障转移,如果master node挂掉了,会自动转移到slave node上。
    • (4)配置中心,如果故障转移发生了,会通知client客户端更新最新的master地址。

    2 哨兵集群

    哨兵本身也是分布式的,作为一个哨兵集群去运行,互相协同工作保证哨兵的高可用

    2.1 哨兵集群工作原理

    • (1)故障转移时,判断一个master node是否宕机了,需要大部分的哨兵同意才行,涉及到了分布式选举的问题。

    • (2)即使部分哨兵节点挂掉了哨兵集群还是能正常工作的,因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的,那就坑爹了。

    3. 哨兵的核心知识

    • (1) 哨兵至少需要3个实例,来保证自己的健壮性

    • (2)哨兵 + redis 主从的部署架构,是不会保证数据零丢失的,只能保证redis集群的高可用性

    • (3) 对于 哨兵 + redis 主从这种复杂的部署架构,尽量在测试环境和生产环境,都要进行充足的测试和演练

    4. 为什么redis哨兵集群只有2个节点无法正常工作

    +----+         +----+
    | M1 |---------| R1 |
    | S1 |         | S2 |
    +----+         +----+
    

    哨兵集群中有两个关键的配置

    • quorum: 只有有最少quorum个哨兵认为master宕机了,就认为master宕机了。

    • majority: 只要有最少majority个哨兵是正常运行的,就允许执行故障转移

    问题分析:为什么只有两个哨兵节点的哨兵集群不能正常运行?

    1. 假如master m1宕机了,只要有s1或s2中其中一个认为master宕机了,就认为master宕机了。

    2. 如果此时需要进行故障转移,就需要 majority 个哨兵都是运行的,并且从中选举出一个哨兵执行故障转移2个哨兵的majority是2(2的majority是2,3的majority是2,4的majority是3,5的majority是3),计算公式是:n/2 + 1

    但是如果整个M1和S1所在的机器宕机了,那么哨兵就只剩下一个了,此时没有足够的majority的哨兵来允许执行故障转移,因此就不会进行故障转移。

    4. 经典的3节点哨兵集群

           +----+
           | M1 |
           | S1 |
           +----+
              |
    +----+    |    +----+
    | R2 |----+----| R3 |
    | S2 |         | S3 |
    +----+         +----+
    

    三个节点的哨兵:quorum配置一般是2,majority也为2

    如果M1所在的机器宕机了,那么三个哨兵就只剩下两个,S2和S3可以一致认为master宕机了,然后从中选举一个哨兵出来,进行故障转移。

    参考 石衫老师 《亿级流量教程》课程笔记

    亲,觉得对你有用的话,点个赞呗!!!

    【Redis主从架构】学习哨兵主从结构,哨兵基础知识先了解一下

    展开全文
  • 1. redis基础知识讲解 1.1. 单机版redis的安装以及redis生产环境启动方案 1.1. 安装单机版redis 大家可以自己去官网下载,当然也可以用课程提供的压缩包 wget ...

    1. redis基础知识讲解

    1.1. 单机版redis的安装以及redis生产环境启动方案


    安装gcc

    yum install gcc
    

    安装tcl

    cd /works/soft
    wget http://downloads.sourceforge.net/tcl/tcl8.6.1-src.tar.gz
    tar -xzvf tcl8.6.1-src.tar.gz -C /usr/local/
    cd  /usr/local/tcl8.6.1/unix/
    ./configure 
    make && make install
    

    安装redis

    cd /works/soft 
    tar -zxvf redis-4.0.1.tar.gz -C /usr/local/
    

    执行make 对Redis解压后文件进行编译

    cd /usr/local/redis-4.0.1
    make
    

    编译完成之后,可以看到解压文件redis-4.0.1中会有对应的src、conf等文件夹,进入src文件夹,执行make install进行Redis安装

    cd /usr/local/redis-4.0.1/src
    make install
    

    1.2. redis的生产环境启动方案

    ​ 在生产环境,要把redis作为一个系统的daemon进程去运行,每次系统启动,redis进程一起启动。

    配置Redis 自动启动步骤如下:

    1、准备配置文件redis.conf

    (1)创建两个目录:/etc/redis,存放redis的配置文件;/var/redis/6379,存放redis的持久化文件;
    (2)修改redis配置文件:将redis软件包下的配置文件redis.conf拷贝到/etc/redis目录中,修改名称为6379.conf;

    (3)修改redis.conf中的部分配置为生产环境

    序号 属性 属性描述
    1 daemonize yes 让redis以daemon进程运行
    2 pidfile /var/run/redis_6379.pid 设置redis的pid文件位置
    3 port 6379 设置redis的监听端口号
    4 dir /var/redis/6379 设置持久化文件的存储位置

    2、准备启动脚本

    (1)拷贝redis_init_script到/etc/init.d目录中:redis utils目录下,有个redis_init_script脚本,将redis_init_script脚本拷贝到linux的/etc/init.d目录中;

    (2)将redis_init_script重命名为redis_6379:6379是我们希望这个redis实例监听的端口号,如果你的端口号是其他值,就修改为其他值,这样方便维护;
    (3)设置端口号:修改redis_6379脚本的第6行的REDISPORT,设置为相同的端口号(默认就是6379);

    (4)设置redis的配置文件:将redis启动的配置文件设置成存放redis.conf所在的文件路径,即上文提到的/etc/redis/6379.conf

    配置如下:

    REDISPORT=6379
    EXEC=/usr/local/bin/redis-server
    CLIEXEC=/usr/local/bin/redis-cli
    
    PIDFILE=/var/run/redis_${REDISPORT}.pid
    CONF="/etc/redis/${REDISPORT}.conf"
    

    (5)启动redis

    执行以下命令

    cd /etc/init.d
    chmod 777 redis_6379
    ./redis_6379 start
    

    (6)确认redis进程是否启动,ps -ef | grep redis。

    3、让redis跟随系统启动自动启动

    在redis_6379脚本中,最上面,加入两行注释

    # chkconfig:   2345 90 10
    # description:  Redis is a persistent key-value database
    

    使用以下命令,设置redis_6379自动启动

    chkconfig redis_6379 on
    

    1.3. redis cli的使用

    redis-cli SHUTDOWN,连接本机的6379端口停止redis进程

    redis-cli -h 127.0.0.1 -p 6379 SHUTDOWN,制定要连接的ip和端口号

    redis-cli PING,ping redis的端口,看是否正常

    redis-cli,进入交互式命令行

    SET k1 v1
    GET k1

    1.4. redis技术简单介绍

    redis的技术,包括四大部分:

    • redis 各种数据结构和命令的使用,包括java api的使用
    • redis一些特殊的解决方案的使用,pub/sub消息系统,分布式锁,输入的自动完成,等等
    • redis日常的管理相关的命令
    • redis企业级的集群部署和架构

    ​ redis集群架构(海量数据、高并发、高可用),是企业级的大型缓存架构中最流行,最常用的分布式缓存系统。redis持久化、主从架构、复制原理、集群架构、数据分布式存储原理、哨兵原理、高可用架构等技术,我们将深入集群架构的底层原理,哨兵的底层原理,讲解redis集群架构如何去支撑海量数据、高并发、高可用的。

    展开全文
  • Redis一、分布式缓存技术1、Redis2、Memcached3、缓存数据的处理流程4、为什么要用Redis二、Redis 常见数据结构1、字符串2、list3、hash4、set5、zset(sorted set)三、Redis 单线程模型四、过期的数据的删除策略1...
  • 一、Redis哨兵架构的相关基础知识 1. 哨兵的介绍 sentinel,中文名是哨兵 哨兵是redis集群架构中非常重要的一个组件,主要功能如下 集群监控,负责监控redis master和slave进程是否正常工作 消息通知,如果某个...
  • Redis知识架构梳理

    千次阅读 2017-09-19 10:26:46
    随着分布式系统架构的深入学习与应用,redis起初以分布式缓存的形式走进了我的视角,渐渐地了解到redis是NoSql非关系行数据库的一种,属于“key-value”类型,之后又随着深入学习,除了将它用做缓存,也可以当做...
  • Redis四、过期数据的删除策略1、设置过期时间2、策略五、⭐Redis 内存淘汰机制六、⭐Redis持久化机制七、⭐缓存击穿与缓存雪崩1、缓存击穿2、缓存雪崩八、保证缓存与数据库的一致性九、分布式锁(RedLock)十、...
  • 哨兵是redis集群架构中非常重要的一个组件,主要功能如下 (1)集群监控,负责监控redis master和slave进程是否正常工作 (2)消息通知,如果某个redis实例有故障,那么哨兵负责发送消息作为报警...
  • 哨兵是redis集群架构中非常重要的一个组件,主要功能如下 (1)集群监控,负责监控redis master和slave进程是否正常工作 (2)消息通知,如果某个redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员 (3...
  • 哨兵是redis集群架构中非常重要的一个组件,主要功能如下 (1)集群监控,负责监控redis master和slave进程是否正常工作 (2)消息通知,如果某个redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员 ...
  • 这套架构使用的是社区版本推出的原生高可用解决方案,其架构图如下! 这里Sentinel的作用有三个: 监控:Sentinel 会不断的检查主服务器和从服务器是否正常运行。 通知:当被监控的某个Redis服务器出现问题...
  • 哨兵是redis集群架构中非常重要的一个组件,主要功能如下 (1)集群监控,负责监控redis master和slave进程是否正常工作 (2)消息通知,如果某个redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员 (3)...
  • Redis集群架构概述 ...但是除了这些基本知识之外,在整个系统的开发架构之中,Redis也有着非常重要的地位。 应用场景: 在进行web项目开发的时候,为了保证性能高效,往往会使用大量的web服...
  • 以下是关于Redis复制功能的几个重要方面: ØRedis使用异步复制。从Redis 2.8开始,从服务器以每秒一次的频率向主服务器报告复制流(replication stream)的处理进度; Ø复制功能不会阻塞主服务器:即使有一个...
  • 哨兵是redis集群架构中非常重要的一个组件,主要功能如下: 集群监控,负责监控redis master和slave进程是否正常工作 消息通知,如果某个redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员 故障转移,...
  • (2)哨兵 + redis主从的部署架构,是不会保证数据零丢失的,只能保证redis集群的高可用性 (3)对于哨兵 + redis主从这种复杂的部署架构,尽量在测试环境和生产环境,都进行充足的测试和演练 3、为什么redis...
  • 摘要:华为云鲲鹏Redis,业界首个基于自研ARM-Based全栈整合的Redis云服务,支持双机热备的HA架构,提供单机、主备、Proxy集群、Cluster集群实例类型,满足高读写性能场景及弹性变配的业务需求。分布式缓存服务DCS ...
  • 摘要:华为云鲲鹏Redis,业界首个基于自研ARM-Based全栈整合的Redis云服务,支持双机热备的HA架构,提供单机、主备、Proxy集群、Cluster集群实例类型,满足高读写性能场景及弹性变配的业务需求。分布式缓存服务DCS...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,311
精华内容 524
关键字:

redis知识架构

redis 订阅