技术

对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go细节 codereview mat使用 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 MVCC 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes自动扩容缩容 神经网络模型优化 直觉上理解机器学习 knative入门 如何学习机器学习 神经网络系列笔记 TIDB源码分析 《阿里巴巴云原生实践15讲》笔记 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 扩展Kubernetes 副本一致性 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全机制 jvm crash分析 Kubernetes监控 Kubernetes 控制器模型 Prometheus 学习 容器日志采集 容器狂占cpu怎么办? Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes objects之编排对象 源码分析体会 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 kubernetes实践 jib源码分析之细节 线程排队 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI——容器网络是如何打通的 为什么很多业务程序猿觉得数据结构和算法没用? 串一串一致性协议 当我在说PaaS时,我在说什么 《数据结构与算法之美》——数据结构笔记 PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 《深入剖析kubernetes》笔记 精简代码的利器——lombok 学习 编程语言的动态性 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 分布式计算系统的那些套路 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 mysql 批量操作优化 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 calico学习 AQS2——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 硬件对软件设计的影响 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记2 《mysql技术内幕》笔记1 log4j学习 为什么netty比较难懂? 回溯法 apollo client源码分析及看待面向对象设计 学习并发 docker 环境(主要运行java项目)常见问题 Scala的一些梗 OpenTSDB 入门 spring事务小结 事务一致性 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型 java exception Linux IO学习 network channel network byte buffer 测试环境docker化实践 netty(七)netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Macvlan Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker中涉及到的一些linux知识 hystrix学习 Linux网络源代码学习——整体介绍 zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty(六)netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 Redis概述 机器学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 异构数据库表在线同步 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring(八) 支持AOP 自己动手写spring(七) 类结构设计调整 分析log日志 自己动手写spring(六) 支持FactoryBean 自己动手写spring(九) 总结 自己动手写spring(五) bean的生命周期管理 自己动手写spring(四) 整合xml与注解方式 自己动手写spring(三) 支持注解方式 自己动手写spring(二) 创建一个bean工厂 自己动手写spring(一) 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM内存与执行 git spring rmi和thrift maven/ant/gradle使用 再看tcp 缓存系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 VPN(Virtual Private Network) Kubernetes存储 Kubernetes 其它特性 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 使用etcd + confd + nginx做动态负载均衡 如何通过fleet unit files 来构建灵活的服务 CoreOS 安装 CoreOS 使用 Go学习 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

标签


副本一致性

2019年05月12日

简介

条分缕析分布式:到底什么是一致性?在证明CAP定理的原始论文Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web,C指的是linearizable consistency,也就是「线性一致性」。更精简的英文表达则是linearizability。而很多人在谈到CAP时,则会把这个C看成是强一致性(strong consistency)。这其实也没错,因为线性一致性的另一个名字,就是强一致性。只不过,相比「线性一致性」来说,「强一致性」并不是一个好名字。因为,从这个名字你看不出来它真实的含义(到底「强」在哪?)

那线性一致性是什么意思呢?它精确的形式化定义非常抽象,且难以理解。具体到一个分布式存储系统来说,线性一致性的含义可以用一个具体的描述来取代:对于任何一个数据对象来说,系统表现得就像它只有一个副本一样。显然,如果系统对于每个数据对象真的只存一个副本,那么肯定是满足线性一致性的。但是单一副本不具有容错性,所以分布式存储系统一般都会对数据进行复制(replication),也就是保存多个副本。这时,在一个分布式多副本的存储系统中,要提供线性一致性的保证,就需要付出额外的成本了。

basic-paxos

每个Node 同时充当了两个角色:Proposer和Acceptor,在实现过程中, 两个角色在同一个进程里面。专门提一个Proposer概念(只是一个角色概念)的好处是:对业务代码没有侵入性,也就是说,我们不需要在业务代码中实现算法逻辑,就可以像使用数据库一样访问后端的数据。

  proposer acceptor  
prepare阶段 proposer 生成全局唯一且自增的proposal id,广播propose
只广播proposal id即可,无需value
Acceptor 收到 propose 后,做出“两个承诺,一个应答”
1. 不再应答 proposal id 小于等于当前请求的propose
2. 不再应答 proposal id 小于 当前请求的 accept
3. 若是符合应答条件,返回已经accept 过的提案中proposal id最大的那个 propose 的value 和 proposal id, 没有则返回空值
proposer 通过prepare请求来发现之前被大多数节点通过的提案
accept阶段 提案生成规则
1. 从acceptor 应答中选择proposalid 最大的value 作为本次的提案
2. 如果所有的应答的天value为空,则可以自己决定value
在不违背“两个承诺”的情况下,持久化当前的proposal id和value  

