谢谢大家的关注

一般情况下，KVServer是以集群的形式存在的，而根据Raft共识算法，只有集群中的Leader才能处理请求。：B/S架构下的SessionId是一个参考，可以考虑给每个通过认证的Client生成一个唯一的SessionId(随机串，比如uuid)，根据客户端提供的SessionId参数来验证会话的有效性。raft对log和snapshot的持久化无需考虑到查找效率，因此也无需采用B+Tree的形式存储，另外，raft的持久化考虑更多的数据的可靠性，因此也无需采用LSM Tree的存储方式。

使用Leader Lease，保证整个集群只有一个Leader，Leader接收到都请求后，记录下当前的commitIndex为readIndex，当applyIndex大于等于readIndex 后，则可以读取状态机中的数据返回。（1）在每个Term开始时，由于新选出的Leader可能不知道上一个Term的commitIndex，所以需要先在当前新的Term提交一条空操作的日志；Leader把每次读请求作为一条日志记录，以日志复制的形式提交，并应用到状态机后，读取状态机中的数据返回。

虽然采用 lease 的做法很高效，但仍然会面临风险问题，也就是我们有了一个预设的前提，各个服务器的 CPU clock 的时间是准的，即使有误差，也会在一个非常小的 bound 范围里面，如果各个服务器之间 clock 走的频率不一样，有些太快，有些太慢，这套 lease 机制就可能出问题。TiKV 是一个要保证线性一致性的分布式 KV 系统，所谓线性一致性，一个简单的例子就是在 t1 的时间我们写入了一个值，那么在 t1 之后，我们的读一定能读到这个值，不可能读到 t1 之前的值。

protobuf是一种用于序列化结构数据的工具，实现数据的存储与交换，与编程语言和开发平台无关。序列化：将结构数据或者对象转换成能够用于存储和传输的格式。反序列化：在其他的计算环境中，将序列化后的数据还原为结构数据和对象。其中后面的数字编号表示；二进制格式中识别各个字段的，一旦开始使用就不能再改变，[1,15]之内的标识号在编码的时候会占用一个字节，之后的[16,2047]会占用两个字节。

在上一篇中，我们详细解析了 ProtoBuf 的编码原理。有了这个知识储备，我们就可以深入 ProtoBuf 序列化、反序列化的源码，从代码的层面理解 ProtoBuf 具体是如何实现对数据的编码（序列化）和解码（反序列化）的。调用 SerializeToString 函数将 example1 对象序列化（编码）成字符串。我们的目的就是了解 SerializeToString 函数里到底发生了什么，是怎么一步一步得到最终的序列化结果的。注意：并非编码成字符串数据，string 只是作为编码结果的容器。

* 反射创建实例 *//* 反射相关接口 */reflecter->SetString(&instance, field, "鸡你太美");// 获取属性的值.return 0;利用上述 ProtoBuf 的反射能力，我们将能够实现许多强大的功能。例如各种 pb2json 库底层多是利用 ProtoBuf 的反射能力，实际上ProtoBuf 自身对编码结果反序列化并构建内存对象的过程用的也正是反射。获取程序元信息。

protocol buffers 是一种语言无关、平台无关、可扩展的序列化结构数据的方法，可用于数据通信协议和数据存储等，它是 Google 提供的一个具有高效协议数据交换格式工具库，是一种灵活、高效和自动化机制的结构数据序列化方法。相比XML，有编码后体积更小，编解码速度更快的优势；相比于 Json，Protobuf 有更高的转化效率。

我们假设就是 5，但这条日志 term = 3，**Leader 不能提交之前任期的日志，所以这条日志是不能提交的。具体流程是在 Leader 刚选举成功的时候，立即追加一条 no-op 日志，并立即复制到其它节点，no-op 日志一经提交，Leader 前面那些未提交的日志全部间接提交，问题就解决了。，Leader 查到日志有记录但又不能回复 1 给客户端(因为按照约束这条日志未提交)，线性一致性要求不能返回陈旧的数据，Leader 迫切地需要知道这条日志到底能不能提交。，这样系统才会快速对外正常工作。

比较严重的问题是，Client 发送的请求 Server 成功接收，Server 也将请求中的 command 成功在 Raft 层达成共识并应用至状态机，然而在回复 Client 时出现了问题，RPC 回复丢失。并在成功应用 command 后，更新 maxSeq。出现这种情况的根本原因是，Raft 层允许同样的 command commit 多次 (Raft 层并不知道这是不是相同的 command，只要有 command 来，就尝试共识)，但实际上，同样的 command 只能 apply 一次。

Raft 相对于 Paxos 有以下三个优点：表现形式(Presentation)、简单性(Simplicity)和高效的领导者选举算法。

本文主要内容如下：ZAB 协议的全称是 Zookeeper Atomic Broadcase，原子广播协议。作用：通过这个 ZAB 协议可以进行集群间主备节点的数据同步，保证数据的一致性。在讲解 ZAB 协议之前，我们必须要了解 Zookeeper 的各节点的角色。

ZooKeeper在分布式领域，能够帮助解决很多很多的分布式难题，但是底层却只是依赖于两个主要的组件：ZNode文件/数据存储系统和watch监听系统，另外还有一大模块，就是ACL系统。本节我们介绍下znode文件/数据存储系统。

（5）线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数，设置当前推荐的leader为获胜的 Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。命名服务是指通过指定的名字来获取资源或者服务的地址，利用zk创建一个全局的路径，即是唯一的路径，这个路径就可以作为一个名字，指向集群中的集群，提供的服务的地址，或者一个远程的对象等等。

【导读】：如何防止C++构造函数的隐式转换，explicit关键字可以帮助我们解决问题。关键字explicit可以阻止隐式转换的发生。例如: C++中只带有一个参数的构造函数,或者或者除了第一个参数外其余参数都有缺省值的多参构造函数,承担了两个角色:1.用于构建单参数的类对象。2.隐含的类型转换操作符。例如：一个类A的构造函数A(int i)就是，既可以用来作为构造器，又可以实现隐式转换A a=1；因为1可以通过构造函数A(int i)转换为一个类A的对象。(隐含的类型转换操作符)但有时我们并不想让他进行隐

从以上输出可以看到，将已构造好的元素 a 使用emplace_back()插入vector时，只调用了 拷贝构造函数。当使用push_back()时，看如下代码，将一个int类型的数字，作为push_back()的参数。总的来说，emplace_back()和push_back()都是用于向容器的尾部插入新元素的函数。当使用push_back()时，看如下代码，先构造变量a，再调用push_back()从以上输出可以看到，emplace_back()的参数是数字 1 时，从上面两组实验可知，

命名服务：命名服务是指通过**「指定的名字」来获取资源或者服务地址。Zookeeper可以创建一个「全局唯一的路径」，这个路径就可以作为一个名字。被命名的实体可以是「集群中的机器，服务的地址，或者是远程的对象」**等。一些分布式服务框架（RPC、RMI）中的服务地址列表，通过使用命名服务，客户端应用能够根据特定的名字来获取资源的实体、服务地址和提供者信息等。配置管理：实际项目开发中，我们经常使用.properties或者xml需要配置很多信息，如数据库连接信息、fps地址端口等等。

首先是负载均衡，单注册中心的承载能力是有限的，在流量达到一定程度的时 候就需要分流，负载均衡就是为了分流而存在的，一个 ZooKeeper 群配合相应的 Web 应用就可以很容易达到负载均衡；zookeeper 采用了全局递增的事务 Id 来标识，所有的 proposal都在被提出的时候加上了 zxid，zxid 实际上是一个 64 位的数字，高 32 位是 epoch 用来标识 leader 周期，如果有新的 leader 产生出来，epoch会自增，低 32 位用来递增计数。

zxid 是一个 64 位的数字，它的高 32 位是 epoch 用来标识 Leader 关系是否改变，每次一个 Leader 被选出来，它都会有一个新的 epoch，标识当前属于那个 leader 的统治时期。Zookeeper 中的所有数据其实都是由一个名为 DataTree 的数据结构管理的，所有的读写数据的请求最终都会改变这颗树的内容，在发出读请求时可能会传入 Watcher 注册一个回调函数，而写请求就可能会触发相应的回调，由 WatchManager 通知客户端数据的变化。

在羊群中一头羊做了某个动作后一群羊跟着做的行为指羊群效应。在Zookeeper分布式锁中会有一个临时的节点只有拿到节点才能操作，当A线程操作完成后会释放掉锁。这个时候分布式系统中就会有大量的线程请求去请求这个线程，如果请求线程过多，一个就4k，如果有几十万个，可能需要的宽带就会到4G甚至40G，导致宽带阻塞，这就是羊群效应。

Zab协议的全称是（Zookeeper原子广播）。Zookeeper 是通过 Zab 协议来保证分布式事务的最终一致性。Zab协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议，是Zookeeper保证数据一致性的核心算法。Zab借鉴了Paxos算法，但又不像Paxos那样，是一种通用的分布式一致性算法。它是特别为Zookeeper设计的支持崩溃恢复的原子广播协议。

设计一个分布式系统必定会遇到一个问题——。这就是著名的CAP。

你说网络通信使用的Netty，你都通过那些设置对Netty进行过调优（我表示Netty的bootstrap的option设置基本都是模仿Netty官方案例搞的，然后他问了我backlog是什么意思）**服务熔断：**如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。你说到你自定义了一个简单协议，自定义的协议头里包括哪些内容，多少字节，各自的作用是什么（魔数，消息长度，请求id，消息类型）一致性，可靠性怎么保证的？

在分布式系统中，需要使用全局唯一ID，期待ID能够按照时间有序生成。

在了解一致性Hash算法之前，先来讨论一下Hash本身的特点。普通的Hash函数最大的作用是散列，或者说是将一系列在形式上具有相似性质的数据，打散成随机的均匀分布的数据。负载均衡正是利用这一特性，对于大量随机的请求或调用，通过一定形式的Hash将他们均匀的散列，从而实现压力的平均化。举个例子，如果我们给每个请求生成一个Key，只要使用一个非常简单的Hash算法来实现请求的负载均衡，如下：不难发现，这样的Hash只要集群的数量N发生变化，之前的所有Hash映射就会全部失效。

一致性，是指所有节点在同一时刻的数据是相同的，即更新操作执行结束并响应用户完成后，所有节点存储的数据会保持相同。

当然，这样得到的最终作战计划也不能保证就是最好的，但这应该是我们能做到的最好的了。我们现在仍然假设将军里没有叛徒。我们发现，前面提到的目标A和目标B的要求可以适当「降低」一些：我们不再关注将军们是否能达成最终一致的作战计划，并且这个计划是不是「合理」；

consensus准确的翻译是共识，即多个提议者达成共识的过程，例如Paxos，Raft 就是共识算法，paxos 是一种共识理论，分布式系统是他的场景，一致性是他的目标。一些常见的误解：使用了 Raft或者 paxos 的系统都是线性一致的（Linearizability 即强一致），其实不然，共识算法只能提供基础，要实现线性一致还需要在算法之上做出更多的努力。

可以认为任何可以达成一致的信息都是一个提案。对于分布式系统来讲，各个节点通常都是相同的确定性状态机模型（又称为状态机复制问题，state-machine replication），从相同初始状态开始接收相同顺序的指令，则可以保证相同的结果状态。是指任何执行结果都是相同的，就好像所有进程对数据存储的读、写操作是按某种序列顺序执行的，并且每个进程的操作按照程序所指定的顺序出现在这个序列中。也就是说，在分布式系统中，如果一个由节点提出的提案，能够用在有限的时间内，达到一致性的结果，我们就说该提案达到了一致性。