The dissertation from ongardie

Gossip based linearizable read instead going through leader

Section 6.4

Lines 288 to 313 in 0c10ea1

 \section{Processing read-only queries more efficiently} 

 \label{clients:readonly} 

 Read-only client commands only query the replicated state machine; they 

 do not change it. Thus, it is natural to ask whether these queries can 

 bypass the Raft log, whose purpose is to replicate changes to the 

 servers' state machines in the same order. Bypassing the log offers an 

 attractive performance advantage: read-only queries are common in many 

 applications, and the synchronous disk writes needed to append entries 

 to the log are time-consuming. 

 However, without additional precautions, bypassing the log could lead to 

 stale results for read-only queries. 

 For example, a leader might be partitioned from the rest of the 

 cluster, and the rest of the cluster might have elected a new leader and 

 committed new entries to the Raft log. If the partitioned leader 

 responded to a read-only query without consulting the other servers, 

 it would return stale results, which are not linearizable. 

 Linearizability requires the results of a read to reflect a state of the 

 system sometime after the read was initiated; each read must at least 

 return the results of the latest committed write. 

 (A system that allowed stale reads would only provide 

 serializability, which is a weaker form of consistency.) 

 Problems due to stale reads have already been discovered in two 

 third-party Raft implementations~\cite{Kingsbury:etcdconsul}, 

 so this issue deserves careful attention.

describes an optimization where reads don't go through raft, but by reading readIndex from leader. This requires 2 hops, and quorum size of requests. First member needs to ask leader for readIndex and leader needs to confirm it has not been superseded by sending a round of heartbeats. This seems not very optimal.

What about having all members gossip about the latest commit index they have seen and require to get updates from at least quorum-1 of members. This would:

Remove hop to leader
~~If gossips are frequent enough remove another hop. As we don't need to wait for heartbeat.~~ - was mistaken we always need to request the heartbeat ourselves to maintain correctness while requests can be reordered.
Remove read dependency on leader being available

Simplest implementation would be use heartbeats for gossiping.

Just sharing my thoughts, might try to do a PoC for etcd project.

ongardie / dissertation Goto Github PK

dissertation's People

Contributors

Stargazers

Watchers

Forkers

dissertation's Issues

Gossip based linearizable read instead going through leader

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

	\section{Processing read-only queries more efficiently}
	\label{clients:readonly}

	Read-only client commands only query the replicated state machine; they
	do not change it. Thus, it is natural to ask whether these queries can
	bypass the Raft log, whose purpose is to replicate changes to the
	servers' state machines in the same order. Bypassing the log offers an
	attractive performance advantage: read-only queries are common in many
	applications, and the synchronous disk writes needed to append entries
	to the log are time-consuming.

	However, without additional precautions, bypassing the log could lead to
	stale results for read-only queries.
	For example, a leader might be partitioned from the rest of the
	cluster, and the rest of the cluster might have elected a new leader and
	committed new entries to the Raft log. If the partitioned leader
	responded to a read-only query without consulting the other servers,
	it would return stale results, which are not linearizable.
	Linearizability requires the results of a read to reflect a state of the
	system sometime after the read was initiated; each read must at least
	return the results of the latest committed write.
	(A system that allowed stale reads would only provide
	serializability, which is a weaker form of consistency.)
	Problems due to stale reads have already been discovered in two
	third-party Raft implementations~\cite{Kingsbury:etcdconsul},
	so this issue deserves careful attention.