数据库历险记（三） | 缓存框架的连环炮

文章首发于微信公众号「陈树义」，专注于 Java 技术分享的社区。点击链接扫描二维码，与500位小伙伴一起共同进步。微信公众号二维码 http://p3npq6ecr.bkt.clouddn.com/blog/chenshuyi_gongzhonghao_guide_full.jpg

最近在思考数据库以及缓存的问题，发现这些知识点其实是有一点关联的，于是这篇文章通过一个连环提问的方式将这些知识点串联起来。

问：为什么要用 Memcached、Redis，直接用 MySQL 这些数据库不好吗？

答：因为 MySQL 等关系型数据库无法承受巨大的数据库访问量。

问：为什么 MySQL 数据库无法承受巨大的访问量，而 Redis Memcached 却可以？

因为 MySQL 使用文件去存储数据，这就意味着它的查询和写入速度受限于硬盘的速度。虽然 MySQL 也使用了内存缓存一部分数据，但这只能减少一部分的查询请求，如果查询请求数变多，同样会到达硬盘的 IO 瓶颈。

另一方面，关系型数据库为了实现数据的强一致性，在每次写入数据的时候会对相关的数据进行加锁操作，这样就导致在某个时刻，相关的数据只能有一个线程在操作，这样也从某种程度上限制了 MySQL 的读写性能。

如果此时查询缓存并没有相关数据，那么还会有一部分 IO 等待的事件，从而导致加锁时间变长。

而 Redis、Memcached 之所以能够承受得住 MySQL 无法承受的海量查询，很大程度上是因为他们将所有数据都存在了内存中，所以它们并不需要进行 IO 等待，直接可以从内存中查询数据并返回。

而内存的读取效率则是硬盘的 40 倍左右，存储介质的巨大区别导致了他们的应用特性。

问：那有了 Memcached 不就好了吗，为什么还要用 Redis 呢？

答：这就要说到这两种缓存的发展历史了。一开始是 2003 年发布的，一开始是为了解决数据库的读写瓶颈问题，于是将一些热点数据存储在内存中，从而有了 Memcached。

但经过几年的使用，人们发现 Memcached 存在一些问题，例如 Memcached 只支持 Key - Value 的字符串数据存储，Memcached 无法持久化数据，一旦重启服务器数据便丢失了。

出于这些原因，2009 年一些工程师在 Memcached 的基础之上打造了 Redis 框架，它与 Memcached 相比，支持更多的数据类型存储，例如：String, List, Set, SortedSet, Hash 等。此外还支持将存储在内存中的数据持久化到文件中，从而实现数据持久化。

另外 Redis 支持更大的数据存储，key-value 的存储大小可达 512M，而 Memcached 的 key 大小只有 512KB，而 value 则只有 1 M 大小。

另外它还支持许多的原子操作。因为 Redis 与 Memcached 相比有上述的优点，所以现在越来越多的人开始使用 Redis 作为缓存框架。

问：但按我所知，现在还是有许多公司使用 Memcached 作为缓存框架。换句话说，你觉得什么时候应该使用 Memcached，什么时候应该使用 Redis？

答：首先，无论 Redis 还是 Memcached，它们都是一个 NoSQL 数据库，并且都将所有数据存在内存中。现在确实有些公司还是使用 Memcached 框架作为缓存，Memcached 在某些方面确实比 Redis 好一些，虽然这些优势非常小。

文章首发于微信公众号「陈树义」，专注于 Java 技术分享的社区。点击链接扫描二维码，与500位小伙伴一起共同进步。微信公众号二维码 http://p3npq6ecr.bkt.clouddn.com/blog/chenshuyi_gongzhonghao_guide_full.jpg

例如 Memcached 在处理小数据量静态数据的速度会非常快，但是一旦数据量变大或者数据变动频繁，那 Memcached 的处理速度就会急剧下降。

另外一个 Memcached 的优势是 Memcached 是多线程的，所以如果你想提高 Memcached的性能，你可以直接给它换一个性能更加强劲的 CPU 就可以。

但是对于 Redis 而言，因为 Redis 是单线程的，所以如果你想提升 Redis 的处理能力，那么你只能多部署一台 Redis 服务器，这比起 Memcached 来说比较麻烦。

总结来说，Memcached 比起 Redis 来说，只有小数据量存储以及横向拓展这两个方面能勉强说得上「优势」，但其实 Redis 也能做得同样好，甚至超过它，只不过是需要花多点学习成本而已。

