不可忽略的缓存重建

本文的主要内容来源于MongoDB官方博客,由NoSQLFan补充说明,本文对传统的分布式Cache系统进行了分析,指出了其在缓存重建中会对数据库产生巨大压力的问题。并分析了MongoDB的mmap方案是如何规避这一问题的。

如下图的架构,在数据库前端加上分布式的Cache(比如我们常用的Memcached),让客户端在访问时先查找Cache,Cache不命中再读数据库并将结构缓存在Cache中。这是目前比较常用的一种分担读压力的方法。

但是这个方法存在一个问题,如果前端的Cache挂掉,或者比较极端的整个机房断电了,那么在机器重启后,原来Cache机器在内存中的缓存会全部清空,在客户端访问过程中,会百分之百的不命中,这样数据库会在瞬间接受巨大的读压力。

试想如果一个64GB的缓存失效了,在其重建时,假设与数据库连接的千兆网卡,假设其以极限速度100M每秒从数据库取数据过来重建缓存,那么也需要10分钟才能建完。更何况这是理想情况,对于客户端触发式的随机缓存重建,可能会花掉更长的时间。这还是在数据库能提供100M每秒的数据读请求的前提下。

我们经常看到一些网站挂掉后又恢复,恢复后又挂掉,如此反复几次才能真正恢复,原因就在于其第一次Cache倒了,数据库无法承受相应的读压力,在缓存重建了一小部分后被压死。相当于数据库每重启一次,可以恢复部分缓存,直到缓存的非命中率到达数据库可承受的压力时,才能够真正恢复服务。

这个问题可以用一些可以提供持久化功能的缓存来实现,比如Redis,在未开启aof的情况下,其定期dump出来的rdb文件出能自动恢复出绝大部分数据,当然,在有的时候这可能导致缓存和数据库数据不一致的情况,需要根据应用场景选择性的使用。

上面是对分布式Cache的问题,而对于很多数据库存储,实际上也几乎都是将热数据尽量放在内存中的。但很多数据库在实现上是自己在内存中实现了Cache机制,这样在数据库重启(非操作系统重启)时,这些Cache可能也就随之被清空了,对于数据库来说,也需要重建缓存,而数据库这时所有的操作可能都落在磁盘IO上,带来了同样的问题。

而MongoDB与上面的方式不太一样,MongoDB采用mmap来将数据文件映射到内存中,所以当MongoDB重启时,这些映射的内存并不会清掉,因为它们是由操作系统维护的(所以当操作系统重启时,MongoDB才会有相同问题)。相对于其它一些自己维护Cache的数据库,MongoDB在重启后并不需要进行缓存重建与预热。

另外,新浪微博的timyang也曾经提出过一种缓存重建加锁的方式,也能部分解决此问题。简单来说就是缓存重建时,当多个客户端对同一个缓存数据发起请求时,会在客户端采用加锁等待的方式,对同一个Cache的重建需要获取到相应的锁才行,只有一个客户端能拿到锁,并且只有拿到锁的客户端才能访问数据库重建缓存,其它的客户端都需要等待这个拿到锁的客户端重建好缓存后直接读缓存,其结果是对同一个缓存数据,只进行一次数据库重建访问。但是如果访问分散比较严重,还是会瞬间对数据库造成非常大的压力。

下面是几点比较实用的知识:

  • 无论使用哪个存储,都最好先搞清楚其缓存重建的过程,如果一次重启就可能导致数据库崩溃,还是小心为好,最好把重启时间选在访问量比较小的时候。
  • 重启MongoDB不会导致MongoDB的缓存失效(除非重启服务器)
  • 当你重新mount磁盘时,文件系统的缓存会失效,这和重启机器时一样,MongoDB也无法避免
  • 一个使用MongoDB的小技巧,当MongoDB服务器刚启动时,你可以将其所有文件copy到/dev/null中,这会触发操作系统对这些文件的读操作,从而在内存允许的条件下,会将尽可能多的MongoDB数据文件映射到物理内存中。当然,如果在MongoDB运行过程中,你能够判断哪些文件保存的数据是热数据,也可以将这些文件copy到/dev/null 来为其争取更多的物理内存。

