高并发高可用复杂系统中的缓存架构(二十) 分布式缓存重建并发冲突问题以及 zookeeper 分布式锁解决方案

最新推荐文章于 2024-01-22 15:36:41 发布
最新推荐文章于 2024-01-22 15:36:41 发布
阅读量299 收藏
点赞数 1
分类专栏： 高可用缓存架构讲解 高可用缓存
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/liuerchong/article/details/107429794
版权

什么是分布式缓存重建并发冲突问题？

很简单，多个缓存服务实例提供服务，发现缓存失效，那么就会去重建，这个时候回出现以下几种情况：

  1. 多个缓存实例都去数据库获取一份数据，然后放入缓存中

  2. 新数据被旧数据覆盖

    缓存 a 和 b 都拿了一份数据，a 拿到 12:00:01 的数据，b 拿到 12:00:05 的数据

    缓存 b 先写入 redis，缓存 a 后写入。

以上问题有多重解决方案，如：

  1. 利用 hash 分发

    相同商品分发到同一个服务中，服务中再用队列去重建

    但是这就变成了有状态的缓存服务，压力全部集中到同一个服务上

  2. 利用 kafka 队列

    源头信息服务，在发送消息到 kafka topic 的时候，都需要按照 product id 去分区

    和上面 hash 方案类似

  3. 基于 zookeeper 分布式锁的解决方案

分布式锁：多个机器在访问同一个共享资源，需要给这个资源加一把锁，让多个机器串行访问

对于分布式锁，有很多种实现方式，比如 redis 也可以实现。

这里讲解 zk 分布式锁，zk 做分布式协调比较流程，大数据应用里面 hadoop、storm 都是基于 zk 去做分布式协调

zk 分布式锁的解决并发冲突的方案

  1. 变更缓存重建以及空缓存请求重建，更新 redis 之前，都需要先获取对应商品 id 的分布式锁

  2. 拿到分布式锁之后，需要根据时间版本去比较一下，如果自己的版本新于 redis 中的版本，那么就更新，否则就不更新

  3. 如果拿不到分布式锁，那么就等待，不断轮询等待，直到自己获取到分布式的锁

基于 zk 进行分布式锁的代码封装；

zk 分布式锁原理简单介绍

  1. 创建一个 zk 临时 node，来模拟一个商品 id 加锁

  2. zk 会保证一个 node path 只会被创建一次，如果已经被创建，则抛出 NodeExistsException

  3. 这个时候可以去做业务操作

  4. 释放锁，则是删除这个临时 node。

当一个多个缓存服务去对同一个商品 id 加锁时，只有一个成功， 其他的则轮循等待锁被释放，获取到锁之后，对比一下商品的时间版本，较新则重建缓存，否则放弃重建

基于 zkClient 封装分布式锁工具

zk 分布式锁有很多种实现方式，这里演示一种最简单的，但是比较实用的分布式锁

添加依赖: compile 'org.apache.zookeeper:zookeeper:3.4.5'

zk client 初始化代码

/**
 * ${todo}

 */
public class ZooKeeperSession {
    private ZooKeeper zookeeper;
    private CountDownLatch connectedSemaphore = new CountDownLatch(1);
​
    private ZooKeeperSession() {
        String connectString = "192.168.99.170:2181,192.168.99.171:2181,192.168.99.172:2181";
        int sessionTimeout = 5000;
        try {
            // 异步连接，所以需要一个  org.apache.zookeeper.Watcher 来通知
            // 由于是异步，利用 CountDownLatch 来让构造函数等待
            zookeeper = new ZooKeeper(connectString, sessionTimeout, event -> {
                Watcher.Event.KeeperState state = event.getState();
                System.out.println("watch event：" + state);
                if (state == Watcher.Event.KeeperState.SyncConnected) {
                    System.out.println("zookeeper 已连接");
                    connectedSemaphore.countDown();
                }
            });
        } catch (IOException e) {
            e.printStackTrace();
        }
        try {
            connectedSemaphore.await();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("zookeeper 初始化成功");
    }
​
    private static ZooKeeperSession instance = new ZooKeeperSession();
​
    public static ZooKeeperSession getInstance() {
        return instance;
    }
​
    public static void main(String[] args) {
        ZooKeeperSession instance = ZooKeeperSession.getInstance();
    }
}

运行测试之后输出信息

watch event：SyncConnected
zookeeper 已连接
zookeeper 初始化成功

接下来编写加锁与释放锁的逻辑

public class ZooKeeperSession {
    private ZooKeeper zookeeper;
    private CountDownLatch connectedSemaphore = new CountDownLatch(1);
​
    private ZooKeeperSession() {
        String connectString = "192.168.99.170:2181,192.168.99.171:2181,192.168.99.172:2181";
        int sessionTimeout = 5000;
        try {
            // 异步连接，所以需要一个  org.apache.zookeeper.Watcher 来通知
            // 由于是异步，利用 CountDownLatch 来让构造函数等待
            zookeeper = new ZooKeeper(connectString, sessionTimeout, event -> {
                Watcher.Event.KeeperState state = event.getState();
                System.out.println("watch event：" + state);
                if (state == Watcher.Event.KeeperState.SyncConnected) {
                    System.out.println("zookeeper 已连接");
                    connectedSemaphore.countDown();
                }
            });
        } catch (IOException e) {
            e.printStackTrace();
        }
        try {
            connectedSemaphore.await();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("zookeeper 初始化成功");
    }
​
    /**
     * 获取分布式锁
     */
    public void acquireDistributedLock(Long productId) {
        String path = "/product-lock-" + productId;
        byte[] data = "".getBytes();
        try {
            // 创建一个临时节点，后面两个参数一个安全策略，一个临时节点类型
            // EPHEMERAL：客户端被断开时，该节点自动被删除
            zookeeper.create(path, data, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);
            System.out.println("获取锁成功 product[id=" + productId + "]");
        } catch (Exception e) {
            e.printStackTrace();
            // 如果锁已经被创建，那么将异常
            // 循环等待锁的释放
            int count = 0;
            while (true) {
                try {
                    TimeUnit.MILLISECONDS.sleep(20);
                    // 休眠 20 毫秒后再次尝试创建
                    zookeeper.create(path, data, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);
                } catch (Exception e1) {
                    e1.printStackTrace();
                    count++;
                    continue;
                }
                System.out.println("获取锁成功 product[id=" + productId + "] 尝试了 " + count + " 次.");
                break;
            }
        }
    }
​
    /**
     * 释放分布式锁
     */
    public void releaseDistributedLock(Long productId) {
        String path = "/product-lock-" + productId;
        try {
            zookeeper.delete(path, -1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        } catch (KeeperException e) {
            e.printStackTrace();
        }
    }
​
    private static ZooKeeperSession instance = new ZooKeeperSession();
​
    public static ZooKeeperSession getInstance() {
        return instance;
    }
​
    public static void main(String[] args) throws InterruptedException {
        ZooKeeperSession instance = ZooKeeperSession.getInstance();
        CountDownLatch downLatch = new CountDownLatch(2);
        IntStream.of(1, 2).forEach(i -> new Thread(() -> {
            instance.acquireDistributedLock(1L);
            System.out.println(Thread.currentThread().getName() + " 得到锁并休眠 10 秒");
            try {
                TimeUnit.SECONDS.sleep(10);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            instance.releaseDistributedLock(1L);
            System.out.println(Thread.currentThread().getName() + " 释放锁");
            downLatch.countDown();
        }).start());
        downLatch.await();
    }
}

运行 main 测试两个线程获取锁的等待过程如下

watch event：SyncConnected
zookeeper 已连接
zookeeper 初始化成功
获取锁成功 product[id=1]
Thread-1 得到锁并休眠 10 秒
​
循环异常中...
org.apache.zookeeper.KeeperException$NodeExistsException: KeeperErrorCode = NodeExists for /product-lock-1
    at org.apache.zookeeper.KeeperException.create(KeeperException.java:119)
​
Thread-1 释放锁
获取锁成功 product[id=1] 尝试了 285 次.
Thread-0 得到锁并休眠 10 秒
Thread-0 释放锁

可以看到，日志输出，证明分布式锁已经编写成功

 

 

 

 主动更新

缓存生产服务接收基础信息更改事件的时候，有一个操作是更新本地缓存和 redis 中的缓存，
这个场景下也存可能存在并发冲突情况。所以这里也可以使用分布式锁来保证数据错乱问题

KafkaMessageProcessor#processProductInfoChangeMessage

回顾下现在的实现代码。以商品为例，来展示怎么使用分布式锁

```java
/**
 * 处理商品信息变更的消息
 */
private void processProductInfoChangeMessage(JSONObject messageJSONObject) {
    // 提取出商品id
    Long productId = messageJSONObject.getLong("productId");

    // 调用商品信息服务的接口
    // 直接用注释模拟：getProductInfo?productId=1，传递过去
    // 商品信息服务，一般来说就会去查询数据库，去获取productId=1的商品信息，然后返回回来

    String productInfoJSON = "{\"id\": 1, \"name\": \"iphone7手机\", \"price\": 5599, \"pictureList\":\"a.jpg,b.jpg\", \"specification\": \"iphone7的规格\", \"service\": \"iphone7的售后服务\", \"color\": \"红色,白色,黑色\", \"size\": \"5.5\", \"shopId\": 1}";
    ProductInfo productInfo = JSONObject.parseObject(productInfoJSON, ProductInfo.class);
    cacheService.saveProductInfo2LocalCache(productInfo);
    log.info("获取刚保存到本地缓存的商品信息：" + cacheService.getProductInfoFromLocalCache(productId));
    cacheService.saveProductInfo2ReidsCache(productInfo);
}
```

使用分布式锁之后

```java
private void processProductInfoChangeMessage(JSONObject messageJSONObject) {
    // 提取出商品id
    Long productId = messageJSONObject.getLong("productId");
    // 增加了一个 modifyTime 字段，来比较数据修改先后顺序
    String productInfoJSON = "{\"id\": 1, \"name\": \"iphone7手机\", \"price\": 5599, \"pictureList\":\"a.jpg,b.jpg\", \"specification\": \"iphone7的规格\", \"service\": \"iphone7的售后服务\", \"color\": \"红色,白色,黑色\", \"size\": \"5.5\", \"shopId\": 1," +
            "\"modifyTime\":\"2019-05-13 22:00:00\"}";
    ProductInfo productInfo = JSONObject.parseObject(productInfoJSON, ProductInfo.class);

    // 加锁
    ZooKeeperSession zks = ZooKeeperSession.getInstance();
    zks.acquireDistributedLock(productId);
    try {
        // 先获取一次 redis ，防止其他实例已经放入数据了
        ProductInfo existedProduct = cacheService.getProductInfoOfReidsCache(productId);
        if (existedProduct != null) {
            // 判定通过消息获取到的数据版本和 redis 中的谁最新
            Date existedModifyTime = existedProduct.getModifyTime();
            Date modifyTime = productInfo.getModifyTime();
            // 如果本次获取到的修改时间大于 redis 中的，那么说明此数据是最新的，可以放入 redis 中
            if (modifyTime.after(existedModifyTime)) {
                cacheService.saveProductInfo2LocalCache(productInfo);
                log.info("最新数据覆盖 redis 中的数据：" + cacheService.getProductInfoFromLocalCache(productId));
                cacheService.saveProductInfo2ReidsCache(productInfo);
            }
        } else {
            // redis 中没有数据，直接放入
            cacheService.saveProductInfo2LocalCache(productInfo);
            log.info("获取刚保存到本地缓存的商品信息：" + cacheService.getProductInfoFromLocalCache(productId));
            cacheService.saveProductInfo2ReidsCache(productInfo);
        }
    } finally {
        // 最后释放锁
        zks.releaseDistributedLock(productId);
    }
}
```

## 缓存重建

回顾下重建的地方

```java
/**
 * 这里的代码别看着奇怪，简单回顾下之前的流程： 1. nginx 获取 redis 缓存 2. 获取不到再获取服务的堆缓存（也就是这里的 ecache） 3.
 * 还获取不到就需要去数据库获取并重建缓存
 */
@RequestMapping("/getProductInfo")
@ResponseBody
public ProductInfo getProductInfo(Long productId) {
    ProductInfo productInfo = cacheService.getProductInfoOfReidsCache(productId);
    log.info("从 redis 中获取商品信息");
    if (productInfo == null) {
        productInfo = cacheService.getProductInfoFromLocalCache(productId);
        log.info("从 ehcache 中获取商品信息");
    }
    if (productInfo == null) {
        // 两级缓存中都获取不到数据，那么就需要从数据源重新拉取数据，重建缓存
        // 但是这里暂时不讲
        log.info("缓存重建 商品信息");
    }
    return productInfo;
}
```

如上代码，都获取不到数据的时候，就需要从数据库读取数据进行重建。

第一版思路：

1. 从数据库读取数据
2. 队列异步重建
3. 返回第一步的数据

下面来实现下这个代码（先不考虑该思路是否有问题）

RebuildCache

```java
/**
 * 缓存重建；一个队列对应一个消费线程
 *

 */
@Component
public class RebuildCache {
    private Logger log = LoggerFactory.getLogger(getClass());
    private ArrayBlockingQueue<ProductInfo> queue = new ArrayBlockingQueue<>(100);
    private CacheService cacheService;

    public RebuildCache(CacheService cacheService) {
        this.cacheService = cacheService;
        start();
    }

    public void put(ProductInfo productInfo) {
        try {
            queue.put(productInfo);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public ProductInfo take() {
        try {
            return queue.take();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return null;
    }

    // 启动一个线程来消费

    private void start() {
        new Thread(() -> {
            while (true) {
                try {
                    ProductInfo productInfo = queue.take();
                    Long productId = productInfo.getId();
                    ZooKeeperSession zks = ZooKeeperSession.getInstance();
                    zks.acquireDistributedLock(productId);
                    try {
                        // 先获取一次 redis ，防止其他实例已经放入数据了
                        ProductInfo existedProduct = cacheService.getProductInfoOfReidsCache(productId);
                        if (existedProduct != null) {
                            // 判定通过消息获取到的数据版本和 redis 中的谁最新
                            Date existedModifyTime = existedProduct.getModifyTime();
                            Date modifyTime = productInfo.getModifyTime();
                            // 如果本次获取到的修改时间大于 redis 中的，那么说明此数据是最新的，可以放入 redis 中
                            if (modifyTime.after(existedModifyTime)) {
                                cacheService.saveProductInfo2LocalCache(productInfo);
                                log.info("最新数据覆盖 redis 中的数据：" + cacheService.getProductInfoFromLocalCache(productId));
                                cacheService.saveProductInfo2ReidsCache(productInfo);
                            } else {
                                log.info("此次数据版本落后，放弃重建");
                            }
                        } else {
                            // redis 中没有数据，直接放入
                            cacheService.saveProductInfo2LocalCache(productInfo);
                            log.info("缓存重建成功" + cacheService.getProductInfoFromLocalCache(productId));
                            cacheService.saveProductInfo2ReidsCache(productInfo);
                        }
                    } finally {
                        // 最后释放锁
                        zks.releaseDistributedLock(productId);
                    }
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }
}

```

controller 中使用该队列

```java
/**
 * 这里的代码别看着奇怪，简单回顾下之前的流程： 1. nginx 获取 redis 缓存 2. 获取不到再获取服务的堆缓存（也就是这里的 ecache） 3.
 * 还获取不到就需要去数据库获取并重建缓存
 */
@RequestMapping("/getProductInfo")
@ResponseBody
public ProductInfo getProductInfo(Long productId) {
    ProductInfo productInfo = cacheService.getProductInfoOfReidsCache(productId);
    log.info("从 redis 中获取商品信息");
    if (productInfo == null) {
        productInfo = cacheService.getProductInfoFromLocalCache(productId);
        log.info("从 ehcache 中获取商品信息");
    }
    if (productInfo == null) {
        // 两级缓存中都获取不到数据，那么就需要从数据源重新拉取数据，重建缓存
        // 假设这里从数据库中获取的数据
        String productInfoJSON = "{\"id\": 1, \"name\": \"iphone7手机\", \"price\": 5599, \"pictureList\":\"a.jpg,b.jpg\", \"specification\": \"iphone7的规格\", \"service\": \"iphone7的售后服务\", \"color\": \"红色,白色,黑色\", \"size\": \"5.5\", \"shopId\": 1," +
                "\"modifyTime\":\"2019-05-13 22:00:00\"}";
        productInfo = JSONObject.parseObject(productInfoJSON, ProductInfo.class);
        rebuildCache.put(productInfo);
    }
    return productInfo;
}
```

缓存重建出现在两个地方：

  1. 当基础服务信息变更之后（被动）

  2. 当所有缓存失效之后（主动）

一个主动一个被动，他们的执行逻辑都相同，其实可以使用一个队列逻辑来处理缓存重建

缓存重建重要依赖「zk 分布式锁」让多个实例/操作 串行化起来。避免脏数据覆盖新数据

 

liu1002880404
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
高并发手册.pdf
01-05
本资源摘要信息主要介绍高并发手册的相关知识点，涵盖了高并发手册的概述、架构设计、高并发解决方案、负载均衡、数据库高并发解决方案、NoSQL数据库、ESB、Zookeeper、Master-Slave架构等多方面的内容。 一、高...
大型分布式网站架构设计与实践.带目录书签.完整版
06-25
在IT行业中，大型分布式网站架构设计与实践是构建高可用、高性能、高可扩展的互联网应用的核心技术。这种架构能够处理海量用户访问、大数据量处理和复杂业务逻辑，确保服务的稳定性和效率。以下是该主题的一些关键...
架构系列---分布式缓存重建并发冲突问题以及zookeeper分布式锁解决方案
FeelTouch Labs
06-12 712
本篇讲解分布式缓存重建冲突原因及利用zookeeper分布式锁解决缓存重建冲突问题。 缓存重建什么意思呢？ 比如应用跑了一段时间，缓存（redis cluster）实例中的部分数据由于被LRU等算法或者其他手段清理了，这时候就需要重新到数据源中拉取数据，然后重新设置到缓存中。 分布式缓存重建又是什么意思呢？ 比如在多个node节点上部署了相同的服务实例，对外提供服务，就会出现多个node分...
分布式重建缓存的并发冲突 详解
chenshun123的博客
05-29 1680
在分布式系统中，如果缓存服务在本地的 Ehcache 中都读取不到数据，此时需要重新到源头的服务中去拉去数据，拉取到数据之后，赶紧先给 Nginx 的请求返回，同时将数据写入 Ehcache 和 Redis中。此时会出现分布式重建缓存的并发冲突问题重建缓存 : 比如数据在所有的缓存中都不存在 (如使用 LRU算法 给清理掉)，就需要重新查询数据写入缓存，重建缓存分布式的重建缓存 : 在不同的机器上...
redis使用—缓存在高并发下的问题及分布式锁
qq_38151401的博客
01-09 663
目录 一、redis整合过程 1 引入pom依赖信息(本工程所有redis统一放入service-util) 2 写一个reids的工具类(用来将redis的池初始化到spring容器中) 3 写一个spring整合redis的配置类 4 注意：每个以用工程引入service-util后，单独配置自己的redis的配置文件 5、使用：通过缓存查询的代码测试 6、在高并发环境下还有如下...
Redis 高并发场景下热点缓存的重建策略
最新发布
记录一下
01-22 1166
在高并发的系统中，缓存是提升性能的关键。然而，当面临热点缓存的问题时，即某些缓存数据频繁被请求，就可能导致缓存雪崩、穿透等问题。为了应对这种情况，需要制定合适的策略进行热点缓存的重建。
架构系列---利用zookeeper 分布式锁解决缓存重建冲突实战
FeelTouch Labs
06-13 855
上一篇 分布式缓存重建并发冲突问题以及zookeeper分布式锁解决方案， 主要讲解了分布式缓存重建冲突原因及利用zookeeper分布式锁解决缓存重建冲突问题，本篇接着上篇，实现上篇思路，带你利用zookeeper代码实现分布式锁解决重建缓存冲突问题。 缓存重建分析图 从上图我们可以看出： 缓存主动更新 我们监听kafka中的缓存操作消息队列，当接收到一个商品变更消息后，我们会立即根...
分布式ID常见解决方案.docx
10-26
在分布式环境中，生成ID面临的主要挑战包括全局唯一性、递增性和高可用高性能。 全局唯一性是ID的基本属性，确保每个ID在系统中都是独一无二的，避免数据冲突。递增性分为趋势递增和连续递增两种，趋势递增要求新的...
PyPI 官网下载 | gp_hashing-1.0.2.tar.gz
01-27
关于标签“zookeeper”、“分布式”和“云原生”，这些都暗示了“gp_hashing”可能被设计用于处理分布式系统和云环境中的问题。Zookeeper是Apache的一个项目，它提供了一个分布式服务框架，用于协调分布式应用程序。...
advancedJava.rar
08-28
本资源"advancedJava.rar"聚焦于Java工程师的进阶学习，旨在帮助开发者掌握高级技术，包括高并发处理、分布式系统、高可用性设计以及微服务架构，以及海量数据的处理策略。 一、高并发 高并发是现代Web应用必备的...
分布式重建缓存的并发冲突问题
kang123488的博客
03-11 1292
分布式重建缓存的并发冲突问题缓存更新和缓存重建在不同机器上的并发冲突问题基于zookeeper分布式锁的冲突解决方案 重建缓存： 比如我们这里，数据在所有的缓存中都不存在了（LRU算法弄掉了），就需要重新查询数据写入缓存，重建缓存 分布式的重建缓存，在不同的机器上，不同的服务实例中，去做上面的事情，就会出现多个机器分布式重建去读取 相同的数据，然后写入缓存中,可能出现分布式重建缓存的并发冲...
CountDownLatch详解
Code_Boy_Code的博客
06-08 650
CountDownLatch详解CountDownLatch的两种使用场景场景1 让多个线程等待：模拟并发，让多个线程同一时刻一起执行场景2 让单个线程等待：多个线程(任务)完成后，进行汇总合并需要注意的地方CountDownLatch 工作原理await()方法阻塞当前线程countDown()方法则是将计数器减1CountDownLatch与Thread.joinCountDownLatch与CyclicBarrier参考 CountDownLatch的两种使用场景 先来看看 CountDownLatc
Webpack配置
nanxun201314的博客
03-15 2777
Loader本质就是一个函数，在该函数中对接收到的内容进行转换，返回转换后的结果。因为 Webpack 只认识 JavaScript，所以 Loader 就成了翻译官，对其他类型的资源进行转译的预处理工作。Plugin就是插件，基于事件流框架Tapable，插件可以扩展 Webpack 的功能，在 Webpack 运行的生命周期中会广播出许多事件，Plugin 可以监听这些事件，在合适的时机通过 Webpack 提供的 API 改变输出结果。
Redis面试相关问题
m0_49608323的博客
11-15 726
1.Redis 双写不一致导致的问题 背景：使用到缓存，无论是本数据库做缓存还是使用Redis 做缓存，那么就会存在数据同步的问题，因为配置信息缓存在内存中，而内存是无法感知到数据在数据库的修改。这样就造成数据不一致性的问题。 共有四种方案： 1.先更新数据库，后更新缓存。 2.先更新缓存，再更新数据库。 3.先删除缓存，后删除数据库。 4.先更新数据库，后更新缓存。 第一种和第二种方案，没有人使用的，因为第一种方案存在问题是：并发更新数据库场景下，会将脏数据刷到缓存。 第二种方案存在的问题是：如果先更新缓
webpack中的代理配置proxy五种常用场景
jiao512的专栏
02-06 4213
请求到 /api/xxx 现在会被代理到请求 http://localhost:3000/api/xxx, 例如 /api/user 现在会被代理到请求 http://localhost:3000/api/user。请求到 /api/xxx 现在会被代理到请求 http://localhost:3000/xxx, 例如 /api/user 现在会被代理到请求 http://localhost:3000/user。例如：对于浏览器请求，你想要提供一个 HTML 页面，但是对于 API 请求则保持代理。
缓存数据生产服务中的zk分布式锁解决方案的代码实现（8）
闵浮龙的博客
02-27 519
zk分布式锁的代码封装 zookeeper java client api去封装连接zk，以及获取分布式锁，还有释放分布式锁的代码 zk分布式锁的原理 我们通过去创建zk的一个临时node，来模拟给摸一个商品id加锁 zk会给你保证说，只会创建一个临时node，其他请求过来如果再要创建临时node，就会报错，NodeExistsException 那么所以说，我们的所谓上锁，其实就是...
分布式缓存重建并发冲突问题以及zookeeper分布式锁解决方案（7）
闵浮龙的博客
02-27 1434
分布式重建缓存的并发冲突问题 重建缓存：比如我们这里，数据在所有的缓存中都不存在了（LRU算法弄掉了），就需要重新查询数据写入缓存，重建缓存 分布式的重建缓存，在不同的机器上，不同的服务实例中，去做上面的事情，就会出现多个机器分布式重建去读取相同的数据，然后写入缓存中 分布式重建缓存的并发冲突问题。。。。。。 1、流量均匀分布到所有缓存服务实例上 应用层nginx，是将请求流量均匀地...
缓存架构--问题篇
u014297572的博客
04-18 188
由问题引发思考，由思考进行学习。 （1）如何让redis集群支撑几十万QPS高并发+99.99%高可用+TB级海量数据+企业级数据备份与恢复？ redis企业级集群架构 （2）如何支撑高性能以及高并发到极致？同时给缓存架构最后的安全保护层？ (nginx+lua)+redis+ehcache的三级缓存架构 （3）高并发场景下，如何解决数据库与缓存双写的时候数据不一致的情况？ 企业级的完...
webpack http-proxy配置
weixin_34270865的博客
08-01 1374
为什么80%的码农都做不了架构师？>>> ...
"深度解密高并发分布式锁架构，优化资源竞争，实现高并发应用稳定运行
综上所述，本文基于高并发场景下的分布式锁应用需求，结合对分布式锁架构的深入解析和优化，为读者提供了系统的分布式锁选择和应用方案。通过本文的阅读与实践，读者可以更好地理解分布式锁的特性和优势，并在实际...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值