所以，如果你之前已经非常了解 Memcached 了，花了很多时间学习 Memcached 的知识，那么你可以选择 Memcached。

否则选择 Redis 是一个更好的选择，因为所有 Memcached 能做的，Redis 也能做，而且 Redis 能做到更多 Memcached 无法做到的事情。

问：那 Redis 除了作为缓存之外，还有其他什么作用吗？

答：作为缓存可能是 Redis 最广为人知的作用吧，但 Redis 除了作为缓存，还能作为消息队列解决方案、分布式锁等。

问：那 MongoDb 与 Redis 相比有什么优势可言，它更适用于什么场景呢？

答：MongoDb 的出现与 Redis 的出现类似，都是用来解决 MySQL 无法实现海量访问而存在的。但 Redis 仅仅是一个 key-value 的缓存系统，其几乎没有任何数据库特性，在那些许多进行查询的场景中，redis 无法胜任。

在这个时候 MongoDb 凭借其出色和丰富的查询功能脱颖而出。

另外 MongoDb 也能存储比 MySQL 更加大量的数据。MongoDb 适合那种数据结构经常变化，数据之间没有联系，这种场景适合用 MongoDb，例如多重嵌套的留言回复。

文章首发于微信公众号「陈树义」，专注于 Java 技术分享的社区。点击链接扫描二维码，与500位小伙伴一起共同进步。微信公众号二维码 http://p3npq6ecr.bkt.clouddn.com/blog/chenshuyi_gongzhonghao_guide_full.jpg

数据库历险记（二） | Redis 和 Mecached 到底哪个好？

文章首发于微信公众号「陈树义」，专注于 Java 技术分享的社区。点击链接扫描二维码，与500位小伙伴一起共同进步。微信公众号二维码 http://p3npq6ecr.bkt.clouddn.com/blog/chenshuyi_gongzhonghao_guide_full.jpg

说起缓存框架，我们最常用的缓存框架有 memcached、Redis 这两个，但它们之间其实是有差异的。

Memcached 的诞生

2003年5月，Brad Fitzpatrick 发布了第一个版本的 Memcached，一开始主要是为了解决 LiveJournal 网站访问缓存问题而诞生的，这个版本的 Memcached 使用 Perl 语言编写。之后 Anatoly Vorobey 使用 C 重写了 Memcached。现在 Memcached 已经被广泛应用于 YouTube、Reddit、Facebook 等网站。

说起 Memcached 的诞生，主要还是因为关系型数据库在存储性能上的瓶颈。因为进入21世纪，随着个人电脑的普及，世界网民数量急剧攀升，网站的访问量也随之攀升。

因为关系型数据库需要将数据持久化，所以会有一些写硬盘IO的过程，因此在写入数据上会有瓶颈。而为了解决硬盘IO速度慢的问题，Memcached 则是将所有数据存储在了内存中，从而能实现快速的数据写入和读取。

也是因为 Memcached 将数据存储在内存中，没有实现持久化，所以当出现一些意外情况，例如：断电重启、机器宕机等情况，Memcached 存储的数据会全部丢失，我们只能重新从数据库中读取一次，再加载到 Memcached 中。

除此之外，Memcached只支持单一的 key-value 存储，所以这里面存储的数据类型单一，无法适应多样化的业务发展。

Redis 的诞生

正是因为以上问题的存储，所以在2009年5月的时候Redis诞生了。Redis创建者看到了Memcached身上存在的许多问题，所以创建了Redis缓存框架。

在Redis缓存框架中，它支持多达 6 种类型的数据存储，并且提供了多个原子命令操作。并且Redis还支持了将数据持久化到本地文件，这样当发生意外时就不需要再从数据库读取一遍数据了，直接读取本地文件恢复即可。

文章首发于微信公众号「陈树义」，专注于 Java 技术分享的社区。点击链接扫描二维码，与500位小伙伴一起共同进步。微信公众号二维码 http://p3npq6ecr.bkt.clouddn.com/blog/chenshuyi_gongzhonghao_guide_full.jpg

到底哪一个好？

从两个缓存框架的发展历程来看，我们可以知道Redis是Memcached的升级版本，Memcached具有的功能Redis基本上都具备了。

所以很多时候我们都是使用Redis作为首选的缓存框架，当然了Memcached也有一些比Redis好一些的性能，比如在存储完全静态的小量 key-value 数据时，Memcached会比Redis快一些。

