There is no official way yet, but you have the following possibilities:
- do it yourself: have an (iterable) collection of redis servers (i.e.
List<JedisShardInfo>) . For each time you do something, you call a
method that gives you a jedis-instace of the redis-server collection,
either a random one, the next one (the latter has the advantage that
it doesn't need random number generation, and maximizes the average
time between acesses to a given server, also beware ). Given a
JedisShardInfo jsi, you can always call jsi.createResource. Then
you'll need to disconnect each time. However, this approach is not
suitable for anything else but the "occasional" Jedis connection,
since it has a huge overhead at creating network connections. You
should definetely have a Pool of your servers, for anything serious.
JedisPool pooles several instances with connections to a single
server. So you would need to adapt Pool...
- or you can directly use RoundRobinPool. It's a simple adaptation of
the same apache commons Pool that JedisPool uses (and you can use it
as Pool<Jedis>), with the main difference that the members of that
pool are not several Jedis instances connected to the same Jedis
server, but a pool of Jedis isntances connected to List of different
Jedis Servers. Furthermore, it's set up as a FIFO queue, instead of
LIFO, hence it effectively cycles through the members of that pool.
You can get it here:
https://gist.github.com/1084272
You use it exactly as you use (Sharded)JedisPool:
Jedis j = rrp.getRessource
j....
rrp.returnResource(j)
Beware that if you use several databases (select), you have to
indicate it each time.
RoundRobinPool implies that the members of the Pool are slaveOf some
master, which must be the case in your case too. So you have to
indicate your master and add it to the slave list.
For further explanation look here
https://github.com/xetorthio/jedis/wiki/AdvancedUsage
at the bottom.
Have a read through UnifiedJedis too, it's fully functional, and gives
you some extra functionality (i.e. tunable redundancy) and convenience
(i.e. spares you get/returnResource), but it's not thoroughly tested
and probably contains some bugs, but it' should be easy to check the
commands you are using. Don't hesistate to contact me for any
assistance. If there is any interest and if I have the time, it may
get an major overhaul using either Java Proxy or scala closures to
avoid massive code duplication.
best,
ingvar
2011/10/18 eddie <tanxi...@gmail.com>: