redis集群搭建

6.redis哨兵功能 Redis-Sentinel Redis-Sentinel是redis官方推荐的高可用性解决方案，当用redis作master-slave的高可用时，如果master本身宕机，redis本身或者客户端都没有实现主从切换的功能。 而redis-sentinel就是一个独立运行的进程，用于监控多个master-slave集群，自动发现master宕机，进行自动切换slave > master。 sentinel主要功能如下： 不时的监控redis是否良好运行，如果节点不可达就会对节点进行下线标识 如果被标识的是主节点，sentinel就会和其他的sentinel节点“协商”，如果其他节点也认为主节点不可达，就会选举一个sentinel节点来完成自动故障转义 在master-slave进行切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换 ↓ShowCode↓ redis命令: redis-cli info #查看redis数据库信息 redis-cli info replication #查看redis的复制授权信息 redis-cli info sentinel

本文目标 本文记录redis集群单哨兵的搭建和测试。 安装准备 centos版本：6.7 redis版本：3.2.3 安装方式：源码安装 操作步骤 6379为主节点，6479和6579为从节点； 26379为哨兵节点。 1、创建集群目录 cd /usr/local mkdir redis_cluster mkdir redis_cluster/master_6379 mkdir redis_cluster/slave_6479 mkdir redis_cluster/slave_6579 2、redis配置 2.1 master 主节点配置 vi ./redis_cluster/master_6379/redis.conf daemonize yes port 6379 requirepass enen masterauth enen slave-read-only yes 对应哨兵节点配置 vi ./redis_cluster/master_6379/6379-sentinel.conf port 26379 sentinel monitor mymaster 192.168.186.92 6379 2 sentinel auth-pass mymaster enen sentinel down-after-milliseconds mymaster 30000 sentinel

关于Redis 安装 官方网站 $ wget http://download.redis.io/releases/redis-3.0.7.tar.gz $ tar xzf redis-3.0.7.tar.gz $ cd redis-3.0.7 $ make install 这里一定需要 make install 命令进行安装 而不是make 使用make会提示你redis-server命令找不到 并且在 usr/local/bin 这个文件夹下不会生成 redis-server 和 redis-cli 安装 启动以及配置 http://www.tuicool.com/articles/aQbQ3u redis 配置文件 以及一些关键配置的讲解 所有的配置文件都在 redis-server.conf 这个文件中 daemonize yes 设置成是不是使用守护线程来进行操作 （no 非守护线程） pidfile 生成的pid 文件的目录 port 6666 端口号 logfile 生成的日志文件，这里配置目录和文件名当redis启动失败，宕机等都可以从这个日志文件中查找到相关信息 dbfilename redis.rdb 生成的数据库文件，因为redis是可以一步把数据写入磁盘的 dir 文件目录 它生成dbfilename的目录 和 在下面配置redis集群的时候 cluster-

7.redis 集群模式的工作原理能说一下么？在集群模式下，redis 的 key 是如何寻址的？分布式寻址都有哪些算法？了解一致性 hash 算法吗？ 考点分析 在前几年，redis 如果要搞几个节点，每个节点存储一部分的数据，得 借助一些中间件 来实现，比如说有 codis ，或者 twemproxy ，都有。有一些 redis 中间件，你读写 redis 中间件，redis 中间件负责将你的数据分布式存储在多台机器上的 redis 实例中。 这两年，redis 不断在发展，redis 也不断的有新的版本，现在的 redis 集群模式，可以做到在多台机器上，部署多个 redis 实例，每个实例存储一部分的数据，同时每个 redis 实例可以挂 redis 从实例，自动确保说，如果 redis 主实例挂了，会自动切换到 redis 从实例顶上来。 现在 redis 的新版本，大家都是用 redis cluster 的，也就是 redis 原生支持的 redis 集群模式，那么面试官肯定会就 redis cluster 对你来个几连炮。要是你没用过 redis cluster，正常，以前很多人用 codis 之类的客户端来支持集群，但是起码你得研究一下 redis cluster 吧。 如果你的数据量很少，主要是承载高并发高性能的场景，比如你的缓存一般就几个 G，单机就足够了

一，Redis作缓存服务器 ​ 本篇博客是接着 上一篇 博客未分享完的技术点。 ​ redis作为缓存服务器是众多企业中的选择之一，虽然该技术很成熟但也是存在一定的问题。就是缓存带来的缓存穿透，缓存击穿，缓存失效问题，继而引用分布式锁。 1.1，缓存穿透 ​ 在如今的项目中大多采用垂直的MVC架构，由service层去调用DAO层，然后DAO层再去查询数据库。而redis作为缓存服务器就是在service层去调用DAO层去查询时先去缓存服务器查询，如果存在则直接返回该数据，否则再去查询数据库。由此可知，这么做大量减少了对磁盘I/O的操作，减轻了数据库的压力。 ​ 现在我们假设一种情况，在数据库中存在有id为1到1000的数据。现在如果有人手动去模拟一个id为1001的请求，那么该数据在缓存服务器中是不存在的，因而便会去查询数据库。那么问题来了，如果是一个大量无效的请求去查询数据库。则势必会对数据库造成难以承受的压力，这种情况就是所谓的缓存穿透。 ​ 那如何解决呢？ ​ 1，将查询到的null值直接保存到缓存服务器中，但是这种做法并不推荐，因为如果是大量不同的请求id同样会去查询数据库。 ​ 2，接口的限流，降级与熔断 ​ 在项目中对于重要的接口一定要做限流，对于以上恶意攻击的请求除了要限流，还要做好降级准备，并且进行熔断，这种做法可以有效控制大量无效请求。 ​ 3，布隆过滤器 ​

