关于进程内缓存与分布式缓存
此文仅只是一个回顾。顾名思义,进程内缓存是在与应用程序相同的地址空间内构建的对象缓存。Google Guava库提供了一个简单的进程内缓存API,这是一个很好的例子。
另一方面,分布式缓存在应用程序外部,很可能部署在形成大型逻辑缓存的多个节点上。Memcached,Redis 都是流行的分布式缓存,还有Hazelcast, Terracotta Ehcache是一种可以配置为以任何一种方式运行的产品。
考虑 | 进程内缓存 | 分布式缓存 | 评论 |
一致性 | 使用进程内缓存时,缓存元素位于应用程序的单个实例本地。但是,许多中型到大型应用程序将没有一个应用程序实例,因为它们很可能是负载平衡的。在这种设置下,最终将获得与应用程序实例一样多的缓存,每个缓存具有不同的状态,从而导致不一致。但是,状态可能最终会随着缓存项超时而保持一致,或者从所有缓存实例中逐出。 | 分布式缓存虽然部署在多个节点的群集上,但提供了缓存的单个逻辑视图(和状态)。在大多数情况下,存储在分布式缓存群集中的对象将驻留在分布式缓存群集中的单个节点上。通过散列算法,缓存引擎始终可以确定特定键值位于哪个节点上。由于缓存集群始终只有一个状态,因此它永远不会不一致。 | 如果要缓存不可变的对象,则一致性不再是问题。在这种情况下,进程内缓存是一个更好的选择,因为通常不存在与外部分布式缓存关联的许多开销。如果应用程序部署在多个节点上,则缓存可变对象,并且希望读取始终保持一致性而不是最终保持一致性,那么分布式缓存是理想之选。 |
开销Overheads | 进程内缓存如何主要由于垃圾回收GC开销而对嵌入式缓存的应用程序的性能产生负面影响。但是,结果在很大程度上取决于诸如高速缓存的大小以及驱逐和超时对象的速度等因素。 | 分布式缓存将有两个主要开销,这将使其比进程内缓存慢(但比根本不缓存更好):网络延迟和对象序列化 | 如前所述,如果要在多节点部署中寻找始终一致的全局缓存状态,则要寻找分布式缓存(以牺牲本地进程内缓存的性能为代价) 。 |
可靠性Reliability | 进程内高速缓存使用与程序相同的堆空间,因此在确定高速缓存的内存使用上限时必须小心。如果程序内存不足,则没有简单的方法可以从中恢复。 | 分布式缓存在多个节点上作为独立的进程运行,因此单个节点的故障不会导致缓存的完全故障。由于节点故障,不再缓存的项目将进入下一个缓存未命中的幸存节点。同样在分布式缓存的情况下,与完全系统故障相反,完全缓存故障的最坏后果应该是降低应用程序的性能。 | 对于少量且可预测的频繁访问的对象(最好是不可变的对象),进程内缓存似乎是一个更好的选择。对于不可预测的大卷,最好使用分布式缓存。 |
Summary
对于必须多次读取的少量可预测对象(最好是不可变对象),进程内缓存是一个很好的解决方案,因为它的性能要优于分布式缓存。但是,对于可以缓存或应该缓存的对象数量无法预测且数量庞大,并且必须具有读取一致性的情况,即使分布式缓存可能不会带来相同的性能优势,它也可能是更好的解决方案作为进程内缓存。应用程序可以根据最适合该方案的情况将两种方案用于不同类型的对象。
今天先到这儿,希望对云原生,技术领导力, 企业管理,系统架构设计与评估,团队管理, 项目管理, 产品管管,团队建设 有参考作用 , 您可能感兴趣的文章:
领导人怎样带领好团队
构建创业公司突击小团队
国际化环境下系统架构演化
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变
如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯,请关注我的微信订阅号:
作者:Petter Liu
出处:http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog。