详谈分布式系统缓存的设计细节

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: 在分布式Web程序设计中,解决高并发以及内部解耦的关键技术离不开缓存和队列,而缓存角色类似计算机硬件中CPU的各级缓存。如今的业务规模稍大的互联网项目,即使在最初beta版的开发上,都会进行预留设计。但是在诸多应用场景里,也带来了某些高成本的技术问题,需要细致权衡。

在分布式Web程序设计中,解决高并发以及内部解耦的关键技术离不开缓存和队列,而缓存角色类似计算机硬件中CPU的各级缓存。如今的业务规模稍大的互联网项目,即使在最初beta版的开发上,都会进行预留设计。但是在诸多应用场景里,也带来了某些高成本的技术问题,需要细致权衡。

de1bcb22e069007e0631ac97a83a5e7459b87514 

服务端数据缓存

一种区分

缓存基于不同的条件有很多种划分方式,本地缓存(Local cache)和分布式缓存(Distributed cache)是一种常见分类,两者自身又包含很多细类。

本地并不是指程序所在本地服务器(从严格概念来说),而是更细粒度的指位于程序自身的内部存储空间,而分布式更多强调的是存储在进程之外的一个或者多个服务器上,彼此交互通信,在具体软件项目的设计和应用中,多数时候是混合一体。当然,个人认为对缓存本质的理解才是最重要的,至于概念上的分类只是一个不同理解下的划分而已。

一些技术成本

在具体项目架构设计时,单纯使用前者(本地缓存)的开发成本毋庸置疑是极低的,主要考虑的是本机的内存负载或者极少量的磁盘I/O影响。而后者的设计初心是为了利于分布式程序之间缓存数据的高效共享和管理,除了考虑缓存所在服务器自身的内存负载,设计时更需要充分考虑网络I/O、CPU的负载,以及某些场景下的磁盘I/O的代价,同时还在具体设计时尽可能规避和权衡整体稳定性和效率,这些不仅仅只是作为缓存服务器的硬件成本和技术维护。需要谨慎考虑的底层问题包括缓存间通信、网络负载和延迟等各种需要权衡的细节。

其实如果理解了缓存本质就该知道,任何存储介质在适当的场景下都可以充当一个高效的缓存角色并进行项目集成和缓存间集群。常见主流的Memcached和Redis等均是属于后者范畴,甚至可以包括如基于NoSQL设计的MongoDB这类文档数据库(但这是从角色角度讲,而狭义划分上这是基于磁盘的存储库,需要注意,各有专攻)。

这些第三方缓存在进行项目集成和缓存间集群,也需要解决一些问题。甚至项目迭代到了后期阶段,往往还需要具备较高专业知识的运维同时参与,并且在开发中的逻辑设计和代码实现也会增加一定的工作量。所以有时候在具体项目的设计上,一方面要尽可能预留,一方面还得根据实际情况尽可能精简。

额外说下其他体会:在个人有限的技术学习和实践里,关于节点数据交互,尤其是服务间通信,是不存在完美的闭环的,理论上也都是在“当前阶段”面向“高一致”的权衡罢了(大概跟生活是一样的吧)。

bd8d913f86121db5499340a39c62f9cf70004da1 

缓存数据库结构设计细节

由于目前个人工作中大多数情况应用的是Redis 3.x,以下若有特性关联,均是以此作为参照说明。

实例(Instance)

根据业务场景,公共数据和业务耦合数据,一定分别使用不同的实例。如果是单实例,才可以考虑以DB划分。当你使用的是Redis,那么DB在Redis里是有数据隔离,但没有严格权限限制,所以划库只是一种选择。在Cluster集群里则是保持默认单个库,不过实际中我会尝试根据项目大小来调整,至于在哪个开发阶段则是作为预留设计。

额外需要注意的是,作为重度依赖服务器内存的缓存产品,如果开启了持久化(后面会提到),并且在为并发量极大的服务提供支持时,服务器硬件资源会出现大量抢占,请结合持久策略配置,考虑实例是否进行分盘存储。

持久化本质是将内存数据同步写入硬盘(刷盘),而磁盘I/O实在有限,被迫的写入阻塞除了造成线程阻塞和服务超时,还会导致额外异常甚至波及其他底层依赖服务。当然,我的建议是,如果条件允许,最好是在项目初期设计时就进行规划并确定。

