How Cassandra select the node to send request?

Question

Imagine a Cassandra cluster needs to be accessed by a client application. In Java api we create a cluster instance and send the read or write request via a Session. If we use read/write consistency ONE, how the api select the actual node (coordinator node) in order to forward the request. Is it a random selection? please help to figure this out.

Answer 1

Cassandra drivers use the "gossip" protocol (and a process called node discovery) to gain information about the cluster. If a node becomes unavailable, the client driver automatically tries other nodes and schedules reconnection times with the dead one(s). According to the DataStax docs:

Gossip is a peer-to-peer communication protocol in which nodes periodically exchange state information about themselves and about other nodes they know about. The gossip process runs every second and exchanges state messages with up to three other nodes in the cluster. The nodes exchange information about themselves and about the other nodes that they have gossiped about, so all nodes quickly learn about all other nodes in the cluster.

Essentially, the list of nodes that you provide your client to connect to, are the initial contact points for gaining information on the entire cluster. This is why your client can communicate with all nodes in the cluster (if need be) even though you may only provide a small subset of nodes in your connection string.

Once your driver has the gossip information on the cluster, it can then make intelligent decisions about which node to run a query on. Node selection is not a process of voting or random selection. Based on the gossip information returned, the client driver applies its Load Balancing Policy. While it does take several factors into consideration, basically it tries to pick the node with the lowest network "distance" from the client.

Edit 20200322

Let me expand a bit on the point about the Load Balancing policy. I encourage developers of high-performance applications to use the TokenAwarePolicy. This policy hashes the partition key values to a "token," and uses this hash to determine which node(s) is responsible for the resulting token range. This has the effect of skipping the intermediate step of selecting a "coordinator" node, and sends the queries directly to the node which contains the requested data.

However, if you are using a non-token aware load balancing policy, or running a query which does not filter on a partition key, then the original process described above applies.