There's more to leader election than keeping a handful of keys up to date. There's also more to distributed coordination than leader election alone. Some of the hairiest problems surround failure conditions that are not easy to test or plan for.
Sure, you could build it all yourself using Cassandra (local_serial or CAS would be fine), but it's largely a solved problem, and better tested than a home grown solution is likely to be. Don't be afraid of hard problems, but also don't fall prey to NIH syndrome. On Thu, Oct 15, 2015 at 9:43 AM Jon Haddad <j...@jonhaddad.com> wrote: > ZK seems a little overkill for just 1 feature though. LOCAL_SERIAL is > fine if all you want to do is keep a handful of keys up to date. > > There’s a massive cost in adding something new to your infrastructure, and > imo, very little gain in this case. > > On Oct 15, 2015, at 8:29 AM, Eric Stevens <migh...@gmail.com> wrote: > > You probably could, but if I were you, I'd consider a tool built for that > purpose, such as Zookeeper. It'd open up access to a lot of other great > cluster coordination features. > > On Thu, Oct 15, 2015 at 8:47 AM Jan Algermissen < > algermissen1...@icloud.com> wrote: > >> Hi, >> >> suppose I have two data centers and want to coordinate a bunch of >> services in each data center (for example to load data into a per-DC system >> that is not DC-aware (Solr)). >> >> Does it make sense to use CAS functionality with explicit LOCAL_SERIAL to >> 'elect' a leader per data center to do the work? >> >> So instead of saying 'for this query, LOCAL_SERIAL is enough for me' this >> would be like saying 'I want XYZ to happen exactly once, per data center'. >> - All services would try to do XYZ, but only one instance *per datacenter* >> will actually become the leader and succeed. >> >> Makes sense? >> >> Jan >> > >
