我设计了个【方案】：比redis好10倍的kv库【一统kv】-Toy模板网

这篇具有很好参考价值的文章主要介绍了我设计了个【方案】：比redis好10倍的kv库【一统kv】。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

我设计的redis9.0方案：redis自带中间件

基于ssd磁盘，此我设计了比redis更好的缓存方案。此方案：没有缓存击穿问题。没有缓存雪崩问题。没有缓存污染问题。没有热key问题。
不需要snap和aof。支持任何sql库，sql库不需要带有任何分布式功能。

基于ssd磁盘，此我设计了比redis更好的缓存方案：在ssd上增加key的lru信息。从ssd到网络存储，到sql。

文章来源地址https://www.toymoban.com/news/detail-433364.html

redis 好10倍一统kv 1.0 博客园
2023-0503，这个方案目前是1.0，方案会持续修补更新，版本号也会变。

世界上为什么没有这种3级数据库?

cpu3级缓存，大家都知道吧。
cpu3级缓存的作用，大家都知道吧。就是分冷热数据，冷数据淘汰。

那么为什么世界上，没有一种【3级，冷热数据自动分层，数据库】？

--------【1级=内存级。lru队列。】--------

内存级。lru队列。队列有容量限制。存储redis兼容的数据类型。队列中的每个键值，都有一个热度值。
客户端来读，已有数据：已有数据直接返回。
客户端来读，但本级无数据：绝不会去读下级队列，而是返回本级没有数据。解决缓存污染问题。

整理队列：只在没有客户端读请求时做。
超出lru队列的冷数据：放入写队列。写后移除。
当内存空余超过多少mb时，读下级队列中，最热的100条数据。把下级热度值一并读取。

内存中，永远只有最热的key。不支持客户端，把key写入内存。

内存中的某些key，有个属性，此属性阻止key写入到ssd磁盘。这样的key断电将丢失。

--------【2级=ssd磁盘级。】--------

直读请求：
1本级已有数据，返回数据，不写入上级队列。支持限制并发数。
2本级无数据：则放入读取下级队列。定时从下级读取。比如每隔2秒。读取每个数据时，相邻的16k数据一同读取。返回数据，不写入上级队列。
支持对客户端ip，限制并发数。比如，建立一个以客户端ip为key。ip｛k1=v1； k2=v2｝把已经向下级查找，但未返回的数据，写入到这个key中。
给这个key设置警告容量=50，最大容量=100。则超过100，返回：太频繁的查询。
支持对一批客户端ip，设定限制警告，最大并发数。

写请求：维护一个很小的缓冲区，基本每秒写入。

整理队列：
lru队列：队列有容量限制。队列中的每个键值，都有一个热度值。
超出lru队列的冷数据：放入写队列。定时写入下级，写后移除。
几乎必须要有这个功能：从kv到非kv，比如到sql，到存储。
定时计算出本级最热的100个key，算出几个，以供上级读取。

1级2级lru之间，有一个边缘。这个边缘记录在一个变量中。临近此边缘的数据，会被频繁移出，移入。
有一个设定值：
上级写下来的冷数据：标记为最冷-2。
上级写下来的冷数据：标记为最热-100。

ssd中的某些key，有个属性，此属性阻止key写入到下级存储。这样的key断电不会丢失。但迁移时会被丢弃，导致丢失。

通过半夜运行的统计功能插件，实现热key分门别类统计，为数据分片，分集群提供建议。
提供一个管理员命令，手动变更key的热度。

还可以在这个中间件中实现：
1对后端3级库分库分表。
2对后端3级库读写分离。
3对后端3级库：从未分库分表，到分库分表，读写分离转换。
4对后端3级库：从1种分库分表，读写分离，转换到另一种分库分表，读写分离的转换。
5分布式cap，做在此中间件上。不需要后端数据库，带有任何分布式功能。不需要后端数据库，带有主从功能。

问：不需要后端数据库，带有任何分布式功能。为什么？
问：它用什么实现的cap？
答：
中间件自己，通过客户端2步提交，实现了对数据库的cap。
2步提交是一种传统cap的手艺，并不神奇。

6这种库（你叫中间件也可以），支持多种后端nosql,sql库。只需要，用各种语言开发插件即可。
7
* 功能以脚本为接口，采用插件的方式。
* 支持各种语言编写的插件。
* 插件运行后是独立进程。支持各种数据库的客户端。
* 热变更。没有停服的概念。随时启动，停止所有功能。

集群:
通过一个标签，如ip，或域名，或项目名，来标识集群peer，最终写入文件名。
对于集群，提供如下管理功能：
1 收。把ssd上的信息，丢弃掉不需要保存的后，从每个集群peer，按照项目备份。
2 放。把备份的恢复到ssd上。
3 整理热key。根据key的热度，在每个peer上平均key。通过这一点，可以达到热key永远平均分布在每个peer。
经过热key重新分布后，在每个peer上的键值对，和项目无法一一对应。即节点1上，有项目125的热key。

