Raft是一种用来管理日志复制的一致性算法。一致性算法允许一组机器像一个整体一样工作，即使其中的一些机器出了错误也能正常工作。
Raft 的目标（或者说是分布式共识算法的目标）是：保证 log 完全相同地复制到多台服务器上。
Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，本文详解其中的 Saga 模式。
上图中，每个RSM都有一个replicated log，存储的是来自客户端的commands。每个RSM中replicate log中commads的顺序都是相同的，状态机按顺序处理replicate log中的command,并将处理的结果返回给客户端。由于状态机具有确定性，因此每个状态机的输出和状态都是相同的。 上图中有一个模块——Consensus Module刚刚没有提及。这个模块用于保证每个server上Log的一致性！
到今天这次总结，如果跟着我一起学一起练的老铁，完全入门docker了。在日常的开发和测试，绝对是没有问题的。不管是我们自己和docker公司，他们的初心都是想用在生产环境下，但是生产环境和测试环境完全是两种环境条件。 之前的学习实践环境 在用学习容器编排之前，所有操作本地进行的，docker cli 连接是一台的docker host，不管是docker run 还是docker container 都是在一台机器上，但是实际的生产环境下，一个应用很复杂他部署在一台机器上满足不了我们的需求，都是通过集群的
分布式事务，一直是实现分布式系统过程中最大的挑战。在只有单个数据源的单服务系统当中，只要这个数据源支持事务，例如大部分关系型数据库，和一些MQ服务，如activeMQ等，我们就可以很容易的实现事务。
《In search of an Understandable Consensus Algorithm (Extended Version)》
Raft 是一种为了管理日志复制的分布式一致性算法。Raft 出现之前，Paxos 一直是分布式一致性算法的标准。Paxos 难以理解，更难以实现。Raft 的设计目标是简化 Paxos，使得算法既容易理解，也容易实现。
「理论基础」：是从Hector&Kenneth在1987年发表的《Sagas》论文中演化而来：
银行业从最初的手工记账到会计电算化，到金融电子化，再到现在的金融科技，可以看到金融与科技的结合越来越紧密，人工智能、大数据、物联网、区块链等新兴技术改变了金融的交易方式，为金融行业的创新前行提供了源源不断的动力。同时互联网金融的兴起是一把双刃剑，带来了机遇的同时也带来了挑战。普惠金融使得金融的门槛降低，更多的普通大众参与到金融活动中，这让金融信息系统承受了越来越大的压力。于是我们可以看到大型商业银行、保险公司、证券公司、交易所等核心交易系统都在纷纷进行分布式改造，其中数据库作为有状态的应用，成为了信息系统中唯一的单点，承担了所有来自上层应用的压力。随着数据库瓶颈的凸显，进行分布式改造迫在眉睫。
前言 “分布式队列编程”是一个系列文，上篇《分布式队列编程模型、实战》，主要剖析了分布式队列编程模型的需求来源、定义、结构以及其变化多样性；根据作者在新美大实际工作经验，给出了队列式编程在分布式环境下的一些具体应用。本文将重点阐述工程师运用分布式队列编程构架的时候，在生产者、分布式队列以及消费者这三个环节的注意点以及优化建议。 确定采用分布式队列编程模型之后，主体架构就算完成了，但工程师的工作还远远未结束。天下事必做于细，细节是一个不错的架构向一个优秀的系统进阶的关键因素。优化篇选取了作者以及其同事在运用分
Raft 是一种为了管理复制日志的一致性算法。它提供了和 Paxos 算法相同的功能和性能，但是它的算法结构和 Paxos 不同，使得 Raft 算法更加容易理解并且更容易构建实际的系统。为了提升可理解性，Raft 将一致性算法分解成了几个关键模块，例如领导人选举、日志复制和安全性。同时它通过实施一个更强的一致性来减少需要考虑的状态的数量。一项用户研究的结果表明，对于学生而言，Raft 算法比 Paxos 算法更加容易学习。Raft 算法还包括一个新的机制来允许集群成员的动态改变，它利用重叠的大多数来保证安全性。
准备提交：已经投票yes，但是没有收到事务提交 处于不确定状态(2) 已经提交：事务提交完成。(4)
👆点击“博文视点Broadview”，获取更多书讯 《云数据库架构》一书全面介绍了主流数据库的技术特点，结合业务场景讲解了数据库技术选型和数据库架构的最佳实践。下面我们摘取本书第1章中对阿里云RDS MySQL三节点企业版的重点内容，让读者先睹为快。 数据库的高可用是个悠久的话题，目前以最常见的主备模式为例, 它主要有异步和半同步两种方式，但这两种方式都有各自的缺陷。 异步在主库宕机后，最后更新的记录有可能没有推送到从库，从而引发数据丢失。 半同步虽然会保证最少有一个从库接收到binlog，但同样有丢
好久没有更新博客了，最近研究了Raft 协议，谈谈自己对 Raft 协议的理解。希望这篇文章能够帮助大家理解 Raft 论文。
基于 MIT 6824 课程 lab 框架，实现一个基于 raft 共识算法、高性能、可容错的分布式 KV 存储系统，保证系统的一致性和可靠性。
这是[码哥]Kafka 系列文章的第二篇，码哥将从原理、实践和源码角度为大家深入剖析并实践 Kafka。此系列包括[原理篇]、[实践篇]和[源码篇]。这篇是[原理篇]的第二篇，主要讲解 Kafka 的架构和实现原理。
Propser,接受Client请求,向集群提出提议(propose),并在发送冲突的时候，起到冲突调节的作用，向议员,替民众提出议案
在开发中总会遇到这样的场景，比如工单状态，流程状态，通过状态判断该执行的操作，不断改动的需求导致永无止境的 IF、ELSE 和 BREAK 子句的层次结构，当事情开始看起来太复杂时，简直就像面满池子的海洋球。
这个和日志复制的机制有关系。首先对于选举，PK的条件不是拼这两个索引值的大小，PK的是最后一条日志的任期号和日志的长度。Leader当选后进行第一次日志复制时，会和Follower进行若干次日志的匹配过程，最终可以得到Leader和各自Follower的日志匹配的matchIndex值。处于majority节点列表的matchIndex的最小值就是当前Leader的commitIndex。所以commitIndex值是完全可以动态计算出来的。 如果所有的日志都保留不截断的话，服务器重启时applyIndex应该等于零。然后重放一下所有的已经提交的日子就可以得到当前的状态机。如果日志截断有快照的话，applyIndex应该正好是日志序列的头部位置，这个位置一般是存储在快照元信息里面的，它是持久化在磁盘中的。
学习ZAB，非常有必要聊聊它诞生的背景。因为在paxos的光芒下，还有必要折腾这样类似的算法吗？这个问题是我们初步了解ZAB关键。
Raft设计出来是为了实现工程上的可用，避免Paxos算法的复杂性，从In Search of an Understandable Consensus Algorithm (Extended Version)这篇论文也可以看出，Raft部分原因也是为教学设计。论文很长，并且也已经有中译版，权且把这篇文章当作一篇导读。
MIT 今年终于主动在 Youtube 上放出了随堂视频资料，之前跟过一半这门课，今年打算刷一下视频，写写随堂笔记。该课程以分布式基础理论：容错、备份、一致性为脉络，以精选的工业级系统论文为主线，再填充上翔实的阅读材料和精到的课程实验，贯通学术理论和工业实践，实在是一门不可多得的分布式系统佳课。课程视频: Youtube，B 站。课程资料：6.824 主页。本篇是第六节课笔记，是 Raft 论文讲解的第一部分，主要总结了容错的几种类型以及 Raft 中的 Leader 选举相关内容。
MIT 今年终于主动在 Youtube 上放出了随堂视频资料，之前跟过一半这门课，今年打算刷一下视频，写写随堂笔记。该课程以分布式基础理论：容错、备份、一致性为脉络，以精选的工业级系统论文为主线，再填充上翔实的阅读材料和精到的课程实验，贯通学术理论和工业实践，实在是一门不可多得的分布式系统佳课。课程视频和资料看这里，本篇是第四节课笔记，VMWare 的 P/B 系统。
所以能看到主从同步的内容就是二进制日志（Binlog），它虽然叫二进制日志，实际上存储的是一个又一个事件（Event），这些事件分别对应着数据库的更新操作，比如 INSERT、UPDATE、DELETE 等。另外我们还需要注意的是，不是所有版本的 MySQL 都默认开启服务器的二进制日志，在进行主从同步的时候，我们需要先检查服务器是否已经开启了二进制日志。
面对一个庞然大物，如果没有一个合理的分工分层。任何一个小小失误都会被无限放大，酿成巨大灾难。
本文转自：https://www.cnblogs.com/bangerlee/p/5655754.html
最近阅读了一本架构方面的入门图书叫《从零开始学架构：照着做，你也能成为架构师》，部分内容比较不错，先做书摘总结，以便加深印象与未来回顾学习。
状态机在我们的工作中应用非常广泛，今天聊一聊分布式事务中间件 Seata 中 Saga 模式的状态机。
> 转载自 https://github.com/maemual/raft-zh_cn/blob/master/raft-zh_cn.md
在平常的后端项目开发中，状态机模式的使用其实没有大家想象中那么常见，笔者之前由于不在电商领域工作，很少在业务代码中用状态机来管理各种状态，一般都是手动get/set状态值。去年笔者进入了电商领域从事后端开发。电商领域，状态又多又复杂，如果仍然在业务代码中东一块西一块维护状态值，很容易陷入出了问题难于Debug，难于追责的窘境。
raft算法是一种保证数据高可用的一致性算法，它和 Paxos 算法 相比，提供了相似的功能和性能，但是提供了更好的阅读成本，因此在推出之后便受到了业界较大的欢迎。其最为显著的特点就是强化了Leader的作用，来减少了处理一致性问题时的多状态的复杂性。比较著名的etcd，TiKV都使用它进行数据一致性的保证。本文尝试从故障发生的视角来解析一下这个算法。
在云计算和容器化技术发展火热的当下，对于微服务架构，服务注册与发现组件是必不可少的。在传统的服务架构中，服务的规模处于运维人员的可控范围内。当部署服务的多个节点时，一般使用静态配置的方式实现服务信息的设定。在微服务应用中，服务实例的数量和网络地址都是动态变化的，这对系统运维提出了巨大的挑战。因此，动态的服务注册与发现就显得尤为重要。
电商是促销拉动式的场景，也是价格战驱动的场景。618和双11都是典型的促销活动。其实都是在抢用户、扩市场占有率。在这样的场景之下，对秒杀、抢购是很热衷的玩法。
本篇文章将模拟一个KV数据读写服务，从提供单一节点读写服务，到结合分布式一致性协议（Raft）后，逐步扩展为一个分布式的，满足一致性读写需求的读写服务的过程。
CAP定理指出，在异步网络模型中，不存在一个系统可以同时满足上述3个属性。换句话说，分布式系统必须舍弃其中的一个属性。对于需要在分布式条件下运行的系统来说，如何在一致性、可用性和分区容错性中取舍，或者说要弱化哪一个属性，是首先要考虑的问题。
大家对Paxos的看法基本是“晦涩难懂”，虽然论文和网上文章也很多，但总觉得“云山雾罩”，也不知道其具体原理以及到底能解决什么问题。
上周，前1号店技术总监、海尔农业电商CTO，《技术管理之巅》作者黄哲铿为大家带来了一场关于微服务架构的分享，包含了微服务架构在千万级别日调用量、亿级别海量数据场景下的应用实践；从领域驱动设计、服务依赖治理、服务高可用、故障熔断降级快速恢复等方面，结合大型移动电商系统等应用案例，全面剖析微服务的应用等丰富的内容。
导语 | 对于很多工程人员来说，Paxos算法不容易理解和落地实现。因此斯坦福学者提出了一个更易理解和实现的共识算法Raft。本文主要介绍Raft的基本原理、算法流程以及和Paxos的区别。 一、Raft算法背景 在学术理论界，分布式一致性算法的代表还是Paxos。但是少数理解的人觉得很简单，尚未理解的觉得很难，大多数人还是一知半解。Paxos的可理解性和工程落地性的门槛很高。斯坦福学者也花了很多时间理解Paxos，于是他们又研究出Raft。 二、Raft算法基本原理 共识算法就是保证一个集群的多
大四期间9月到11月写的毕业系统，仿照百度文库设计的，融合了session共享，nginx负载均衡，lucene全文检索，敏感词过滤算法，office文件转pdf并提供免下载在线预览功能，登录邮件通知等功能。页面都是趴的51CTO网站套用的。
raft 协议是一致性协议中相对容易理解的一个实现，类似的还有zab，paxos等一致性算法。etcd是基于raft协议的，k8s依赖于etcd，下面介绍下raft协议的一些要点
Tech 导读 在分布式系统中， 什么是拜占庭将军问题？产生的场景和解决方案是什么？什么是 Raft 共识算法？Raft 算法是如何解决拜占庭将军问题的？其核心原理和算法逻辑是什么？除了 Raft，还有哪些共识算法？共识问题作为分布式系统的一大难点和痛点，本文主要介绍了其产生的背景、原因，以及通用的 Raft 算法解决方案。
Raft是一个用于管理日志一致性的协议。它将分布式一致性分解为多个子问题：Leader选举（Leader election）、日志复制（Log replication）、安全性（Safety）、日志压缩（Log compaction）等。同时，Raft算法使用了更强的假设来减少了需要考虑的状态，使之变的易于理解和实现。Raft将系统中的角色分为领导者（Leader）、跟从者（Follower）和候选者（Candidate）：
Paxos算法解决的是一个分布式系统如何就某个值（决议）达成一致。一个典型的场景是，在一个分布式数据库系统中，如果各个节点的初始状态一致，每个节点执行相同的操作序列，那么他们最后能够得到一个一致的状态。为了保证每个节点执行相同的操作序列，需要在每一条指令上执行一个“一致性算法”以保证每个节点看到的指令一致。在Paxos算法中，有三种角色：Proposer (提议者),Acceptor（接受者），Learners（记录员）
先来解释什么是“状态”（ State ）。现实事物是有不同状态的，例如一个自动门，就有 open 和 closed 两种状态。我们通常所说的状态机是有限状态机，也就是被描述的事物的状态的数量是有限个，例如自动门的状态就是两个 open 和 closed 。
Atomicity 原子性 构成事务的一组SQL，要么全部生效，要么全不生效，不会出现部分生效的情况
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
