摘要：
OceanBase的2PC（两阶段提交）协议在保证分布式事务原子性的同时，通过多项创新优化，大幅提升了性能与可用性。其核心思想是去中心化的协调者、利用Paxos日志保证一致性，以及针对单机事务的优化。 下图清晰地展示了OceanBase 2PC的完整流程、核心角色及关键优化点： 下面分阶段详细说明流 阅读全文
posted @ 2025-12-30 17:28
程煕
阅读(7)
评论(0)
推荐(0)
摘要：
Raft和Multi-Paxos都是分布式共识算法，确保多个节点在某个值上达成一致。以下是它们达成共识的具体流程： Raft算法流程 Raft将共识分解为三个子问题：领导选举、日志复制 和 安全性。 1. 领导选举 角色：Leader（领导者）、Follower（跟随者）、Candidate（候选人 阅读全文
posted @ 2025-12-30 17:24
程煕
阅读(14)
评论(0)
推荐(0)
摘要：
基于Kubernetes Operator的云原生分布式数据库是一个进阶主题，其核心是将数据库运维专家的知识转化为Kubernetes平台上的自动化操作。它通过声明式的配置，让用户能够像管理原生Kubernetes资源一样管理复杂的数据库集群。 下表汇总了几个主流分布式数据库Operator的核心设 阅读全文
posted @ 2025-12-30 17:08
程煕
阅读(3)
评论(0)
推荐(0)
摘要：
云原生数据库的存算分离架构本质上是将传统单体数据库拆解为可独立伸缩、故障隔离的微服务化组件，并通过云原生的标准接口（如对象存储、块存储服务）进行高效协作。这种架构是数据库充分释放Kubernetes和云基础设施潜力的关键设计。 🏗️ 架构核心：三层解耦与K8s实现 下图清晰地展示了存算分离架构在云 阅读全文
posted @ 2025-12-30 00:57
程煕
阅读(13)
评论(0)
推荐(0)
摘要：
在Kubernetes上进行云原生分布式数据库的垂直规格变更，本质上是通过声明式API，让数据库工作负载（Pod）的资源配置（CPU/内存）在无需重启或最小化影响的情况下被动态更新。 下面我将以 StatefulSet 为核心，详细解释在K8s中对云原生分布式数据库进行垂直规格变更的正确流程和K8s 阅读全文
posted @ 2025-12-30 00:47
程煕
阅读(12)
评论(0)
推荐(0)
摘要：
OceanBase 的底层存储引擎核心是基于 LSM‑Tree（Log‑Structured Merge‑Tree） 的“基线‑增量”架构。在此基础上，从 V4.3 版本开始扩展了对列存的支持，形成了行存/列存/混存一体化的存储体系。 📚 核心架构：LSM‑Tree 的“基线‑增量”模型 Ocea 阅读全文
posted @ 2025-12-30 00:41
程煕
阅读(14)
评论(0)
推荐(0)
摘要：
RocksDB 是一个由 Facebook（现 Meta）开发并开源的高性能嵌入式键值存储库。它专为在快速存储设备（如 SSD、NVMe）上运行而优化，被广泛应用于需要高性能持久化存储的场景。 核心特性 1. LSM-Tree 架构 基于 日志结构合并树（Log-Structured Merge-T 阅读全文
posted @ 2025-12-30 00:37
程煕
阅读(75)
评论(0)
推荐(0)
摘要：
概述 LSM-Tree（日志结构合并树）是一种高效的数据结构，专门为写密集型存储系统设计，广泛应用于现代数据库和存储引擎中。 核心设计理念 1. 基本思想 将随机写转换为顺序写：这是LSM-Tree最重要的特性 延迟合并策略：数据先写入内存，批量合并到磁盘 分层存储结构：数据从内存到磁盘逐层移动 2 阅读全文
posted @ 2025-12-30 00:32
程煕
阅读(77)
评论(0)
推荐(0)
摘要：
Merkle树和LSM-Tree是两种在计算机科学中常用的数据结构，它们在设计目标、应用场景和实现原理上有显著区别，但在某些系统中也可以结合使用。 一、核心区别 1. 设计目的不同 Merkle树：主要用于数据完整性验证和高效比较 验证数据块是否被篡改 快速比较两个大数据集的一致性 轻客户端验证（如 阅读全文
posted @ 2025-12-30 00:28
程煕
阅读(3)
评论(0)
推荐(0)
摘要：
LevelDB 是一个由 Google 开发的、高性能、轻量级的嵌入式键值存储库。它不是一个独立的数据库服务器，而是一个供程序直接链接使用的 C++ 库，用于将数据持久化存储在本地磁盘上。 核心特性 键值存储： 数据模型非常简单，所有的数据都由一个键（key）和一个值（value）组成。 键和值都是 阅读全文
posted @ 2025-12-30 00:27
程煕
阅读(18)
评论(0)
推荐(0)
摘要：
MongoDB和Cassandra通过完全不同的机制保障分布式事务一致性，这源于它们迥异的设计哲学（MongoDB偏向CP，Cassandra偏向AP）。 简单来说： MongoDB（v4.0+）：提供真·多文档ACID事务，类似传统数据库，但使用分布式快照隔离。 Cassandra：核心是最终一致 阅读全文
posted @ 2025-12-30 00:23
程煕
阅读(8)
评论(0)
推荐(0)
摘要：
Multi-Paxos和Raft都是确保分布式系统一致性的核心算法，但它们在设计哲学、工程实现和性能特征上存在根本区别。简单来说，Raft追求“易于理解和实现”，而Multi-Paxos追求“极致的理论性能”。 下面是两者的核心区别对比： 特性维度 Raft Multi-Paxos 核心设计哲学 易 阅读全文
posted @ 2025-12-30 00:17
程煕
阅读(13)
评论(0)
推荐(0)
摘要：
OceanBase利用Multi-Paxos协议来实现高可用的分布式事务，核心目标是替换传统的主备同步机制，确保在未发生多数派永久性故障的前提下，所有提交成功的数据均可恢复。 🔧 Multi-Paxos在OceanBase中的工作原理 在OceanBase中，事务日志的提交和回放过程是其分布式一致 阅读全文
posted @ 2025-12-30 00:15
程煕
阅读(12)
评论(0)
推荐(0)
摘要：
根据公开的技术资料和区块链共识原理，Hyperchain（趣链）的Replica节点在Prepare阶段对Primary广播的Batch哈希验证，主要目标是确保收到的批量交易数据（Batch）与主节点声明的完全一致，并且排序正确。 虽然搜索结果中没有直接给出Hyperchain在此处的具体代码实现， 阅读全文
posted @ 2025-12-30 00:11
程煕
阅读(4)
评论(0)
推荐(0)
摘要：
Hyperchain动态分片的实现 1. 动态分片的核心工作流程 Hyperchain的动态分片遵循"监控-决策-执行-反馈"的闭环机制，与知识库[1]中描述的去中心化AI系统动态分片原理一致： 状态监控（5-10秒间隔） 节点层面：CPU/GPU利用率、内存占用、网络带宽/延迟、电量 任务层面：交 阅读全文
posted @ 2025-12-30 00:03
程煕
阅读(4)
评论(0)
推荐(0)
摘要：
Hyperchain的智能合约执行是一个分布在验证节点（VP） 和非验证节点（NVP） 上的协同过程。简单来说，验证节点负责达成交易的共识顺序，而非验证节点则负责具体执行这些交易中的智能合约。 下图可以帮你更直观地理解从你发起一笔交易到合约状态最终上链的完整流程： flowchart LR subg 阅读全文
posted @ 2025-12-30 00:00
程煕
阅读(9)
评论(0)
推荐(0)
浙公网安备 33010602011771号