-
Notifications
You must be signed in to change notification settings - Fork 312
Feature Request: consul.io storage back-end. #15
Comments
I'm thinking about doing a first pass at something like this, but I've never written a line of go in my life. ;) |
My main concern for Consul, or something similar like etcd, is performance. They are built for service discovery and not really for high performance messaging. What's your main goal for using consul? Is it for persistence? |
Yes just for persistence. Everything would be cached in mem otherwise. |
Cassandra might be fast enough, especially if some sort of "eventual consistency" is ok between the brokers. I am thinking of a high availability broker here. |
Oh the other reason for consul is to register surgemq as a service with the system, but that would just be for service discovery. |
@bentwire Cassandra is no real option for persistency, really... Same with etcd and consul. Etcd and consul provide distributed data storage for service discovery and Cassandra has been built for totally different use cases. A persistency solution would more likely go into the direction of LevelDB and requires quite some refactoring work. |
I think consul.io would possibly make a good storage back-end to add to the current in mem back-end.
Thoughts?
The text was updated successfully, but these errors were encountered: