refactor slot mechanism

[siddontang]

Now xcodis use redis/ledisdb db index as slot, ledisdb can only support 256 dbs, this is too small can increase the probability of busy keys in same slot.

I don't want to change ledisdb code and upgrade all data, this is a very huge work and has some risks.

Maybe we can do this, codis saves all data in db 0, and in the inner modified redis, codis uses a slot hash to store slot and its associated keys, this is convenient when migrating a slot from one redis to another, we will not scan all redis keys but only keys in the slot hash.

LedisDB can not use this feature which may cause many code changed. So when migrating slot, we have to scan all keys, find the actual key in the slot, then migrate it. This may be not efficient but acceptable:

• Migration does not happen frequently.
• When a slot is migrating, e.g, from group1 to group2 for slot0, if xcodis want to operate a key in slot0, xcodis will force trying to migrate this key whether it is in group1 or already in group2. Migrating a key is very fast.

So migrating a slot does not block whole service, but only a little slow.

@kouhate, how do you think so?

[kouhate]

Hi @siddontang, sorry for my late, and those solution may be acceptable.

It depends on his key design how keys will become so busy. Migration is not so often, so full scan will not affect the whole system. It is true, but not efficient because it needs unnecessary scan for a small slot.

I wonder you could take the same way as codis or redis-cluster. e.g. updating slot hash while logging write operations in binlog.

[siddontang]

Hi @kouhate,

I don't know what you mean here:

I wonder you could take the same way as codis or redis-cluster. e.g. updating slot hash while logging write operations in binlog.

Btw, I have found a way to let ledisdb support large index, so we can use a large slot number, like 1024 or more.

Codis save 1024 slots in zookeeper, but I don't know the performance if we save more slots. Maybe we can save huge routing table in another ledisdb and use zookeeper to coordinate xcodis proxy server.

[kouhate]

@siddontang, well, what I mean is not so same as codis and redis-cluster, but this means ledis can have a map which relates slot to key.

Since you said ledis had a binlog to log all write-operation, so I guess wrapping or hooking those event would not be so difficult, but I did't read your code deeply, so maybe I'm saying something strange.

Btw, that's a good news to hear!

Then, I also think keeping over 1024 routing table may decrease its performance, but using "another" ledisdb to support it needs additional ledisdb instance.

So, It is better to spend one of the db space to save those routing meta data if possible. I don't know but redis-cluster may have something efficient way because they have tons of slots.