schrockwell
Processes registry across a cluster: one global versus many local registries
I have a cluster of nodes, each node containing some processes that are used primarily for maintaining and retrieving state. That state information is read frequently and does not change very often. When I do a read, it always has to call local processes AND remote processes. Writes are typically local only.
Currently I am using the awesome syn library, adding each process to global groups, and then using :syn.multi_call/3 to retrieve state from all the processes on the cluster. So far this has worked mostly fine, except for some bugs resulting from syn’s inherent eventual consistency.
Another solution I had considered was to start up a local process registry on each individual node (e.g. Registry), and then have a single “manager” or “coordinator” process that would know how to call all its local processes and then return the results en masse to remote nodes with a single remote call (e.g. GenServer.multi_call/4 to the coordinator only).
Does this latter pattern have a name? What tradeoffs would I have to consider in terms of performance and flexibility versus a global process registry? It seems like the coordinator could easily become a message bottleneck but I’m not sure how to design around that.
In this particular case should I just be create an mnesia table and use that to sync up the state across nodes?
Most Liked
ostinelli
Instead of using any library, you may consider a distributed mnesia table where the key is the node() (or some combination such that you can have multiple of those per node if needed), and the value the state. If you cannot go with eventual consistency, ensure that you use transactions when you write and you should be good with normal reads. Probably {read_concurrency,true} can help in your case.
Best,
r.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









