分布式系统架构7:本地缓存

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
应用实时监控服务-应用监控,每月50GB免费额度
简介: 这是小卷关于分布式系统架构学习的第10篇文章,主要介绍本地缓存的基础理论。文章分析了引入缓存的利弊,解释了缓存对CPU和I/O压力的缓解作用,并讨论了缓存的吞吐量、命中率、淘汰策略等属性。同时,对比了几种常见的本地缓存工具(如ConcurrentHashMap、Ehcache、Guava Cache和Caffeine),详细介绍了它们的访问控制、淘汰策略及扩展功能。

这是小卷对分布式系统架构学习的第10篇文章,在开始学习分布式缓存之前,先来学习本地缓存的理论基础,了解为什么需要用缓存

1.引入缓存的影响

我们在开发时,用到缓存的情况,无非就是为了减少客户端对相同资源的重复请求,降低服务器的负载压力。引入缓存后,既有好处也有坏处

引入缓存负面影响:

  • 开发角度,增加了系统复杂度,需考虑缓存失效、更新、一致性问题
  • 运维角度,缓存会掩盖一些缺陷问题
  • 安全角度,缓存可能泄密某些保密数据

引入缓存的理由:

  • 为了缓解CPU压力,将实时计算运行结果存储起来,节省CPU压力
  • 为了缓解I/O压力,将原本对网络、磁盘的访问改为对内存的访问

2.缓存的属性

选择缓存时,主要考虑吞吐量、命中率、扩展功能、分布式支持。 前3个这篇文章会讲,下一篇再讲分布式缓存

2.1吞吐量

并发场景下,每秒操作数OPS,反映了缓存的工作效率

如Java8并发包的ConcurrentHashMap,线程安全实现原理是CAS+synchronized锁单个元素。但是该类仅有缓存功能,没有命中率、淘汰策略、缓存统计等功能

并发场景下,不可避免的会有读写数据带来的状态竞争问题,当前有2种处理套路:

  • 以Guava Cache为代表的同步处理机制:在访问缓存数据时,一并完成缓存淘汰、统计、失效等状态变更操作,通过分段加锁等优化手段来尽量减少数据竞争。
  • 以Caffeine为代表的异步日志提交机制:参考经典的数据库设计理论,把对数据的读、写过程看作是日志(即对数据的操作指令)的提交过程。

Caffeine使用了环形缓冲区来记录状态变动日志,为进一步减少数据竞争,Caffeine给每个线程都设置了专用的环形缓冲区,如下是Wikipedia上的环形缓冲示意:

本地缓存1.gif

环形缓冲区结构中,读取和写入是一起进行的,只要读取指针不落后于写指针一圈,这个操作可以永久进行下去,容纳无限多的新字符。

如果不满足,则必须阻塞写指针,等待读取清空缓冲区

2.2 命中率与淘汰策略

缓存的容量是有限的,也因此需要自动地实现淘汰低价值目标,也就是缓存淘汰策略

主要实现方案有三种:

第一种:FIFO(First In First Out)

优先淘汰最早进入被缓存的数据。FIFO 的实现十分简单,但一般来说,越是频繁被用到的数据,往往越会早早地被存入缓存之中。

所以这种淘汰策略,很可能会大幅降低缓存的命中率

第二种:LRU(Least Recent Used)

优先淘汰最久未被使用访问过的数据。LRU 通常会采用 HashMap 加 LinkedList 的双重结构(如 LinkedHashMap)来实现。每次缓存命中时,将命中对象调整到LinkedList的头部,每次淘汰从链表尾部清理

存在问题:如果热点数据一段时间没被访问,就会被淘汰;

第三种:LFU(Least Frequently Used)

优先淘汰最不经常使用的数据。LFU 会给每个数据添加一个访问计数器,每访问一次就加 1,当需要淘汰数据的时候,就清理计数器数值最小的那批数据。

缺点:每个数据都需要维护计数器,不便于处理随时间变化的热点数据

以上只是列了三种基础的淘汰策略,实际Caffeine 官方还制定了两种高级淘汰策略:ARC(Adaptive Replacement Cache)和LIRS(Low Inter-Reference Recency Set),更复杂的淘汰策略都是为了提高命中率的。

3.扩展功能

缓存不是只实现一个Map接口就可以的,还需要一些额外的功能,下面列出缓存的扩展功能:

  • 加载器:从被动放入,变为主动通过加载器去加载指定 Key 值的数据
  • 淘汰策略:支持用户根据需要自行选择淘汰策略
  • 失效策略:缓存数据在超过一定时间内自动失效,Redis的策略是定时删除、定期删除、惰性删除
  • 事件通知:提供事件监听器,在数据状态变动时进行一些额外操作
  • 并发级别:如Guava Cache通过分段加锁来实现缓存的并发设置
  • 容量控制:设置初始容量和最大容量
  • 统计信息:命中率、平均加载时间、自动回收计数等信息
  • 持久化:将缓存数据存储到数据库或者磁盘