但只要数据量稍微大一点，或者数据是动态的，那么Memcached的性能就会直线下降。

所以即使Memcached在某些方面有细微的优势，但总体上Redis还是优于Memcached这个缓存框架的。

文章首发于微信公众号「陈树义」，专注于 Java 技术分享的社区。点击链接扫描二维码，与500位小伙伴一起共同进步。微信公众号二维码 http://p3npq6ecr.bkt.clouddn.com/blog/chenshuyi_gongzhonghao_guide_full.jpg

数据库历险记（一） | MySQL这么好，为什么还有人用Oracle？

文章首发于微信公众号「陈树义」，专注于 Java 技术分享的社区。点击链接扫描二维码，与500位小伙伴一起共同进步。微信公众号二维码 http://p3npq6ecr.bkt.clouddn.com/blog/chenshuyi_gongzhonghao_guide_full.jpg

关系型数据库（Relational DataBase Management System），简称 RDBMS。说起关系型数据库，我们脑海中会立即浮现出 Oracle、MySQL、SQLServer 等数据库，这些都是我们常用的关系型数据库。

关系型数据库最大的特点就是在其关系这个词，它可以保存数据库中的各种关系。那么这个关系如何理解呢？我们就拿学校的一个例子来讲吧。在学校里，我们有老师（Teacher）、学生（Student）、课程（Course）这几个实体，而这几个实体之间都是有一定关系的。例如：一个老师能教多个学生，一个学生也能被多个老师教，所以老师和学生之间的关系是N:N的关系。于此类似，学生与课程也是N:N的关系。

关系型数据库的发展历程

在1979年，Larry Ellison 使用汇编和C语言主导开发了第一个商用关系型数据库 Oracle。在此之后的接近16年内的时间，Oracle 数据库一路奔跑，成为了世界上最流行的关系型数据库。

在1989年，微软（Microsoft）也发布了一个关系型数据库 SQL Server，但其同样也是一个收费的商业型数据库。

直到1995年，瑞典公司MySQL AB发布了 MySQL 数据库的第一个版本，从此终结了关系型数据库只能用 Oracle、SQL Server 这些收费软件的神话。

在 MySQL 诞生后，因为其开源、免费的特性，所以其得到了众多中小使用者的拥护，其用户量增长迅猛。而在这期间，MySQL的主人也几易其手。在2008年，Sun 公司收购了 MySQL AB 公司，同时也获得了 MySQL 数据库的管理权。在 2010 年的时候，Oracle 公司收购了 Sun 公司，获得了 MySQL 的管理权。而就在 Oracle 收购 Sun 公司的当天，因为担心被 Oracle 收购后MySQL的前景会受到限制，被称为 MySQL 之父的 Michael Widenius fork 了 MySQL 的一个分支，启动了 MariaDB 项目。

果不其然，在被收购不久后，MySQL随即推出了相关的收费版本。虽然原来的免费版本仍然可以使用，但在可预见的未来，Oracle 投入到 MySQL 中的精力可能很有限。毕竟Oracle是一个商业公司，也是要养家糊口的。

现在我们可以了解到现在主流关系型数据库的诞生和发展概况，主要可以分为下面几个阶段：

1979年，Oracle 数据库诞生
1989年，SQL Server 数据库诞生
1995年，MySQL 数据库诞生

那这些关系型数据库都有什么差异呢？

它们各自的适用场景又是哪些呢？

文章首发于微信公众号「陈树义」，专注于 Java 技术分享的社区。点击链接扫描二维码，与500位小伙伴一起共同进步。微信公众号二维码 http://p3npq6ecr.bkt.clouddn.com/blog/chenshuyi_gongzhonghao_guide_full.jpg

MySQL 与 Oracle 之间的恩怨

说到上面这三个数据库，很多人的印象是 Oracle 很大，但是很难使用。MySQL 使用很方便，似乎是最好的选择。SQL Server 是最没有存在感的一个数据库，基本上处于高不成低不就的状态。

从 db-engines.com 网站关系型数据库市场份额排名来看，现在市场份额最高的还是 Oracle 数据库，MySQL 次之，接下来则是 SQL Server 数据库。

上图的排名似乎远远颠覆了我们的日常认知，因为在我们周边貌似很少人使用Oracle，但为什么其市场份额能这么高呢？

