当前位置：Gxlcms > 数据库问题 > 既生 Redis 何生 LevelDB ？

既生 Redis 何生 LevelDB ？

时间：2021-07-01 10:21:17 帮助过：20人阅读

有过这方面开发经验的朋友们就知道写这样的代码还是挺繁琐的，所有的涉及到缓存的业务代码都需要加上这一部分逻辑。

严格来说我们还需要仔细考虑缓存一致性问题，比如在 updateUser 方法中，数据库正确执行了更新，但是缓存 redis 因为网络抖动等原因置为失效没有成功，那么缓存中的数据就成了过期数据。如果你将设置缓存和更新持久存的先后顺序反过来，也还是会有其它问题，这个读者可以自行思考一下。

在多进程高并发场合也会导致缓存不一致，比如一个进程对某个 userId 调用 getUser() 方法，因为缓存里没有，它需要从数据库里加载。结果刚刚加载出来，正准备要设置缓存，这时候发生了内存 fullgc 代码暂停了一会，而正在此时另一个进程调用了 updateUser 方法更新了数据库，将缓存置为失效（其实缓存里本来就没有数据）。然后前面那个进程终于 fullgc 结束要开始设置缓存了，这时候进缓存的就是过期的数据。

LevelDB 是如何解决的？

LevelDB 将 Redis 缓存和持久层合二为一，一次性帮你搞定缓存和持久层。有了 LevelDB，你的代码可以简化成下面这样

function getUser(String userId) User {
  return leveldb.get(userId);
}

function updateUser(String userId, User user) {
  leveldb.set(userId, user);
}
复制代码

而且你再也不用当心缓存一致性问题了，LevelDB 的数据更新要么成功要么不成功，不存在中间薛定谔状态。LevelDB 的内部已经内置了内存缓存和持久层的磁盘文件，用户完全不用操心内部是数据如何保持一致的。

LevelDB 具体是什么？

前面我们说道它是一个 NOSQL 存储引擎，它和 Redis 不是一个概念。Redis 是一个完备的数据库，而 LevelDB 它只是一个引擎。如果将数据库比喻成一辆高级跑车，那么存储引擎就是它的发动机，是核心是心脏。有了这个发动机，我们再给它包装上一系列的配件和装饰，就可以成为数据库。不过也不要小瞧了配件和装饰，做到极致那也是非常困难，将 LevelDB 包装成一个简单易用的数据库需要加上太多太多精致的配件。LevelDB 和 RocksDB 出来这么多年，能够在它的基础上做出非常一个完备的生产级数据库寥寥无几。

在使用 LevelDB 时，我们还可以将它看成一个 Key/Value 内存数据库。它提供了基础的 Get/Set API，我们在代码里可以通过这个 API 来读写数据。你还可以将它看成一个无限大小的高级 HashMap，我们可以往里面塞入无限条 Key/Value 数据，只要磁盘可以装下。

正是因为它只能算作一个内存数据库，它里面装的数据无法跨进程跨机器共享。在分布式领域，LevelDB 要如何大显身手呢？

这就需要靠包装技术了，在 LevelDB 内存数据库的基础上包装一层网络 API。当不同机器上不同的进程要来访问它时，都统一走网络 API 接口。这样就形成了一个简易的数据库。如果在网络层我们使用 Redis 协议来包装，那么使用 Redis 的客户端就可以读写这个数据库了。

如果要考虑数据库的高可用性，我们在上面这个单机数据库的基础上再加上主从复制功能就可以变身成为一个主从结构的分布式 NOSQL 数据库。在主从数据库前面加一层转发代理（负载均衡器如 LVS、F5 等），就可以实现主从的实时切换。

如果你需要的数据容量特别大以至于单个机器的硬盘都容不下，这时候就需要数据分片机制将整个数据库的数据分散到多台机器上，每台机器只负责一部分数据的读写工作。数据分片的方案非常多，可以像 Codis 那样通过转发代理来分片，也可以像 Redis-Cluster 那样使用客户端转发机制来分片，还可以使用 TiDB 的 Raft 分布式一致性算法来分组管理分片。最简单最易于理解的还是要数 Codis 的转发代理分片。