没有人能事先知道哪些key热。我的方案通过在ssd上存储key的热度，通过一个每天半夜运行的热key移动程序，达到了热key平均分布在各个集群peer。

--------【3级=网络存储。】--------

不分冷热，存有所有数据。

--------【3级=任意sql，nosql数据库。数据库不需要带cap，数据库不需要带主从。】--------

不分冷热，存有所有数据。与上述3互斥。

--------【此数据库的特性：】--------

1必须有2级存储。即必须使用ssd。

2程序永远只操作redis的kv对象，不关心是否有sql。
后端库sql库不关心kv功能。
因为所有的活，都被这个库中的2级缓存中的，中间件干了。

3对于一个冷读取，至少需要等待3秒：即从3级库hdd磁盘到2级磁盘等2秒，从2级磁盘到1级ssd等1秒。

4对于每个写请求：可选写入：4-1内存表示写入成功，4-2写入ssd表示写入成功，4-3写入hdd磁盘表示成功，4-4写入分布式库表示成功。
4-1会丢数据。丢数据情况为：断电，进程死机，数据被列入队列抛弃。234不会。这其中，最不重要的数据写入4-1，其次大多数写入4-2，剩下所有重要的数据写入4-4。
从4-2，到4-3，或到4-4，只能管理员手动操作。给管理员提供一个命令即可。

5不需要redis的snap，和aof，落盘功能。因为上述234保证了数据安全。

ssd2级磁盘，相当于redis的snap。
hdd3级磁盘，相当于redis的snap的snap。但又不是单纯的snap。这里面有很多种玩法。

5-1 hsnap比ssnap更大。是数据库，这样就不需要任何sql数据库，nosql库。
5-2 hsnap文件的大小，格式，都可以自定义。
5-3 hsnap可以带上域名，服务器ip。这样就成了分布式缓存。如此一来只需要网络上的2个副本，redis3主3从集群也没必要了。

6redis只是缓存，不能当库用。redis不存冷数据，但这个库可以。redis存储空间有限，但这个库可以看做空间无限。

6没有缓存击穿问题。没有缓存雪崩问题。没有缓存污染问题。没有热key问题。

--------【结论】--------

内存缓存 ---> ssd硬盘 ---> 网络存储上的文件
内存缓存 ---> ssd硬盘 ---> nosql，sql数据库 <--- 数据分析工具

问：为什么说redis集群没必要了？为什么说redis集群错了？

答：

网络磁盘分为：【单台】，【冗余】。对于自带冗余的网络磁盘，我们只需要简单的写入1台即可。
这里我们只谈：【单台】。单台需要从ssd读取，写入到所有2台【单台】网络磁盘。这里采用2步提交即可。
对于从【ssd】到【nosql，sql数据库】也是采用2步提交。
也就是说redis的集群，维持心跳，都没必要。
我再说明白点：
1客户端给ab提交，带着uuid，和写入时间，只要成功写入其中1台ssd即可。
2读的时候，任意1台客户机读成功即可。

redis集群特色：
每个集群节点，只有部分数据。
通过分插槽的方法，尽量平均读写压力。

本架构集群特色：

集群服务器不需要选主。没有raft。不需要3，5节点。支持1-4节点。

每个节点【最多】只需要2台网络副本，简称网络raid1。不分主，从。
基于2级磁盘ssd，可以人为手动，或配置文件自动，分库，分表，合库，合表。
继而实现：分节点，合节点。

集群客户端：

每个集群节点内存中，内有个key，含有所有集群的节点的ip，端口，版本。此key永远存在内存中。
客户端来读，非本集群的key，返回错误。
客户端来写，非本集群的key，返回错误。
或者说从客户端，选择返回数据的服务器。即，假如客户端不知道某key所在的节点，客户端首次读写某key，需要遍历所有服务器。
得到某个key所在的服务器后，会把本key的服务器ip，端口，写在本地。
也就是说，客户端维持每个key的服务器属性。这个属性，保存到磁盘上。
当服务器上的key，迁移到其他服务器后，不会通知客户端，只会返回错误。此时，客户端将从新遍历服务器，以查找key的所在。

假设集群有10个节点，那么客户端最多读10次，才能读到key值。
为了给这个操作提速，可以增加一个【key索引服务器】。
【key索引服务器】也是一个内存kv库。它频繁从10个节点上的ssd中，读key，然后建立索引。
有了【key索引服务器】，客户端只需要2次，即可读到key值：
1读key索引服务器，返回此key所在的peer的ip，记录在本地。
2从peer的ip，读取值。
很显然，集群节点少的情况，不需要【key索引服务器】。

问：为什么说redis的snap错了？

答：
客户端进来的数据，直接写入ssd，相当于aof。
因为本架构不需要snap。本架构没有snap过程。
在本架构中，1级缓存写入数据到ssd，必须经过lru。分buffer，分时段，写入。这个过程最多耗时1-2秒。即分片写入。
而进程重启后，从下级ssd缓存读取，也只选择ssd盘上lru队列中的topn条数据，塞满内存缓存的95%即可。
或者说redis的缺点是：snap保存到磁盘时，丢失了lru队列信息。