缓存和数据库一致性

已于 2024-01-17 15:53:24 修改
阅读量1.2k 收藏 19
点赞数 19
文章标签： 缓存 数据库
于 2024-01-13 17:46:03 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_47743353/article/details/135569733
版权

前言：

项目的难点是如何保证缓存和数据库的一致性。无论我们是先更新数据库，后更新缓存还是先更新数据库，然后删除缓存，在并发场景之下，仍然会存在数据不一致的情况（也存在删除失败的情况，删除失败可以使用异步重试解决）。有一种解决方法是延迟双删的策略，先删除缓存，再更新数据库，然后休眠一会儿，再删除一次缓存，这样做可以提高提高数据的一致性，但是，延迟的时间是要根据业务需求决定的，需要谨慎设置，同时由于删除了两次缓存，导致性能下降。这个项目中选择的是借助canal，订阅binlog的方式来实现同步。当我们对数据进行修改的时候，数据库就有一个binlog，用canal订阅这个binlog，并将消息投放到kafka中，获取到变更数据的id，删除缓存，如果失败，则重新从消息队列中获得该数据进行重试，超过次数后提示错误信息。重试使用的是@Retryable注解，有最大重试次数、重试延迟时间等属性，如果三次重试后仍然失败，会抛出 RuntimeException，然后触发@recover注解标记的备用方法。

（把canal.serverMode = kafka，canal.destinations = example （对应一个数据库实例），

在example下修改MySQL实例配置文件，设置用户名、登陆密码、需要同步的表，topic等等）

然后创建消费者，接收topic传过来的消息，进行解析，获取id，删除缓存。

canal本质（工作原理）

  • canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送 dump 协议；
  • MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )；
  • canal 解析 binary log 对象(原始为 byte 流)；
  • 并将其发送给下游消息队列
     
/**
 * canal 发送过来的消息
 *
 * @author huan.fu 2021/9/2 - 下午4:06
 */
@Getter
@Setter
@ToString
public class CanalMessage {

    /**
     * 测试得出 同一个事物下产生多个修改，这个id的值是一样的。
     */
    private Integer id;

    /**
     * 数据库或schema
     */
    private String database;
    /**
     * 表名
     */
    private String table;
    /**
     * 主键字段名
     */
    private List<String> pkNames;
    /**
     * 是否是ddl语句
     */
    private Boolean isDdl;
    /**
     * 类型:INSERT/UPDATE/DELETE
     */
    private String type;
    /**
     * binlog executeTime, 执行耗时
     */
    private Long es;
    /**
     * dml build timeStamp, 同步时间
     */
    private Long ts;
    /**
     * 执行的sql,dml sql为空
     */
    private String sql;
    /**
     * 数据列表
     */
    private List<Map<String, Object>> data;
    /**
     * 旧数据列表,用于update,size和data的size一一对应
     */
    private List<Map<String, Object>> old;
}

import org.springframework.kafka.annotation.KafkaListener;
import org.springframework.retry.annotation.Backoff;
import org.springframework.retry.annotation.Recover;
import org.springframework.retry.annotation.Retryable;
import org.springframework.stereotype.Component;

@Component
@Slf4j
public class KafkaConsumer {

