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集群方案什么情形下会导致全体集群不可用？
有A，B，C三个节点的集群,在没有复制模型的情形下,如果节点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实例最多能存放多少的keys？
List、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 Codis2、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 改造的 reborndbRedis 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_memory=1，否则会持久化失落败 没有持久化情形下，主从，主重启太快，从还没认为主挂的情形下，从会清空自己的数据——人为 重启主节点前，先关闭从节点的同步回答二：
我大略说下 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的参数调优问题，根据场景不同，有不同的调优方法，以下列举踩过的一些坑的参数调优。我们的 场景的海量数据，高并发。
（1）timeout参数，非常须要关注，官方对timeout的阐明如下：该参数表示当某一个客户端连接上来 并闲置timeout（单位秒）的韶光后，Redis做事端就主动关闭这个客户端连接。我们创造如果客户端对 连接处理比较差的时候，存在连接不开释的问题，导致连接池耗尽，单个redis默认的连接数是1000.所 以须要在timeout参数做文章，逼迫开释无效连接，我们的参数调度为timeout 30000
（2）持久化参数，RDB和AOF究竟开哪个，很多人很纠结。实在选择很大略，两者的差异是持久化的颗 粒度不一样，如果你关注数据的强同等性，选择AOF，如果你选择更好的性能，选型RDB。如果你选择 极致的性能，又能容忍数据的丢失，那你可以完备不用开启持久化，当然了，集群是一定要开持久化 的。
（3）tcp-backlog和maxclient，这两个参数可能大家也比较含糊，maxclient模式10000，一样平常情形下 是够了，但是在高并发海量访问的时候，还是会涌现客户端缓慢的情形，那便是系统的限定，便是 backlog参数，你可以理解为在三次握手时进入accept queue行列步队的最大值，也便是send_Q，以是这个 值设大点是没有坏处的，我们的设置是1024
（4）重点提一下安全的参数，requirepass foobared 个人认为，如果你们以为你们hold住，那就不用 开，如果在DMZ区，数据又比较主要，那就开。个人认为，密码的浸染不是你想象中的带给你安全，第 一redis一分钟可以访问你想象不到的次数，如果弱密码，分分钟破解，第二auth命令是明文的，破解也 很随意马虎。
（5）maxmemory，这个参数比较常见，但是也非常的坑。如果你选择用，有个原则，你是当数据库用 还是当缓存用，如果当数据库用，就不要开，如果当缓存用，可以开。曾经有个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的架构就不再知足了 比如说以了局景
基于日志的流式打算监控指标的基线数据的统计剖析 通用的打算周期多维度的告警规则：如无数据告警、基于同环比的告警、基于基线的告警、 越来越多的监控场景、监控指标、触发器，redis的浸染便是供应你更快、更优质的做事3.我们的系统现在利用了两套Redis；分别用作热点数据缓存、会话保持保存全局ID。热点数据缓存采取 的是一主一从三哨兵（分别独立，共五个节点）；会话保持采取的是一主三从四个哨兵（共四个节点， 每个节点上启动了一个哨兵进程）；这个是乙方给的方案，请教大神，这个方案可靠吗？能否利用 cluster方案来替代呢？有必要吗？
答：你有两套Redis，A作为热数据缓存，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的条件，那便是不能对其他业务有影响。
key-value的命名规范定 义利用场景完善的监控定期巡检慢查询日志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涌现的目的是为了作为缓存提升访问性能，对数据同等性的支持相比拟较弱
Redis学习条记总结一、缓存的观点
系统缓存用户层缓存CDN缓存运用层缓存其他层面缓存二、Redis支配与利用
Redis根本Redis安装及利用Redis配置文件Redis 数据类型行列步队Redis 常用命令三、Redis 高可用与集群
配置Reids 主从Redis 集群四、memcached
单机支配memcached集群支配架构完全版资料领取见下图