Proposer 之间并不直接交互,Acceptor除了一个“存储”的作用外,还有一个信息转发的作用。从Acceptor的视角看,basic-paxos 及 multi-paxos 选举过程是协商一个值,每个Proposer提出的value 都可能不一样。所以第一阶段,先经由Acceptor将已提交的ProposerId 最大的value 尽可能扩散到Proposer(即决定哪个Proposer 是“意见领袖”)。第二阶段,再将“多数意见”形成“决议”(Acceptor持久化value)

目前比较好的通俗解释,以贿选来描述 如何浅显易懂地解说 Paxos 的算法? - GRAYLAMB的回答 - 知乎

multi-paxos

《分布式协议与算法实战》Multi-Paxos 是一种思想,不是算法,缺失实现算法的必须编程细节。而 Multi-Paxos 算法是一个统称,它是指基于 Multi-Paxos 思想,通过多个 Basic Paxos 实例实现一系列值的共识的算法(比如 Chubby 的 Multi-Paxos 实现、Raft 算法等)。

当存在一批提案时,用Basic-Paxos一个一个决议当然也可以,但是每个提案都经历两阶段提交,显然效率不高。Basic-Paxos协议的执行流程针对每个提案(每条redo log)都至少存在三次网络交互:1. 产生log ID;2. prepare阶段;3. accept阶段。所以,Mulit-Paxos基于Basic-Paxos做了优化,引入领导者节点作为唯一提议者,以 Chubby 的 Multi-Paxos 实现为例

  1. 主节点作为唯一提议者,这样就不存在多个提议者同时提交提案的情况,也就不存在提案冲突的情况
  2. 在 Chubby 中,主节点是通过执行 Basic Paxos 算法,进行投票选举产生的,并且在运行过程中,主节点会通过不断续租的方式来延长租期(Lease)。
  3. 在 Chubby 中实现了兰伯特提到的,“当领导者处于稳定状态时,省掉准备阶段,直接进入接受阶段”这个优化机制,减少非必须的协商步骤来提升性能。
  4. 在 Chubby 中,为了实现了强一致性,所有的读请求和写请求都由主节点来处理。也就是说,只要数据写入成功,之后所有的客户端读到的数据都是一致的。

Raft

强烈推荐细读 《In Search of an Understandable Consensus Algorithm》 论文,说清楚好多事情。

通过选出leader,Raft 将一致性问题分解成为三个相对独立的子问题

  1. leader选取, 在一个leader宕机之后必须要选取一个新的leader
  2. 日志复制,leader必须从client接收日志然后复制到集群中的其他服务器,并且强制要求其他服务器的日志保持和自己相同
  3. 安全性(Safety),一系列的规则约束

针对 正场情况 和 leader 崩溃后的恢复场景 定义了一系列规则,最终达到一致性的要求。

  正常情况 leader崩溃后的恢复
Leader 选举 参见论文 参见论文
日志复制 参见论文 参见论文
安全性   选举限制
提交之前任期的日志条目

Raft 和 Paxos

Raft 算法属于 Multi-Paxos 算法,它是在兰伯特 Multi-Paxos 思想的基础上,做了一些简化和限制,比如增加了日志必须是连续的,只支持领导者、跟随者和候选人三种状态,在理解和算法实现上都相对容易许多。Raft 算法是现在分布式系统开发首选的共识算法。绝大多数选用 Paxos 算法的系统(比如 Cubby、Spanner)都是在 Raft 算法发布前开发的,当时没得选;而全新的系统大多选择了 Raft 算法(比如 Etcd、Consul、CockroachDB)。

《In Search of an Understandable Consensus Algorithm》: In order to enhance understandability, Raft separates the key elements of consensus, such as leader election, log replication, and safety, and it enforces a stronger degree of coherency to reduce the number of states that must be considered.

《In Search of an Understandable Consensus Algorithm》单决策(Single-decree)Paxos 是晦涩且微妙的:它被划分为两个没有简单直观解释的阶段,并且难以独立理解。正因为如此,它不能很直观的让我们知道为什么单一决策协议能够工作。为多决策 Paxos 设计的规则又添加了额外的复杂性和精巧性。我们相信多决策问题能够分解为其它更直观的方式。PS: 现实问题是多决策的,paxos 单决策出现在 多决策之前,彼时是以单决策的视角来考虑问题(在单决策场景下,选主不是很重要),又简单的以为将单决策 组合起来就可以支持 多决策。

Raft 和 Paxos 最大的不同之处就在于 Raft 的强领导特性:Raft 使用leader选举作为一致性协议里必不可少的部分,并且将尽可能多的功能集中到了leader身上。这样就可以使得算法更加容易理解。例如,在 Paxos 中,leader选举和基本的一致性协议是正交的:leader选举仅仅是性能优化的手段,而且不是一致性所必须要求的。但是,这样就增加了多余的机制:Paxos 同时包含了针对基本一致性要求的两阶段提交协议和针对leader选举的独立的机制。相比较而言,Raft 就直接将leader选举纳入到一致性算法中,并作为两阶段一致性的第一步。这样就减少了很多机制。

Leader 选举

Raft协议比paxos的优点是 容易理解,容易实现。它强化了leader的地位,把整个协议可以清楚的分割成两个部分,并利用日志的连续性做了一些简化:

  1. Leader在时。leader来处理所有来自客户端的请求,由Leader向Follower同步日志 ==> 日志流动是单向的
  2. Leader挂掉了,选一个新Leader
    1. 在初始状态下,集群中所有的节点都是follower的状态。
    2. Raft 算法实现了随机超时时间的特性。也就是说,每个节点等待Leader节点心跳信息的超时时间间隔是随机的。等待超时时间最小的节点(以下称节点 A),它会最先因为没有等到Leader的心跳信息,发生超时。
    3. 这个时候,节点 A 就增加自己的任期编号,并推举自己为候选人,先给自己投上一张选票,然后向其他节点发送请求投票 RPC 消息,请它们选举自己为领导者。
    4. 如果其他节点接收到候选人 A 的请求投票 RPC 消息,在编号为 1 的这届任期内,也还没有进行过投票,那么它将把选票投给节点 A,并增加自己的任期编号。
    5. 如果候选人在选举超时时间内赢得了大多数的选票,那么它就会成为本届任期内新的领导者。节点 A 当选领导者后,他将周期性地发送心跳消息,通知其他服务器我是领导者,阻止跟随者发起新的选举,篡权。

在 Raft 算法中,约定了很多规则,主要有这样几点

  1. 领导者周期性地向所有跟随者发送心跳消息,通知大家我是领导者,阻止跟随者发起新的选举。
  2. 如果在指定时间内,跟随者没有接收到来自领导者的消息,那么它就认为当前没有领导者,推举自己为候选人,发起领导者选举。
  3. 在一次选举中,赢得大多数选票的候选人,将晋升为领导者。
  4. 在一个任期内,领导者一直都会是领导者,直到它自身出现问题(比如宕机),或者因为网络延迟,其他节点发起一轮新的选举。
  5. 在一次选举中,每一个服务器节点最多会对一个任期编号投出一张选票,并且按照“先来先服务”的原则进行投票。
  6. 日志完整性高的跟随者(也就是最后一条日志项对应的任期编号值更大,索引号更大),拒绝投票给日志完整性低的候选人。
  7. 如果一个候选人或者领导者,发现自己的任期编号比其他节点小,那么它会立即恢复成跟随者状态。
  8. 如果一个节点接收到一个包含较小的任期编号值的请求,那么它会直接拒绝这个请求。

在议会选举中,常出现未达到指定票数,选举无效,需要重新选举的情况。在 Raft 算法的选举中,也存在类似的问题,那它是如何处理选举无效的问题呢?其实,Raft 算法巧妙地使用随机选举超时时间的方法,把超时时间都分散开来,在大多数情况下只有一个服务器节点先发起选举,而不是同时发起选举,这样就能减少因选票瓜分导致选举失败的情况。如何避免候选人同时发起选举?

  1. 跟随者等待领导者心跳信息超时的时间间隔,是随机的;
  2. 如果候选人在一个随机时间间隔内,没有赢得过半票数,那么选举无效了,然后候选人发起新一轮的选举,也就是说,等待选举超时的时间间隔,是随机的。

日志复制

一旦选出了leader,它就开始接收客户端的请求。每一个客户端请求都包含一条需要被复制状态机(replicated state machine)执行的命令。leader把这条命令作为新的日志条目加入到它的日志中去,然后并行的向其他服务器发起 AppendEntries RPC ,要求其它服务器复制这个条目。当这个条目被安全的复制之后,leader会将这个条目应用到它的状态机中并且会向客户端返回执行结果。如果追随者崩溃了或者运行缓慢或者是网络丢包了,leader会无限的重试 AppendEntries RPC(甚至在它向客户端响应之后)直到所有的追随者最终存储了所有的日志条目。

一旦被leader创建的条目已经复制到了大多数的服务器上,这个条目就称为可被提交的(commited)

副本数据是以日志的形式存在的,日志是由日志项组成,日志项是一种数据格式,它主要包含用户指定的数据,也就是指令(Command),还包含一些附加信息,比如索引值(Log index)、任期编号(Term)。

  1. 指令:一条由客户端请求指定的、状态机需要执行的指令。你可以将指令理解成客户端指定的数据。
  2. 索引值:日志项对应的整数索引值。它其实就是用来标识日志项的,是一个连续的、单调递增的整数号码。
  3. 任期编号:创建这条日志项的领导者的任期编号。

  1. 接收到客户端请求后,领导者基于客户端请求中的指令,创建一个新日志项,并附加到本地日志中。
  2. 领导者通过日志复制 RPC,将新的日志项复制到其他的服务器。
  3. 当领导者将日志项,成功复制到大多数的服务器上的时候,领导者会将这条日志项应用到它的状态机中。
  4. 领导者将执行的结果返回给客户端。
  5. 当跟随者接收到心跳信息,或者新的日志复制 RPC 消息后,如果跟随者发现领导者已经提交了某条日志项,而它还没应用,那么跟随者就将这条日志项应用到本地的状态机中。

在实际环境中,复制日志的时候,你可能会遇到进程崩溃、服务器宕机等问题,这些问题会导致日志不一致。那么在这种情况下,Raft 算法是如何处理不一致日志,实现日志的一致的呢?

  1. 领导者通过日志复制 RPC 的一致性检查,找到跟随者节点上,与自己相同日志项的最大索引值。也就是说,这个索引值之前的日志,领导者和跟随者是一致的,之后的日志是不一致的了。
  2. 领导者强制跟随者更新覆盖的不一致日志项,实现日志的一致。

跟随者中的不一致日志项会被领导者的日志覆盖,而且领导者从来不会覆盖或者删除自己的日志。

补充

复制模型

假设KV集群有三台机器,机器之间相互通信,把自己的值传播给其他机器,三个客户端并发的向集群发送三个请求,值X 应该是多少?是多少没关系,135都行,向一个client返回成功、其它client返回失败(或实际值)也可,关键是Node1、Node2、Node3 一致。

  Replicated State Machine Primary-Backup System
中文 复制状态机  
应用的协议 Paxos、Raft Zab
mysql binlog的数据格式 statement
存储的是原始的sql语句
raw
数据表的变化数据
redis持久化的两种方式 AOF
持久化的是客户端的set/incr/decr命令
RDB
持久化的是内存的快照
数据同步次数 客户端的写请求都要在节点之间同步 有时可以合并

如何理解ProposerId——逻辑锁

如何浅显易懂地解说 Paxos 的算法?Basic Paxos 的两个阶段可以看成多机下的一次读 version number + value(读阶段,原文中的准备阶段),然后拿读到的 version number 和 value 做一次 CAS (略有不同,但思想类似)(写阶段,原文中的接受阶段),非常直观。

类比一下,以mvcc 方式并发修改一行记录为例,假设一个student表, 带有version字段,当前version = 0, money = 100。线程1 和 线程2 都给zhangsan打钱(150,180), 则打钱过程分两步

  1. 读取到money = 100,此时version = 0 select money,version from student where name = zhangsan
  2. 打钱 update money = 150,version=1 set student where name = zhangsan and version = 0

    1. 如果在此期间 线程2没有修改过, 则vesion 为0,执行成功
    2. 若修改过,则因为实际version = 1 无法匹配数据记录,修改失败。

假设存在一个全局唯一自增id服务,线程2_id > 线程1_id,也可以换个方式

步骤 线程1 线程2
改version占坑 update version = 线程1_id where name = zhangsan and version < 线程1_id  
改version占坑   update version = 线程2_id where name = zhangsan and version < 线程2_id
结果   version = 线程2_id
打钱 update money = 150 set student where name = zhangsan and version = 线程1_id  
打钱   update money = 180 set student where name = zhangsan and version = 线程2_id
结果 失败 成功