4.本地缓存对比

ConcurrentHashMap Ehcache Guava Cache Caffeine
访问控制 最高 一般 良好 优秀(接近ConcurrentHashMap)
淘汰策略 多种:FIFO、LRU、LFU等 LRU W-TinyLFU
扩展功能 无,只有基础访问接口 并发控制、失效策略、容量控制等 同左 同左
相关文章
|
27天前
|
存储 缓存 NoSQL
分布式系统架构8:分布式缓存
本文介绍了分布式缓存的理论知识及Redis集群的应用,探讨了AP与CP的区别,Redis作为AP系统具备高性能和高可用性但不保证强一致性。文章还讲解了透明多级缓存(TMC)的概念及其优缺点,并详细分析了memcached和Redis的分布式实现方案。此外,针对缓存穿透、击穿、雪崩和污染等常见问题提供了应对策略,强调了Cache Aside模式在解决数据一致性方面的作用。最后指出,面试中关于缓存的问题多围绕Redis展开,建议深入学习相关知识点。
166 8
|
1月前
|
存储 Prometheus Cloud Native
分布式系统架构6:链路追踪
本文深入探讨了分布式系统中的链路追踪理论,涵盖追踪与跨度的概念、追踪系统的模块划分及数据收集的三种方式。链路追踪旨在解决复杂分布式系统中请求流转路径不清晰的问题,帮助快速定位故障和性能瓶颈。文中介绍了基于日志、服务探针和边车代理的数据收集方法,并简述了OpenTracing、OpenCensus和OpenTelemetry等链路追踪协议的发展历程及其特点。通过理解这些概念,可以更好地掌握开源链路追踪框架的使用。
97 41
|
1月前
|
存储 关系型数据库 分布式数据库
[PolarDB实操课] 01.PolarDB分布式版架构介绍
《PolarDB实操课》之“PolarDB分布式版架构介绍”由阿里云架构师王江颖主讲。课程涵盖PolarDB-X的分布式架构、典型业务场景(如实时交易、海量数据存储等)、分布式焦点问题(如业务连续性、一致性保障等)及技术架构详解。PolarDB-X基于Share-Nothing架构,支持HTAP能力,具备高可用性和容错性,适用于多种分布式改造和迁移场景。课程链接:[https://developer.aliyun.com/live/253957](https://developer.aliyun.com/live/253957)。更多内容可访问阿里云培训中心。
[PolarDB实操课] 01.PolarDB分布式版架构介绍
|
2月前
|
设计模式 存储 算法
分布式系统架构5:限流设计模式
本文是小卷关于分布式系统架构学习的第5篇,重点介绍限流器及4种常见的限流设计模式:流量计数器、滑动窗口、漏桶和令牌桶。限流旨在保护系统免受超额流量冲击,确保资源合理分配。流量计数器简单但存在边界问题;滑动窗口更精细地控制流量;漏桶平滑流量但配置复杂;令牌桶允许突发流量。此外,还简要介绍了分布式限流的概念及实现方式,强调了限流的代价与收益权衡。
94 11
|
2月前
|
设计模式 监控 Java
分布式系统架构4:容错设计模式
这是小卷对分布式系统架构学习的第4篇文章,重点介绍了三种常见的容错设计模式:断路器模式、舱壁隔离模式和重试模式。断路器模式防止服务故障蔓延,舱壁隔离模式通过资源隔离避免全局影响,重试模式提升短期故障下的调用成功率。文章还对比了这些模式的优缺点及适用场景,并解释了服务熔断与服务降级的区别。尽管技术文章阅读量不高,但小卷坚持每日更新以促进个人成长。
66 11
|
2月前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
73 11
|
4月前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
|
8天前
|
缓存 NoSQL 中间件
Redis,分布式缓存演化之路
本文介绍了基于Redis的分布式缓存演化,探讨了分布式锁和缓存一致性问题及其解决方案。首先分析了本地缓存和分布式缓存的区别与优劣,接着深入讲解了分布式远程缓存带来的并发、缓存失效(穿透、雪崩、击穿)等问题及应对策略。文章还详细描述了如何使用Redis实现分布式锁,确保高并发场景下的数据一致性和系统稳定性。最后,通过双写模式和失效模式讨论了缓存一致性问题,并提出了多种解决方案,如引入Canal中间件等。希望这些内容能为读者在设计分布式缓存系统时提供有价值的参考。感谢您的阅读!
86 9
Redis,分布式缓存演化之路
|
2月前
|
存储 NoSQL Java
使用lock4j-redis-template-spring-boot-starter实现redis分布式锁
通过使用 `lock4j-redis-template-spring-boot-starter`,我们可以轻松实现 Redis 分布式锁,从而解决分布式系统中多个实例并发访问共享资源的问题。合理配置和使用分布式锁,可以有效提高系统的稳定性和数据的一致性。希望本文对你在实际项目中使用 Redis 分布式锁有所帮助。
210 5
|
3月前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
101 8