不用缓存服务,还能怎么缓存数据? 糖太宗 • 2022年5月15日 下午9:13 • 技术 • 阅读 43 除了常见的redis/memcache等进程外缓存服务,还能怎么缓存数据? 缓存还有一种常见的玩法,进程内缓存。 什么是进程内缓存? 将一些数据缓存在站点,或者服务的进程内,这就是进程内缓存。 进程内缓存的实现载体,最简单的,可以是一个带锁的Map。又或者,可以使用第三方库,例如leveldb。 进程内缓存能存储啥? redis/memcache等进程外缓存服务能存什么,进程内缓存就能存什么。 如上图,可以存储json数据,可以存储html页面,可以存储对象。 进程内缓存有什么好处? 与没有缓存相比,进程内缓存的好处是,数据读取不再需要访问后端,例如数据库。 如上图,整个访问流程要经过1,2,3,4四个步骤。 如果引入进程内缓存, 如上图,整个访问流程只要经过1,2两个步骤。 与进程外缓存相比(例如redis/memcache),进程内缓存省去了网络开销,所以一来节省了内网带宽,二来响应时延会更低。 进程内缓存有什么缺点? 统一缓存服务虽然多一次网络交互,但仍是统一存储。 如上图,站点和服务中的多个节点访问统一的缓存服务,数据统一存储,容易保证数据的一致性。 而进程内缓存,如上图,如果数据缓存在站点和服务的多个节点内,数据存了多份,一致性比较难保障。 如何保证进程内缓存的数据一致性? 保障进程内缓存一致性,有几种方案。 第一种方案,可以通过单节点通知其他节点。如上图:写请求发生在server1,在修改完自己内存数据与数据库中的数据之后,可以主动通知其他server节点,也修改内存的数据。 这种方案的缺点是:同一功能的一个集群的多个节点,相互耦合在一起,特别是节点较多时,网状连接关系极其复杂。 第二种方案,可以通过MQ通知其他节点。如上图,写请求发生在server1,在修改完自己内存数据与数据库中的数据之后,给MQ发布数据变化通知,其他server节点订阅MQ消息,也修改内存数据。 这种方案虽然解除了节点之间的耦合,但引入了MQ,使得系统更加复杂。 前两种方案,节点数量越多,数据冗余份数越多,数据同时更新的原子性越难保证,一致性也就越难保证。 第三种方案,为了避免耦合,降低复杂性,干脆放弃了“实时一致性”,每个节点启动一个timer,定时从后端拉取最新的数据,更新内存缓存。在有节点更新后端数据,而其他节点通过timer更新数据之间,会读到脏数据。 为什么不能频繁使用进程内缓存? 分层架构设计,有一条准则:站点层、服务层要做到无数据无状态,这样才能任意的加节点水平扩展,数据和状态尽量存储到后端的数据存储服务,例如数据库服务或者缓存服务。 可以看到,站点与服务的进程内缓存,实际上违背了分层架构设计的无状态准则,故一般不推荐使用。 什么时候可以使用进程内缓存? 以下情况,可以考虑使用进程内缓存。 情况一,只读数据,可以考虑在进程启动时加载到内存。 画外音:此时也可以把数据加载到redis / memcache,进程外缓存服务也能解决这类问题。 情况二,极其高并发的,如果透传后端压力极大的场景,可以考虑使用进程内缓存。 例如,秒杀业务,并发量极高,需要站点层挡住流量,可以使用内存缓存。 情况三,一定程度上允许数据不一致业务。 例如,有一些计数场景,运营场景,页面对数据一致性要求较低,可以考虑使用进程内页面缓存。 末了,再次强调,进程内缓存的适用场景并不如redis/memcache广泛,不要为了炫技而使用。 更多的时候,还是老老实实使用redis/mc吧。 画外音:额,介绍技术,不希望把大家带偏了。 发布者:糖太宗,转载请注明出处:https://www.qztxs.com/archives/science/technology/6863 缓存 赞 (0) 打赏 微信扫一扫 支付宝扫一扫 糖太宗 0 0 生成海报 MQ,究竟如何做到削峰填谷? 上一篇 2022年5月15日 下午9:11 InnoDB并发如此高,原因竟然在这? 下一篇 2022年5月15日 下午9:15 相关推荐 甲方安全建设的一些思路和思考 0x00 前言 本文主要是介绍一下笔者对于甲方安全能力建设的一些经验,心得和零散的思考。需要特别强调的是不同企业的实际情况不尽相同,本文仅供参考,不具普遍意义。 0x01 Red Teaming 近几年随着Red Team建设的话题越来越流行,不管是甲方或者乙方都在极力的发展自己的Red Teaming能力,尤其是各个乙方都推出了... 常山赵子龙 技术 2022年5月28日 21000 技术 除了解析域名,DNS还能干吗? 一个http请求,典型的执行流程是怎么样的呢? 可以看到,典型流程为: (1)客户端请求dns-server,发起域名解析; (2)dns-server返回域名对应的外网ip(1.2.3.4); (3)客户端通过外网ip(1.2.3.4),访问反向代理; (4)反向代理通过内网ip(192.168.x.x),将请求分发给web-server; (5)web-... 糖太宗 2022年5月14日 15000 技术 我C,一个库里Curry几百个表,这谁受得了? 随着业务越来越复杂,数据量越来越大,并发量越来越大,数据库的性能越来越低。好不容易找运维申请了两台机器,让DBA部署了几个实例,想把一些业务库拆分出来,却发现一个库里几百个表,拆不出来,扩不了容,尴尬! 因为数据库强关联在一起,无法通过增加数据库实例扩容,就是一个耦合的典型案例。 什么样的场景会出现这类耦合? 举个栗子。 有一个公共用户数据库DB... 糖太宗 2022年5月11日 12000 技术 为什么微服务并不是越早越好? 微服务架构,是分层架构演进过程中很重要的一环,那微服务是不是越早越好呢?今天和大家一起聊聊这一个问题。 什么时候进行DAO层的分层抽象? 最开始,分层架构长什么样? 一个业务系统最初的分层架构如上: (1)web-server层从db层获取数据并进行加工处理; (2)db层存储数据; 此时,web-server层如何获取底层的数据呢? web-serve... 糖太宗 2022年5月14日 29000 技术 百亿关系链,架构如何设计? 文章较长,听我娓娓道来。 粉丝与关注,社交好友,都是典型的“多对多关系”的业务,这类业务的核心服务是好友中心,当关系链达到百亿之后,好友中心架构设计要考虑哪些因素,是本文将要分享的内容。 什么是“多对多”关系? 所谓的“多对多”,来自数据库设计中的“实体-关系”ER模型,用来描述实体之间的关联关系,一个学生可以选修多个课程,一个课程可以被多个学生选修... 糖太宗 2022年5月14日 32000 发表回复 您的电子邮箱地址不会被公开。 必填项已用*标注*昵称: *邮箱: 网址: 记住昵称、邮箱和网址,下次评论免输入 提交