    @KafkaListener(topics = "customer", groupId = "canal-kafka-springboot-001", concurrency = "5")
    @Retryable(maxAttempts = 3, backoff = @Backoff(delay = 1000))
    public void consumer(ConsumerRecord<String, String> record, Acknowledgment ack) throws InterruptedException {
        log.info(Thread.currentThread().getName() + ":" + LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")) + "接收到kafka消息,partition:" + record.partition() + ",offset:" + record.offset() + "value:" + record.value());

        CanalMessage canalMessage = JSON.parseObject(record.value(), CanalMessage.class);

        log.info("\r=================================");
        log.info("接收到的原始 canal message为: {}", record.value());
        log.info("转换成Java对象后转换成Json为 : {}", JSON.toJSONString(canalMessage));

        // 重试删除缓存的操作
        retryDeleteCache(canalMessage);

        ack.acknowledge();
    }

    @Retryable(maxAttempts = 3, backoff = @Backoff(delay = 1000))
    private void retryDeleteCache(CanalMessage canalMessage) {
        // 实现删除缓存的逻辑，如果失败将会重试，最多三次
        try {
            // 删除缓存的操作
            deleteCache(canalMessage);
        } catch (Exception e) {
            // 处理删除缓存失败的异常
            log.error("删除缓存失败：{}", e.getMessage());
            throw new RuntimeException("删除缓存失败");
        }
    }

    private void deleteCache(CanalMessage canalMessage) {
        // 实际的删除缓存的操作
        // ...
        log.info("删除缓存成功");
    }

    @Recover
    private void recoverAfterMaxAttempts(Exception e, CanalMessage canalMessage) {
        // 在达到最大重试次数后执行的备用方法
        log.error("删除缓存达到最大重试次数，执行备用方法：{}", e.getMessage());
        // 可以在这里处理达到最大重试次数后的逻辑，例如记录日志、发送通知等
    }
}

先更新数据库，后更新缓存

假设我们采用「先更新数据库，再更新缓存」的方案，并且两步都可以「成功执行」的前提下，如果存在并发，情况会是怎样的呢？

有线程 A 和线程 B 两个线程，需要更新「同一条」数据，会发生这样的场景：

  1. 线程 A 更新数据库（X = 1）

  2. 线程 B 更新数据库（X = 2）

  3. 线程 B 更新缓存（X = 2）

  4. 线程 A 更新缓存（X = 1）

最终 X 的值在缓存中是 1，在数据库中是 2，发生不一致。A 虽然先于 B 发生，但 B 操作数据库和缓存的时间，却要比 A 的时间短，执行时序发生「错乱」，最终这条数据结果是不符合预期的。

先更新数据库，后删除缓存

依旧是 2 个线程并发「读写」数据：

  1. 缓存中 X 不存在（数据库 X = 1）

  2. 线程 A 读取数据库，得到旧值（X = 1）

  3. 线程 B 更新数据库（X = 2)

  4. 线程 B 删除缓存

  5. 线程 A 将旧值写入缓存（X = 1）

最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），也发生不一致。

相关代码：

    public R save(UserVO userVO) {
        User user = new User();
        BeanUtils.copyProperties(userVO, user);
        saveUser(user);
        //删除缓存
        redisTemplate.delete("userInfo:" + user.getUserName());
        return R.success("操作成功");
    }

在查询数据时，先从缓存获取，如果缓存没有，就从数据库查询，并同时存放到缓存上，这样保证了下次访问时数据能直接从缓存获取，减少了数据库压力

    public User getByUserName(String userName) {
        User user = (User) redisTemplate.opsForValue().get(userName);
        if (user != null) {
            return user;
        }
        user = this.getOne(Wrappers.<User>lambdaQuery().eq(User::getUserName, userName));
        redisTemplate.opsForValue().set("userInfo:" + userName, user);
        return user;
    }

但是执行redis的删除操作时，比如因为网络问题，或者redis本身服务问题，就会失败，而且多线程并发访问时，也会出现数据不一致的情况。

    //使用注解，直接实现先更新数据库，后删除缓存的操作
    @CacheEvict(value = "category",allEntries = true)       //删除某个分区下的所有数据

延迟双删：

  1. 首先，删除了 Redis 中的缓存数据，以确保接下来的读取操作会从数据库中读取最新的数据。
  2. 接着，更新数据库中的数据，将数据更新为最新的值。
  3. 在此之后，代码让当前线程休眠一段时间N，这个时间段是为了给数据库操作足够的时间来完成，确保数据已经持久化到数据库中。
  4. 最后，代码再次删除 Redis 中的缓存数据。这里是延迟双删的关键步骤。由于之前已经删除了缓存数据，再次删除的目的是为了防止在休眠的时间内有其他线程读取到旧的数据，加载到缓存中。

