Redis那么快，为什么不用它做主数据库，只用它做缓存？

先来看看 Redis 官网的介绍：The open-source, in-memory data store used by millions of developers as acache, vector database,document database,streaming engine, and message broker。 划重点：in-memory data store

我们都知道 Redis 非常快，其实这主要得益于它的数据都是直接存储在内存中的，但是别忘了，任何技术的选择都是一种权衡。接下来我们聊聊为什么Redis虽很快，却通常只被用作缓存，而不是主数据库。

首先，数据持久性方面。传统的关系型数据库，比如MySQL，它们对数据的保存是以磁盘为主，虽然速度比不过内存操作，但是关机了数据还在，可靠性高。而Redis虽然也有持久化的功能，像RDB快照和AOF日志，但这些操作都是周期性的，如果发生突然宕机，最近的数据可能会丢失。

这时候可能有人会说：那我可以通过调整RDB快照和AOF日志的配置，提高 Redis 数据的持久性啊。没错，这确实是一种可行的方法，我们再详细说说：

1. 对于RDB持久化，这个是通过定期进行快照来保存数据状态的。如果你降低快照的生成间隔，确实可以减少数据丢失的情况，但这样做的代价是会更频繁地进行磁盘I/O操作，这可能会影响Redis的性能。而且，如果Redis数据集非常大的话，每次保存快照可能都需要较长的时间，这期间如果发生故障，还是会有数据丢失的风险。

2. AOF持久化是通过记录每次写操作来实现的。你可以配置AOF的写入策略，例如，每次写操作后都同步到磁盘，或者每秒同步一次。如果设置为每次写操作后都同步，那理论上是可以实现几乎零数据丢失的，但这同样会对性能有所影响，因为磁盘I/O操作通常比内存操作要慢得多。

3. 另外，AOF文件有个问题就是随着操作的累积，文件会越来越大。Redis提供了重写机制来压缩AOF文件的大小，但这个操作也是需要消耗资源的。

所以，我们虽然可以通过调整持久化的策略来减少数据的丢失，但这总是要在性能和数据安全性之间做出平衡。对于要求不那么苛刻的场景，适当调整持久化策略是个不错的选择。但如果你的业务对数据的安全性要求极高，那可能还是需要主从复制、哨兵系统这样的高可用方案来确保数据的安全，当然，成本也是一个需要考虑的因素。

再来说说数据结构方面。Redis的数据结构非常的丰富，键值对嘛，但是它的这些结构主要是为了快速访问、缓存数据设计的，并不适合做复杂的关系数据处理。比如说你要做一些连表查询、事务处理，这些在关系型数据库中就像小菜一碟，但在Redis中就有些力不从心了。

还有成本问题，内存相比磁盘要贵不少，如果你的数据量特别大，把所有数据都放在内存里，成本可不是个小数目。而且内存毕竟有限，数据量一大，内存压力也大，这时候用作主数据库的话，成本效益比可能就不太理想了。

最后，安全性和复杂查询。传统关系型数据库对于安全性和支持复杂SQL查询都有很成熟的解决方案，而Redis的这些支持就比较有限。企业级应用对数据安全性有严格要求，复杂的查询需求也是家常便饭，这些方面Redis就比较吃力了。

所以呢，综合来看，Redis用来做高性能的缓存是非常合适的，它能极大地提高应用访问速度，缓解后端数据库的压力。但要用它做主数据库，就需要慎重考虑数据的安全性、持久性、查询复杂度和成本等因素了。

最后说一句(求关注，求赞，别白嫖我)

最近无意间获得一份阿里大佬写的刷题笔记和面经，一下子打通了我的任督二脉，进大厂原来没那么难。

这是大佬写的，7701页的阿里大佬写的刷题笔记，让我offer拿到手软

求一键三连：点赞、分享、收藏

点赞对我真的非常重要！在线求赞，加个关注我会非常感激！@小郑说编程