建设自己的淘宝优惠券网站,学生网站建设的基本流程,企业网站网页设计有哪些,推荐一下网站谢谢本文包括#xff1a;30 个 Redis 基础知识#xff1b;10个 Redis 架构和运维必懂的知识#xff1b;Redis 调优、监控知识和10个具体应用难点。
本篇文档已整理成pdf文档#xff0c;需要的同学文末自取
30 个 Redis 基础知识 1、Redis支持哪几种数据类型#xff1f;
Str…本文包括30 个 Redis 基础知识10个 Redis 架构和运维必懂的知识Redis 调优、监控知识和10个具体应用难点。
本篇文档已整理成pdf文档需要的同学文末自取
30 个 Redis 基础知识 1、Redis支持哪几种数据类型
String、List、Set、Sorted Set、hashes
2、Redis主要消耗什么物理资源
Redis是一种基于内存高性能的数据库--- 主要依赖于内存
3、Redis有哪几种数据淘汰策略
noeviction返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令大部分的写入指令但DEL和几个例外
allkeys-lru尝试回收最少使用的键LRU使得新添加的数据有空间存放。
volatile-lru尝试回收最少使用的键LRU但仅限于在过期集合的键,使得新添加的数据有空间存放。
allkeys-random回收随机的键使得新添加的数据有空间存放。
volatile-random回收随机的键使得新添加的数据有空间存放但仅限于在过期集合的键。
volatile-tt回收在过期集合的键并且优先回收存活时间TTL较短的键,使得新添加的数据有空间存放。
4、为什么Redis需要把所有数据放到内存中
Redis为了达到最快的读写速度将数据都读到内存中并通过异步的方式将数据写入磁盘。所以redis具有快速和数据持久化的特征。如果不将数据放在内存中磁盘I/O速度为严重影响redis的性能。在内存越来越便宜的今天redis将会越来越受欢迎。如果设置了最大使用的内存则数据已有记录数达到内存限值后不能继续插入新值。
5、Redis集群方案应该怎么做都有哪些方案
twemproxy大概概念是它类似于一个代理方式使用方法和普通redis无任何区别设置好它下属的多个redis实例后使用时在本需要连接redis的地方改为连接twemproxy它会以一个代理的身份接收请求并使用一致性hash算法将请求转接到具体redis将结果再返回twemproxy。使用方式简便(相对redis只需修改连接端口)对旧项目扩展的首选。问题twemproxy自身单端口实例的压力使用一致性hash后对redis节点数量改变时候的计算值的改变数据无法自动移动到新的节点。
codis目前用的最多的集群方案基本和twemproxy一致的效果但它支持在 节点数量改变情况下旧节点数据可恢复到新hash节点。
redis cluster3.0自带的集群特点在于他的分布式算法不是一致性hash而是hash槽的概念以及自身支持节点设置从节点。具体看官方文档介绍。
在业务代码层实现起几个毫无关联的redis实例在代码层对key 进行hash计算然后去对应的redis实例操作数据。这种方式对hash层代码要求比较高考虑部分包括节点失效后的替代算法方案数据震荡后的自动脚本恢复实例的监控等等。
6、Redis集群方案什么情况下会导致整个集群不可用
有ABC三个节点的集群,在没有复制模型的情况下,如果节点B失败了那么整个集群就会以为缺少5501-11000这个范围的槽而不可用。
7、Redis如何设置密码及验证密码
设置密码config set requirepass 123456
授权密码auth 123456
8、说说Redis哈希槽的概念
Redis集群没有使用一致性hash,而是引入了哈希槽的概念Redis集群有16384个哈希槽每个key通过CRC16校验后对16384取模来决定放置哪个槽集群的每个节点负责一部分hash槽。
9、Redis集群的主从复制模型是怎样的
为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用所以集群使用了主从复制模型,每个节点都会有N-1个复制品.
10、Redis集群会有写操作丢失吗为什么
Redis并不能保证数据的强一致性这意味着在实际中集群在特定的条件下可能会丢失写操作。
11、Redis集群之间是如何复制的
异步复制
12、怎么理解Redis事务
事务是一个单独的隔离操作事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中不会被其他客户端发送来的命令请求所打断。
事务是一个原子操作事务中的命令要么全部被执行要么全部都不执行。
13、Redis事务相关的命令有哪几个
MULTI、EXEC、DISCARD、WATCH
14、Redis key的过期时间和永久有效分别怎么设置
EXPIRE和PERSIST命令。
15、Redis如何做内存优化
尽可能使用散列表hashes散列表是说散列表里面存储的数少使用的内存非常小所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比如你的web系统中有一个用户对象不要为这个用户的名称姓氏邮箱密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面.
16、Redis回收进程如何工作的
一个客户端运行了新的命令添加了新的数据。
Redi检查内存使用情况如果大于maxmemory的限制, 则根据设定好的策略进行回收。
一个新的命令被执行等等。
所以我们不断地穿越内存限制的边界通过不断达到边界然后不断地回收回到边界以下。
如果一个命令的结果导致大量内存被使用例如很大的集合的交集保存到一个新的键不用多久内存限制就会被这个内存使用量超越。
17、Redis回收使用的是什么算法
LRU算法
18、Redis如何做大量数据插入
Redis2.6开始redis-cli支持一种新的被称之为pipe mode的新模式用于执行大量数据插入工作。
19、为什么要做Redis分区
分区可以让Redis管理更大的内存Redis将可以使用所有机器的内存。如果没有分区你最多只能使用一台机器的内存。分区使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。
20、Redis持久化数据和缓存怎么做扩容
如果Redis被当做缓存使用使用一致性哈希实现动态扩容缩容。
如果Redis被当做一个持久化存储使用必须使用固定的keys-to-nodes映射关系节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况必须使用可以在运行时进行数据再平衡的一套系统而当前只有Redis集群可以做到这样。
21、分布式Redis是前期做还是后期规模上来了再做好为什么
既然Redis是如此的轻量单实例只使用1M内存,为防止以后的扩容最好的办法就是一开始就启动较多实例。即便你只有一台服务器你也可以一开始就让Redis以分布式的方式运行使用分区在同一台服务器上启动多个实例。
一开始就多设置几个Redis实例例如32或者64个实例对大多数用户来说这操作起来可能比较麻烦但是从长久来看做这点牺牲是值得的。
这样的话当你的数据不断增长需要更多的Redis服务器时你需要做的就是仅仅将Redis实例从一台服务迁移到另外一台服务器而已而不用考虑重新分区的问题。一旦你添加了另一台服务器你需要将你一半的Redis实例从第一台机器迁移到第二台机器。
22、都有哪些办法可以降低Redis的内存使用情况呢
如果你使用的是32位的Redis实例可以好好利用Hash,list,sorted set,set等集合类型数据因为通常情况下很多小的Key-Value可以用更紧凑的方式存放到一起。
23、查看Redis使用情况及状态信息用什么命令
info
24、Redis的内存用完了会发生什么
如果达到设置的上限Redis的写命令会返回错误信息但是读命令还可以正常返回。或者你可以将Redis当缓存来使用配置淘汰机制当Redis达到内存上限时会冲刷掉旧的内容。
25、Redis是单线程的如何提高多核CPU的利用率
可以在同一个服务器部署多个Redis的实例并把他们当作不同的服务器来使用在某些时候无论如何一个服务器是不够的 所以如果你想使用多个CPU你可以考虑一下分片shard。
26、一个Redis实例最多能存放多少的keysList、Set、Sorted Set他们最多能存放多少元素
理论上Redis可以处理多达232的keys并且在实际中进行了测试每个实例至少存放了2亿5千万的keys。我们正在测试一些较大的值。
任何list、set、和sorted set都可以放232个元素。
换句话说Redis的存储极限是系统中的可用内存值。
27、Redis常见性能问题和解决方案
(1) Master最好不要做任何持久化工作如RDB内存快照和AOF日志文件
(2) 如果数据比较重要某个Slave开启AOF备份数据策略设置为每秒同步一次
(3) 为了主从复制的速度和连接的稳定性Master和Slave最好在同一个局域网内
(4) 尽量避免在压力很大的主库上增加从库
(5) 主从复制不要用图状结构用单向链表结构更为稳定即Master - Slave1 - Slave2 - Slave3…
这样的结构方便解决单点故障问题实现Slave对Master的替换。如果Master挂了可以立刻启用Slave1做Master其他不变。
28、Redis提供了哪几种持久化方式
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。
AOF持久化方式记录每次对服务器写的操作当服务器重启的时候会重新执行这些命令来恢复原始的数据AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写使得AOF文件的体积不至于过大。
如果你只希望你的数据在服务器运行的时候存在你也可以不使用任何持久化方式。
你也可以同时开启两种持久化方式在这种情况下当redis重启的时候会优先载入AOF文件来恢复原始的数据因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
最重要的事情是了解RDB和AOF持久化方式的不同让我们以RDB持久化方式开始。
29、如何选择合适的持久化方式
一般来说 如果想达到足以媲美PostgreSQL的数据安全性 你应该同时使用两种持久化功能。如果你非常关心你的数据 但仍然可以承受数分钟以内的数据丢失那么你可以只使用RDB持久化。
有很多用户都只使用AOF持久化但并不推荐这种方式因为定时生成RDB快照snapshot非常便于进行数据库备份 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快除此之外 使用RDB还可以避免之前提到的AOF程序的bug。
30、修改配置不重启Redis会实时生效吗
针对运行实例有许多配置选项可以通过 CONFIG SET 命令进行修改而无需执行任何形式的重启。从 Redis 2.2 开始可以从 AOF 切换到 RDB 的快照持久性或其他方式而不需要重启 Redis。检索 ‘CONFIG GET *’ 命令获取更多信息。
但偶尔重新启动是必须的如为升级 Redis 程序到新的版本或者当你需要修改某些目前 CONFIG 命令还不支持的配置参数的时候。
10个 Redis 架构和运维必懂的知识 一、高可用相关 1、Redis 常用高可用架构有哪些
Redis 高可用架构如下
Redis Sentinel 集群 内网 DNS 自定义脚本
Redis Sentinel 集群 VIP 自定义脚本
封装客户端直连 Redis Sentinel 端口 JedisSentinelPool适合 Java PHP 基于 phpredis 自行封装
Redis Sentinel 集群 Keepalived/Haproxy
Redis M/S Keepalived
Redis Cluster
Twemproxy
Codis
2、Redis 高可用架构优劣对比
—Redis Sentinel 集群 内网 DNS 自定义脚本
优点
秒级切换
脚本自定义架构可控
对应用透明
缺点
维护成本略高
依赖 DNS存在解析延时
Sentinel 模式存在短时间的服务不可用
—Redis Sentinel 集群 VIP 自定义脚本
优点
秒级切换
脚本自定义架构可控
对应用透明
缺点
维护成本略高
Sentinel 模式存在短时间的服务不可用
—封装客户端直连 Redis Sentinel 端口
优点
服务探测故障及时
DBA 维护成本低
缺点
依赖客户端支持 Sentinel
Sentinel 服务器需要开放访问权限
对应用有侵入性
—Redis Sentinel 集群 Keepalived/Haproxy
优点
秒级切换
对应用透明
缺点
维护成本高
存在脑裂
Sentinel 模式存在短时间的服务不可用
—Redis M/S Keepalived
优点
秒级切换
对应用透明
部署简单维护成本低
缺点
需要脚本实现切换功能
存在脑裂
Redis Cluster、Twemproxy、Codis 优劣对比见下个问题
3、常见的 Redis 集群方案有哪些优缺点 Twemproxy:
多个同构 Twemproxy配置相同同时工作接受客户端的请求根据 hash 算法转发给对应的 Redis。
优点
开发简单对应用几乎透明
历史悠久方案成熟
缺点
代理影响性能
LVS 和 Twemproxy 会有节点性能瓶颈
Redis 扩容非常麻烦
Twitter 内部已放弃使用该方案新使用的架构未开源
Codis: ZooKeeper
存放路由表和代理节点元数据
分发Codis-Config的命令
Codis-Config 集成管理工具有web界面
Codis-Proxy
无状态代理兼容Redis协议
对业务透明
Codis-Redis
基于2.8版本二次开发
加入slot支持和迁移命令
优点
开发简单对应用几乎透明
性能比 Twemproxy 好
有图形化界面扩容容易运维方便
缺点
代理依旧影响性能
组件过多需要很多机器资源
修改了 Redis 代码导致和官方无法同步新特性跟进缓慢
开发团队准备主推基于 Redis 改造的 reborndb
Redis Cluster: P2P模式无中心化。把 key 分成 16384 个 slot每个实例负责一部分 slot。客户端请求若不在连接的实例该实例会转发给对应的实例。通过Gossip协议同步节点信息。
优点
组件 all-in-box部署简单节约机器资源
性能比 proxy 模式好
自动故障转移、Slot 迁移中数据可用
官方原生集群方案更新与支持有保障
缺点
架构比较新最佳实践较少
多键操作支持有限驱动可以曲线救国
为了性能提升客户端需要缓存路由表信息
节点发现、reshard 操作不够自动化
二、Redis 通用 1、Redis 相对 MySQL、PostgreSQL 这些关系型数据库有什么优缺点
观点一
Redis 主要是用来做缓存它有持久化但也只是为了缓存的可靠而已。优点是数据全放内存速度快。缺点就是数据大小不能超过内存大小。两个用在不同业务场景Redis 无法取代传统关系型数据库。
观点二
Redis 首先它是一种内存数据库最大的优势在于效率高。尤其在某些特定场合下例如热点数据量非常大而数据从内存和磁盘之间的换入换出代价比较高的情况下Redis 就会体现它的价值。
传统关系型数据库在于它对数据的一致性保障它的数据模型范式是遵循严格事务规则的结构化数据由于其数据的高度抽象化它调度到内存的数据一般场合下不会占用很大的内存空间。
总的来说两种数据库各有各的优点和缺点。不同的业务场合有特定的追求目标redis 首要的是效率适用的是一些单纯二维结构化数据无法表达的数据模型而关系型数据库处理的是可以用范式模型表达的二维数据追求的是数据的高度一致性。随着 IT 的发展每一类型的数据库都会在其特定的场合内发挥出无可比拟的优势最终的趋势是大家趋于平衡没有最好只有最适合。
观点三
记住一句话任何数据库都有自己的应用场景应该关注数据流、数据属性。
个人的经验来说Redis 不可能取代 MySQL 或者 PG。
2、Redis 有哪些应用场景
Redis 是一个高性能的缓存一般应用在 Session 缓存、队列、排行榜、计数器、最近最热文章、最近最热评论、发布订阅等。
更多应用场景可以参考此处。
可以这样讲Redis 适用于 数据实时性要求高、数据存储有过期和淘汰特征的、不需要持久化或者只需要保证弱一致性、逻辑简单的场景。
3、新接手一个复杂的 Redis 集群Sentinel 模式如何了解它
刚刚接手一套 Redis 集群想要了解这套集群的相关配置。应该如何入手。难道只能通过 info 命令去查看各个配置吗
这是笔者的建议
通读 Sentinel 官方文档https://redis.io/topics/sentinel
Google 搜索 Redis Sentinel找几篇中英文的文章看看
进入 Sentinel 集群后使用 info 查看集群信息
查看 Sentinel 配置文件配合文档搞清楚每个参数的含义
使用几台虚拟机模拟线上环境然后做测试在实践中深入理解
思考当前 Sentinel 集群是否有不合理的地方如有提出并改进
三、Redis 故障排查 1、Redis 实例中存在大量的 FIN_WAIT2 连接
客户端 TCP 状态迁移
CLOSED-SYN_SENT-ESTABLISHED-FIN_WAIT_1-FIN_WAIT_2-TIME_WAIT-CLOSED
服务器 TCP 状态迁移
CLOSED-LISTEN-SYN 收到 -ESTABLISHED-CLOSE_WAIT-LAST_ACK-CLOSED
这个状态存在于主动发起断开请求的一端如果服务器存在大量的这个状态那么这个服务器就充当客户端的角色如网络爬虫出现的原因是由于客户端发起 FIN 请求结束连接之后收到了服务端的应答之后进入 FIN_WAIT2之后就没收到服务端发送的 FIN 信号导致。
PS线上 Web 客户端用的什么语言
此问题的评论值得一看http://www.aixchina.net/Question/231035-1406575
2、如何知道当前 Redis 实例是处于阻塞状态
解答一
随便 get 一个 key然后卡着不动就行简单粗暴。优雅一点是看 latency 的延迟blocked_clients 的数量rejected_connections 的数量等。
解答二
方法一登录 Redis执行 info查看 blocked_clients
方法二执行 redis-cli --latency -h -p 查看延时情况
3、Redis 运维的故障有哪些 回答一
常见的运维故障
使用 keys * 把库堵死——建议使用别名把这个命令改名
超过内存使用后部分数据被删除——这个有删除策略的选择适合自己的即可
没开持久化却重启了实例数据全掉——记得非缓存的信息需要打开持久化
RDB 的持久化需要 vm.overcommit_memory1否则会持久化失败
没有持久化情况下主从主重启太快从还没认为主挂的情况下从会清空自己的数据——人为重启主节点前先关闭从节点的同步
回答二
我简单说下 Redis 故障的排查方法吧。
了解清楚业务数据流是怎么样的
结合 Redis 监控查看 QPS、缓存命中率、内存使用率等信息
确认机器层面的资源是否有异常
故障时及时上机使用 redis-cli monitor 打印出操作日志然后分析事后分析此条失效
和研发沟通确认是否有大 Key 在堵塞大 Key 也可以在日常的巡检中获得
和组内同事沟通确实是否有误操作
和运维同事、研发一起排查流量是否正常是否存在被刷的情况
更多的排查需要对线上系统的分析。
四、Redis 性能优化 1、提高 Redis 内存数据库的性能有哪些措施
这个问题有点偏题了还是回答下吧。整理下工作中积累的经验
根据不同业务选择数据类型有必要时对数据结构进行审核减少数据冗余
精简键名和键值控制键值的大小
使用前缀管理好 key
使用 scan 代替 keys将遍历 Redis DB 中所有 key 的操作放到客户端来做
避免使用 O(N) 复杂度的命令
配置使用 ziplist 来优化 list
合理配置 maxmemory
数据量大的情况做好 key 和 value 的压缩
利用管道批量处理命令
根据不同业务选择短链接或者长链接
定期使用 redis-cli --big-keys 检测大 Key
Redis 调优、监控知识和10个具体应用难点 一、Redis数据库的优缺点及适用场景 Redis持久服务的特点key-value键值类型存储系统支持数据可靠存储单进程单线程高性能服务器恢复比较慢单机qps秒并发可以达到10W适合小数据高速读写访问。
Redis存储系统优、缺点可以持久化存储数据支持每秒10W的读写频率支持丰富的数据类型所有操作都是原子性的支持异机主从复制内存管理开销大低于物理内存的3/5不同命令延迟差别大官方网站http://www.redis.io
主要使用场景分为两大块
1、缓存热点数据放到缓存里大部分情况命中缓存不命中时访问磁盘存储并更新缓存
2、键值存储独立使用缓存作为数据提供方。依赖于缓存服务的可靠性不高业务对事务和数据的一致性要求不高。具体的一般由架构师和开发人员根据业务的特性设计出具体的使用方法。
二、Redis的调优参数 Redis的参数调优问题根据场景不同有不同的调优方法以下列举踩过的一些坑的参数调优。我们的场景的海量数据高并发。
1timeout参数非常需要关注官方对timeout的解释如下该参数表示当某一个客户端连接上来并闲置timeout单位秒的时间后Redis服务端就主动关闭这个客户端连接。我们发现如果客户端对连接处理比较差的时候存在连接不释放的问题导致连接池耗尽单个redis默认的连接数是1000.所以需要在timeout参数做文章强制释放无效连接我们的参数调整为timeout 30000
2持久化参数RDB和AOF究竟开哪个很多人很纠结。其实选择很简单两者的区别是持久化的颗粒度不一样如果你关注数据的强一致性选择AOF如果你选择更好的性能选型RDB。如果你选择极致的性能又能容忍数据的丢失那你可以完全不用开启持久化当然了集群是一定要开持久化的。
3tcp-backlog和maxclient这两个参数可能大家也比较迷糊maxclient模式10000一般情况下是够了但是在高并发海量访问的时候还是会出现客户端缓慢的情况那就是系统的限制就是backlog参数你可以理解为在三次握手时进入accept queue队列的最大值也就是send_Q所以这个值设大点是没有坏处的我们的设置是1024
4重点提一下安全的参数requirepass foobared 个人认为如果你们觉得你们hold住那就不用开如果在DMZ区数据又比较重要那就开。个人认为密码的作用不是你想象中的带给你安全第一redis一分钟可以访问你想象不到的次数如果弱密码分分钟破解第二auth命令是明文的破解也很容易。
5maxmemory这个参数比较常见但是也非常的坑。如果你选择用有个原则你是当数据库用还是当缓存用如果当数据库用就不要开如果当缓存用可以开。曾经有个BUG多个salve的情况下会导致擦除主节点的数据。如果你开启这个参数记得预留一些空间给系统的buffer。
遵循你的使用场景和你对参数的了解。宁愿逐步踩坑逐步解决问题逐步深入了解也不要盲从的调整参数。
三、Redis 的监控指标 内存使用。如果 Redis 使用的内存超出了可用的物理内存大小那么 Redis 很可能系统会被杀掉。针对这一点你可以通过 info 命令对 used_memory 和 used_memory_peak 进行监控为使用内存量设定阀值并设定相应的报警机制。当然报警只是手段重要的是你得预先计划好当内存使用量过大后你应该做些什么是清除一些没用的冷数据还是把 Redis 迁移到更强大的机器上去。
持久化。如果因为你的机器或 Redis 本身的问题导致 Redis 崩溃了那么你唯一的救命稻草可能就是 dump 出来的rdb文件了所以对 Redis dump 文件进行监控也是很重要的。可以通过对rdb_last_save_time 进行监控了解最近一次 dump 数据操作的时间还可以通过对rdb_changes_since_last_save进行监控来获得如果这时候出现故障会丢失即已改变多少数据。
Keys。通过获取Keyspace中的结果得到各个数据库中key的数量
QPS。即每分钟执行的命令个数即(total_commands_processed2-total_commands_processed1)/span为了实时得到QPS可以设定脚本在后台运行记录过去几分钟的total_commands_processed。在计算QPS时利用过去的信息和当前的信息得出QPS的估计值。
四、如何更好更合理的使用Redis——10个具体应用难点解读 1.Redis与Oracle中存有同一份数据当数据发生变化时应用程序是先写Redis然后再同步到Oracle还是先写Oracle然后再同步到Redis呢使用何种同步机制可以有效的解决这个时间差中两份数据的不一致性呢
答如果你是当数据库用那就类似于电商抢购场景。抢购的场景中有个需要解决的问题是超买和超卖意思就是说我要控制库存数量而且要保证可用库存的数量为0不能出现负数。一般是把数据从Oracle刷到Redis贴合题主的问题那就是同样有一份数据当数据变化的时候是先写Redis还是先写Oracle是先写Redis再写Oracle因为代码层面保证数据的一致性在高并发情况下悲观锁机制并不会很友好而且影响性能。而redis天然的原子性事务是可以保证数据的一致性。
如果你当缓存用又要确保数据的强一致性是可以先写Redis也可以先写Oracle如果先写Redis参考前一段话采取Redis的强一致性如果先写Oracle那就采取悲观锁来实现。
2.目前的监控系统是Python到Oracle取配置信息经过运算之后再写回Oracle然后根据阀值来触发告警在这样的模式之下Redis是否有可以应用的空间呢**
答当你的监控的需求具备秒级监控的能力后你的web-db的架构就不再满足了 比如说以下场景
1基于日志的流式计算
2监控指标的基线
3数据的统计分析
4通用的计算周期
5多维度的告警规则如无数据告警、基于同环比的告警、基于基线的告警、
越来越多的监控场景、监控指标、触发器redis的作用就是提供你更快、更优质的服务
3.我们的系统现在使用了两套Redis分别用作热点数据缓存、会话保持保存全局ID。热点数据缓存采用的是一主一从三哨兵分别独立共五个节点会话保持采用的是一主三从四个哨兵共四个节点每个节点上启动了一个哨兵进程这个是乙方给的方案请教大神这个方案可靠吗能否使用cluster方案来替代呢有必要吗
答你有两套RedisA作为热数据缓存B作为回话保持。
缺点A有5个节点B有4个节点9个节点中只有2个节点是主节点提供服务备节点只是冗余存在比较大的资源浪费。
优点sentinel集群客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息做到代理层的可用性。切换至cluster后在资源使用率方面按照9节点的规模实际组网只能有8台4主4从资源使用率得到很大的提升而且代理层分别由8个节点负担因此也能保证了可用性。
4.主机房部署了Redis集群并数据持久化。问题要求在主机房发生灾难并不可修复的情况下容灾机房能在一定时间内承担起主机房的业务能力。如何保障容灾机房的Redis集群数据跟主机房一致如何操作
答主要看你采用集群的方式如果是cluster请参考关于双活机房中cluster模式的组网根据你的业务场景来决定。如果redis的使用中并不处在核心链路上完全当做cache来使用且在击穿情况下有后续的数据库来支撑可以放在同一机房内。如果Redis的使用在核心链路上当做数据库来使用在单侧机房部署不能保证多机房环境下的多活。以双活机房为例集群有A、a、B、b、C、c节点A、B、C三个节点部署在甲机房a、b、c三个节点部署在乙机房甲乙两个机房使用波分线路进行大二层透传能够使某一业务同时在某一都使用同一网段地址。基于Redis本身能够实现双数据副本模式当甲机房单侧异常时乙机房单侧接管重新完成组网提供服务。
如果是其他集群请描述我再补充。我大概明白你的意思了我猜测1你应该没有使用集群模式而且采取了无状态的三个节点进行组网。2你采取的cluster三主三从都是部署在单侧机房。目前你的做法是AB两个机房你集群部署在A单侧机房另外在B机房又复制了A机房的集群镜像当单侧机房故障时B机的Redis进行启动进行加载数据提供服务。目前我有个问题你们有没有演练过且应用要不要改Redis的IP如果你们对Redis的场景没有横向扩展的要求建议在Redis集群上加一层代理比如sentinel、twemproxy通过代理去路由Redis同时Redis的主备分别部署两侧机房当主节点异常备节点进行选举接管。
5.多个系统共用Redis集群如何防止某个系统独占大量资源导致其他系统不可用
答多个系统共用一套redis的前提那就是不能对其他业务有影响。1key-value的命名规范、2定义使用场景、3完善的监控、4定期巡检慢查询日志
6.Redis生产部署中集群方案是否有简化部署
目前在实际生产部署中已经在使用Redis主备方案的部署但还仅是依靠硬件负载均衡设备进行应用分发后由2台Redis服务器实现主备。基于Redis在系统仅是做为数据写入缓存的单一功能。想了解一下除了Redis多机集群是否有简单的Redis双机部署方案性能如何2台物理机我们是电力行业系统 用于将通信端抄送上来的并发数20万左右的报文缓存然后存于数据库
答20万的数据量不大可以采用Redis主从方式搭配sentinel进行自动主从切换。如果团队开发能力较强可以研究一下twemproxy开源架构。另外Redis是单线程模式运行的为了充分使用机器的CPU资源可以搭建多个Redis实例部署多套主从架构或者使用twemproxy开源架构对数据进行分片适应将来的业务量上涨。
7.Redis cluster在多活机房中采取怎样的架构
答关于双活机房中cluster模式的组网根据你的业务场景来决定。
如果Redis的使用中并不处在核心链路上完全当做cache来使用且在击穿情况下有后续的数据库来支撑可以放在同一机房内。如果Redis的使用在核心链路上当做数据库来使用在单侧机房部署不能保证多机房环境下的多活。以双活机房为例集群有A、a、B、b、C、c节点A、B、C三个节点部署在甲机房a、b、c三个节点部署在乙机房甲乙两个机房使用波分线路进行大二层透传能够使某一业务同时在某一都使用同一网段地址。基于Redis本身能够实现双数据副本模式当甲机房单侧异常时乙机房单侧接管重新完成组网提供服务。
8.Redis Cluster什么情况下会导致数据丢失应该怎么避免
答cluster模式下数据丢失有两种可能1请求击穿写入失败这个要从代码层面来解决2主从切换从节点的数据跟主节点数据有差异。这个解决方式可以采取配置always参数保持数据的大概率的一致性。
9.Redis主从间是异步复制这里提到强一致是如何做到的应用层的工作吗
答不得不说Redis的数据同步强一致性是有前置条件的强一致性的根据有两个前提1持久化文件的生成的一致性2持久化文件的写入的一致性。针对1目前有两种持久化方式RDB和AOF针对两者而言其实都是异步的两个都有优缺点但针对落地数据而言都是异步的所以能做到准实时不能做到真正意义上的实时。很多人有疑问了appendfsync always这个参数明明是同步的是能牺牲性能保证数据的一致性的。仔细看官网的介绍AOF持久化中的文件写入操作其实是将aof_buf缓冲区的内容存放到了内存缓冲区中这时还没有真正写入到磁盘中这个缓冲区达到同步条件时才会执行fsync将这个缓冲区的内容写入到硬盘中完成文件同步。所以持久化和REDIS事务的原子性是解耦的。针对2取决于持久化文件的大小曾遇到一种情况当持久化文件非常大的时候同步也是需要时间的。综上所述不能做到绝对的强一致性只能做到可接受的范围的强一致性。
10.在金融行业为了保证数据的强一致性应该选择哪种持久化方式换句话说在主从切换中通过哪些途径保持数据的强一致性
答持久化并且要保证数据不丢失可以开启aof备份并且把appendfsync参数设置为 always 保证收到写命令后就立即写入磁盘但是效率最差一般的sata盘只能支持几百的QPS。可以使用高效的SSD磁盘提升性能。但是这也违背了redis高速缓存的初衷。主从切换目前原生redis不支持同步复制它的主从只能是异步复制也就是无法保证数据强一致性。有些公司通过修改复制内核支持主从完全同步的复制。这也牺牲了性能和QPS。redis出现的目的是为了作为缓存提升访问性能对数据一致性的支持相对比较弱。
作者马哥高薪IT实战
