您现在的位置是:首页 > cms教程 > discuz教程discuz教程
Discuz的NT进行缓存分层本地缓存+memcached介绍
陈仓翼2025-06-24 23:07:17discuz教程已有3人查阅
导读在以前的两篇文章(DiscuzNT 缓存设计简析, DiscuzNT中集成Memcached分布式缓存)中,介绍了DiscuzNT中的缓存设计思路以及如何引入Memcached,当然前者是IIS进程的缓存
在以前的两篇文章(DiscuzNT 缓存设计简析, DiscuzNT中集成Memcached分布式缓存)中,介绍了DiscuzNT中的缓存设计思路以及如何引入Memcached,当然前者是IIS进程的缓存(本地缓存),后者是分布式内存对象缓存系统。
两者通过DiscuzNT中的memcached.config文件中的ApplyMemCached结点的值来决定使用哪一种缓存方式。不过在之后,有朋友反映当使用Memcached时,特别是在大并发来时,效率会打折扣,甚至有很多时间会消耗在socket套接字(创建和传输方面)上。而事实上也的确如此,尽管Memcached在使用池化的方式初始化一定数量的套接字资源(之前测试时实始化为128个链接),在小并发(100左右)时,可能问题不大,但并发上了1000-2000时,其效率要比本地化缓存机制低1/3(loadrunner测试场景),比如loadrunner测试1000并发时,如果showtopic(显示主题),本地缓存处理时间为15秒,而使用memcached可能会达到25-35秒。
显然这是用户所不能忍受的,所以要想解决方案。也就有了今天的文章。
其实要解决这个问题的原理很简单,就是将之前的两种缓存方案(本地缓存和memcached)进行整合,原理如下:
首先在iis进程中会将要缓存的数据缓存一份,同时也将该数据放入memcached一份,当然本地缓存的数据生命周期要比memcached少。这就造成本地缓存数据到期后,当再次访问其则将memcached中的数据加载到本地缓存中并返回给应用程序。当缓存的数据更新时,则要更新memcached中的数据和本地缓存的数据(当然如果你要将应用程序布署的到多个站点时,因为不同的站点运行在不同的web园或主机上,这时你就不可以用最简单的方式来更新其它进程和主机上的应用程序了,因为当前缓存的数据只保存在当前web园进程中),这也就是为什么要给本地缓存数据设置到期时间这个值,让其在到期后来自动从memcached获取数据。
原理解释完了之后,我们来看看如何实现这个方案.
我们要看一下默认的本地缓存策略文件,其功能也就是两年前所说的那个本地缓存策略功能,如下: 因为在一开始设计DiscuzNT缓存方案时,就使用了Strategy(策略)模式,所以这里我们只要将上面所说的改动方案以继承的方式继承自上面的
DefaultCacheStrategy 之后,就可以在DNTCache中使用它了。因为之前我已经将memcached引入到了discuznt产品中,所以这里只要改动一下已有的那个MemCachedStrategy,使其支持上面所说的缓存分布方案即可,请看下面的代码: 注:MemCachedStrategy 原来已实现了ICacheStrategy接口,参见这篇文章。
这样,我们还是可以通过memcached.config中的ApplyMemCached来判断是否使用本地缓存方案还是当前的缓存分层方案。当然原有的memcache.config中还有添加一下属性用于记录当使用缓存分层方案之后的本地缓存的缓存数据时间,以向上面的类属性TimeOut注入相应参数信息。
这样memcached.config的内容就会变成这个样子(本地测试配置): 这样,当使用Lr测试时,其在并发1000的情况下与使用本地缓存方案的响应时间基本稳定在15秒左右,想一下大家就会明白了,因为在数据首次加载并进行缓存时(本地和memcached都会缓存一份,参见上面的实现代码)。当再次访问时,如在60秒的数据有效期内,仅访问本地缓存,只有在数据过期时间,才会运行再次加载数据的工作,而这种加载也只是从memcached中获得数据,这里我们可以暂时将memcached中的数据想像是永不过期,这样就可以减少对database的访问压力,因为这时相对于本地缓存而言,memcached已经变成了一个‘缓存数据库’了: 现在用两张图再对比说明之前的memcached与现在的缓存分层方案:
其实在大网站的数据缓存方案中,往往会将大量的数据(不经常变化或对时效性要求不强,但却需频繁访问的数据)放入到缓存中,以此来降低数据库的负载。本地缓存数据的时效性和稳定性受制于IIS进程中线程的运行情况,资源的占用等因素影响,可以说数据的稳定性(不易丢失)远不如memcached,所以这种分层方案可以有效的解决这个问题,当然这种做法还有一些其它方面的好处,就不一一说明了。
两者通过DiscuzNT中的memcached.config文件中的ApplyMemCached结点的值来决定使用哪一种缓存方式。不过在之后,有朋友反映当使用Memcached时,特别是在大并发来时,效率会打折扣,甚至有很多时间会消耗在socket套接字(创建和传输方面)上。而事实上也的确如此,尽管Memcached在使用池化的方式初始化一定数量的套接字资源(之前测试时实始化为128个链接),在小并发(100左右)时,可能问题不大,但并发上了1000-2000时,其效率要比本地化缓存机制低1/3(loadrunner测试场景),比如loadrunner测试1000并发时,如果showtopic(显示主题),本地缓存处理时间为15秒,而使用memcached可能会达到25-35秒。
显然这是用户所不能忍受的,所以要想解决方案。也就有了今天的文章。
其实要解决这个问题的原理很简单,就是将之前的两种缓存方案(本地缓存和memcached)进行整合,原理如下:
首先在iis进程中会将要缓存的数据缓存一份,同时也将该数据放入memcached一份,当然本地缓存的数据生命周期要比memcached少。这就造成本地缓存数据到期后,当再次访问其则将memcached中的数据加载到本地缓存中并返回给应用程序。当缓存的数据更新时,则要更新memcached中的数据和本地缓存的数据(当然如果你要将应用程序布署的到多个站点时,因为不同的站点运行在不同的web园或主机上,这时你就不可以用最简单的方式来更新其它进程和主机上的应用程序了,因为当前缓存的数据只保存在当前web园进程中),这也就是为什么要给本地缓存数据设置到期时间这个值,让其在到期后来自动从memcached获取数据。
原理解释完了之后,我们来看看如何实现这个方案.
我们要看一下默认的本地缓存策略文件,其功能也就是两年前所说的那个本地缓存策略功能,如下: 因为在一开始设计DiscuzNT缓存方案时,就使用了Strategy(策略)模式,所以这里我们只要将上面所说的改动方案以继承的方式继承自上面的
DefaultCacheStrategy 之后,就可以在DNTCache中使用它了。因为之前我已经将memcached引入到了discuznt产品中,所以这里只要改动一下已有的那个MemCachedStrategy,使其支持上面所说的缓存分布方案即可,请看下面的代码: 注:MemCachedStrategy 原来已实现了ICacheStrategy接口,参见这篇文章。
这样,我们还是可以通过memcached.config中的ApplyMemCached来判断是否使用本地缓存方案还是当前的缓存分层方案。当然原有的memcache.config中还有添加一下属性用于记录当使用缓存分层方案之后的本地缓存的缓存数据时间,以向上面的类属性TimeOut注入相应参数信息。
这样memcached.config的内容就会变成这个样子(本地测试配置): 这样,当使用Lr测试时,其在并发1000的情况下与使用本地缓存方案的响应时间基本稳定在15秒左右,想一下大家就会明白了,因为在数据首次加载并进行缓存时(本地和memcached都会缓存一份,参见上面的实现代码)。当再次访问时,如在60秒的数据有效期内,仅访问本地缓存,只有在数据过期时间,才会运行再次加载数据的工作,而这种加载也只是从memcached中获得数据,这里我们可以暂时将memcached中的数据想像是永不过期,这样就可以减少对database的访问压力,因为这时相对于本地缓存而言,memcached已经变成了一个‘缓存数据库’了: 现在用两张图再对比说明之前的memcached与现在的缓存分层方案:
其实在大网站的数据缓存方案中,往往会将大量的数据(不经常变化或对时效性要求不强,但却需频繁访问的数据)放入到缓存中,以此来降低数据库的负载。本地缓存数据的时效性和稳定性受制于IIS进程中线程的运行情况,资源的占用等因素影响,可以说数据的稳定性(不易丢失)远不如memcached,所以这种分层方案可以有效的解决这个问题,当然这种做法还有一些其它方面的好处,就不一一说明了。
本文标签:
很赞哦! (0)
暂无内容 |
暂无内容 |
相关文章
暂无内容 |
暂无内容 |
随机图文
Discuz本地安装discuz网站的方法
网站建目前都很简单,建站容易,管理难,网站做大优化更难。本人有建站经验,目前给大家分享一下如何建站,当然,目前使用的是本地建站,因为非本地建站需要购买域名和网站空间Discuz开发移动端访客功能的实现步骤
discuz在移动端的功能着实很简单基本就几个页面就完了,pc端的很多功能都没事实现,尤其是个人空间页面,移动端简直没有任何操做可言。宝塔nginx服务器安装Discuz的步骤方法
需要说明的是,下网上以前一直流传的Rewrite都是有误的。下面的Rewrite中百分号前面多了个转移字符“\”,这在Apache中是需要的,而在Nginx中则是不需要的。Discuz安装过程中数据库连接失败的原因及解决方法
数据库连接失败通常是因为配置错误、数据库服务器不可用或权限问题导致的。了解PHP和MySQL的基础知识,如如何配置数据库连接、常见的错误代码及其含义,将有助于你更快地解决问题。
留言与评论 (共有 0 条评论) |