paxos 与线程安全问题不同的地方是,paxos的node之间 是为了形成一致,而线程安全则是要么成功要么失败,所以有一点差异。

生活中面临的任何选择,最后都可以转换为一个问题:你想要什么(以及为此愿意牺牲什么)。任何不一致问题, 本质上都可以转换为一个一致问题。 一个队伍谁当老大 可以各不服气,但大家可以对“多票当选”取得一致,这就是所谓“民主”。你可以不尊重老大,但必须尊重价值观。而在basic-poxos 中,底层的“价值观”就是:谁的ProposerId 大谁的优先级更高。有了“优先级”/“价值观” 就可以让“无序”的世界变“有序”。

读写性能优化

Quorum NWR 中的三个要素NWR

  1. N 表示副本数,又叫做复制因子(Replication Factor)
  2. W又称写一致性级别(Write Consistency Level),表示成功完成 W 个副本更新,才完成写操作
  3. R,又称读一致性级别(Read Consistency Level),表示读取一个数据对象时需要读 R 个副本。你可以这么理解,读取指定数据时,要读 R 副本,然后返回 R 个副本中最新的那份数据

N、W、R 值的不同组合,会产生不同的一致性效果,具体来说,有这么两种效果:

  1. 当 W + R > N 的时候,对于客户端来讲,整个系统能保证强一致性,一定能返回更新后的那份数据。
  2. 当 W + R <= N 的时候,对于客户端来讲,整个系统只能保证最终一致性,可能会返回旧数据。

Kafka 数据可靠性深度解读虽然 Raft 算法能实现强一致性,也就是线性一致性(Linearizability),但需要客户端协议的配合。在实际场景中,我们一般需要根据场景特点,在一致性强度和实现复杂度之间进行权衡。比如 Consul 实现了三种一致性模型。

  1. default:客户端访问领导者节点执行读操作,领导者确认自己处于稳定状态时(在 leader leasing 时间内),返回本地数据给客户端,否则返回错误给客户端。在这种情况下,客户端是可能读到旧数据的,比如此时发生了网络分区错误,新领导者已经更新过数据,但因为网络故障,旧领导者未更新数据也未退位,仍处于稳定状态。
  2. consistent:客户端访问领导者节点执行读操作,领导者在和大多数节点确认自己仍是领导者之后返回本地数据给客户端,否则返回错误给客户端。在这种情况下,客户端读到的都是最新数据。
  3. stale:从任意节点读数据,不局限于领导者节点,客户端可能会读到旧数据。

当kafka producer 向 leader 发送数据时,可以通过 request.required.acks 参数来设置数据可靠性的级别:

  • 1(默认):这意味着 producer 在 ISR 中的 leader 已成功收到的数据并得到确认后发送下一条 message。如果 leader 宕机了,则会丢失数据。
  • 0:这意味着 producer 无需等待来自 broker 的确认而继续发送下一批消息。这种情况下数据传输效率最高,但是数据可靠性确是最低的。
  • -1:producer 需要等待 ISR 中的所有 follower 都确认接收到数据后才算一次发送完成,可靠性最高。但是这样也不能保证数据不丢失,比如当 ISR 中只有 leader 时(前面 ISR 那一节讲到,ISR 中的成员由于某些情况会增加也会减少,最少就只剩一个 leader),这样就变成了 acks=1 的情况。

如果要提高数据的可靠性,在设置 request.required.acks=-1 的同时,也要 min.insync.replicas 这个参数 (可以在 broker 或者 topic 层面进行设置) 的配合,这样才能发挥最大的功效。

其它

分布式系统原理介绍副本控制协议指按特定的协议流程控制副本数据的读写行为,使得副本满足一定的可用性和一致性要求的分布式协议。

  1. 中心化(centralized)副本控制协议,由一个中心节点协调副本数据的更新、维护副本之间的一致性。所有的副本相关的控制交由中心节点完成。并发控制将由中心节点完成,从而使得一个分布式并发控制问题,简化为一个单机并发控制问题。所谓并发控制,即多个节点同时需要修改副本数据时,需要解决“写写”、“读写”等并发冲突。单机系统上常用加锁等方式进行并发控制。
  2. 去中心化(decentralized)副本控制协议

kafka 因为有更明确地业务规则,有一个专门的coordinator,选举过程进一步简化,复制log的逻辑基本一致。《软件架构设计》 多副本一致性章节的开篇就 使用kafka 为例讲了一个 做一个强一致的系统有多难。