缓存“表”(Table)

一般缓存中并没有传统RDBMS中直观的表概念(往往以键值对“KV”形式存在),但从结构上来讲,键值对本身就可以组装为各种表结构。一般我会先生成数据库表关系图,然后分析什么时候存储字符串,什么时候存储对象,然后使用缓存键(KEY)进行表和字段(列)分割。

假定需要存储一个登录服务器表数据,包含字段(列):name、sign、addr,那么可以考虑将数据结构拆分为以下形式:

  { key : "server:name" , value : "xxxx" }

  { key : "server:sign" , value : "yyyy" }

  { key : "server:addr" , value : "zzzz" }

需要注意的是,往往在分布式缓存产品中,例如Redis,存在多种数据结构(如String、Hash等),还需要根据数据关联性和列的数量,来选择对应缓存的存储数据结构,相关存储空间和时间复杂度是完全不同的,而这个在初期阶段是很难感受到的。

同时,就算缓存的内存设置的足够大,剩余也很多,也同样需要考虑类似RDBMS中的单表容量问题,控制条目数量不能无限增长(比如预知到存储条目可以轻松达到百万级),“分库分表”的设计思路都是相通的。

缓存键(Key)

上面提到了基于缓存键来设计表,这里再单独说明一下键相关的个人规范。在键长度足够简短的前提下,如果关联相同业务模块,则必须设计为以同一个标识(代号)开头,目的是方便查找和统计管理。

如用户登录服务器列表:

  { key : "ul:server:a" , value : "xxxx" }

  { key : "ul:server:b" , value : "yyyy" }

另外,每个独立业务系统可考虑配置一个唯一的通用前缀标识。当然,这里不是必需,若实际工作中,如果使用的是不同库,则可以忽略。

缓存值(value)

缓存中的值(这里指单一条目)的大小没有平均标准,但Size自然是越小越好(若使用的是Redis,一次操作的value较大会直接影响整个Redis的响应时间,不仅仅是指网络I/O)。如果存储占用空间直达10M+,建议考虑关联的业务场景是否可以拆分为热点和非热点数据。

持久化(Permanence)

上面也简单提了下,一般来说,持久和缓存本身是没有直接关系的,可以粗略想象为一个面向硬盘一个面向内存。但如今的Web项目里,有些业务场景是高度依赖缓存的,持久化可以一方面帮助提高缓存服务重启后的快速恢复,另一方面提供特定场景下的存储特性。当然,由于持久化必然需要牺牲一些性能,包括CPU的抢占和硬盘I/O影响。不过大多数时候是利大于弊,建议在应用缓存的时候,没有特别情况的话,尽量搭配持久化,无论是使用自身机制还是第三方来实现。

如果是使用的Redis,其自身就具备相关持久策略,包含AOF和RDB,我在大多数情况下是两者同时配置的(当然,最新官方版本本身也提供了混合模式)。如果在一些非高并发的场景下,或者说在一些中小项目的管理模块里,仅仅只是作为优化手段,确定了不需持久,也可以直接设置关闭,节约性能开销损耗,但建议在程序中将该实例做好标注,确保该实例的公共使用范围。

淘汰(Eliminate)

缓存如果无限制的增长,即使设置了较短的过期(Expiration ),在一些时间点上,高并发的一批大数据会在较短时间内就达到了可使用内存的峰顶,此时程序中与缓存服务器的交互会出现大量延迟和错误,甚至给服务器自身都带来了严重的不稳定性。所以在生产环境里尽量给缓存配置最大内存限制,以及适当的淘汰策略。

如果使用的是Redis,自身淘汰策略选择比较灵活。

个人的设计是,在数据呈现类似幂律分布情况下,总有大量数据访问较低,我会选择配置allkeys-lru、volatile-lru,将最少访问的数据进行淘汰。再比如缓存是作为日志应用的,那么我一般是项目前期是配置no-enviction,后期会配置为volatile-ttl。

当然,我也见过一种特殊业务下的设计,缓存直接用来作为轻量的持久数据库使用,而且是终端,开始觉得有些新奇,后来发现是非常符合业务设计的(比如几乎没有任何复杂逻辑和强事务)。所以合情合理,确实不应该禁锢在传统设计里,毕竟架构总是基于业务去实时组合和改变的。