休眠时间的控制

  • 延迟时间要大于「主从复制」的延迟时间

  • 延迟时间要大于线程 B 读取数据库 + 写入缓存的时间

方案的选择：

  • 延时双删适用于对数据一致性要求较高的场景。它能够保证在数据库更新期间，读取请求不会读取到已经失效的缓存数据，从而保证数据的一致性。但是它需要进行两次缓存删除操作，可能会增加一定的资源开销;
  • 先更新数据库后删除缓存对性能要求较高的场景。它能够减少一次缓存删除的开销，但是在数据库更新期间，读取请求可能会读取到已经失效的缓存数据，从而导致数据不一致。
     

RedisUtils.del(key);// 先删除缓存    
updateDB(user);// 更新db中的数据    
Thread.sleep(N);// 延迟一段时间，在删除该缓存key    
RedisUtils.del(key);// 先删除缓存

最好的方法是开设一个线程池，在线程中删除key，而不是使用Thread.sleep进行等待，这样会阻塞用户的请求。

代码：

OrderController中新增接口：

/**
 * 下单接口：先更新数据库，再删缓存
 * @param sid
 * @return
 */
@RequestMapping("/createOrderWithCacheV2/{sid}")
@ResponseBody
public String createOrderWithCacheV2(@PathVariable int sid) {
    int count = 0;
    try {
        // 完成扣库存下单事务
        orderService.createPessimisticOrder(sid);
        // 删除库存缓存
        stockService.delStockCountCache(sid);
    } catch (Exception e) {
        LOGGER.error("购买失败：[{}]", e.getMessage());
        return "购买失败，库存不足";
    }
    LOGGER.info("购买成功，剩余库存为: [{}]", count);
    return String.format("购买成功，剩余库存为：%d", count);
}

新增线程池接口

// 延时双删线程池
private static ExecutorService cachedThreadPool = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS,new SynchronousQueue<Runnable>());
 
 
/**
 * 缓存再删除线程
 */
private class delCacheByThread implements Runnable {
    private int sid;
    public delCacheByThread(int sid) {
        this.sid = sid;
    }
    public void run() {
        try {
            LOGGER.info("异步执行缓存再删除，商品id：[{}]， 首先休眠：[{}] 毫秒", sid, DELAY_MILLSECONDS);
            Thread.sleep(DELAY_MILLSECONDS);
            stockService.delStockCountCache(sid);
            LOGGER.info("再次删除商品id：[{}] 缓存", sid);
        } catch (Exception e) {
            LOGGER.error("delCacheByThread执行出错", e);
        }
    }
}

异步重试：

将删除缓存的请求写到消息队列中，如果删除成功，则去除消息；如果删除失败，执行失败策略，重试服务从消息队列中重新读取这些值，然后再次进行删除重试，重试超过的一定次数，向业务层发送报错信息。但是这在一定程度上也会增加代码的耦合度和维护成本。

高内聚，低耦合：耦合指模块与模块之间的关系，依赖程度，尽量减少一个模块过度依赖另一个模块的情况（我们在A元素去调用B元素，当B元素有问题或者不存在的时候，A元素就不能正常的工作，那么就说元素A和元素B耦合）。内聚模块内部的功能职责的相关性，如果元素有高度的相关职责，除了这些职责在没有其他的工作，那么该元素就有高内聚。这样做是为了可读性，复用性，可维护性和易变更性。

代码实现（使用rocketmq）：

pom.xml新增rocketmq依赖：

<rocketmq-spring-boot-starter-version>2.0.3</rocketmq-spring-boot-starter-version>

<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-client</artifactId>
    <version>4.9.3</version>
</dependency>
<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-spring-boot-starter</artifactId>
    <version>${rocketmq-spring-boot-starter-version}</version>
</dependency>

yaml配置

rocketmq:
  name-server: xxx.xxx.xxx.174:9876;xxx.xxx.xxx.246:9876
  producer:
    group: shopDataGroup