Sentinel实现Redis集群的高可用 redis集群中有一主一从两个节点。当主节点down掉的时候需要把从节点提升为主节点继续提供服务，从而实现高可用。结构图如下， redis单机多实例主从的安装和配置请参考： http://my.oschina.net/xinxingegeya/blog/389521 下面是具体的搭建过程和一些验证。这里我们建立三个redis节点，其中两个是slave节点；建立三个sentinel节点，同时监控redis集群中的master节点。 目录结构如下， ➜ redis tree -L 1 . ├── conf ├── data ├── log ├── redis_7000 ├── redis_7001 ├── redis_7002 ├── redis_8000 ├── redis_9000 └── run 9 directories, 0 files 其中conf存放redis的配置文件，data为redis的数据存储目录，log为redis的日志目录，run为redis的pid文件目录。 这里使用了一个master节点，两个slave节点的结构设计，其中的7000作为master节点，7001和7002节点作为slave节点。 首先启动三台redis服务器，如下， ➜ redis_7000 ./src/redis-server ./7000

目录 开始配置主从复制 开始配置Redis Sentinel 原文: http://blog.gqylpy.com/gqy/332 @ *** 在开始之前，我们先来看看Redis的主从复制 主从复制原理： 从服务器向主服务器发送 SYNC 命令。 主服务器接到 SYNC 命令后，会调用 BGSAVE 命令，创建一个 RDB 文件，并使用缓冲区记录接下来执行的所有写命令。 当主服务器执行完 BGSAVE 命令后，会向从服务器发送 RDB 文件，而从服务器则会接收并执行这个文件。 主服务器将缓冲区存储的所有写命令发送给从服务器执行。 --------- Redis主从复制使用的是RDB备份方式来同步主从服务器的数据的。 同步开始之后，通过主库命令传播的方式，主动复制方式实现。 2.8以后实现PSYNC饿机制，实现断线重连。 Redis主从复制的背景问题 Reids主从复制可将主节点数据同步给从节点，从节点此时有两个作用： 一旦主节点宕机，从节点作为主节点的备份可以随时顶上来. 扩展主节点的读能力，分担主节点的读压力. . 一旦主节点宕机，从节点上位，那么就需要人为修改所有应用方的主节点地址（指定新的master地址），还需要命令所有从节点复制新的主节点. 这个问题很麻烦，而redis-sentinel就可以很好的解决这个问题. * Redis-Sentinel **     Redis

Redis Cluster 集群搭建 一、 原生方式安装： cd /opt wget http://download.redis.io/releases/redis-4.0.11.tar.gz tar zxvf redis-4.0.11.tar.gz cd redis-4.0.11 (如果编译时报: “ zmalloc.h:50:31: 致命错误：jemalloc/jemalloc.h：没有那个文件或目录 ”，可以使用make MALLOC=libc解决。) make && make install[或make PREFIX=/data/soft/redis install] redis-cli –v cp redis.conf redis.conf.bak redis-cli -h 192.168.26.52 -p 6379 mkdir cluster cp redis.conf ./cluster/redis-8001.conf vim redis-8001.conf //先创建未有的目录 … bind 192.168.xx.xx port 8001 dir "/opt/redis-4.0.11/" logfile "/opt/redis-4.0.11/log/redis-8001.log" appendonly yes daemonize yes //以独立服务启动

1、前言 　　第一次接触Kubernetes是在2016年，再一次浏览博文的时候，那是我第一次听到Kubernetes这个名词，也是第一次认识了k8s这么一个东西。后来在慢慢了解它的时候，被它天生高可用、负载均衡、弹性计算、自动扩容缩容和全自动容灾机制的设计理念吸引，于是自己便踏入了k8s这条不归路，在调研学习的过程中，开始不断填坑、挖坑再填坑，周而复始。 　　2017年，公司还在使用裸Docker部署一些无状态的应用，随着越来越多的Docker实例，发生故障时，人工填坑的方式，让我们实在头疼，有时候大半夜正在做着美梦的时候，被一个电话铃喊起来处理着由于宿主机宕机或者网络不可达引起的各类问题。这种惨绝人寰的处理方式更是让我们头疼难忍。虽然后来引用了Swarm和Compose，但随着业务的不断增多，已经越来越来满足不了我们的应用场景，然后就想着把所有Docker应用迁移到Kubernetes中去管理。 　　 2017年6月30日，k8s发布1.7版本，2017年10月，Docker拥抱Kubernetes，也是我们正式开始使用Kubernetes的开始。但事情并没有我们想象中的那么简单，k8s的设计太多复杂，概念实在是太多，搭建过程更是让人吐血，当时可参考的文章又是少之又少。在经过一个多月的研究与不断回血之后，终于在k8s集群中部署了我们的第一个应用。虽然整个过程中踩了无数坑

redis的安装： https://www.cnblogs.com/knightdreams6/p/11270400.html 集群搭建： 两台虚拟机模拟6个节点，一台机器3个节点，创建3 master， 3 salve 环境 redis采用 redis-5.0.5版本。 两台虚拟机都是CentOS7，一台ip（192.168.3.222），另一台（192.168.3.223） 1.首先在192.168.3.222机器上 　　进入到/usr/local/bin中，mkdir redis-cluster 创建集群文件夹，然后在该文件夹下创建3个子文件夹，根据端口号命名（非必须）为7000，7001，7002 2.复制 redis.conf 到7000, 7001, 7002三个文件夹中 3.修改这三个配置文件，修改如下内容 port 7000 // 端口7000,7002,7003 bind 本机ip // 默认ip为127.0.0.1 需要改为其他节点机器可访问的ip 否则创建集群时无法访问对应的端口，无法创建集群 daemonize yes // redis后台运行 pidfile /var/run/redis_7000.pid // pidfile文件对应7000,7001,7002 cluster-enabled yes // 开启集群 把注释#去掉 cluster