关键词：
Redis的使用非常简单，只需要安装配置一下就能轻松上线，短时间不会出现什么问题，但是随着时间推移，Redis实例增多，客户端调用繁杂，真正的问题开始出现，整个关系就变得非常乱。Redis从使用角度来讲是需要像应用服务一样去治理的。
下面先看一段日常开发过程中常见的对话：
开发：Redis为啥不能访问了?
运维：刚刚服务器内存坏了，服务器自动重启了。
开发：为什么Redis延迟这么久?
运维：大哥，不要在Zset里面放几万条数据，插入排序的后果很严重啊!
开发：写进去的key呢，为什么不见了?
运维：你的Redis内存超过最大大小了，不常用的key都丢了呀!
开发：刚刚为啥读取全部失败了?
运维：刚刚网络临时中断了一下，slave全同步了，在全同步完成之前，slave的读取全部失败。
开发：我刚刚想到一个好方案，我需要800GB的Redis，什么时候能准备好呢?
运维：大哥，我们线上的服务器最大也就256GB，别玩这么大好吗?一些常见策略以及其弊端：
1.单机不是不安全吗?那么就开启主从+Keepalived，用虚IP地址在master和 slave两边漂移,master挂了直接切换到slave。
主从+Keepalived 的方案，本来是个很好的方案，但是忽略了主数据节点挂掉的情况。Redis的单进程、单线程设计是其简单和稳定的基石，只要不是服务器发生了故障，在一般情况下是不会挂的。但同时，单进程、单线程的设计会导致Redis接收到复杂指令时会忙于计算而停止响应，可能就因为一个Zset或者keys之类的指令，Redis计算时间稍长，Keepalived就认为其停止了响应，直接更改虚IP的指向，然后做一次主从切换。过不了多久，Zset和 keys之类的指令又会从客户端发送过来，于是从机上又开始堵塞，Keepalived就一直在主从机之间不断地切换IP。终于主节点和从节点都堵了，Keepalived发现后，居然直接将虚IP释放了，然后所有的客户端都无法连接Redis了，只能等运维到线上手工绑定才行。
2.数据放内存不是不安全吗?可以开启数据落盘，根据业务需要决定落盘规则，有AOF的，也有RDB的。
数据落盘也引起了很大的问题，RDB属于非阻塞式的持久化，它会创建一个子进程来专门把内存中的数据写入RDB文件里，同时主进程可以处理来自客户端的命令请求。但子进程内的数据相当于是父进程的一个拷贝，这相当于两个相同大小的Redis进程在系统上运行，会造成内存使用率的大幅增加。如果在服务器内存本身就比较紧张的情况下再进行RDB配置，内存占用率就会很容易达到100%，继而开启虚拟内存和进行磁盘交换，然后整个Redis的服务性能就直线下降了。
另外，Zset、发布订阅、消息队列、Redis的各种功能不断被介绍，开发者们也在利用这些特性，开发各种应用，但从来没想过这么一个小小的Redis 有这么多新奇的功能，它的缺点在什么地方，什么样的场景是不合适用的?这时Redis在大部分的开发者手上就是像是一把锤子，看什么都是钉子，随时都一锤了事。同时也会渐渐地淡忘了开发的一些细节点和规范，因为用它解决性能的问题是那么轻松简单，于是一些基于Redis的新奇功能就接连不断地出现了:基于Redis的分布式锁、日志系统、消息队列、数据清洗，等等，各种各样的功能不断上线使用，从而引发了各种各样的问题。这时候原来那个救火神器就会变成四处点火的神器，Redis堵塞、网卡打爆、连接数爆表等问题层出不穷，经过这么多折腾，Redis终于也变成了大家的噩梦了。
总结以下几点需要解决：
- 必须搭建完善的监控系统，在这之前要先预警，不能等到发生了，我们才发现问题。
- 控制和引导Redis 的使用，我们需要有自己研发的Redis客户端，在使用时就开始控制和引导。
- Redis的部分角色要改，将Redis 由 storage角色降低为cache角色
- Redis的持久化方案要重新做，需要自己研发一个基于Redis协议的持久化方案，让使用者可以把 Redis当DB用。
- Redis 的高可用要按照场景分开，根据不同的场景决定采用不同的高可用方案。
具体方案：
- 重建Redis客户端，在客户端内植入日志，记录所有操作时间，如：耗时、key、value大小、网络断开等，由一个收集程序进行分析和处理。
- 设置阈值报警，通知到运维系统，运维系统基于运维数据来自动故障转移、扩容、分片、负载均衡等。
- 取消直接的IP端口连接方式，通过配置中心分配IP端口，当Redis发生问题需要切换时可直接在配置中心修改，由配置中心推送新的配置到客户端。
- 解决研发人员使用Redis规范问题，将Redis的命令操作分为安全命令和不安全命令，安全命令可直接使用，不安全命令需要分析审核后才能打开，也由配置中心控制。
- 将Redis定位成缓存角色，不做其他用途。
- Redis采用主从+哨兵的模式部署，通过一致性Hash算法均衡分片。
- 做一个Redis的Proxy，提供统一的入口点，Proxy也可以集群部署。
redis技术专题「高可用技术基础」一同分析一下redis高可用的“基石”之主从架构的本质原理解析(代码片段)
...登，就不会在意脚下的泥沼。📕前提概要Redis高可用的方案包括：持久化、主从复制（及读写分离）、哨兵和集群（Cluster）。📕📕持久化：侧重解决的是Redis数据的单机备份问题（从内... 查看详情
基于consul的数据库高可用架构(代码片段)
...草。本次主要分享如何利用consul来实现redis以及mysql的高可用。以前的公司mysql是单机单实例，高可用MHA加vip就能搞定，新公司mysql是单机多实例，那么显然这个方案不适用，后来也实现了故障切换调用dnsapi来修改域名记录，但是... 查看详情
高可用redis服务架构分析与搭建(代码片段)
...会被调用方问起的一个问题是：你的服务是否具有高可用性？最好不要因为你的服务经常出问题，导致我这边的业务跟着遭殃。最近我所在的项目中也自己搭了一套小型的“高可用”Redis服务，在此做一下自己的... 查看详情
redis实战搭建高可用架构(代码片段)
...近在看关于redis缓存方面的知识，今天就来个Redissentinel高可用架构，实战开始之前，先看看sentinel的概念 什么是redis-sentinel Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如mast... 查看详情
redis技术探索「高可用架构模式」哨兵（sentinel）模式实现主从故障互切换模式详解(代码片段)
哨兵（sentinel）模式实现主从故障互切换模式详解Redis的多种模式Redis单机模式Redis单机模式的优点Redis单机模式的缺点Redis主从复制旧版本配置新版本配置查看主节点信息主从模式的优点主从复制的弊端Redis哨兵模式分析哨... 查看详情
高可用与可伸缩架构(代码片段)
分布式业务系统设计的时候，基本的问题有：1.高可用2.可伸缩3.容错性(弹力设计)4.高性能以上是最基本的业务诉求。而在分布式基础系统设计的时候，基本的问题有：1.体系结构2.进程3.通信4.命名5.同步6.一致性与复制7.容错性8.... 查看详情
canal——高可用架构设计与应用(代码片段)
前言本篇只介绍跟高可用相关的配置。TCP模式 请参考文章：【Canal——增量同步MySQL数据到ElasticSearch】Kafka模式请参考文章：【Canal——canalserver读取binlog到kafka然后在使用canal-adapter】Canalserver和client端的高可... 查看详情
redis高可用篇：你管这叫主从架构数据同步原理？(代码片段)
...可以通过重新读取RDB快照和执行AOF日志实现快速恢复的高可用手段。高可用有两个含义：一是数据尽量不丢失，二是服务尽可能提供服务。AOF和RDB保证了数据 查看详情
redis进阶高可用之哨兵(代码片段)
...介绍哨兵之前，首先从宏观角度回顾一下Redis实现高可用相关的技术。它们包括：持久化、复制、 查看详情
k8s-高可用架构设计(代码片段)
docker的私有仓库harbor、容器化kubernetes部分组建、使用阿里云日志服务收集日志。部署完成后，你将理解系统各组件的交互原理，进而能快速解决实际问题，所以本文档主要适合于那些有一定kubernetes基础，想通过一步步部署的方... 查看详情
系统架构高可用系统设计原则01(代码片段)
一、也谈谈高可用“高可用性”（HighAvailability）简称HA，通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。通俗来讲就是通过专业的设计保障系统相关服务能够不间断的稳定运行。度量方式... 查看详情
高可用架构-熔断实现详解(代码片段)
很多人问：熔断到底机制是什么？什么场景下需要熔断？熔断器如何设计？细致讲解，Demo分析，欢迎阅读。Whatis熔断？很多人问：熔断机制是什么？百科解释:熔断机制（CircuitBreaker），也叫自动停盘机制，是指当股指波幅达到... 查看详情
高可用集群架构——redis的主从复制与哨兵模式，cluster(代码片段)
redis的集群一、redis的集群模式1、三种模式2、redis集群与哈希槽二、Redis主从复制概述1、Redis主从复制概述2、主从复制流程三、哨兵模式1、简单介绍2、哨兵的工作原理5、哨兵模式下的故障迁移四、Cluster群集redis-Cluster的故障转... 查看详情
大厂二面高可用之redis哨兵策略(代码片段)
前言笔者在二面某知名大厂时，从Redis的高可用问到kafka的高可用、MySQL的高可用，又让我阐述从高可用的角度设计自己应用程序的高可用，自己回答得不够好，特别是自己项目在QPS陡增时如何设计系统，快速... 查看详情
flume+kafka+storm+redis实时分析系统基本架构(代码片段)
...比如使用Storm的ACK机制保证数据都能被正确处理,集群的高可用架构,消费数据时如何处理重复数据或者丢失数据等问题，根据不同的业务场景 查看详情
mysql高可用架构(代码片段)
高可用HA（HighAvailability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。假设系统一直能够提供服务，我们说系统的可用性是100%。如果系统每运行100个时间单位，会有1个时... 查看详情
redis进阶-高可用：集群(代码片段)
前言前面几篇文章中，已经介绍了Redis的几种高可用技术：持久化、主从复制和哨兵，但这些方案仍有不足，其中最主要的问题是存储能力受单机限制，以及无法实现写操作的负载均衡。Redis集群解决了上述... 查看详情
1.mysql之mha高可用(01)(代码片段)
1.前言 在众多的Mysql高可用架构中，MHA架构目前属于现在比较成熟且岁数比较年长的架构之一了，目前，在Mysql的业界比较流行的高可用架构除了MHA，还有官方的MGR高可用架构、Percona公司出品的PXC(perconaXtraDBCluster)高可用架构... 查看详情