raft

由于目前的项目把mysql换成了TiDb，所以特意来了解下tidb。其实也不能说换，由于tidb和mysql几乎完全兼容，所以我们的程序没有任何改动就完成了数据库从mysql到TiDb的转换，TiDB 是一个分布式 NewSQL ( SQL 、 NoSQL 和 NewSQL 的优缺点比较 )数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。下面是对有关资料的整理还有一些扩展内容以链接的方式展示，有兴趣可以点击了解一下。 一、TiDb简介 TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。TiDB 具备如下核心特点： 1. 高度兼容 MySQL 大多数情况下

一 TiDb简介 　TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。TiDB 具备如下核心特点： 1 高度兼容 MySQL 　大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。 2水平弹性扩展 　通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。 3分布式事务 　TiDB 100% 支持标准的 ACID 事务。 4 真正金融级高可用 　相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。 5

lab 2 raft 本节作为实现ft KV store的基础部分，实现raft状态机复制协议，lab3基于lab2的raft模块，构建KV service，lab4基于上述构建shared KV service 一般来说，容错通过复制集实现状态的复制，保证在少数节点故障的场景下服务依旧可用，挑战是数据的一致性 Raft控制一个服务的状态复制，保证故障后的一致性，保证所有operator log按照相同的顺序在所有复制集节点上执行，保证所有节点对log的内容达成一致性共识。当故障节点重新上线时，raft采用一定的策略保证它慢慢到达最新的一致性状态，Raft依赖主节点同步log，当没有主节点时，raft不会同步log，而是开始新一轮的选举 本节实现Raft为模块独立，每个Raft实例之间通过rpc调用来维持复制状态机，log entries with index numbers，每条entry写来index，最终达成一致的情况下commit，此时raft模块会将结果返回上层服务来执行（仅允许rpc调用，不允许共享变量，不允许依赖共享存储文件等等） 主要参考raft paper来做实现，同时参考reference 更深入理解一致性，可以参考paxos、chubby、Paxos Made Live、Spanner、Zookeeper、Harp… 本节会实现raft论文中大部分操作

由于目前的项目把mysql换成了TiDb，所以特意来了解下tidb。其实也不能说换，由于tidb和mysql几乎完全兼容，所以我们的程序没有任何改动就完成了数据库从mysql到TiDb的转换，TiDB 是一个分布式 NewSQL (SQL 、 NoSQL 和 NewSQL 的优缺点比较 )数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。下面是对有关资料的整理还有一些扩展内容以链接的方式展示，有兴趣可以点击了解一下。 一 TiDb简介 TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。TiDB 具备如下核心特点： 1 高度兼容 MySQL 大多数情况下

由于目前的项目把mysql换成了TiDb，所以特意来了解下tidb。其实也不能说换，由于tidb和mysql几乎完全兼容，所以我们的程序没有任何改动就完成了数据库从mysql到TiDb的转换，TiDB 是一个分布式 NewSQL (SQL 、 NoSQL 和 NewSQL 的优缺点比较 )数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。下面是对有关资料的整理还有一些扩展内容以链接的方式展示，有兴趣可以点击了解一下。 一 TiDb简介 　TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。TiDB 具备如下核心特点： 1 高度兼容 MySQL 　大多数情况下

在已经遍览网上Raft的相关博客之后，大致了解了Raft的性质和算法过程，但许多细节还是没有掌握，而且各个博客各执一词，不知谁对谁错，因此看一遍原论文： Raft论文 ，只看关键算法部分，略过其他部分。 只看以下几个章节： 2 Replicated state machines 5.1 Raft basics 5.2 Leader election 5.3 Log replication 5.4.1 Election restriction 建议先看我总结的Raft简介 分布式理论Paxos, Raft 的Raft部分，大致了解Raft的原理和过程，然后再看下面的细节。 raft论文的阅读笔记写在： Raft论文阅读笔记 来源： CSDN 作者： 千里驰援李天霞 链接： https://blog.csdn.net/weixin_41519463/article/details/103989438

基于Raft 的分布式一致性协议是构建很多分布式服务的基础，某种程度上它充当了心脏的角色，为此有必要对Raft 的一些难点进行深入理解。 正确理解commited 一个常见的误解就是复制到多数副本的就可以视作commited, 其实还不够。缺少必须已经执行了对应的操作这个步骤。个人理解在实际 Raft使用过程中，就是存在某个Raft log 在append到多个副本的瞬间宕机了，由于还没有执行on_apply() ，其实还没有向上层用户ACK 这条日志已经成功。 因此这条日志可以truncate, 也可以后续随着后续的log commited 之后自己也被commited。 正确理解选主的几个比较条件 为什么需要把距离上次主更新的时间和election_timeout 比较 这个比较大规则如下： 某个follower 收到 vote 请求之后，会计算出收到请求的时间和上次收到主心跳的时间间隔，然后把这个间隔和一个约定的较小时间进行比较。如果前者还小(此时说明还有其他节点长时间没有收到主的心跳，发起了vote），拒绝这次vote 请求，否则投赞成票。 考虑三个互联互通的IDC A、B、C，B是主副本，如果由于某种原因B、C网络不通了，如果没有上面限制，B发起带有最高term信息的vote请求，A会同样vote请求，这样主就从B变成了C。同理，过了以后，主又很可能从C再变成B。如此

前言 本文旨在讲述如何使用 Java 语言实现基于 Raft 算法的，分布式的，KV 结构的存储项目。该项目的背景是为了深入理解 Raft 算法，从而深刻理解分布式环境下数据强一致性该如何实现；该项目的目标是：在复杂的分布式环境中，多个存储节点能够保证数据强一致性。 项目地址：https://github.com/stateIs0/lu-raft-kv 欢迎 star ：） 什么是 Java 版 Raft 分布式 KV 存储 Raft 算法大部分人都已经了解，也有很多实现，从 GitHub 上来看，似乎 Golang 语言实现的较多，比较有名的，例如 etcd。而 Java 版本的，在生产环境大规模使用的实现则较少； 同时，他们的设计目标大部分都是命名服务，即服务注册发现，也就是说，他们通常都是基于 AP 实现，就像 DNS，DNS 是一个命名服务，同时也不是一个强一致性的服务。 比较不同的是 Zookeeper，ZK 常被大家用来做命名服务，但他更多的是一个分布式服务协调者。 而上面的这些都不是存储服务，虽然也都可以做一些存储工作。甚至像 kafka，可以利用 ZK 实现分布式存储。 回到我们这边。 此次我们语言部分使用 Java，RPC 网络通信框架使用的是蚂蚁金服 SOFA-Bolt，底层 KV 存储使用的是 RocksDB，其中核心的 Raft 则由我们自己实现

Raft算法之日志压缩 最后的一部分是关于服务器日志压缩的，因为随着运行时间的增增长，日志信息也会变得越来越多，占有更多的空间。因此Raft采取了日志压缩的方法解决该问题，即将当前整个系统状态写入稳定存储的快照，然后该时间点之前的日志就可以丢弃掉，从而释放存储空间。 1 快照结构 从图中可见，快照包括以下几个部分内容: lastIncludedIndex: 表明快照中最后一条日志的索引值。也就是说日志一直压缩到该索引值的位置。该值以前连续若干个索引值的日志被压缩为快照，而该值以后的日志则不在快照中。 lastIncludedTerm:表明快照中最后一条日志所在的任期值。 state machine state:复制状态机的当前状态。 集群中每一个服务器都可以独立地进行拍摄快照(只对已提交的日志进行快照的拍摄)，其中 lastIncludedIndex 与 lastIncludedTerm 值的存在时为了通过之前讲到的在日志复制中需要做的一致性检查。当服务器完成了该快照的写入之后，就可以将从快照中最后一条日志一直到先前所有的日志删除。 2 快照的发送 正常情况下， Leader 的日志将会与 Follower 保持一致，但并不是所有情况都处于正常情况下，有时候可能因为 Follower 的反应缓慢或崩溃造成与 Leader 的日志不一致。所以有时候需要 Leader 将快照信息发送给

上一篇文章: Raft算法之Leader选举   之前说完了Raft算法中的Leader选举过程，本文将在上一篇文章的基础上说明日志复制。 Raft算法之日志复制   先看以下日志所包含的基本内容: 可以被复制状态机执行的命令 任期号 :创建该日志时Leader所处的当前任期号 索引号 :整数，用于标识日志所在的位置 日志的状态分为两种:未被提交，已被提交(日志为安全的，不会被删除或覆盖)。 1 正常情况 当 Leader 接收到由客户端发送的请求(请求中包含可以被复制状态机执行的命令)时，Leader将会把该请求作为新的内容添加到日志中(任期号为当前 Leader 所处的任期号，索引号为当前 Leader 本地存储的日志集合中的日志的最高索引号加1)。 Leader 在当前任期内最多只能创建一个给定索引号的日志(即不可能在一个任期内创建两个以上的具有相同索引的日志条目) 然后将该日志通过 AppendEntries RPC 消息发送到网络中其他的服务器(以下简称 Follower )，从而复制该日志。 在网络中 Follower 接收到该日志消息后则会返回复制成功的回复。 在 Leader 接收到网络中大部分的 Follower 的成功复制的回复之后， Leader 便认为该日志 可以被提交 。此时 Leader 将会同时做三件事： 将该日志应用到 Leader 本地的复制状态机