raft

python threading method stuck

落花浮王杯 提交于 2021-02-17 05:27:10
问题 I have a class MyClass which creates 7 threads when it is initialized. One thread is a TCPServer, and the other six are objects of MyClass which the TCPServer uses to process requests. My intention is to create method which can run in the background of MyClass and maintain the 6 threads. The 6 threads correspond to 2 distributed objects obj1 and obj2 replicated with an implementation of Raft called PySyncObj. There are three threads per object. Each cluster of objects obj_1_cluster and obj_2

How to add a new Orderer Organization to existing Hyperledger Fabric network

拥有回忆 提交于 2021-01-27 14:15:59
问题 I am trying to add a new Orderer Organization to RAFT based existing ordering service. I am using the first-network from fabric-samples as the base network. While generating crypto-material, I have modified to generate crypto-material for 1 more orderer organization. The crypto-config.yaml looks like: OrdererOrgs: # --------------------------------------------------------------------------- # Orderer # --------------------------------------------------------------------------- - Name: Orderer

Raft算法赏析

…衆ロ難τιáo~ 提交于 2020-11-01 05:32:09
系列文章 Raft算法赏析 ZooKeeper的一致性算法赏析 Raft对比ZAB协议 1 leader选举 1.1 刚开始所有server启动都是follower状态 然后等待leader或者candidate的RPC请求、或者超时。 上述3种情况处理如下: leader的AppendEntries RPC请求:更新term和leader信息,当前follower再重新重置到follower状态 candidate的RequestVote RPC请求:为candidate进行投票,如果candidate的term比自己的大,则当前follower再重新重置到follower状态 超时:转变为candidate,开始发起选举投票 1.2 candidate收集投票的过程 candidate会为此次状态设置随机超时时间,一旦出现在当前term中大家都没有获取过半投票即split votes,超时时间短的更容易获得过半投票。 candidate会向所有的server发送RequestVote RPC请求,请求参数见下面的官方图 上面对参数都说明的很清楚了,我们来重点说说图中所说的这段话 If votedFor is null or candidateId, and candidate’s log is at least as up-to-date as receiver’s log,

how raft follower rejoin after network disconnected?

谁说我不能喝 提交于 2020-07-08 19:46:17
问题 I have a problem on raft. In paper "In Search of an Understandable Consensus Algorithm(Extended Version)" it says: To begin an election, a follower increments its current term and transitions to candidate state. (in section 5.2) and it also says: reciever should be "Reply false if args.term < currentTerm" in AppendEntries RPC and RequestVot RPC so, let's think this scene, there are 5 machine in raft system, and now machine 0 is leader, machine 1 to 4 is follower, now is term 1. Suddenly,

how raft follower rejoin after network disconnected?

烈酒焚心 提交于 2020-07-08 19:41:32
问题 I have a problem on raft. In paper "In Search of an Understandable Consensus Algorithm(Extended Version)" it says: To begin an election, a follower increments its current term and transitions to candidate state. (in section 5.2) and it also says: reciever should be "Reply false if args.term < currentTerm" in AppendEntries RPC and RequestVot RPC so, let's think this scene, there are 5 machine in raft system, and now machine 0 is leader, machine 1 to 4 is follower, now is term 1. Suddenly,

What's the benefit of advanced master election algorithms over bully algorithm?

主宰稳场 提交于 2020-05-15 04:18:28
问题 I read how current master election algorithms like Raft, Paxos or Zab elect master on a cluster and couldn't understand why they use sophisticated algorithms instead of simple bully algorithm. I'm developing a cluster library and use UDP Multicast for heartbeat messages. Each node joins a multicast address and also send datagram packets periodically to that address. If the nodes find out there is a new node that sends packets to this multicast address, the node is simply added to cluster and

vivo 大规模特征存储实践

扶醉桌前 提交于 2020-04-08 00:18:18
本文首发于 vivo互联网技术 微信公众号 链接: https://mp.weixin.qq.com/s/u1LrIBtY6wNVE9lzvKXWjA 作者:黄伟锋 本文旨在介绍 vivo 内部的特征存储实践、演进以及未来展望,抛砖引玉,吸引更多优秀的想法。 一、需求分析 AI 技术在 vivo 内部应用越来越广泛,其中特征数据扮演着至关重要的角色,用于离线训练、在线预估等场景,我们需要设计一个系统解决各种特征数据可靠高效存储的问题。 1. 特征数据特点 (1)Value 大 特征数据一般包含非常多的字段,导致最终存到 KV 上的 Value 特别大,哪怕是压缩过的。 (2)存储数据量大、并发高、吞吐大 特征场景要存的数据量很大,内存型的 KV(比如 Redis Cluster)是很难满足需求的,而且非常昂贵。不管离线场景还是在线场景,并发请求量大,Value 又不小,吞吐自然就大了。 (3)读写性能要求高,延时低 大部分特征场景要求读写延时非常低,而且持续平稳,少抖动。 (4)不需要范围查询 大部分场景都是单点随机读写。 (5)定时灌海量数据 很多特征数据刚被算出来的时候,是存在一些面向 OLAP 的存储产品上,而且定期算一次,希望有一个工具能把这些特征数据及时同步到在线 KV 上。 (6)易用 业务在接入这个存储系统时,最好没有太大的理解成本。 2. 潜在需求 扩展为通用磁盘

