[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-5111":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":15,"forks30d":15,"starsTrendScore":19,"compositeScore":20,"rankGlobal":9,"rankLanguage":9,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":24,"hasPages":22,"topics":25,"createdAt":9,"pushedAt":9,"updatedAt":26,"readmeContent":27,"aiSummary":28,"trendingCount":15,"starSnapshotCount":15,"syncStatus":29,"lastSyncTime":30,"discoverSource":31},5111,"raft","hashicorp\u002Fraft","hashicorp","Golang implementation of the Raft consensus protocol",null,"Go",9034,1073,394,34,0,1,11,28,4,75.39,"Mozilla Public License 2.0",false,"main",true,[],"2026-06-12 04:00:24","raft [![Build Status](https:\u002F\u002Fgithub.com\u002Fhashicorp\u002Fraft\u002Fworkflows\u002Fci\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002Fhashicorp\u002Fraft\u002Factions)\n[![Go Reference](https:\u002F\u002Fpkg.go.dev\u002Fbadge\u002Fgithub.com\u002Fhashicorp\u002Fraft.svg)](https:\u002F\u002Fpkg.go.dev\u002Fgithub.com\u002Fhashicorp\u002Fraft)\n[![Go Report Card](https:\u002F\u002Fgoreportcard.com\u002Fbadge\u002Fgithub.com\u002Fhashicorp\u002Fraft)](https:\u002F\u002Fgoreportcard.com\u002Freport\u002Fgithub.com\u002Fhashicorp\u002Fraft)\n[![License: MPL 2.0](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FLicense-MPL%202.0-brightgreen.svg)](https:\u002F\u002Fopensource.org\u002Flicenses\u002FMPL-2.0)\n[![Build Status](https:\u002F\u002Fgithub.com\u002Fhashicorp\u002Fraft\u002Factions\u002Fworkflows\u002Fci.yml\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002Fhashicorp\u002Fraft\u002Factions)\n[![Release](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fv\u002Frelease\u002Fhashicorp\u002Fraft)](https:\u002F\u002Fgithub.com\u002Fhashicorp\u002Fraft\u002Freleases)\n[![Issues](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fissues\u002Fhashicorp\u002Fraft)](https:\u002F\u002Fgithub.com\u002Fhashicorp\u002Fraft\u002Fissues)\n[![Pull Requests](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fissues-pr\u002Fhashicorp\u002Fraft)](https:\u002F\u002Fgithub.com\u002Fhashicorp\u002Fraft\u002Fpulls)\n====\n\nraft is a [Go](http:\u002F\u002Fwww.golang.org) library that manages a replicated\nlog and can be used with an FSM to manage replicated state machines. It\nis a library for providing [consensus](http:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FConsensus_(computer_science)).\n\nThe use cases for such a library are far-reaching, such as replicated state\nmachines which are a key component of many distributed systems. They enable\nbuilding Consistent, Partition Tolerant (CP) systems, with limited\nfault tolerance as well.\n\n## Building\n\nIf you wish to build raft you'll need Go version 1.16+ installed.\n\nPlease check your installation with:\n\n```\ngo version\n```\n\n## Documentation\n\nFor complete documentation, see the associated [Godoc](http:\u002F\u002Fgodoc.org\u002Fgithub.com\u002Fhashicorp\u002Fraft).\n\nTo prevent complications with cgo, the primary backend `MDBStore` is in a separate repository,\ncalled [raft-mdb](http:\u002F\u002Fgithub.com\u002Fhashicorp\u002Fraft-mdb). That is the recommended implementation\nfor the `LogStore` and `StableStore`.\n\nA pure Go backend using [Bbolt](https:\u002F\u002Fgithub.com\u002Fetcd-io\u002Fbbolt) is also available called\n[raft-boltdb](https:\u002F\u002Fgithub.com\u002Fhashicorp\u002Fraft-boltdb). It can also be used as a `LogStore`\nand `StableStore`.\n\n\n## Community Contributed Examples \n- [Raft gRPC Example](https:\u002F\u002Fgithub.com\u002FJille\u002Fraft-grpc-example) - Utilizing the Raft repository with gRPC\n- [Raft-based KV-store Example](https:\u002F\u002Fgithub.com\u002Fotoolep\u002Fhraftd) - Uses Hashicorp Raft to build a distributed key-value store\n\n\n## Tagged Releases\n\nAs of September 2017, HashiCorp will start using tags for this library to clearly indicate\nmajor version updates. We recommend you vendor your application's dependency on this library.\n\n* v0.1.0 is the original stable version of the library that was in main and has been maintained\nwith no breaking API changes. This was in use by Consul prior to version 0.7.0.\n\n* v1.0.0 takes the changes that were staged in the library-v2-stage-one branch. This version\nmanages server identities using a UUID, so introduces some breaking API changes. It also versions\nthe Raft protocol, and requires some special steps when interoperating with Raft servers running\nolder versions of the library (see the detailed comment in config.go about version compatibility).\nYou can reference https:\u002F\u002Fgithub.com\u002Fhashicorp\u002Fconsul\u002Fpull\u002F2222 for an idea of what was required\nto port Consul to these new interfaces.\n\n    This version includes some new features as well, including non voting servers, a new address\n    provider abstraction in the transport layer, and more resilient snapshots.\n\n## Protocol\n\nraft is based on [\"Raft: In Search of an Understandable Consensus Algorithm\"](https:\u002F\u002Fraft.github.io\u002Fraft.pdf)\n\nA high level overview of the Raft protocol is described below, but for details please read the full\n[Raft paper](https:\u002F\u002Fraft.github.io\u002Fraft.pdf)\nfollowed by the raft source. Any questions about the raft protocol should be sent to the\n[raft-dev mailing list](https:\u002F\u002Fgroups.google.com\u002Fforum\u002F#!forum\u002Fraft-dev).\n\n### Protocol Description\n\nRaft nodes are always in one of three states: follower, candidate or leader. All\nnodes initially start out as a follower. In this state, nodes can accept log entries\nfrom a leader and cast votes. If no entries are received for some time, nodes\nself-promote to the candidate state. In the candidate state nodes request votes from\ntheir peers. If a candidate receives a quorum of votes, then it is promoted to a leader.\nThe leader must accept new log entries and replicate to all the other followers.\nIn addition, if stale reads are not acceptable, all queries must also be performed on\nthe leader.\n\nOnce a cluster has a leader, it is able to accept new log entries. A client can\nrequest that a leader append a new log entry, which is an opaque binary blob to\nRaft. The leader then writes the entry to durable storage and attempts to replicate\nto a quorum of followers. Once the log entry is considered *committed*, it can be\n*applied* to a finite state machine. The finite state machine is application specific,\nand is implemented using an interface.\n\nAn obvious question relates to the unbounded nature of a replicated log. Raft provides\na mechanism by which the current state is snapshotted, and the log is compacted. Because\nof the FSM abstraction, restoring the state of the FSM must result in the same state\nas a replay of old logs. This allows Raft to capture the FSM state at a point in time,\nand then remove all the logs that were used to reach that state. This is performed automatically\nwithout user intervention, and prevents unbounded disk usage as well as minimizing\ntime spent replaying logs.\n\nLastly, there is the issue of updating the peer set when new servers are joining\nor existing servers are leaving. As long as a quorum of nodes is available, this\nis not an issue as Raft provides mechanisms to dynamically update the peer set.\nIf a quorum of nodes is unavailable, then this becomes a very challenging issue.\nFor example, suppose there are only 2 peers, A and B. The quorum size is also\n2, meaning both nodes must agree to commit a log entry. If either A or B fails,\nit is now impossible to reach quorum. This means the cluster is unable to add,\nor remove a node, or commit any additional log entries. This results in *unavailability*.\nAt this point, manual intervention would be required to remove either A or B,\nand to restart the remaining node in bootstrap mode.\n\nA Raft cluster of 3 nodes can tolerate a single node failure, while a cluster\nof 5 can tolerate 2 node failures. The recommended configuration is to either\nrun 3 or 5 raft servers. This maximizes availability without\ngreatly sacrificing performance.\n\nIn terms of performance, Raft is comparable to Paxos. Assuming stable leadership,\ncommitting a log entry requires a single round trip to half of the cluster.\nThus performance is bound by disk I\u002FO and network latency.\n\n\n  ## Metrics Emission and Compatibility\n\n  This library can emit metrics using either `github.com\u002Farmon\u002Fgo-metrics` or `github.com\u002Fhashicorp\u002Fgo-metrics`. Choosing between the libraries is controlled via build tags. \n\n  **Build Tags**\n  * `armonmetrics` - Using this tag will cause metrics to be routed to `armon\u002Fgo-metrics`\n  * `hashicorpmetrics` - Using this tag will cause all metrics to be routed to `hashicorp\u002Fgo-metrics`\n\n  If no build tag is specified, the default behavior is to use `armon\u002Fgo-metrics`. \n\n  **Deprecating `armon\u002Fgo-metrics`**\n\n  Emitting metrics to `armon\u002Fgo-metrics` is officially deprecated, but usage of `armon\u002Fgo-metrics` is still the default. Please continue to use the `hashicorpmetrics` build tag if you want to opt into `hashicorp\u002Fgo-metrics`. [hashicorp\u002Fraft#676](https:\u002F\u002Fgithub.com\u002Fhashicorp\u002Fraft\u002Fissues\u002F676) will have status updates on the migration.\n\n  **Migration**\n  To migrate an application currently using the older `armon\u002Fgo-metrics` to instead use `hashicorp\u002Fgo-metrics` the following should be done.\n\n  1. Upgrade libraries using `armon\u002Fgo-metrics` to consume `hashicorp\u002Fgo-metrics\u002Fcompat` instead. This should involve only changing import statements. All repositories in the `hashicorp` namespace\n  2. Update an applications library dependencies to those that have the compatibility layer configured.\n  3. Update the application to use `hashicorp\u002Fgo-metrics` for configuring metrics export instead of `armon\u002Fgo-metrics`\n     * Replace all application imports of `github.com\u002Farmon\u002Fgo-metrics` with `github.com\u002Fhashicorp\u002Fgo-metrics`\n     * Instrument your build system to build with the `hashicorpmetrics` tag.\n\n  Eventually once the default behavior changes to use `hashicorp\u002Fgo-metrics` by default, you can drop the `hashicorpmetrics` build tag.\n","hashicorp\u002Fraft 是一个用 Go 语言实现的 Raft 共识协议库，用于管理复制日志并可与有限状态机（FSM）结合使用以管理复制的状态机。该项目的核心功能包括提供共识机制，支持构建一致性和分区容错性（CP）系统，并具有一定的容错能力。它采用纯 Go 语言编写，支持多种后端存储选项如 MDBStore 和 Bbolt，便于集成到不同类型的分布式系统中。适合于需要在多个节点间保持数据一致性的场景，例如构建分布式键值存储服务或任何需要高可用性和强一致性的应用环境。",2,"2026-06-11 03:02:36","top_language"]