- 综合排序
- 最热优先
- 最新优先
- 来自专栏廖念波的专栏
谈谈 KV 存储集群的设计要点
Key-value存储系统，是非常普遍的需求，几乎每个在线的互联网后台服务都需要KV存储，我们团队在KV存储方面，经历过几个时期，我自己深感要做好不容易。 第三个时期，为了应对普遍的KV存储需求，我们以公共组件的形式重新设计了KV存储，作为团队标准的组件之一，得到了大规模的应用。 但这个阶段就用了我们团队足足2年多时间。 不同于无数据的逻辑层框架，KV存储系统的架构设计会更复杂、运维工作更繁琐、运营过程中可能出现的状况更多、bug收敛时间会更长。 一句话：团队自己做一个KV存储系统是成本很高的，而且也有比较高的技术门槛。 存储，用于存储一些公众号的个数不受限粉丝列表 上面八点，业内的KV存储组件一般都会考虑到，或者各有特色，各自优势在伯仲之间。
5.2K00发布于 2016-10-03 - 来自专栏QQ音乐技术团队的专栏
KV存储跨IDC容灾部署
1.背景 目前部分KV存储不支持跨IDC部署，所以如果有机房故障的话，就会影响KV存储的可用性。本文提供了一种通过KV存储代理层来实现跨IDC容灾部署的方案。 2.实现原理 ? 为了降低存储代理的压力，读写服务可以做读写分离，读取操作可以直接访问本地存储。 3.KV存储代理层实现原理 ? 客户端通过API接入KV存储代理, 如果是写操作, 存储代理会先写流水再操作本地KV存储. 流水转发程序会每隔10ms扫描流水,然后转发给流水转换服务. ，而KV存储本身不一定是支持跨IDC容灾部署的。 本文提供了一个通用的解决方案，实现KV存储跨IDC容灾部署。
1.8K80发布于 2018-01-30 - 来自专栏鸿蒙开发笔记
OpenHarmony 移植案例与原理 - utils子系统之KV存储部件 (2)
3、KV存储部件对外接口在文件utils\native\lite\include\kv_store.h中定义了KV存储部件对外接口，如下，支持从键值对缓存里读取键值，设置键值，删除键值，清除缓存等等。 int UtilsSetEnv(const char* path);4、KV存储部件对应POSIX接口部分的代码分析下KV存储部件对应POSIX接口部分的代码。 EC_FAILURE : EC_SUCCESS;}3、KV存储部件对外接口在文件utils\native\lite\include\kv_store.h中定义了KV存储部件对外接口，如下，支持从键值对缓存里读取键值 【OpenHarmony】Uboot 驱动加载流程12.OpenHarmony构建系统--GN与子系统、部件、模块详解13.ohos开机init启动流程14.鸿蒙版性能优化指南.......4、KV存储部件对应 POSIX接口部分的代码分析下KV存储部件对应POSIX接口部分的代码。
24010编辑于 2025-06-14 - 来自专栏携程技术
干货 | 携程持久化KV存储实践
图1 随着业务发展和Redis集群的日益增长，需求更加多样化，需要在私有云上同样能有一种持久化的KV存储系统来提供服务，包括： 1）KV存储和读写的场景，Redis能提供的存储上限过低，需要有大容量的 KV存储系统； 2）数据持久化，而不是像Redis那样重启数据即丢失； 3）节约Redis的使用成本，毕竟私有云上的Redis集群非常庞大； 4）提供类似selectforudpate的语义来实现库存之类字段的扣减 性能也是重要考量的一块，希望找到一种性能优异的KV数据库。 其次标识位往往有一定含义或者能与当前业务数据做关联，这就相当于额外存储了一份业务数据，存在一定的安全隐患。 2）硬盘的带宽与内存有2个数量级的差距，而这些先天不足也无法满足某些Redis场景的需求。
1.4K20发布于 2021-07-22 - 来自专栏小白debug
聊聊原美图开源的 kv 存储 titan
市面上开源 kv 轮子一大堆，架构上都是 rocksdb 做单机引擎，上层封装 proxy, 对外支持 redis 协议，或者根据具体业务逻辑定制数据类型，有面向表格 table 的，有做成列式存储的 即使开源也很难有持续的动力去维护，比如本文要分享的 美图 titan[1]，很多优化的 proposals[2] 都没实现，但是做为学习项目值得研究，万一哪天二次开发呢 整体架构 Titan 代码 1.7W 如果基于最新版本的 tikv 集群测试效果可能更好 数据类型实现 目前数据结构只实现了 string, set, zset, hash, list, 有些也只是部分支持，只能说够用 持久化的 kv 轮子 原因在于对于 Linsert 操作，如果插入 (2, 3) 之间，那么会失败，但是用 float64 大概率会成功，但是考滤 float64 也有精度问题，存在失败的概率 // calculateIndex 可以说 tikv 减少了持久化 kv 开发难度，也束缚了灵活性 删除 GC Delete 时，删除 MetaKey，如果存在 TTL 那么删除 ExpireKey, 对于非 String，将 DataKey
55510编辑于 2023-09-13 - 来自专栏roseduan写字的地方
使用 WAL 构建你自己的 KV 存储
这篇文章将主要描述，如何使用我最近新开发的 WAL（Write Ahead Log）构建属于你自己的 KV 存储引擎。 简单可靠的 KV 存储引擎。 ，也可以使用 wal 来存储 kv 分离之后的 Value Log 文件。 首先，我们要做的就是选择一个内存数据结构，比如 B-Tree、跳表、红黑树、哈希表等等都是可以的，只要是能够存储一个 KV 值即可。 这几个主要的步骤一完成，一个最基础的 KV 存储引擎就构建起来了，当然你还可以基于此做很多的完善和优化。
61420编辑于 2023-09-01 - 来自专栏roseduan写字的地方
硬核项目 KV 存储，轻松拿捏面试官！
本文是《从零实现 KV 存储》课程的面试要点总结，相当于只要你学习了课程，以下提到的内容都是你自己完成的。 项目概述 基于 Bitcask 模型，兼容 Redis 数据结构和协议的高性能 KV 存储引擎 设计细节 采用 Key/Value 的数据模型，实现数据存储和检索的快速、稳定、高效 存储模型：采用 Bitcask 有哪些适用场景 缓存系统 KV 数据库可用作缓存系统的后端存储，以提供快速的数据访问和响应能力。 由于 Bitcask 存储模型具有高性能和低读写放大的特性，它适合存储频繁访问的热数据，提供快速的缓存读取操作。 日志存储 KV 数据库可以作为日志存储系统使用，将日志数据持久化到磁盘上的日志文件中。 key 和索引数据 追问 2：Hint 文件的格式是什么 和数据文件是一样的，都采用了日志追加的方式 持久化策略优化 在最开始的设计中，默认的刷盘策略是交给了操作系统来调度，这样的好处是性能很好，
1.3K20编辑于 2023-09-01 - 来自专栏roseduan写字的地方
一个全新的 kv 存储引擎 — LotusDB
idea，让我有了做一个新的 kv 存储引擎的想法。 感兴趣的可以参考下论文，叫做 SLM-DB，地址：https://www.usenix.org/conference/fast19/presentation/kaiyrakhmet 众所周知，数据存储引擎 和 bitcask 模型的设计，存储到单独的 value log 文件中。 = nil { // ... } key2 := []byte("feature") // 2. Sync: true, ExpiredAt: time.Now().Add(time.Second * 100).Unix(), } err = db.PutWithOptions(key2,
1K20编辑于 2022-04-18 - 来自专栏分布式研究小院
200行代码实现基于paxos的kv存储
这是一个基于paxos, 200行代码的kv存储系统的简单实现, 作为 [paxos的直观解释] 这篇教程中的代码示例部分. VBal *BallotNum ... ... } 以及KV服务的client端和server端的代码, client端是实现好的, server端只有一个interface, 后面我们需要来完成它的实现 voted的值都为空, 则直接返回: if p.Val == nil { return nil } [Example_setAndGetByKeyVer] 这个测试用例展示了如何使用paxos实现一个kv 遇到冲突并解决冲突的例子, 略长不贴在文中了, 代码可以在 [TestCase2DoubleProposer] 看到 下一步 我们实现了指定key, ver的存储系统, 但相比真正生产可用的kv存储, 以上这3块内容, 后续播出, 下个版本的实现将使用经典的log 加 snapshot的方式存储数据.
60510编辑于 2022-04-28 - 来自专栏后端码匠
美团万亿级 KV 存储架构与实践
美团点评 KV 存储发展历程 美团第一代的分布式 KV 存储如下图左侧的架构所示，相信很多公司都经历过这个阶段。 在客户端内做一致性哈希，在后端部署很多的 Memcached 实例，这样就实现了最基本的 KV 存储分布式设计。 内存 KV Squirrel 架构和实践 在开始之前，本文先介绍两个存储系统共通的地方。比如分布式存储的经典问题：数据是如何分布的？这个问题在 KV 存储领域，就是 Key 是怎么分布到存储节点上的。 B 节点正常处理完客户端的读写请求之后，还会把本应该写入 A 节点的分片 1&2 数据写入到本地的 Log 中。 ? Squirrel 和 Cellar 虽然都是 KV 存储，但是因为它们是基于不同的开源项目研发的，所以 API 和访问协议不同，我们之后会考虑将 Squirrel 和 Cellar 在 SDK 层做整合
1.5K20发布于 2020-07-22 - 来自专栏NebulaGraph 技术文章
Nebula Graph 的 KV 存储分离原理和性能测评
值得注意的是，Nebula 从 3.0.0 版本开始已经提供了 KV 分离的功能。用户可以通过 nebula-storaged 的配置文件来配置 KV 分离的功能。 2. [Nebula Graph 的 KV 存储分离原理和性能测评] 图2. NVMe SSD 性能 因此大量的读写放大会浪费带宽。 3.2 KV 分离后 RocksDB 的内部结构 我们分别使用 KV 分离和不分离的方式导入数据集 Data2。 的 KV 存储分离原理和性能测评] [Nebula Graph 的 KV 存储分离原理和性能测评] [Nebula Graph 的 KV 存储分离原理和性能测评] [Nebula Graph 的 KV 针对数据集 Data2 的数据分布特性，我们测试了分别以 100B 和 4KB 作为 KV 分离的阈值。可以很明显地看到 KV 分离极大地提升了 Data2 的查询性能。
1.4K20编辑于 2022-03-01 - 来自专栏大数据-BigData
B站分布式KV存储混沌工程实践
01 背景 之前我们介绍了B站分布式KV存储在B站的探索实践（←点击回顾前文）。本文主要介绍对于高可靠、高可用、高性能、高扩展的B站分布式KV存储系统来如何保障其可靠性以及混沌工程的落地实践。 分布式存储业界已经发展几十年，各个商用存储团队也有对应的开源测试框架，比较知名的比如P#[2]和Jepsen[3]，但是这些框架应用成本高，在非商用存储团队中已有的迭代开发过程中很难有额外的人力应用实施 04 混沌工程实践 4.1 建立稳态假设 B站分布式KV存储是随着业务需求不断迭代开发，功能需求逐渐覆盖到全公司各个业务线，性能和可靠性也是逐步完善优化的过程，在实践中需要对于稳态的标准不断更新和优化。 两套KV存储集群，模拟多机房部署物理隔离。 单套集群部署多region分区。 单个region分区中包含同等规模的raft group。 () //封装批量请求PUT/GET/DEL并持续检查数据状态go func() { common.PutGetDelBatch(t, true, b.Client) close(done2)
83040编辑于 2022-06-12 - 来自专栏呼啸长风的专栏
FastKV：一个真的很快的KV存储组件
一、前言 KV存储无论对于客户端还是服务端都是重要的构件。 我之前写过一个叫LightKV的存储组件，当时认知不足，设计不够成熟。 [2ac2c3f9f4bcfaebc10ea0d6564299b6.png] 虽然说现在APP体积都不小，但毕竟增加体积对打包、分发和安装时间都多少有些影响。 (objectKey, list, LongListEncoder.INSTANCE); List<Long> list2 = kv.getObject("long\_list"); 除了支持基本类型外 四、结语 本文探讨了当下Android平台的各类KV存储方式，提出并实现了一种新的存储组件，着重解决了KV存储的效率和数据可靠性问题。
1.7K00发布于 2021-10-14 - 来自专栏roseduan写字的地方
实现分布式 kv—2 raft leader 选举
上一篇文章讲到了实现一个简单的单机版 kv，如果不熟悉的话可以先回顾一下： 实现分布式 kv—1 Standalone KV 从本篇文章起，就要基于 raft 构建分布式 kv 了。 这篇文章暂时只介绍第一个 Leader 选举问题，对应的是 TinyKV 中的 Project 2aa 部分。 advances the internal logical clock by a single tick. func (r *Raft) tick() { // Your Code Here (2A Candidate 节点收到 MsgRequestVoteResponse 消息之后，需要记下投票的结果，然后计算投票是否满足： 如果拒绝票超过节点数的 1/2，那么竞选失败，Candidate 节点变为 Follower 状态 如果赞成票超过节点数的 1/2，那么竞选成功 如果竞选成功，需要变更自己的状态为 Leader，然后向其他节点发送一个 MsgAppend 消息，附带一个空的数据 Entry，
62320编辑于 2021-12-27 - 来自专栏并发笔记
如何设计一个基于Paxos的KV存储系统
介绍 Klein是一个基于Paxos分布式共识类库，我使用它实现了KV存储、缓存。 基于此，你可以有无限多的想法，例如用Klein来实现KV存储，或者用它来实现分布式缓存，甚至用它来实现分布式锁，etc anything. 2. 成员变更、优化读请求【进行中】 • 成员自动发现(调研) • 数据对齐：成员上线、落后成员对齐 • NWR • confirm优化读请求 • 不存在干扰key，无需执行一轮Prepare 2.
78731编辑于 2022-11-21 - 来自专栏roseduan写字的地方
实现分布式 kv—1 Standalone KV
这个课程分为了 4 个 Project： Standlone KV Raft KV Multi Raft KV Transaction 分别需要实现单机版 kv、基于 raft（和 multi raft 当然这个课程也是入门和实践分布式存储领域的挺好的学习资源，因此记录一下自己的学习历程。 今天这篇文章先来看看第一个 Project。 Badger 是一个很优秀的开源的单机版 kv 存储引擎，基于 LSM Tree 实现，读写性能都很好，因此需要简单熟悉下 Badger 的用法，可以参考下官方示例：github.com/dgraph-io 在 TinyKV 中，存储层是一个抽象接口，分别实现了 raft storage、mem storage、standalone storage，这里我们只需要实现 standalone storage 你可以把 TinyKV 的代码 clone 下来，然后自己跟着我的节奏做，一步一步坚持下去，相信能够在分布式存储领域有个初步的认知。
1.1K20发布于 2021-11-30 - 来自专栏Rust语言学习交流
【Rust日报】2022-12-27 Rust 中的 KV 存储引擎
Rust 中的 K/V 存储引擎 Bassfaceapollo 发现了一些很酷的 Rust K/V 存储引擎项目，想与社区分享： Engula - 分布式 K/V 存储。它似乎是最活跃的项目。 AgateDB - 由 PingCAP 新创建的存储引擎，试图在 Tikiv 数据库中替换 RocksDB。 Marble - 一个新的 K/V 存储，旨在成为 Sled 的底层存储引擎，本身仍在开发中。 PhotonDB - 一种高性能存储引擎，旨在利用现代多核芯片、存储设备、操作系统和编程语言的强大功能。 DustData - Rustbase 的存储引擎（Rustbase 是一个 NoSQL K/V 数据库）。 Persy - 是用 Rust 编写的事务存储引擎. ReDB - 一种简单、可移植、高性能、ACID、嵌入式键值存储，其灵感来自 LMDB。
62040编辑于 2023-02-15 - 来自专栏idba
使用开源技术构建有赞分布式 KV 存储服务
当时对比了几个开源产品， 最终选择了 aerospike 作为我们的 KV 存储方案。 有了此架构后， 我们就可以在不改动现有 aerospike 集群的基础上， 来完善我们目前的KV服务短板， 因此我们基于几个成熟的开源产品自研了 ZanKV 这个分布式 KV 存储。 我们称之为表2 rocksdb 使用 LSM 作为底层数据存储结构，扫描按照过期时间顺序存储的表2速度是比较快的。 通过 raft 协议发起删除请求，在删除请求处理过程中将存储的数据和过期元数据信息(表1和表2的数据)一并删除。 与一致性数据过期不同的是，在该策略下，不再存储表1的数据，而仅仅保留表2的数据，如下图所示： ?
1.8K21发布于 2019-07-01 - 来自专栏鸿蒙开发笔记
OpenHarmony 移植案例与原理 - utils子系统之KV存储部件 (1)
LiteOS-A内核：KV(key value)存储、定时器、JS API(设备查询，数据存储)、Dump系统属性。 本文介绍下移植开发板时如何适配utils子系统之KV存储部件，并介绍下相关的运行机制原理。KV存储部件定义在utils\native\lite\。 # KV存储实现│ ├── innerkits # KV存储内部接口│ └── src # KV ⑴处用于配置子系统的KV存储部件。 中声明了KV存储的函数，并定义了结构体KvItem。
28010编辑于 2025-06-14 - 来自专栏JavaGuide
腾讯自研的分布式高性能KV存储开源了！
项目简介 Tendis是腾讯互娱CROS DBA团队 & 腾讯云数据库团队自主设计和研发的分布式高性能KV存储数据库，兼容Redis核心数据结构与接口。 持久化存储 使用rocksdb作为存储引擎，所有数据以特定格式存储在rocksdb中，最大支持PB级存储。 Tendis冷热混合存储关键组件 得益于Tendis存版的设计和内部优化，Redis和Tendis存储版可以一起工作成为Tendis冷热混合存储。混合存储区非常适用于KV存储场景，并平衡了性能和成本。 对于redis占用大量存储空间的冷数据降冷后可以最多减少80%的成本，同时保证了热数据在redis的访问性能。 Tendis 存储版 vs Redis cluster 优点： 所有数据存储到磁盘，提供更大的容量和更低的成本，数据可靠性更高 多线程架构，单进程的性能吞吐比redis单进程更高（30wQPS vs 13wQPS
2.6K30发布于 2021-01-08
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号