创建服务：

@Override
@Transactional
public Result updateShopById(Shop shop) {
    Long id = shop.getId();
    if(ObjectUtil.isNull(id)){
        return Result.fail("====>店铺ID不能为空");
    }
    log.info("====》开始更新数据库");
    //更新数据库
    updateById(shop);
    String shopRedisKey = SHOP_CACHE_KEY + id;
    Message message = new Message(TOPIC_SHOP,"shopRe",shopRedisKey.getBytes());
    //异步发送MQ
    try {
        rocketMQTemplate.getProducer().send(message);
    } catch (Exception e) {
        log.info("=========>发送异步消息失败：{}",e.getMessage());
    }
    //stringRedisTemplate.delete(SHOP_CACHE_KEY + id);
    //int i = 1/0;  验证异常流程后，
    return Result.ok();
}

创建消费者：

package com.hmdp.mq;
/**
 * @author xbhog
 * @describe:
 * @date 2022/12/21
 */
@Slf4j
@Component
@RocketMQMessageListener(topic = TOPIC_SHOP,consumerGroup = "shopRe",
        messageModel = MessageModel.CLUSTERING)
public class RocketMqNessageListener  implements RocketMQListener<MessageExt> {
    @Resource
    private StringRedisTemplate stringRedisTemplate;

    @SneakyThrows
    @Override
    public void onMessage(MessageExt message) {
        log.info("========>异步消费开始");
        String body = null;
        body = new String(message.getBody(), "UTF-8");
        stringRedisTemplate.delete(body);
        int reconsumeTimes = message.getReconsumeTimes();
        log.info("======>重试次数{}",reconsumeTimes);
        if(reconsumeTimes > 3){
            log.info("消费失败：{}",body);
            return;
        }
        throw new RuntimeException("模拟异常抛出");
    }

}

kafuka的删除重试机制：Kafka 生产者负责将删除缓存的请求发送到指定主题，而 Kafka 消费者则监听该主题，处理删除缓存的逻辑。在处理失败时，通过不提交偏移量来实现消息的重试。

import org.apache.kafka.clients.consumer.*;
import org.apache.kafka.common.TopicPartition;

import java.time.Duration;
import java.util.Collections;
import java.util.Properties;

public class CacheDeletionConsumer {

    private static final String TOPIC = "cache-deletion-topic";
    private static final String GROUP_ID = "cache-deletion-group";
    private static final String BOOTSTRAP_SERVERS = "your_bootstrap_servers";

    public static void main(String[] args) {
        Properties props = new Properties();
        props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, BOOTSTRAP_SERVERS);
        props.put(ConsumerConfig.GROUP_ID_CONFIG, GROUP_ID);
        props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");
        props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");

        try (KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props)) {
            consumer.subscribe(Collections.singletonList(TOPIC));

            while (true) {
                ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));

                for (ConsumerRecord<String, String> record : records) {
                    try {
                        // 处理删除缓存的业务逻辑
                        processCacheDeletion(record);

                        // 如果删除成功，手动提交偏移量
                        consumer.commitSync();
                    } catch (Exception e) {
                        // 处理删除缓存失败，不提交偏移量，消息将在下次拉取时重新获取
                        handleCacheDeletionFailure(record, e);
                    }
                }
            }
        }
    }

    private static void processCacheDeletion(ConsumerRecord<String, String> record) {
        // 实际的删除缓存逻辑
        String cacheKey = record.value().substring("DELETE_CACHE:".length());
        System.out.println("Deleting cache for key: " + cacheKey);
    }

    private static void handleCacheDeletionFailure(ConsumerRecord<String, String> record, Exception e) {
        // 处理删除缓存失败的逻辑，可以记录日志、进行重试等
        System.err.println("Error deleting cache for key: " + record.value() + ". Exception: " + e.getMessage());
    }
}

参考：两难！先更新数据库再删缓存？还是先删缓存再更新数据库？-CSDN博客