Raft系列文章之一: 什么是Raft?

陌路散爱 提交于 2020-03-26 13:16:31
3 月,跳不动了?>>> 简单的说, Raft 是一种易于理解的一致性算法,其功能相当于Paxos。目前很多提供一致性服务的系统都采用Paxos, 例如Chubby, ZooKeeper, 那么为何还需要 Raft ?自Lamport 1998年提出Paxos以来, 该协议虽逐渐成为主流一致性协议,但也以难以理解而著名,实现起来比较困难。针对 Raft 难以理解的缺陷, Raft 设计的主要目的之一就是容易理解, Raft 将整个算法过程分解为若干个独立的子过程,并且详细描述了每个子过程如何实现,容易理解和实现。我自己也用 Java 实现了 Raft , 代码在 https://github.com/chicm/CmRaft , 本系列文章的最后我将介绍我的实现。 本文主要参考了 In Search of an Understandable Consensus Algorithm (Extended Version) ,也包含了我自己的理解。 那么什么是一致性算法? 一致性是分布式容错系统的基本功能,例如在分布式共享文件系统中,通常有多台服务器向客户提供文件服务,当客户通过其中一台服务器A向文件系统存储 了一个文件,如何保证能从服务器B获取刚刚保存的文件?其核心问题在于多台机器就某个值达成一致,一旦某个值达成了一致,客户向整个集群的任何一台机器请 求该值时都会得到同一个值

基于 raft 协议的 RocketMQ DLedger 多副本日志复制设计原理

大兔子大兔子 提交于 2020-03-25 14:38:04
3 月,跳不动了?>>> 目录 1、RocketMQ DLedger 多副本日志复制流程图 1.1 RocketMQ DLedger 日志转发(append) 请求流程图 1.2 RocketMQ DLedger 日志仲裁流程图 1.3 RocketMQ DLedger 从节点日志复制流程图 2、RocketMQ DLedger 多副本日志复制实现要点 2.1 日志编号 2.2 追加与提交机制 2.3 日志一致性如何保证 上一篇 源码分析 RocketMQ DLedger(多副本) 之日志复制(传播) ,可能有不少读者朋友们觉得源码阅读较为枯燥,看的有点云里雾里,本篇将首先梳理一下 RocketMQ DLedger 多副本关于日志复制的三个核心流程图,然后再思考一下在异常情况下如何保证数据一致性。 @(本节目录) 1、RocketMQ DLedger 多副本日志复制流程图 搜小说 https://shupu.org/ 1.1 RocketMQ DLedger 日志转发(append) 请求流程图 1.2 RocketMQ DLedger 日志仲裁流程图 1.3 RocketMQ DLedger 从节点日志复制流程图 2、RocketMQ DLedger 多副本日志复制实现要点 上图是一个简易的日志复制的模型:图中客户端向 DLedger 集群发起一个写请求,集群中的 Leader

Raft共识算法

吃可爱长大的小学妹 提交于 2020-03-15 12:58:16
Raft共识算法在分布式系统中是常用的共识算法之一,论文原文 In Search of an Understandable Consensus Algorithm ,作者在论文中指出Poxas共识算法的两大问题,其一是难懂,其二是应用到实际系统存在困难。针对Paxos存在的问题,作者的目的是提出一个易懂的共识算法,论文中有Designing for understandability单独一小节,其中强调Raft必须是一个实用的、安全可用、有效易懂的共识算法。本文描述了Raft共识算法的细节,很多内容描述及引用图片均摘自论文原文。 Raft概述 我们主要分以下三部分对Raft进行讨论: Leader election——a new leader must be chosen when an existing leader fails. (领导人选举) Log replication——the leader must accept log entries from clients and replicate them across the cluster, forcing the other logs to agree with its own.(日志复制) Safety——the key safety property for Raft. (安全性) 正常工作过程中