首先明確一下兩者的目標(biāo)：braft是解決復(fù)制狀態(tài)機(jī)問題，brpc是解決模塊間RPC通信問題。braft中Raft協(xié)議的互通直接使用brpc實(shí)現(xiàn)，runtime使用了bthread，因此braft編譯需要依賴brpc，從這點(diǎn)來看braft和brpc有一定的綁定關(guān)系。
但是從另一個(gè)角度來看，braft中核心的是協(xié)議狀態(tài)機(jī)比如log、snapshot、configuration這些東西的抽象和實(shí)現(xiàn)，協(xié)議RPC只是其中一環(huán)，做一層transport抽象也可以比較容易的替換為其他的coroutine based protobuf RPC框架，對(duì)于非coroutinebased protobuf RPC來講，braft只能用類似logcabin中pthread同步RPC，這樣就喪失了多復(fù)制組支持的特性，RPC的回調(diào)改造成本就比較高了。
如何看待raft的前景？
當(dāng)下，Raft已經(jīng)成為分布式一致性算法的主流，業(yè)界的TiDB、CockroachDB、etcd、consul等一系列流行的組件和服務(wù)都在使用，但是業(yè)界還有一些其他的paxos變種比如epaxos，未來可能會(huì)有一種新的Paxos變種成為主流。
對(duì)于Raft來講基于日志的連續(xù)提交的設(shè)定，相比multi-paxos的亂序提交在寫入性能上會(huì)有些差距。對(duì)于Raft協(xié)議來講沒有太多改進(jìn)空間了，但是braft要做一個(gè)理想的Raft庫實(shí)現(xiàn)的話，依然需要不斷的改進(jìn)和優(yōu)化。
用作品證明實(shí)力，網(wǎng)站建設(shè)行業(yè)排名前列
