Успях да прекарам известно време миналата седмица с момчетата от Linux, които тестват сценарии и работят върху C# страната на тази реализация и използвам следния подход:
- Прочетете сигналните адреси от конфигурацията и създайте ConnectionMultiplexer, за да се свържете с тях
- Абонирайте се за +превключвател-главен канал
- Попитайте всеки сентинел сървър на свой ред какво смятат за главния редис и подчинените, сравнете ги всички, за да се уверите, че всички са съгласни
- Създайте нов ConnectionMultiplexer с адресите на сървъра Redis, прочетени от Sentinel и се свържете, добавете манипулатора на събития към ConnectionFailed и ConnectionRestored.
- Когато получа съобщението +switch-master, извиквам Configure() на Redis ConnectionMultiplexer
- Като подход за колан и скоби винаги извиквам Configure() на Redis ConnectionMultiplexer 12 секунди след получаване на събитие connectionFailed или connectionRestored, когато типът на връзката е ConnectionType.Interactive.
Откривам, че обикновено работя и преконфигурирам след около 5 секунди от загубата на главната страница на redis. През това време не мога да пиша, но мога да чета (тъй като можеш да четеш от роб). 5 секунди е добре за нас, тъй като нашите данни се актуализират много бързо и стават остарели след няколко секунди (и впоследствие се презаписват).
Едно нещо, в което не бях сигурен, беше дали трябва да премахна сървъра на redis от redis ConnectionMultiplexer, когато даден екземпляр се повреди, или да го оставя да продължи да опитва отново връзката. Реших да го оставя да опита отново, тъй като се връща в микса като роб веднага щом се появи отново. Направих някои тестове на производителността със и без повторен опит за връзка и изглежда имаше малка разлика. Може би някой може да изясни дали това е правилният подход.
От време на време връщането на екземпляр, който преди това е бил главен, изглежда предизвиква известно объркване - няколко секунди след като се появява отново ще получавам изключение от писането - "САМО ЧЕТЕНЕ", което предполага, че не мога да пиша на подчинен. Това беше рядко, но открих, че моят "обхватен" подход за извикване на Configure() 12 секунди след промяна на състоянието на връзката улови този проблем. Извикването на Configure() изглежда много евтино и следователно извикването му два пъти, независимо дали е необходимо или не, изглеждаше добре.
Сега, когато имам подчинени устройства, разтоварих част от кода си за почистване на данни, който сканира ключове на подчинените, което ме прави щастлив.
Като цяло съм доста доволен, не е идеален, но за нещо, което трябва да се случи много рядко, е повече от достатъчно.
