1.FREE SOLO - 自己动手实现Raft - 16 - leveldb源码分析与调试-2
2.FREE SOLO - 自己动手实现Raft - 10 - libuv源码分析与调试-1
3.FREE SOLO - 自己动手实现Raft - 开篇
4.Raft 论文导读：探索一种可理解的源码共识算法
5.FREE SOLO - 自己动手实现Raft - 17 - leveldb源码分析与调试-3
6.一文说透Raft协议

FREE SOLO - 自己动手实现Raft - 16 - leveldb源码分析与调试-2

       继续探讨leveldb的内部操作，首先解析写入过程。详解write-batch和leveldb key是源码核心数据结构，它们在数据写入中的详解角色至关重要。

       1. 数据写入流程：当通过DBImpl::Put或DB::Put添加键值对时，源码数据会被封装成write-batch。详解洋河源码组这个batch随后交给DBImpl::Write，源码最终由log::Writer::AddRecord负责将数据写入log。详解这样，源码数据便有了持久化的详解记录。

       2. 写入memtable：写入log后，源码数据还会被添加到memtable，详解便于快速查询。源码同样，详解DBImpl::Write通过MemTableInserter::Put调用MemTable::Add，源码将数据写入memtable，形成内存中的临时存储。

       3. 数据读取：对于查询，DBImpl::Get是起点，通过MemTable::Get调用SkipList::FindGreaterOrEqual在SortedTable的SkipList中搜索，提供即时的数据访问。

       总结：通过上述调用栈，我们可以对leveldb的写入和读取有更深入的理解。在后续的内容中，我们将关注大量数据写入对内存和磁盘影响的详细分析。

       期待在下次与您分享更多内容，再见！

       联系信息：email: castermode@gmail.com | 网站：vectordb.io | 项目未指定

FREE SOLO - 自己动手实现Raft - - libuv源码分析与调试-1

       了解EventLoop这一核心概念，就是“Reactor模型”的主体框架。Reactor模型是一种程序设计模式，其本质在于如何对外界各种刺激做出反应，利用单一或者多个线程，处理各类外部事件，如网络数据包接收、定时器超时等，根据不同事件注册相应的回调函数。

       以“状态机思维”分析libuv源码，为后续开发奠定基础。状态机思想提供了一种简洁高效的方式来描述程序的工作流程。在libuv中，主要有两种核心数据结构：Handle与Request。转转源码授权Handle代表常驻内存提供服务的数据结构，如uv_tcp_s，表示TcpServer，不断对外提供服务，同样可以作为TcpClient。Request则代表一次请求，如uv_req_s，其生命周期与请求处理过程相同，不会驻留在内存中。请求被处理后，该数据结构随即释放。

       libuv能够处理多种不同事件，常见的几种包括：网络事件、文件系统事件、信号事件、异步操作完成事件等。未来，我们将深入解析这些核心事件的相关源代码。

FREE SOLO - 自己动手实现Raft - 开篇

       欢迎来到我的 Raft 自动实现项目，旨在通过个人实践，加深对Raft协议的理解并分享经验。在大数据和AI时代，分布式系统变得至关重要，而Raft协议作为一致性保证的首选，更是不可或缺。我在业界有过多次Raft协议的开发经验，虽然过程充满挑战，但也收获颇丰。现在，我决定重新实现Raft，以MVP形式出发，目标是创建一个用户友好的开源项目，帮助初学者深入理解协议原理和源码工作原理。

       项目难点主要体现在理解、测试和应用三个层面。首先，Raft的设计目标是易于理解，但在实际编程时可能会遇到困惑。解决这个问题的关键在于掌握状态机思维，即将分布式系统视为一系列状态转换，源码仓库地址遵循明确的规则。状态机模型简单却深具启发，比如图灵机和状态机的区别，将在后续文章中详细介绍。

       在测试上，Raft的复杂性导致难以构建精确的自动化测试，尤其是涉及多节点协调的场景。为解决这个问题，我设计了remu工具，它模拟分布式系统的暂停和恢复，以辅助测试。通过gdb扩展，remu允许编写自动化测试用例，并检查系统状态的一致性。

       应用方面，我计划提供vmeta、vstore、vectordb、vgraph等多种功能，以适应不同的业务场景。这需要一个灵活的框架，通过插件化设计，如kv引擎、vector引擎等，以简化开发工作。

       技术栈的选择上，C/C++是底层开发的首选，因其对硬件的适应性和功能强大的面向对象编程。我利用C++的智能指针和现代特性，同时避免过度复杂性。第三方库方面，我谨慎选择，并在项目中保持代码的可调试性。

       SEDA架构被用于项目，它的分阶段事件驱动设计有助于扩展性。尽管不是最高效，但在分布式系统中，扩展性是首要考虑的。我正在探讨如何让开源更深入，鼓励更多人参与和学习。string方法源码

       未来，我将继续迭代和完善vraft项目，如果你对此感兴趣，可以通过邮件castermode@gmail.com或访问我的网站vectordb.io与我交流，共同进步。感谢你的关注与支持，让我们一起探索Raft的世界！