https://www.cnblogs.com/xbhog/p/17004151.html

订阅binlog异步删除，使用canal

流程如下图所示：

（1）更新数据库数据

（2）数据库会将操作信息写入binlog日志当中

（3）canal订阅程序提取出所需要的数据以及key

（4）另起一段非业务代码，获得该信息

（5）尝试删除缓存操作，发现删除失败

（6）将这些信息发送至消息队列

（7）重新从消息队列中获得该数据，重试操作

canal基础知识：

Canal组件是一个基于MysQL数据库增量日志解析,提供增量数据订阅和消费,支持将增量数据投递到下游消费者(如Kafka、RocketMQ等)或者存储(如Elasticsearch、HBase等)的组件。

binlog的格式：

canal工作原理

  1. Canal将自己伪装为MysQL slave(从库),向MysQL master(住库)发送dump协议
  2. MysQLmaster(主库)收到dump请求,开始推送binarylog给slave(即canal).
  3. Canal接收并解析Binlog日志,得到变更的数据,执行后续逻辑

修改配置支持binlog：

修改canal.properties配置：

修改mysql文件的instance.properties配置：

代码：

//1.获取canal连接对象
CanalConnector canalConnector=CanalConnectors.newSingleConnector(new InetSocketAddress(   hostname:"localhost",port:11111),destination:"example",username:"",password:"");
    while(true){
        //2.获取连接
        canalConnector.connect(;
        //3.指定要监控的数据库
        canalConnector.subscribe( s:"canal-demo.*");
        //4.获取Message
        Message message =canalConnector.get(100);
        List<CanalEntry.Entry>entries =message.getEntries();
        if(entries.size()<=0){
            System.out.println("没有数据,休息一会");
            try {
                Thread.sleep(millis:1000);
            }catch(InterruptedException e){
                e.printStackTrace();
            }
        }else{
            for(CanalEntry.Entry entry:entries){
            //获取表名
            String tableName =entry.getHeader().getTableName();
            //Entry类型
            CanalEntry.EntryType entryType =entry.getEntryType();
            //判断entryType 是否为ROWDATA
            if (CanalEntry.EntryType.ROWDATA.equals(entryType)){    
            //序列化数据
            ByteString storeValue =entry.getStoreValue();
            // 反序列化
            CanalEntry.RowChange rowChange =CanalEntry.RowChange.parseForm(storeValue);
            //获取事件类型
            CanalEntry.EventType eventType =rowChange.getEventType();
            //获取具体的数据
            List<CanalEntry.RowData>rowDatasList =rowChange.getRowDatasList();
            //遍历并打卬
            for (CanalEntry.RowData rowData : rowDatasList){
                //获取变更前的列
                List<CanalEntry.Column> beforeColumnsList = rowData.getBeforeColumnsList();
                Map<String,0bject>bMap=new HashMap<>();
                for (CanalEntry.CoLumn coLumn : beforeCoLumnsList)
                    //列名和对应的值
                    Map.put(column.getName(O),column.getValue(0);
                    Map<String,0bject> afMap =new HashMap>();
                    //变更后的
                    List<CanalEntry.ColumnafterColumnsList=rowData.getAfterColumnsList();

问:Canal是什么?有哪些特性?
答:Canal是阿里巴巴开源的一款基于Netty实现的分布式、高性能、可靠的消息队列,在实时数据同步和数据分发场景下有着广泛的应用。Canal具有以下特性:支持MysQL、Oracle等数据库的日志解析和订阅;支持多种数据输出方式,如Kafka、RocketMQ、ActiveMQ等;支持支持数据过滤和格式转换;拥有低延迟和高可靠性等优秀的性能指标。
问:Canal的工作原理是什么?
答:Canal主要通过解析数据库的binlog日志来获取到数据库的增、删、改操作,然后将这些变更事件发送给下游的消费者。Canal核心组件包括Client和Server两部分,Client负责连接数据库,并启动日志解析工作,将解析出来的数据发送给Server;Server则负责接收Client发送的数据,并进行数据过滤和分发。Canal还支持多种数据输出器,如Kafka、RocketMQ、ActiveMQ等,可以将解析出来的数据发送到不同的消息队列中,以便进行进一步的处理和分析。
问:Canal的优缺点是什么?
答:Canal的优点主要包括:高性能、分布式、可靠性好、支持数据过滤和转换、跨数据库类型(如MysQL、Oracle等)等。缺点包括:使用难度较大、对数据库的日志产生一定的影响、不支持数据的回溯(即无法获取历史数据)等。
问:Canal在业务中有哪些应用场景?
答:Canal主要用于实时数据同步和数据分发场景,常见的应用场景包括:数据备份与灾备、增量数据抽取和同步、数据实时分析、在线数据迁移等。特别是在互联网大数据场景下,Canal已经成为了各种数据处理任务的重要工具之一。

榛果嗨
关注
  • 19
    点赞
  • 踩
  • 19
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
查看表最后DML和DDL时间
cizhaorun3127的博客
05-06 1115
查看表最后DML和DDL时间 SQL> create table uuu as select * from emp; 表已创建。 SQL> select ora_rowscn,t.* f...
缓存与数据库一致性保证
03-01
（1）啥时候数据库和缓存中的数据会不一致 （2）不一致优化思路 （3）如何保证数据库与缓存的一致性
简化ETL工作，编写一个Canal胶水层
Throwable
10-06 6442
前提❝这是一篇憋了很久的文章，一直想写，却又一直忘记了写。整篇文章可能会有点流水账，相对详细地介绍怎么写一个小型的"框架"。这个精悍的胶水层已经在生产环境服役超过半年，这...
hive常用基础DML
qq_37283909的博客
03-19 204
DML: 基本的Select操作 语法结构:与sql语法基本相同 SELECT [ALL | DISTINCT] select_expr, select_expr, ... FROM table_reference [WHERE where_condition] [GROUP BY col_list [HAVING condition]] [CLUSTER BY col_list | ...
flink教程-详解flink 1.11 中的CDC (Change Data Capture)
热门推荐
公众号[大数据技术与应用实战]，分享大数据实战案例
07-27 3万+
文章目录CDC简介CanalCanalJson反序列化源码解析 CDC简介 CDC,Change Data Capture,变更数据获取的简称，使用CDC我们可以从数据库中获取已提交的更改并将这些更改发送到下游，供下游使用。这些变更可以包括INSERT,DELETE,UPDATE等， 用户可以在以下的场景下使用CDC： 使用flink sql进行数据同步,可以将数据从一个数据同步到其他的地方，比如mysql、elasticsearch等。 可以在源数据库上实时的物化一个聚合视图 因为只是增量同步，所以可以
缓存和数据库一致性问题
scorpio的博客
03-30 4176
如何保证缓存与数据库双写一致性问题
缓存和数据库一致性解决方案
程序员子龙
07-19 782
引入缓存后，需要考虑缓存和数据库一致性问题，可选的方案有「更新数据库+更新缓存」、「更新数据库+删除缓存」更新数据库+更新缓存方案
【全网最详细】如何保证缓存和数据库一致性
loss_rose777的博客
04-12 1227
最全面最容易理解的关于数据库与缓存一致性问题的描述，以及解决方案的文章，看这一篇绝对够了！
如何保证Redis缓存和数据库一致性
csdn_life18的博客
03-15 815
这里可以结合使用canal(阿里的一款开源框架)，通过该框架可以对MySQL的binlog进行订阅，而canal正是模仿了mysql的slave数据库的备份请求，使得Redis的数据更新达到了相同的效果。，或者是分布式队列按顺序去操作数据库或者 Redis，带来的副作用就是：数据库本来是并发的，现在变成串行的了，加锁或者排队执行的方案降低了系统性能，所以这个方案看起来不太可行。其实这种机制，很类似MySQL的主从备份机制，因为MySQL的主备也是通过binlog来实现的数据一致性。
如何保证Redis缓存和数据库一致性？
justin_sunshine的博客
03-13 3867
如何保证Redis缓存和数据库一致性？
redis缓存和数据库一致性
Summer_i的博客
04-08 1139
redis 数据库双写一致性
分布式之数据库和缓存双写一致性方案解析
01-27
本文由以下三个部分组成1、讲解缓存更新策略2、对每种策略进行缺点分析3、针对缺点给出改进方案先做一个说明，从理论上来说，给缓存设置过期时间，是保证最终一致性的解决方案。这种方案下，我们可以对存入缓存的...
如何保证缓存和数据库数据的一致性
07-06
如何保证缓存和数据库数据的一致性 知识点： 缓存：读、写、更新、删除，这些操作可能失败； 数据库：读、写、更新、删除，这些操作可能失败。 面试题剖析 一般来说，如果允许缓存可以稍微的跟数据库偶尔有不一致的...
Redis缓存与数据库一致性解决方案1
08-03
【Redis缓存与数据库一致性解决方案】 在高并发的业务环境中，数据库常常成为性能瓶颈。因此，引入Redis作为缓存来分担数据库的压力是常见的优化手段。然而，这种架构会带来缓存与数据库之间的一致性问题。主要问题...
【Redis】-缓存以及Serializable接口
cnzzs的博客
06-28 198
问题当用户访问量比较大时，某个业务功能需要频繁查询数据库，会让数据库访问压力增大，会导致系统响应慢，用户体验差解决通过Redis来缓存数据，减少数据库查询操作实例当我们在小程序点餐时，每次都需要通过查询数据库来获取菜品的数据，那么当用户量一多的时候，就会让数据库的访问压力增大，导致系统响应慢，现在就需要通过Redis来缓存...
java:aocache的单实例缓存(二)
10km的专栏
06-29 145
之前一篇博客介绍了使用注解实现单实例缓存的方式，同时也指出了这种方式的使用限制，就是这个注解定义的构造方法，不能再创建出新实例。为了更灵活方便的实现单实例。aocache最新版本0.4.0增加了支持单实例缓存的工具类SingletonSingleton提供了两种方法分别提供弱引用单实例缓存，和普通强引用单实例。
深入Ruby缓存：掌握Memcached的使用艺术
最新发布
2401_85341950的博客
06-29 831
在现代Web应用中，缓存是提高性能的关键技术之一。Memcached作为一个高性能的分布式内存缓存系统，与Ruby的结合使用可以显著提升应用的响应速度。本文将详细介绍在Ruby中如何集成和使用Memcached，包括安装、配置、基本操作和实际应用示例。Memcached是一个基于内存的分布式缓存系统，它支持多种协议进行数据存储和检索，适用于处理大量数据的高并发环境。
CXL：拯救NVMe SSD缓存不足设计难题-1
存储随笔
06-25 1108
这意味着设备能够利用全局范围的内存资源，而不受制于单一主机的内存限制，从而显著扩展了可用内存容量，减轻了主机应用程序对设备内存的干扰，并促进了由设备驱动的性能提升。内存语义SSD结合了成本效益高的字节寻址DRAM和SSD，用作CPU可访问的缓存，但受限于DRAM容量和缓存命中率，未命中的情况会导致延迟问题。：DRAM的密度增长速度落后于闪存，这意味着即便有技术手段能够克服物理空间的限制，DRAM的增加也无法与快速扩增的闪存容量保持同步，进一步加剧了SSD内部DRAM不足的问题。
cpu，缓存，辅存，主存之间的关系及特点
2301_80064376的博客
06-28 385
CPU是计算机系统的核心处理单元，负责执行指令和处理数据。缓存是高速小容量存储器，位于CPU和主存之间，用于减少访问主存的延迟。主存是大容量存储器，用于存储当前被CPU处理的程序和数据。辅存是超大容量存储器，用于长期存储数据和程序，速度较慢但非易失。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值