gosexy / redis

Redis client for Go that maps the full redis command list into equivalent Go functions.
MIT License
167 stars 44 forks source link

Support for Sentinel commands #31

Open therealbill opened 10 years ago

therealbill commented 10 years ago

Redis now comes with several Sentinel commands such as:

"sentinel masters" -> list of pods (master+slaves) the sentinel constellation is managing where each master is a key/value sequence of pod-specific information.

"sentinel master " -> returns the information for a specific pod in the same format as the sentinel masters command

"sentinel slaves " -> a key/value sequence giving a list of slaves with per-slave information.

The command "sentinel master cache" (where "cache" is the name of a master being monitored by the sentinel). issued in the CLI will return data along the following format:

127.0.0.1:26379> sentinel master cache
 1) "name"
 2) "cache"
 3) "ip"
 4) "127.0.0.1"
 5) "port"
... remainder snipped for brevity

Including this in the library via a specific command would greatly increase this use case's simplicity.

However, moving to the command "sentinel masters" you get a list of the above entries:

127.0.0.1:26379> sentinel masters
1)  1) "name"
    2) "cache"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    ...
2) ....

This too should be parsed into a Struct by the library. Other sentinel commands have this same pattern.

For the Sentinel commands, there is a reason beyond user ease to build this into the library. In order to support Sentinel, and possibly Redis Cluster, the library will need to know this same information in order to select a master to write/read to/from or a collection of slaves to read from.

At an absolute minimum, defining the structs in the library and exporting them for the user to reference would be an improvement.

As far as the command names I'd start with a suggestion of something like

SentinelMaster(name string) -> returns a struct representing a MasterEntry SentinelMasters() -> Returns a []MasterEntry InfoStruct(section string) -> returns a Struct for the section given, unless "all" is the section in which case a [] of Structs or an InfoAllStruct which contains each section's struct in it. I suggest InfoStruct to avoid breaking the current Info interface.