参考源:blog.mongodb.org

anyShare赠人玫瑰,手有余香,分享知识,德艺双馨!
          

无觅相关文章插件,快速提升流量

  1. 上面说机房断电 下面又说 系统维护的缓存- – 扯的什么啊,一般的灾难都是硬件坏掉,哪里还有个系统!
    另外缓存重建加锁也不是针对这种情况的吧 。。 加锁只能更慢

    对于需要重建的缓存就得持久化存在硬盘里。 以最快的速度恢复 10分钟也比挂几次强的多

    • 机房断电和系统重启都会造成内存中内容的丢失,有什么扯的?只能说你没看懂。

      一般的灾难是硬件坏掉?不知道你指的一般灾难是什么情况?我们这里说的是意外断电或者升级重启的情况,你升个级会坏硬件?再说你坏硬件的情况,肯定是用其它没坏的硬件或者新的机器节点加入,这时候和重启造成的情况无异。

      缓存加锁当然是针对这种情况,缓存加锁的目的就是防止缓存失效的雪崩效应把压力压到DB上,如果缓存重建加锁,就能将对同一个缓存只进行一次重建操作,用户是否会感觉慢都不一定(一个是等待另一个进程重建缓存,一个是穿透到DB,DB此时的压力骤升,响应时间根本不可预测),而且加锁的话DB操作会倍减,不会那么容易压倒。

      以最快的速度10分钟恢复,首先这是理论情况,实际情况比这慢十倍是完全可能的。另外你认为你在恢复缓存的10分钟或者更长时间内就停止对用户服务了?我们的前提是提供服务的同时来逐步恢复缓存。

      • 好吧,怪我没说清楚,我是说下面说Mongodb的优势是重启不会导致缓存丢失,但上面却说机房断电之类的灾难,当然也不排除硬件坏掉的情况(这种情况还是时有发生的),当然也不排除你的升级情况。相对会造成重启的情况,这个优势是不具备的,而且也不能依赖这种不靠谱的优势。

        另外加锁我指的不是说用于灾难恢复,其实加锁这个和灾难恢复应该没关系, 缓存建立的策略也要看速度、过期等情况,所以加锁只是存的时候针对速度的情况一种可以说必须的方法。

        至于不停止服务的情况进行升级的话,如果机器吃紧,是很难办到的,这种雪崩情况只会带来更糟糕的体验。还不如向用户发表的升级公告之类的。

        • 其实断电的例子,目的只有一个,就是缓存因为断电失效这样简单的例子,这个例子中是两层架构,缓存和数据库分离。而MongoDB实际上是希望尽量做到数据库即缓存。所以上面例子是个引子而已。

          后面主要是MongoDB和那些自己做缓存管理(非mmap)的数据库的对比,MongoDB在升级、重启的时候原来在内存中映射的数据都不会丢。可以少一次内部缓存预热的过程。仅此而已。

          后面加锁的东西我觉得还是理解不一,我说的是加锁,是重建同一个缓存的时候,防止多个相同请求并发,导致多次访问DB取同样数据的问题。这个可以看一下timyang的这篇文章:http://timyang.net/programming/memcache-mutex/

          另外说到升级不停服务,我认为这是再正常不过的需求了。如非有重大好处且无可避免的情况,停机维护成本太高。

          本文的思路一直是如何防止缓存失效雪崩等情况。技术人员从技术角度能解决此问题应该优先去考虑解决方案吧,比如我们这边几个业务用到MongoDB,升级了几个版本,还有服务大了后迁移到多个节点,就从没停过服务。我认为只有技术无法解决的时候才应该考虑停机发公告的手段。