Raft 论文导读：探索一种可理解的共识算法

       对于理解和实现一种可理解的共识算法，如 Raft，首先，它像跑步一样，虽然重要但难以入门。一个好的论文导读能帮你克服语言障碍，特别是对于 Raft 的小论文，虽然大论文提供了更多细节，但本文将主要聚焦于小篇幅但关键的页内容。

       论文的核心是寻找一种易于理解的共识算法，以替代复杂且难以掌握的 Paxos。作者通过对比 Paxos的挑战，指出其难懂且对系统构建和教育的实用性不足，从而引出 Raft 的目标——提供更好的理解和实践基础。

       Raft 通过问题拆解，将共识算法简化为三个可理解的子问题，并提供了行的C++代码示例，方便理解和实现。它还通过实验验证了Raft在理解性上的优势，与Paxos形成了鲜明对比。

       设计原则方面，Raft注重可理解性，例如通过减少状态数量和引入随机化来降低系统的不确定性。论文还介绍了复制状态机的概念，这是共识算法设计的基础，它确保在多副本系统中数据保持强一致性且高度可用。

       实现中，Raft强调日志和数据的分离，算法独立于底层存储，以及算法的网络和存储抽象。此外，节点状态、任期和RPCs等概念在Raft中起着关键作用，越狱游戏源码特别是leader选举，它是共识达成的核心机制。

       通过讲述leader选举的规则和过程，我们看到Raft如何通过规则和随机性来保证系统的稳定。日志复制是另一个重要环节，它与leader选举共享实现基础，但这里我们只给出了大致的图示和流程概述。

       最后，虽然本文只介绍了论文的冰山一角，但希望能激发你进一步探索的兴趣。如果你想深入理解或实际应用，大论文和源码学习是必不可少的，同时也可以参考相关问题和专家的观点。

FREE SOLO - 自己动手实现Raft - - leveldb源码分析与调试-3

       leveldb的数据流动路径是单向的，从内存中的memtable流向不可变的memtable，最终写入到磁盘上的sorted table文件中。以下是几个关键状态的分析，来了解内存和磁盘上数据的分布。

       以下是分析所涉及的状态：

       1. 数据全在内存中

       随机写入条数据，观察到数据全部存储在memtable中，此时还没有进行compaction操作。

       2. 数据全在磁盘中

       写入大量数据，并等待数据完全落盘后重启leveldb。此时，数据全部存储在磁盘中，分布在不同的level中。在每个level的sstable文件中，可以看到key的最大值与最小值。

       3. 数据部分在内存中，部分在磁盘中

       随机写入条数据，发现内存中的memtable已满，触发compaction操作，数据开始写入到sstable文件。同时，继续写入的数据由于还未达到memtable上限，仍然保存在内存中。

       4. 总结

       通过观察不同数据写入量导致的数据在内存与磁盘间的流动，我们可以看到leveldb内部状态的转换。

       下篇文章将分析LRUCache数据状态的变化。敬请期待！

