课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
缓存是我们在学习软件架构的时候需要重点掌握的一个技术知识,而今天我们就一起来了解一下,缓存的应用都有哪些方法。
redis在架构上其实承担着两个角色,一个是缓存,另一个是内存计算服务。
共享的缓存其实出现得比较早,广泛使用的memcached诞生于2003年。
缓存以及后面出现的[[ES]]等全文搜索引擎很大程度缓解了[[数据库]]的压力,甚至改变了数据库在架构中的一些使用方式。比如之前对数据库使用推崇读写分离,但缓存引入之后,数据库的读写量差异已经不大,所以不少设计又回归到在线业务全部使用主库的设计,这个设计更加简单,还能规避掉很多因为数据库主从不一致导致的幻读等问题。ES则大幅度解放了对数据库索引的需求,引入ES后,数据索引一般只用于必要的主键、外键、性约束等场景。
缓存的使用其实需要比较谨慎,因为每引入一处缓存就需要解决一处同步问题。我个人比较喜欢在两端加缓存:API出口以及紧邻数据库的区域,这两种之外一般还会有三方调用缓存、计算缓存等场景。
对于API出口,一般情况下会设计成对于单个实体的缓存周期略长,但在使用缓存时会先校验关键元素(实体本身以及被引用的其他身体)版本是否变更;对于列表则会设计成较低缓存周期(比如1-5分钟),但查询时不做任何检查。
对于紧邻数据库的场景,则需要严肃考虑缓存淘汰机制。一般我缓存的目标会是一个领域对象,而不是简单的数据库的一行。更新领域对象时,会先更新数据库,然后清理缓存。但这种处理方式仍然没法严格保证一致性,一般解决方式有三种,a.设置缓存有效期b.用一个延时队列再清理一次缓存c.使用分布式事务锁。
考虑到b/c两种方式成本高,普通场景下用a的比较多。这种方式对多中心的设计也比较友好,当多中心数据库同步时,只需要对同步的每一个Entity都清理对应的缓存的即可。对于紧邻数据库的列表型缓存,一般也有两种处理手法,一种是短缓存周期存储全部内容;另一种是中缓存周期,但只保存ID。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请在707945861群中学习了解。