有关做美食的网站,制作图官网,在线制作图片模板,重庆开办企业一网通平台引言
大家即使没用过Redis#xff0c;也应该都听说过Redis的威名。
Redis是一种Nosql类型的数据存储#xff0c;全称Remote Dictionary Server#xff0c;也就是远程字典服务器#xff0c;用过Dictionary的应该都知道它是一种键值对#xff08;Key-Value#xff09;的数…引言
大家即使没用过Redis也应该都听说过Redis的威名。
Redis是一种Nosql类型的数据存储全称Remote Dictionary Server也就是远程字典服务器用过Dictionary的应该都知道它是一种键值对Key-Value的数据结构所以Redis也称为KV存储。
Redis的用途十分广泛包括帮助网页快速加载管理登录状态更新社交动态、游戏积分排名、电商抢购秒杀等等有点规模的应用后边都有它的身影。 Redis之所以这么流行首先是因为它的处理速度特别快它主要在内存中处理数据其次它提供了多种数据结构使用起来比较方便而且这些数据结构的操作时间复杂度都很优秀最后Redis会将数据保存到磁盘中提供一定的持久性。
但是很多同学常常对Redis的数据安全有所担忧大家经常问Redis能保证数据不丢失吗怎么做到的本文会简单说说Redis的数据保护机制它的好处和局限以及我们应该怎样设置、有哪些高级技巧。
Redis面临的数据丢失风险
Redis中的数据是有可能丢失的。
首先咱们搞清楚一个概念——数据持久性。简单来说数据持久性就是确保你的数据在遇到各种意外情况时比如断电、系统崩溃等之后还能安然无恙的存在。就像是手机即使没电了充上电之后里面的照片和信息都还在没有丢失。
那么Redis面临的数据丢失风险有哪些呢
上文说到Redis主要在内存中操作数据内存是一种临时存储一旦断电或者硬件故障、软件错误等内存中的数据就会烟消云散。有的同学会说数据不是会保存到硬盘吗是的但是还是可能会有一些数据来不及写入硬盘这是Redis的持久化机制导致的下边会进行详细说明。
而且即使Redis将全部数据都及时保存到了硬盘硬盘出现问题也可能会导致Redis的数据丢失。
另外有的同学会说我只是在Redis中缓存数据所有的数据在数据库中都有完整的记录。这个问题虽然有点超纲但是这里还是简单交代下。这种情况下如果要恢复的数据量比较大从数据库恢复数据的时间会比较长这会延长故障的恢复时间。而且如果系统访问量比较大还可能导致缓存穿透的问题击垮数据库。
所以尽管Redis给我们的应用带来了极速体验但是如果不采取措施数据丢失的风险是实实在在的。下面我们将探讨Redis如何通过各种持久化策略来应对这些风险尽量保证数据的安全。
基础策略
保证数据不丢失的基础策略就是使用Redis自带的持久化机制Redis提供了两种主要的数据持久化方法RDB快照和AOF追加文件。这两种方法各有千秋让我们来详细了解一下。
RDB机制
RDB持久化是通过创建数据集的快照来工作的在指定的时间间隔内Redis会自动将内存中的数据集写入硬盘的一个文件通常是dump.rdb。这就像是给数据拍了一张快照当需要的时候可以随时从这个快照恢复。 优点
性能高快照生成时用到了写时拷贝技术此时Redis主进程只负责写入数据实际保存工作由子进程完成因此对性能影响较小。恢复快与AOF相比使用RDB文件恢复数据通常更快。
缺点
数据可能丢失如果Redis异常停止那么最后一次快照之后的所有数据更改都会丢失。大数据集恢复时间长虽然比AOF快但是如果数据集非常大恢复过程仍然可能需要较长时间。
AOF机制
AOF持久化通过记录每个写操作到一个日志文件中实现数据的持久化。这就像是把每次数据变动都先记录下来然后再更新到内存中需要恢复时按照这个操作日志一步步来就行了。 需要注意AOF记录也很难做到每个写操作都先持久化到硬盘中这是因为硬盘的读写速度一般都很慢比内存操作低几个数量级如果每次都先写到硬盘Redis也做不到目前的低延迟高并发。所以写操作一般都是先缓存一段时间然后再批量flush到硬盘。
优点
数据安全性高AOF持久化可以配置不同的同步频率例如每秒同步这样可以在保证性能的同时减少数据丢失的风险。可读的日志文件AOF文件是一个纯文本文件可以被人读懂便于理解和问题排查。
缺点
文件体积大由于记录了所有写操作AOF文件的体积通常会大于RDB文件。恢复速度慢与RDB相比AOF在恢复大量数据时通常更慢因为需要重新执行所有操作。
配置建议
RDB配置建议
大部分情况下都建议开启RDB因为RDB需要的资源相对AOF小很多。如果对数据完整性的要求不高或者能很快的从其它渠道恢复数据一般只需要开启RDB就可够了。
合理设置快照间隔
Redis的RDB持久化允许我们配置多个不同的快照条件以适应不同的数据更新频率和保证数据安全。我们可以在 redis.conf 配置文件中设置多个快照规则。以下是一个示例配置展示了如何根据数据变化的频繁程度来设置快照的条件
# 在900秒内如果至少有1个键被改变则进行一次快照
save 900 1
# 在300秒内如果至少有10个键被改变则进行一次快照
save 300 10
# 在60秒内如果至少有1000个键被改变则进行一次快照
save 60 1000这样的配置意味着
如果数据变化不是很频繁我们不需要那么频繁地进行快照保存以避免不必要的性能开销。当数据变化变得更加频繁时我们通过更紧密的快照来减少数据丢失的风险。
动态调整快照规则
除了在配置文件中静态设置快照规则外Redis还提供了命令让我们可以在运行时动态调整快照规则。使用CONFIG SET命令我们可以根据应用的当前状态和需求动态地调整快照条件
# 动态设置快照规则
redis-cli CONFIG SET save 60 1000 300 10 900 1
注意事项
性能考量虽然频繁的快照可以减少数据丢失的风险但也可能会对性能产生影响特别是在数据集很大的情况下。因此需要根据实际情况权衡快照频率和性能。监控与调整建议监控Redis的性能指标并根据实际运行情况调整快照规则。随着业务的发展可能需要定期回顾和调整这些设置。
AOF配置建议
当数据仅保存在Redis中或对数据的丢失难以容忍时建议开启AOF。
考虑到性能和数据安全建议设置为每秒同步一次。这样既可以保证数据的及时性又不会对性能影响太大。
以下是一个示例配置
appendfsync everysec
定期重写AOF
随着时间的推移AOF文件可能会变得很大不仅会占用更多的磁盘空间而且重启后或从故障恢复时处理的会比较慢。缓解这个问题可以使用Redis提供的定期重写机制。
在AOF重写过程中Redis会创建一个新的AOF文件这个新文件仅包含重建当前数据集所需的最小命令集合。例如如果一系列的INCR命令将某个键的值从0递增到了100那么在重写后的AOF文件中可能只会记录一条SET命令来直接设置这个键为100从而大大减小文件。
通过 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 参数可以配置自动重写的条件。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
auto-aof-rewrite-percentage重写时机当前AOF文件大小相对于上一次重写后的文件大小的增长百分比。例如若设置为100则表示每当AOF文件大小翻倍时Redis将自动触发AOF重写。auto-aof-rewrite-min-size即使满足了增长百分比条件Redis也不会立即进行重写还需要AOF文件达到一个最小尺寸。只有当文件大小超过这个设定值时才会真正触发重写。 通过以上配置在保证Redis性能的同时数据安全性也有了基础的保证。
高级策略
从对基础策略的分析中我们了解到即使采用AOF日志因为写日志的延迟数据仍存在丢失的可能性。而且即使数据都写入到了硬盘也无法处理单机硬盘故障导致数据丢失的问题。
这一小节就让我们来看下处理这个问题的一些高级策略包括主从架构、哨兵系统和集群架构。这些策略可以提高数据的安全性和可用性。
主从架构实现多副本保存
在Redis的主从架构中数据会从一个主节点复制到一个或多个从节点。这样做的好处是即使主节点出现问题我们也可以从从节点中恢复数据而且从节点可以继续提供查询服务。
工作原理主节点负责处理所有的写操作并将这些操作记录同步到从节点。从节点则可以处理读请求分担主节点的读负载。 优点
数据冗余通过在多个从节点上保存数据副本提高了数据的可靠性。读负载均衡从节点可以处理读请求帮助分担主节点的读负载。
配置示例
# 从节点配置
slaveof masterip masterport
主节点无需特别配置只需正常启动。从节点的配置文件中增加slaveof配置masterip、masterport是主节点的IP和端口。
哨兵系统实现故障转移
哨兵系统Sentinel是一种用于监控Redis主从节点状态的系统能够在主节点故障时自动进行故障转移。
工作原理哨兵通过发送命令检查主从节点的健康状态。如果主节点不可达哨兵会自动将其中一个从节点提升为新的主节点并更新其他从节点以指向新的主节点。 优点
自动故障转移提高了系统的可用性当主节点出现故障时能够快速恢复。监控哨兵还负责监控Redis节点的运行状态提供了一定程度的自动管理。
配置示例
# 哨兵配置文件 sentinel.conf
sentinel monitor mymaster masterip masterport 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel monitor mymaster这条命令让哨兵监控一个名为 mymaster 的主节点其IP和端口分别为 masterip 和 masterport 。数字2表示当至少有两个哨兵认为主节点不可达时才会进行故障转移。这是为了避免因为网络闪断导致的误判。这也告诉我们如果需要更高的可用性哨兵进程也要部署多个一般3个或5个就够了。sentinel down-after-milliseconds mymaster 5000设置哨兵判断主节点为“下线”的时间。例如这里设置为5000毫秒5秒如果哨兵在这段时间内无法达到主节点则认为主节点下线。因为各种原因哨兵可能会出现误判的问题多等一会说不定又能访问主节点。sentinel failover-timeout mymaster 60000设置故障转移的超时时间单位是毫秒。在这个例子中设置为60000毫秒60秒。如果故障转移操作在这段时间内没有完成则会被取消。sentinel parallel-syncs mymaster 1设置在故障转移后同时可以有多少个从节点同时对新的主节点进行同步。这里设置为1意味着一次只有一个从节点可以同步。在故障转移后所有从服务器都需要与新的主服务器进行全量同步以保证数据一致性。由于全量同步会阻塞从节点并且可能会消耗较大的网络带宽和CPU资源所以通过限制并发同步的从节点数量可以避免过多从节点同时进行同步带来的资源压力过大问题。
集群架构实现数据冗余
Redis集群通过分片的方式来存储数据每个分片存储不同的数据。通过多个节点的协作实现数据的冗余和分布式存储。
工作原理Redis集群将所有的数据分为16384个哈希槽每个节点负责一部分哈希槽。客户端根据特定的哈希规则将数据存储到相应的节点上。 优点
数据分片实现了数据的自动分片便于管理大规模数据。高可用性集群中的节点可以相互备份即使部分节点失败也不会影响整个集群的可用性。
配置示例 配置Redis集群涉及到启动多个Redis实例可使用redis-cli工具创建集群
# 启动Redis实例假设启动6个实例作为示例
redis-server --port 7000 --cluster-enabled yes --cluster-config-file nodes-7000.conf --cluster-node-timeout 5000 --appendonly yes --appendfilename appendonly-7000.aof --dbfilename dump-7000.rdb --logfile 7000.log
# 重复上述命令修改端口为7001-7005# 使用redis-cli创建集群
redis-cli --cluster create ip1:7000 ip2:7001 ip3:7002 ip4:7003 ip5:7004 ip6:7005 --cluster-replicas 1
--cluster-enabled yes启用Redis集群模式。--cluster-config-file nodes-7000.conf指定集群的配置文件。这个文件由Redis自动维护记录了集群中所有节点的信息。--cluster-node-timeout 5000设置节点超时时间单位是毫秒。如果一个节点在这段时间内没有响应集群会认为该节点已经下线。--appendonly yes启用AOF持久化模式。在集群模式下推荐使用AOF持久化来保证数据安全。--appendfilename appendonly-7000.aof指定AOF文件的名字。这里根据不同的端口号为每个实例指定了不同的AOF文件名以避免冲突。--dbfilename dump-7000.rdb指定RDB文件的名字。同样地根据不同的端口号为每个实例指定了不同的RDB文件名。--logfile 7000.log指定日志文件的名字。这有助于在出现问题时进行故障排查。 通过主从架构、哨兵系统和集群架构可以有效地实现数据的多副本保存、故障转移和数据冗余提高系统的可靠性和可用性基本上可以避免单机系统的数据丢失问题。
跨机房部署
服务器所在的机房也可能出现问题比如光缆被挖断了、空调系统坏了、机房着火了等实际出现过的状况为了解决这些问题我们还可以通过跨机房的方法来提升Redis的数据可靠性和可用性。
在不同机房间部署主从复制架构。在一个数据中心内设置主节点在另一个或多个数据中心设置从节点。Sentinel哨兵集群也应跨机房部署以避免单点故障。使用Redis Cluster进行跨机房部署每个机房都可以有多个分片shard并且每个分片的主节点和从节点分别位于不同的地理位置这样即使一个机房完全不可用其他机房的副本仍然能够提供服务。
跨机房部署时需要自行解决网络的通信问题让各个节点之间可以无障碍的相互访问机房间最好使用低延迟、高带宽的专线连接以加速数据同步过程并降低网络问题导致的数据不一致风险。
还有面试中经常提及的两地三中心的多活架构也可以安排上。每个机房都部署一套完整的、独立处理读写请求的Redis集群并通过分布式锁或者数据同步中间件等技术保证各个集群间数据的一致性。
分布式锁可以采用ZooKeeper、etcd、redis等确保在多个数据中心进行同步更新时只有一个数据中心的Redis集群在给定时间内对某个资源拥有写权限。数据同步中间件主要用于实时或近实时地将一个数据中心的写入操作同步到另一个数据中心。可以使用消息队列、专业的数据同步工具比如阿里巴巴开源的Canal等。多活架构还要设计数据分片策略、数据路由机制以及事务处理方式比如根据地域或者一致性Hash分片来区分用户然后使用客户端驱动路由或者网关路由来把用户导向不同的机房最后使用分布式事务提交数据。
多活架构比较复杂我也没有实际搞过这里就不多说了。
其他运维措施
日常运维中的定期检查和文件备份虽然平时看起来不起眼但在关键时刻却能发挥巨大作用。
运维工具检测
就像我们用手表监测心率一样使用专业的运维工具可以帮助我们实时监控Redis服务器的状态包括性能指标、资源使用情况、可能的瓶颈等。
具体做法
选择合适的工具市面上有许多优秀的运维监控工具如Prometheus结合Grafana、Zabbix等可以根据自己的需求和环境选择。定制监控项根据你的具体需求定制监控项。比如内存使用率、磁盘使用率、命令执行延迟、连接数等这些都是常见的监控指标。设置告警设置阈值一旦监控到的数据超过这个阈值就会触发告警。这就像是你的手表在你心率异常时提醒你帮助你及时发现并处理问题。
定期备份数据
备份就是我们给文件买了一份保险无论是误操作还是系统故障都能够确保数据不会丢失可以快速恢复到备份时的状态。
具体做法
定期执行设定一个合理的备份频率比如每天凌晨进行一次。频率的选择取决于你的业务需求和数据变化的频繁程度。自动化利用crontab等工具自动化备份流程让备份工作自动化进行减少人为遗忘的风险。远程存储将备份文件存储在远程服务器或云存储服务上。这样做的好处是即使本地发生灾难性事件数据仍然是安全的。
通过实施这些常规措施我们可以大大提高数据的安全性和系统的稳定性。
总结
说了这么多让我们做一个总结。
如果你的业务对数据的完整性要求非常高建议开启AOF持久化并设置合理的fsync策略如每秒同步一次。同时配合使用主从复制和哨兵系统以确保数据的高可用性和安全性。
对于读写性能有极高要求的场景可以考虑只使用RDB持久化或者RDB与AOF结合的方式数据完整性要求高AOF用于故障恢复RDB用于重启加速。同时通过增加从节点和合理分配读写负载可以进一步提升性能、提高数据安全性。
如果业务数据量巨大单个Redis实例难以满足存储需求那么Redis集群是一个不错的选择。它通过分片来实现数据的分布式存储同时保持高可用性。
日常的监控和备份也要搞起来如果服务和数据及其重要跨机房部署可以提供极大的数据安全性和系统稳定性。至于传说中的多活架构不到万不得已不要轻易尝试极为复杂成本很高。
最后不要忘了定期演练搞了这么多的机制到底能不能发挥作用有没有被不小心搞坏定期演练可以提前发现问题及时解决避免更大的损失。 以上就是本文的主要内容。
关注萤火架构加速技术提升