一文说透Raft协议

       分布式一致性共识算法指的是在分布式系统中，使得所有节点对同一份数据的认知能够达成共识的算法。这个命名强调了一致性，但是我们知道在满足强C的情况下，对应的A就会被破坏地支离破碎。所以分布式一致性共识算法一般基于各种精妙的算法机制，能够在尽可能少地牺牲 C 的基础之上，将 A 提升到尽可能高的水平。

       在讨论 Raft 算法的可用性A方面，它确保了当分布式系统中多于半数的节点仍然存活时，系统能够稳定运行, 多数派原则是提高分布式系统可用性 A 的关键。此外，请求处理时间是基于大多数节点的最小响应时间，而非整个系统的最小响应时间。

       在数据一致性C方面，Raft 算法的标准版本可以确保数据达到最终一致性。但是，在实际工程实践中，我们可以对 Raft 算法进行些许改良，由此实现数据的即时一致性，从而进一步确保强C特性的实现。

       Raft协议基于quorum机制，即大多数同意原则，任何的变更都需超过半数的成员确认。

       状态机可以被视为节点用来实际存储数据的仓库。每个写入请求的最终步骤都是把结果保存到状态机里面，同时，读取请求也需要从这个状态机中提取数据以便响应。

       预写日志（Write-Ahead Logging, WAL）是一种常用的数据持久化方法，其主要目标是在系统发生故障时保证数据的一致性和可靠性。当进行状态改变的操作时，系统首先将这些操作记录到日志中，然后再实际执行这些操作。只有在操作被成功记录到日志中后，才会修改内存中的状态。如果过程中发生了故障，例如系统崩溃或者电源中断，可以通过重新执行日志中的操作来恢复之前的状态。只有当一个日志（即写入请求）得到了集群大多数派的认同后，它才会被提交并将修改应用到状态机中。

       wal日志采用二进制格式，解码后得到的是LogEntry数据结构。其首个字段type包含两个值，0代表Normal，1代表ConfChange（ConfChange用于同步Etcd的配置更改，例如新节点的加入）。其次是term字段，每个term标识一个主节点的任期，任期会在主节点更改时更新。第三个字段index是严格单调增加的序列，代表变更编号。最后一个字段是二进制data，存储了raft request对象的pb结构。在Etcd源代码中有一个工具叫做etcddump-logs，它可以将wal日志转储为文本格式，以便分析Raft协议。

       Raft协议并不处理应用数据即data字段的内容，而是通过同步wal日志来保证一致性。每个节点需要将从主节点接收的data应用到其本地存储。在这个过程中，Raft只关心日志的同步状态。因此，如果在应用data到本地存储的过程中存在bug，可能会导致数据不一致，即使所有Raft日志已经同步。

       "Term"或"任期"是一个核心概念，它用于标识领导者选举的轮次。

       一个Term开始于一个候选人尝试成为领导者，并发起选举。这个候选人会增加他的Term计数，并将其与投票请求一同发送给其他所有节点。如果其他节点收到了带有更高Term的投票请求，那么他们就会更新自己的Term并投票给该候选人。

       在 Raft 算法中，所有的节点（无论是领导者、候选人还是跟随者）在发送 RPC (Remote Procedure Call) 请求或响应时，都会在消息中带上自己当前的任期号（Term）。这是因为 Term 是 Raft 协议中用于标识消息新旧和避免过期操作的关键信息。

       如果一个节点收到了一个包含较新任期（更大的任期号）的消息，那么它会立即更新自己的当前任期到这个新的任期，并将自己的状态切换为跟随者。如果收到的消息的任期号小于自身的任期号，则该消息会被视为过期信息并被忽略。

       因此，在 Raft 中，无论是跟随者、候选人还是领导者，所有的 RPC 消息都会带上 Term 信息。

       当一个新的日志条目被领导者创建并添加到其日志中时，这个条目会被赋予一个新的索引号，这个索引号等于当前日志列表的长度加一。因为日志索引号是递增的，所以每一条日志都会有一个唯一的索引号。

       每一笔日志除了索引号之外，还有一个核心属性term: 用于标识这则日志是哪个任期的 leader写入的。

       Raft协议中的领导者承担两种职责： 接收写请求 周期性发送心跳包

       对于两阶段提交我们可以分别从单机和系统的两个角度去理解.

       从单机层面，一笔写请求会分为添加到预写日志和应用到状态机两个步骤，这可以看做是一种两阶段提交.

       在整个系统层面，两阶段提交的流程可拆解如下：

       第2步是提议阶段（proposal），第4步是提交阶段（commit），两者构成了所谓的"两阶段提交"的流程.

       如果跟随者（follower）发现当前领导者（leader）的任期小于自己记录的最新任期，跟随者会拒绝领导者的这次同步请求，并在响应中告诉领导者当前的最新任期。在感知到新任期的存在后，领导者也会适时地主动退位变为跟随者。

       领导者（leader）的任期滞后主要发生在以下几种情况：

       即使领导者（leader）的任期是最新的，如果跟随者（follower）在该最新同步日志之前的预写日志数据存在缺失，那么跟随者会拒绝领导者的同步请求。当领导者发现自己的任期与跟随者响应的任期相同，但同步请求被拒绝时，它会试图递归地逐个向跟随者同步预写日志数组中的早期日志，直到补全跟随者缺失的全部日志。一旦所有缺失日志被补全，流程将恢复正常。

       当一个领导者试图向跟随者复制一个日志条目时，但在该日志条目还没被提交前，领导者突然宕机，然后新的领导者被选出。这种情况下，已经接收到旧领导者日志条目的节点的日志就会比新领导者的日志更“新”。当新领导者尝试将自己的日志复制给这些节点时，这些节点就需要删除"超前"的日志并同步新领导者的日志，以保持集群状态的一致性。

       当跟随者（follower）接收到读请求时，它会将这些请求统一转发给领导者处理。只要领导者在处理写请求时，确保先更新状态机，然后再向客户端响应，就能保证状态机的数据实时一致性。然而，这种方式的缺点是领导者的负载可能过高，其他跟随者节点主要作用变成存储备份数据，相对较为被动。

       这种强制读主存在另外一个问题，即在网络分区后仍错误地认为自己是领导者，提供的数据都是旧数据(因为多数派原则的存在，领导者写数据都会失败，但是读数据不受影响)。解决方案是在领导者提供读服务时，先广播所有节点以得到多数响应来确认自己的领导者身份。

       这种设计可以确保，在任何时刻，所有正常运行的副本节点上的状态机都处于一个一致的状态。即使在发生故障转移的情况下，新选出的领导者也能够完成未完成的日志复制，并保证所有正常运行的副本节点上的状态机达到一致的状态。

       在网络分区的情况下，处于小分区的节点可能会触发无效的选举，因为它们不能获得多数派的投票。这将导致多余的领导者选举以及不必要的term增加。

       预检查或预投票机制可以有效地解决这个问题。在这种机制下，在真正进行选举之前，候选人会先向其他节点发送预投票请求。只有在收到多数节点的回应，即确认自己能够和集群中的大多数节点进行通信，候选人才会增加term并启动真正的选举流程。

       这两种机制配合起来，可以有效地确保客户端请求的不丢失和不重复。