1f9314e0cfdce5f5d82c73cf393c93a45873f1d8 

 

 

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
4月前
|
缓存 NoSQL Java
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
这篇文章是关于如何在SpringBoot应用中整合Redis并处理分布式场景下的缓存问题,包括缓存穿透、缓存雪崩和缓存击穿。文章详细讨论了在分布式情况下如何添加分布式锁来解决缓存击穿问题,提供了加锁和解锁的实现过程,并展示了使用JMeter进行压力测试来验证锁机制有效性的方法。
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
|
3月前
|
缓存 NoSQL Java
谷粒商城笔记+踩坑(12)——缓存与分布式锁,Redisson+缓存数据一致性
缓存与分布式锁、Redisson分布式锁、缓存数据一致性【必须满足最终一致性】
144 14
谷粒商城笔记+踩坑(12)——缓存与分布式锁,Redisson+缓存数据一致性
|
2月前
|
存储 缓存 NoSQL
大数据-38 Redis 高并发下的分布式缓存 Redis简介 缓存场景 读写模式 旁路模式 穿透模式 缓存模式 基本概念等
大数据-38 Redis 高并发下的分布式缓存 Redis简介 缓存场景 读写模式 旁路模式 穿透模式 缓存模式 基本概念等
67 4
|
4月前
|
缓存 NoSQL Java
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解、如何添加锁解决缓存击穿问题?分布式情况下如何添加分布式锁
这篇文章介绍了如何在SpringBoot项目中整合Redis,并探讨了缓存穿透、缓存雪崩和缓存击穿的问题以及解决方法。文章还提供了解决缓存击穿问题的加锁示例代码,包括存在问题和问题解决后的版本,并指出了本地锁在分布式情况下的局限性,引出了分布式锁的概念。
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解、如何添加锁解决缓存击穿问题?分布式情况下如何添加分布式锁
|
5月前
|
canal 缓存 NoSQL
Redis常见面试题(一):Redis使用场景,缓存、分布式锁;缓存穿透、缓存击穿、缓存雪崩;双写一致,Canal,Redis持久化,数据过期策略,数据淘汰策略
Redis使用场景,缓存、分布式锁;缓存穿透、缓存击穿、缓存雪崩;先删除缓存还是先修改数据库,双写一致,Canal,Redis持久化,数据过期策略,数据淘汰策略
Redis常见面试题(一):Redis使用场景,缓存、分布式锁;缓存穿透、缓存击穿、缓存雪崩;双写一致,Canal,Redis持久化,数据过期策略,数据淘汰策略
|
4月前
|
缓存 NoSQL 关系型数据库
(八)漫谈分布式之缓存篇:唠唠老生常谈的MySQL与Redis数据一致性问题!
本文来聊一个跟实际工作挂钩的老生常谈的问题:分布式系统中的缓存一致性。
161 11
|
5月前
|
存储 缓存 NoSQL
高并发架构设计三大利器:缓存、限流和降级问题之Redis用于搭建分布式缓存集群问题如何解决
高并发架构设计三大利器:缓存、限流和降级问题之Redis用于搭建分布式缓存集群问题如何解决
100 1
|
5月前
|
存储 缓存 数据库
分布式篇问题之全量缓存解决数据库和缓存的一致性问题如何解决
分布式篇问题之全量缓存解决数据库和缓存的一致性问题如何解决
|
5月前
|
缓存 Devops 微服务
微服务01好处,随着代码越多耦合度越多,升级维护困难,微服务技术栈,异步通信技术,缓存技术,DevOps技术,搜索技术,单体架构,分布式架构将业务功能进行拆分,部署时费劲,集连失败如何解决
微服务01好处,随着代码越多耦合度越多,升级维护困难,微服务技术栈,异步通信技术,缓存技术,DevOps技术,搜索技术,单体架构,分布式架构将业务功能进行拆分,部署时费劲,集连失败如何解决
|
7月前
|
缓存 监控 数据库
分布式系统中缓存穿透问题与解决方案
在分布式系统中,缓存技术被广泛应用以提高系统性能和响应速度。然而,缓存穿透是一个常见而严重的问题,特别是在面对大规模请求时。本文将深入探讨缓存穿透的原因、影响以及一些有效的解决方案,以确保系统在面对这一问题时能够保持稳定和高效。
109 13