任何事情都不可能空穴来风，Oracle能占有这么大市场份额是因为其在海量数据的处理上更具有优势，并且能提供一整套的数据存储解决方案。所以在一些非常大的企业里，这些企业拥有庞大的资金能力，所以它们会选择用钱购买解决方案，而不是自己雇佣人员使用 MySQL 去维护。总的来说，Oracle比起MySQL具有下面的优点：

众多的数据库特性，能满足企业的多样性需求
海量数据处理的优势
一整套数据解决方案

但是 Oracle 的缺点也很明显，那就是价格昂贵。

因为Oracle有上面这些特性，所以Oracle更加适合那些大型跨国企业。因为这些企业资金充足，能承担得起Oracle的昂贵费用。另一方面，这些企业的数据量也是非常庞大，它们更注重数据的安全性和高效存储，并且关心的出现问题的时候能快速解决，Oracle提供的一系列服务正好符合它们的需求。

而对于一些中小型企业或者个人使用者来说，一方面Oracle软件非常笨重，另一方面Oracle授权费用昂贵，对于它们来说无法承受。而它们的数据库又恰好不是特别大，所以对于这些使用者来说，使用MySQL已经能够解决它们的需求了。那么也就无需去付费使用Oracle的数据库了。

总结

如果单单是从数据库性能来比较的话，那么Oracle数据库无疑是天下第一、吊打MySQL的，毕竟Oracle比MySQL诞生早了10多年。但很多时候还是得结合具体的使用场景来做出合适的选择，毕竟杀鸡不用牛刀嘛，能不用钱解决的，为何要付费解决呢！

所以当你的数据量很大，并且你自身并不缺钱，那么你直接上Oracle吧！如果资金有限，数据量也不大，那么就用MySQL吧！

面对海量请求，缓存设计还应该考虑哪些问题？

从第一个缓存框架 Memcached 诞生以来，缓存就广泛地存在于互联网应用中。如果你的应用流量很小，那么使用缓存可能并不需要做多余的考虑。但如果你的应用流量达到了成百上千万，那么你就不得不考虑深层次的缓存问题：缓存穿透、缓存击穿与缓存雪崩。

缓存穿透

缓存穿透是指查询一个一定不存在的数据，因为这个数据不存在，所以永远不会被缓存，所以每次请求都会去请求数据库。

例如我们请求一个 UserID 为 -1 的用户数据，因为该用户不存在，所以该请求每次都会去读取数据库。在这种情况下，如果某些心怀不轨的人利用这个存在的漏洞去伪造大量的请求，那么很可能导致DB承受不了那么大的流量就挂掉了。

对于缓存穿透，有几种解决方案，一种是事前预防，一种是事后预防。

事前预防。其实就是对所有请求都进行参数校验，把绝大多数非法的请求抵挡在最外层。在我们举的这个例子中，那么就是做参数校验，对于 UserID 小于 0 的请求全部拒绝。但即使我们做了全面的参数校验，还是可能存在漏网之鱼，会出现一些我们没想到的情况。

例如我们的 UserID 是递增的，那么如果有人请求一个 UserID 很大的用户信息（例如：1000000），而我们的 UserID 最大也就 10000。这个时候，你不可能限制 UserID 大于 1 万的就是非法的，或者说大于 10 万就是非法的，所以该用户ID肯定可以通过参数校验。但该用户确实不存在，所以每次请求都会去请求数据库。

其实上面只是我所能想到的一种情况，我们没想到的情况肯定还有很多。对于这些情况，我们能做的就是时候预防。

事后预防。事后预防说的就是当查询到一个空的结果时，我们仍然将这个空的结果进行缓存，但是设置一个很短的过期时间（例如一分钟）。在这里我们可以看到，其实我们并没有完全预防非法请求，只不过是将非法请求的风险让承受能力更强的redis去承担，让承受能力稍弱的数据库更安全。

通过上面这两种处理方式，我们基本可以解决缓存穿透的问题。事前预防解决80%的非法请求，剩下的20%非法请求则使用Redis转移风险。

缓存击穿

如果你的应用中有一些访问量很高的热点数据，我们一般会将其放在缓存中以提高访问速度。另外，为了保持时效性，我们通常还会设置一个过期时间。但是对于这些访问量很高的KEY，我们需要考虑一个问题：当热点KEY在失效的瞬间，海量的请求会不会产生大量的数据库请求，从而导致数据库崩溃？

例如我们有一个业务 KEY，该 KEY 的并发请求量为 10000。当该 KEY 失效的时候，就会有 1 万个线程会去请求数据库更新缓存。这个时候如果没有采取适当的措施，那么数据库很可能崩溃。

其实上面这个问题就是缓存击穿的问题，它发生在缓存KEY的过期瞬间。对于这种情况，现在常用的解决方式有这么两种：互斥锁、永远不过期。

互斥锁

互斥锁指的是在缓存KEY过期去更新的时候，先让程序去获取锁，只有获取到锁的线程才有资格去更新缓存KEY。其他没有获取到锁的线程则休眠片刻之后再次去获取最新的缓存数据。通过这种方式，同一时刻永远只有一个线程会去读取数据库，这样也就避免了海量数据库请求对于数据库的冲击。

而对于上面说到的锁，我们可以使用缓存提供的一些原则操作来完成。例如对于 redis 缓存来说，我们可以使用其 SETNX 命令来完成。

public String get(key) {
    String value = redis.get(key);
    if (value == null) { //缓存过期
        if (redis.setnx(key_mutex, 1, 1 * 60) == 1) {
                value = db.get(key);
                redis.set(key, value, expireTime);
                redis.del(key_mutex);
            } else {
                //休眠片刻后重试
                sleep(50);
                get(key);
            }
        } else {
            return value;
    }
}

上面的 key_mutex 其实就是一个普通的 KEY-VALUE 值，我们使用 setnx 命令去设置其值为 1。如果这时候已经有人在更新缓存KEY了，那么 setnx 命令会返回 0，表示设置失败。

永远不过期

从缓存的角度来看，如果你设置了永远不过期，那么就不会有海量请求数据库的情形出现。此时我们一般通过新起一个线程的方式去定时将数据库中的数据更新到缓存中，更加成熟的方式是通过定时任务去同步缓存和数据库的数据。

但这种方案会出现数据的延迟问题，也就是线程读取到的数据并不是最新的数据。但对于一般的互联网功能来说，些许的延迟还是能接受的。

缓存雪崩

缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到数据库，最终导致数据库瞬时压力过大而崩溃。

例如我们有 1000 个KEY，而每个 KEY 的并发请求不大，只有 10 次。而缓存雪崩指的就是这 1000 个 KEY 在同一时间，同时失效，这个时候就突然有 1000 ** 10 = 一万次查询。

缓存雪崩导致的问题一般很难排查，如果没有事先预防，很可能要花很大力气才能找得到原因。对于缓存雪崩的情况，最简单的方案就是在原有失效时间的基础上增加一个随机时间（例如1-5分钟），这样每个缓存过期时间的重复率就会降低，从而减少缓存雪崩的发生。

总结

对于缓存穿透、缓存击穿、缓存雪崩这三个情景，许多人会搞不明白，甚至会混淆。

「缓存穿透」指的是请求不存在的数据，从而使得缓存形同虚设，缓存层被穿透了。例如我们请求一个 UserID 为 -1 的用户数据，因为该用户不存在，所以该请求每次都会去读取数据库。在这种情况下，如果某些心怀不轨的人利用这个存在的漏洞去伪造大量的请求，那么很可能导致DB承受不了那么大的流量就挂掉了。

「缓存击穿」指的是并发量很高的 KEY，在该 KEY 失效的瞬间有很多请求同同时去请求数据库，更新缓存。例如我们有一个业务 KEY，该 KEY 的并发请求量为 10000。当该 KEY 失效的时候，就会有 1 万个线程会去请求数据库更新缓存。这个时候如果没有采取适当的措施，那么数据库很可能崩溃。

「缓存雪崩」则是指缓存在同一时间同时过期，就像所有雪块同一时刻掉下来，像雪崩一样。例如我们有 1000 个KEY，而每个 KEY 的并发请求不大，只有 10 次。而缓存雪崩指的就是这 1000 个 KEY 在同一时间，同时失效，这个时候就突然有 1000 ** 10 = 一万次查询。

对于它们出现的情形，我们可以做一些总结：

「缓存穿透」是业务层面的漏洞导致非法请求，与请求量、缓存失效没关系。「缓存击穿」则只会出现在热点数据上，发生在缓存失效的瞬间，与业务没多大关系。「缓存雪崩」则是因为多个 KEY 同时失效，导致数据库请求太多。非热点数据也会导致缓存雪崩，只要同时失效的 KEY 足够多。