FREE SOLO - 自己动手实现Raft - - leveldb源码分析与调试-1

       leveldb 是由 Google 基础架构工程师 Jeff Dean 所设计的，是一种高效、可靠的键值对存储系统。它基于LSM（Log-Structured Merge）存储引擎，代码简洁精炼，非常适合深入学习与理解。leveldb 不仅可以作为一个简单的键值对引擎使用，而且内部组件如LRU Cache也具有独立的实用性，还能在此基础上封装出其他操作接口，例如vraft中的raftlog和metadata等。

       通过理解leveldb，能够对后续学习如rocksdb等更高级的数据库引擎提供坚实基础。本文旨在从状态机的角度解析leveldb，帮助读者深入理解其内部工作原理。

       在leveldb中，关键状态包括但不限于内存、磁盘状态以及LRU Cache状态。内存数据与磁盘数据的交互是leveldb的核心，用户的键值对数据通过日志写入到memtable，然后通过immutable memtable最终到达磁盘上的sorted table文件，这些文件按照级别（level）从0到6逐级存储。通过在关键时刻添加ToJson函数，可以记录这些状态的变化，便于分析。

       LRU Cache在leveldb中的实现同样值得深入研究。它作为一种缓存机制，有助于优化数据访问效率。通过在LRU Cache中添加ToJson函数并打印状态，可以直观地观察其内部结构和状态的动态变化。

       为了更好地理解leveldb，本文将重点分析关键数据结构，并通过观察不同动作导致的状态变化，来深入探究leveldb的内部机制。在后续文章中，将详细展示leveldb内部状态的转换过程，以帮助读者掌握其核心工作原理。