Redis不仅仅是缓存,还是……

你需要一个经典数据库吗？

一段时间以来，巨大数量的数据处理迫使所有的应用程序在数据库层前添加缓存策略。即使经典数据库进行了大量的下划线优化，仍然不能提供足够的速度和可用性。主要原因在于数据存储越远，获取数据就越困难。另一个原因是因为数据库中的数据通常保存在磁盘中，而不是在内存。经典数据库却是在内存上嵌入了缓存来优化，但是拥有一个专用的独立缓存也是一种很常用的策略。

在解决访问数据库的性能问题，通常的解决方案是缓存。缓存并不新鲜，缓存实际上是把经常访问的少量数据保存在离你更近的地方。我们在处理器上有缓存，数据库中也有缓存，你甚至可以在自己的应用中编写缓存。

但随着事情的发展，现在我们有来高可用的分布式内存缓存，可以被不同的实例同时使用。

缓存——redis

也许最流行的分布式内存数据存储是redis，它不是缓存，但被当作缓存使用。 引用官方的描述如下：

redis是一个开源的（bsd协议），内存中的数据结构存储，它可以用作数据库，缓存，消息代理。它支持的数据结构包括字符串，哈希，列表，集合，有序集合，位图，超级日志，具有半径查询和流的地理空间索引和流，redis具有内置复制，lua脚本，lru驱逐，事务和不同级别的磁盘持久化，并通过redis哨兵和redis集群自动分区。

redis速度很快，它被认为是目前最快的数据存储之一。它对cpu缓存进行了优化，并且没有上下文切换。从一开始它就被设计成了内存数据库，这不仅意味着将数据从磁盘移动到内存，它从一开始就针对性的优化了。

由于redis速度非常快，可以存储各种数据结构，因此它是分布式缓存的一个很好的备选。

因为作为缓存，redis获得了非常高的人气。有一些缓存加载器库在使用redis作为应用程序和数据库之间的缓存层。以redisson地图加载器为例：

因此，使用分布式缓存可以极大的提高性能。但是代码和架构变得更复杂了。数据被复制到数据库和缓存中，我们必须保持它们的数据同步。代码应该管理整个缓存策略，控制缓存失效，重新填充缓存，都是为了保持数据的一致性。我们实现了更高的性能和可伸缩性，但引入了高风险的复杂性。

数据是重复的

你可能会问为什么要在两个地方都保存数据？不能只保存redis中的数据吗？如果这样做我们可以减少代码的复杂性。但首先让我们看看经典数据库的一下特点和优势，看看我们是否可以直接使用redis实现这些。

关系型数据库的优点

传统来说，缓存是不会长期保存数据的。我们将数据保存在缓存中只是为了快速的访问，但是为了长时间的持久性，我们通常使用一个*数据库。

除了数据的持久性以外，关系型数据库提供了数据一致性等其他特点。使用关系型数据库，你可以定义数据间的关系，约束，复杂查询，构建它是为了保证多个相关表间的一致性。

它有一些重要的优势，即使nosql数据库很流行，关系型数据库也不会很快消失。

但是使用redis作为缓存和关系型数据库搭配使用，增加了一层复杂性，因为你必须通过代码保持两者的数据同步。

考虑到你的缓存策略，你不得不构建一些复杂的代码在redis和数据库间进行数据发送。不要误解我的意思，有时候你必须这么做。就像之前提到的，关系型数据库有它的优点，我们不能把它扔掉。

但是我们必须每次都这么做吗？如果不同数据间不需要非常复杂的关系，而只存储一个键映射就足够了呢？我们是不是可以不用关系型数据库了？

redis作为*数据存储

如前所述，关系型数据库的优点是一致性和持久性。如果我们不需要数据之间的关系映射，那么它将只保留持久性。有很多nosql数据库提供键映射存储，但我们可以直接使用redis。

redis持久化

redis有两种持久化模型：rdb和aof。

rdb在指定的时间间隔保存数据快照。它们非常适合快速恢复备份。rdb最大化了redis的性能，因为父进程所做的唯一工作就是fork创建快照的子进程。

但是由于rdb在一定时间间隔执行计划，如果你无法承受丢失一些数据，那么这就不是一个好的选择。fork是一个高成本的操作，不能在每次数据变化都进行fork，因此可能会出现最近的数据没有被保存在快照中的情况。

aof是一个不同的持久化模型。它是由一个只能追加的文件组成，只在其中添加所有数据。它更持久，因为fsync策略通常比整个rdb更有计划性。由于该文件仅用于追加，因此数据是不可更改的。即使在最后一条数据没有完全写完而出现断电，也可以很容易的重新断电前的构建状态。

但是它也有缺点。第一个是aof文件通常比rdb更大。另外，如果fsync策略被调度的太频繁，举个例子，在每次写命令之后，那么性能会大打折扣。在默认情况下，fsync每秒运行一次。

你应该使用哪个？

如果你想要一个类似postgres提供的安全级别，你将不得不两种情况都使用。使用rdb可以让你在重启后更快的恢复备份；使用aof可以避免数据丢失。但是如果你能承受一些数据损失，那可以只使用rdb。记住，redis会把它们合并成一个单一的持久化模型。

其他优势

未来是属于字节寻址的

由于磁盘旋转在很长一段时间都是持久化单元，所以当前的大多数数据库仍然在适应磁盘的旋转方面进行优化。比如数据定位，以减少磁盘旋转滞后，甚至选择了专门的格式，将索引放在了盘片的特定部分。但是这些优化对于当前的技术，比如ssd，是没有意义的。redis存储数据是为字节寻址优化的。未来是属于字节寻址的，而redis已经在那里了。

可伸缩性和高可用性

redis提供了不同的方式来实现伸缩性和高可用性。

你可以在不同的redis节点上分割数据来实现水平的可扩展性。分片将减轻单个实例的负担，你将受益于多核和计算能力。但是你应该知道分片的局限性，因为不能支持多键操作和事务。

通过复制获得高可用性。主节点是同步复制的，可以免受节点故障，数据中心故障和redis进程故障。如果主节点宕机，副节点将会取而代之。在不同的az中也有一个副本，这将保护你免受灾难时间的影响，比如整个az失败。

如果你打算使用redis企业集群，所有的这些对你都是抽象的，你将拥有分片和高可用性，而不需要额外的代码。你可以通过编码连接到一个redis实例。

复杂数据结构

redis不仅可以处理字符串，还可以处理不同的数据结构，如：二进制安全字符串，列表，集合，排序集合，位图，超级日志，流等等。这使得redis不仅是一个键值存储，更是一个完整的数据结构服务器。

不是银弹

一切听起来都非常棒，但是作为一个事实，没什么东西是银弹，redis也不是。主要的缺点是所有的数据都应该装进内存中。这使redis适合那些有足够内存进行存储的数据。如果没有，那就必须将数据拆分。但是你会失去一下保证，如事务，管道，或发布/订阅。

结论

在很长一段时间里，redis被认为只是一个缓存。一个非常好的分布式缓存，但仍然只是一个应用程序和主数据库之间的缓存。正如你所看到的，redis不仅仅是一个缓存，它试图摆脱这个误解。redis不是一个缓存，它是一个分布式数据存储。它可以以线程安全模式以令人难以置信的速度处理不同的数据结构，并为数据持久性提供了不同的机制。

考虑到所有这些，即使redis被非常成功地用作缓存，它还是可以做更多的事情。如果你不需要一些像关系数据和高存储的sql属性，为什么你要在应用程序中创建一个复杂的三层系统？redis作为缓存和还是数据库?在这些情况下，你可以只使用redis作为主要的持久层。

原文链接:https://dzone.com/articles/redis-is-not-just-a-cache

到此这篇关于redis不仅仅是缓存,还是……的文章就介绍到这了,更多相关redis 缓存 内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！