附原英文:
Select a suitable slave to promote. The current algorithm only uses
the following parameters:
1) None of the following conditions: S_DOWN, O_DOWN, DISCONNECTED.
2) Last time the slave replied to ping no more than 5 times the PING period.
3) info_refresh not older than 3 times the INFO refresh period.
4) master_link_down_time no more than:
(now - master->s_down_since_time) + (master->down_after_period * 10).
Basically since the master is down from our POV, the slave reports
to be disconnected no more than 10 times the configured down-after-period.
This is pretty much black magic but the idea is, the master was not
available so the slave may be lagging, but not over a certain time.
Anyway we'll select the best slave according to replication offset.
5) Slave priority can't be zero, otherwise the slave is discarded.
Among all the slaves matching the above conditions we select the slave
with, in order of sorting key:
Basically if runid is the same, the slave that processed more commands
from the master is selected.
runid
Redis "Run ID", a SHA1-sized random number that identifies a
given execution of Redis, so that if you are talking with an instance
having run_id == A, and you reconnect and it has run_id == B, you can be
sure that it is either a different instance or it was restarte
util.c
void getRandomHexChars(char *p, unsigned int len);