DZone
Cloud Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Cloud Zone > Large Scale Distributed Consensus Approaches: Concurrent Consistent Decisions

Large Scale Distributed Consensus Approaches: Concurrent Consistent Decisions

Oren Eini user avatar by
Oren Eini
·
Nov. 25, 14 · Cloud Zone · Interview
Like (0)
Save
Tweet
2.91K Views

Join the DZone community and get the full member experience.

Join For Free

so far we tackled the idea of large compute cluster, and a large storage cluster. i mentioned that the problem with the large storage cluster is that it doesn’t handle consistency within itself. two concurrent requests can hit two storage nodes and make concurrent operations that aren’t synchronized between themselves. that is usually a good thing, since that is what you want for high throughput system. the less coordination you can get away with, the more you can actually do.

so far, so good, but that isn’t always suitable. let us consider a case where we need to have a consistent approach, for some business reason. the typical example would be transactions in a bank, but i hate this example, because in the real world banks deal with inconsistency all the time, this is an explicit part of their business model. let us talk about auctions and bids, instead. we have an auction service, which allow us to run a large number of auctions.

for each auction, users can place bids, and it is important for us that bids are always processed sequentially per auction, because we have to know who place a bid that is immediately rejected ($1 commission) or a wining bid that was later overbid (no commission except for the actual winner). we’ll leave aside the fact that this is something that we can absolutely figure out from the auction history and say that we need to have it immediate and consistent. how do we go about doing this?

remember, we have enough load on the system that we are running a cluster with a hundred nodes in it. the rough topology is still this:

image

we have the consensus cluster, which decide on the network topology. in other words, it decide which set of servers is responsible for which auction. what happens next is where it gets interesting.

instead of just a set of cooperating nodes that share the data between them and each of which can accept both reads and writes, we are going to twist things a bit. each set of servers is their own consensus cluster for that particular auction . in other words, we first go to the root consensus cluster to get the topology information, then we add another command to the auction’s log. that command go through the same distributed consensus algorithm between the three nodes. the overall cluster is composed of many consensus clusters for each auction.

this means that we have a fully consistent set of operations across the entire cluster, even in the presence of failure. which is quite nice. the problem here is that you have to have a good way to distinguish between the different consensuses. in this case, an auction is the key per consensus, but it isn’t always so each to make such distinction, and it is important that an auction cannot grow large enough to overwhelm the set of servers that it is actually using. in those cases, you can’t really do much beyond relax the constraints and go in a different manner.

for optimization purposes, you usually don’t run an independent consensus for each of the auctions. or rather, you do, but you make sure that you’ll share the same communication resources, so for auctions/123 the nodes are d,e,u with e being the leader, while for auctions/321 the nodes are also d,e,u but u is the leader. this gives you the ability to spread processing power among the cluster, and the communication channels (tcp connections, for example) are shared between both auctions consensuses.

cluster AI

Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Growth in Java Development for Web and Mobile Apps
  • 6 Best Books to Learn Multithreading and Concurrency in Java
  • Maven Tutorial: Nice and Easy [Video]
  • Querying Kafka Topics Using Presto

Comments

Cloud Partner Resources

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo