持久化配置最佳实践

发表于2026-04-09|更新于2026-04-09|后端

|浏览量:

RDB 持久化配置

手动触发RDB

save：会阻塞当前 Redis 服务器，直到持久化完成，线上应该禁止使用

bgsave：该触发方式会 fork 一个子进程，由子进程负责持久化过程，因此阻塞只会发生在 fork 子进程的时候

定时触发RDB

根据我们的 save m n 配置规则自动触发

从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发 bgsave

执行 shutdown 时，如果没有开启 aof，也会触发

AOF 持久化配置

AOF 重写：当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF文件的内容压缩，只保留可以恢复数据的最小指令集

触发机制：Redis 会记录上次重写时的 AOF 大小，默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64MB 时触发

bgrewriteaof 可以手动触发

重写原理：将整个内存中的数据库内容用命令的方式重写了一个新的 AOF 文件，这点和快照有点类似

持久化数据恢复

文章作者: 褚成志

文章链接: https://www.chucz.asia/2026/04/09/%E6%8C%81%E4%B9%85%E5%8C%96%E9%85%8D%E7%BD%AE%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5/

架构最佳实践

相关推荐

接口幂等方案

对于一个接口而言，无论调用了多少次，最终得到的结果都是一样的。幂等性的实现与判断需要消耗一定的资源，因此不应该给每个接口都增加幂等性判断，要根据实际的业务情况和操作类型来进行区分。在进行查询操作和删除操作时就无须进行幂等性判断。查询操作查一次和查多次的结果都是一致的，因此我们无须进行幂等性判断。删除操作也是一样，删除一次和删除多次都是把相关的数据进行删除（这里的删除指的是条件删除而不是删除所有数据），因此也无须进行幂等性判断。关键步骤每个请求操作必须有唯一的 ID，而这个 ID 就是用来表示此业务是否被执行过的关键凭证每次执行业务之前必须要先判断此业务是否已经被处理过第一次业务处理完成之后，要把此业务处理的状态进行保存，比如存储到 Redis 中或者是数据库中，这样才能防止业务被重复处理。前端拦截用户点击完“提交”按钮后，我们可以把按钮设置为不可用或者隐藏状态，避免用户重复点击。数据库实现数据库实现幂等性的方案有三个：通过悲观锁来实现幂等性开启事务实现原子操作 id 字段一定要是主键或者是唯一索引，不然会锁表，影响其他业务执行。通过唯一索引来实现...

日志放在拦截器还是过滤器

Filter过滤器是 Web 应用程序组件，可以在请求到达 Servlet 之前对其进行访问，也可以在响应信息返回到客户端之前对其进行拦截。 Filter 的接口方法： init：Serverlet 容器创建过滤器实例的时候调用 doFilter：拦截到达的请求，检查和处理Header的body的数据 destory：销毁过滤器，doFilter 中所有的方法超时之后，web 容器才会调用销毁链式调用： Interceptor拦截器是 AOP 的一种实现策略，用于在某个方法或宁段被访问前对它进行拦截，然后在其之前或之后加上某些操作。 Interceptor 的接口方法：preHandler、postHandler、afterCompletion HandlerInterceptor 的接口方法： preHandle：方法前置初始化操作，请求预处理，权限校验，返回Boolean postHandle：方法后置处理，Controller 调用之后，DispatcherServelet视图渲染之前处理 afterCompletion：请求处理完成，包括 DispatcherS...

消灭重复代码的最佳实践

代码重复本身不可怕，可怕的是漏改或改错。消灭重复代码，降低改动可能引入的风险。学习笔记：https://time.geekbang.org/column/article/228964 工厂模式 + 模板方法消除 if else 和重复代码假设要开发一个购物车下单的功能，针对不同用户进行不同处理：普通用户需要收取运费，运费是商品价格的 10%，无商品折扣； VIP 用户同样需要收取商品价格 10% 的快递费，但购买两件以上相同商品时，第三件开始享受一定折扣；内部用户可以免运费，无商品折扣。我们的目标是实现三种类型的购物车业务逻辑，把入参 Map 对象（Key 是商品 ID，Value 是商品数量），转换为出参购物车类型 Cart。原始代码12345678910111213141516171819202122232425262728//购物车@Datapublic class Cart { //商品清单 private List<Item> items = new ArrayList<>(); //总优惠 ...

群发红包系统

业务流程发红包输入金额以及人数创建红包订单（订单ID，金额，份数）调用支付系统红包订单支付之后红包就发出去了钱先拆好（行锁分散，加大并发）抢红包抢红包业务群，检测当前是否有剩余钱没有剩余直接返回，有剩余就将请求转发到Redis里面的list（先来先服务），同时将请求发到mq启动一个延时任务（对账作用），之后有一个worker调度中心监听Redis，也就是消费队列里面的消息。抢红包业务群会阻塞轮询worker调度中心是否抢到红包，之后返回给用户，这个过程用户看来是同步的，只是在后端用Redis的list实现了简单排下队异步。拆红包抢到红包之后，计算红包的金额，计算更新剩余的红包的余额。分支1：返回给用户分支2：将拆红包的流水写到数据库里面（MQ异步记账）红包结算（异常结算池）红包入账业务特点个数少，人数少：小系统个数多，人数少：美团。饿了么红包个数多，人数大：微信群红包个数少，人数多：春晚红包设计思路数据量大：分库分表避免所有请求都到达DB：Redis 并发请求量大：Redis高可用 + 分布式ID + 消息队列抢红包的...

分布式锁最佳实践

在单体的应用开发场景中涉及并发同步的时候，大家往往采用 Synchronized（同步）或者同一个JVM内Lock机制来解决多线程间的同步问题。在分布式集群工作的开发场景中，就需要一种更加高级的锁机制来处理跨机器的进程之间的数据同步问题，这种跨机器的锁就是分布式锁。超卖问题复现现象存在如下的几张表：商品表订单表订单item表 :::danger 商品的库存为1，但是并发高的时候有多笔订单。 ::: 错误案例一：数据库 update 相互覆盖直接在内存中判断是否有库存，计算扣减之后的值更新数据库，并发的情况下会导致相互覆盖发生： 123456789101112131415161718192021222324252627@Transactional(rollbackFor = Exception.class)public Long createOrder() throws Exception { Product product = productMapper.selectByPrimaryKey(purchaseProductId); ...

从消息队列理解Pull与Push模型底层逻辑

在构建分布式消息系统时，我们面临的一个基本决策是确定数据流动的方向：消费者是从代理 (Broker) 拉取数据，还是由代理主动将数据推送给消费者。这一决策不仅影响系统的性能和效率，还决定了系统的架构和可扩展性。推送 (Push) 模型的优势与局限在推送模型中，数据流是由生产者主动向代理发送数据，随后代理根据预先设定的规则或策略，将数据推送给注册的消费者，这种模型的优点包括较低的延迟和实时性更强的数据传递。然而，推送模型也有明显的局限性。首先，它对网络带宽的要求较高，特别是在高并发的场景下，大量的小数据包频繁传输会导致网络拥塞。例如，消费者的消费能力为 10 条/s，而生产者生产能力为 100 条/s，此时会导致大量请求向下积压，当然，可以在 mq (Broker) 处进行消息堆积，或利用死信队列等机制进行退回，但是相应的，对于 Broker 的服务器压力也会显著增大。其次，由于数据传输速率由代理控制，不同消费者之间的处理能力差异可能导致部分消费者无法及时处理接收到的数据，从而造成系统资源浪费或系统过载。特别是当消费者的处理速度低于生产者的生...

数据加载中