Redis: репликация, часть 1. Replication vs Sharding. Sentinel vs Cluster. Топология Redis

Thank you for reading this post, don't forget to subscribe!

Redis Replication vs Sharding

Redis под­дер­жи­ва­ет два типа рас­пре­де­ле­ния дан­ных — replication (mirroring, дуб­ли­ро­ва­ние дан­ных) и sharding (partitioning, сег­мен­ти­ро­ва­ние). При этом в кла­сте­ре (см. ниже) воз­мож­но исполь­зо­ва­ние обо­их типов одновременно.

Replication

Пред­став­ля­ет собой копи­ро­ва­ние всех дан­ных меж­ду все­ми узла­ми кла­сте­ра, что поз­во­ля­ет выпол­нять запро­сы к дан­ным с двух или более нод, плюс дан­ные хра­нят­ся на всех нодах, таким обра­зом обес­пе­чи­вая надёж­ность дан­ных (high availability).

При таком под­хо­де уве­ли­чи­ва­ет­ся ско­рость выпол­не­ния read-операций.

Sharding

При исполь­зо­ва­нии сег­мен­ти­ро­ва­ния — дан­ные раз­би­ва­ют­ся на несколь­ко частей, что улуч­ша­ет про­из­во­ди­тель­ность каж­дой отдель­ной ноды, т.к. она не хра­нит и не отве­ча­ет за все дан­ные кластера.

При таком под­хо­де уве­ли­чи­ва­ет­ся ско­рость выпол­не­ния write-операций.

Redis Sentinel vs Redis Cluster

Redis Sentinel

Был добав­лен в Redis v.2.4, и явля­ет­ся сер­ви­сом мони­то­рин­га состо­я­ния мастер и слейв нод. Уме­ет отправ­лять уве­дом­ле­ния о собы­ти­ях, выпол­нять пере­клю­че­ние меж­ду масте­ром и слей­вом, если мастер вышел из строя и т.д. Име­ет смысл в исполь­зо­ва­нии, если исполь­зу­ет­ся «голая» мастер-слейв репли­ка­ция без пол­но­цен­но­го кластера.

Рабо­та­ет как отдель­ный демон исполь­зуя либо отдель­ный испол­ня­е­мый файл sentinel, либо redis-server в режи­ме sentinel.

Выпол­ня­ет настрой­ку нод в слу­чае выхо­да из строя масте­ра: опре­де­ля­ет, какая из нод ста­нет новым масте­ром, выпол­ня­ет их пере­на­строй­ку на ходу.

Тре­бу­ет как мини­мум трёх рабо­та­ю­щих инстан­сов для дости­же­ния кво­ру­ма при опре­де­ле­нии ста­ту­са Redis-масте­ра или слейв-нод.

Redis Cluster

Был добав­лен в Redis v.3.0, и явля­ет­ся пол­но­цен­ным native реше­ни­ем для созда­ния и управ­ле­ния кла­сте­ром с сег­мен­та­ци­ей и репли­ка­ций дан­ных. Выпол­ня­ет зада­чи управ­ле­ния нода­ми, репли­ка­ции, син­хро­ни­за­ции дан­ных, обес­пе­че­ни­ем досту­па к ним в слу­чае выхо­да из строя одно­го или более мастеров.

Исполь­зо­ва­ние Sentinel в слу­чае созда­ния кла­сте­ра не име­ет смыс­ла, т.к. кла­стер сам будет решать все необ­хо­ди­мые задачи.

Топология Redis

Один Redis-инстанс

Самый клас­си­че­ский случай.

Про­стой в запус­ке и настройке.

Огра­ни­чен ресур­са­ми хоста, на кото­ром запу­щен — его про­цес­со­ром и памятью.

В слу­чае выхо­да из строя хоста или само­го сер­ве­ра Redis — разу­ме­ет­ся, упа­дут все зави­ся­щие от него служ­бы, т.е. ника­ко­го обес­пе­че­ния надёж­но­сти нет.

Master-slave репликация

Один мастер, к кото­ро­му под­клю­че­ны несколь­ко слей­вов, на кото­рые выпол­ня­ет­ся пол­ная репли­ка­ция всех данных.

Дан­ные обнов­ля­ют­ся на масте­ре, после чего он отправ­ля­ет инфор­ма­цию об обнов­ле­ни­ях на слейвы.

Слей­вы обща­ют­ся толь­ко  с масте­ром (но могут иметь соб­ствен­ные слейвы).

Слей­вы явля­ют­ся read-only нода­ми — ника­ких изме­не­ний на них не выпол­ня­ет­ся (если явно не зада­но другое,)

В слу­чае выхо­да из строя одной из нод — все дан­ные оста­нут­ся доступ­ны­ми с дру­гих улов.

Прост в настрой­ке, но опе­ра­ции запи­си огра­ни­че­ны доступ­ны­ми масте­ру ресурсами.

В слу­чае выхо­да из строя масте­ра — тре­бу­ет руч­но­го вме­ша­тель­ства для пере­опре­де­ле­ния ново­го масте­ра из одно­го из слей­вов, кро­ме того — кли­ен­ты долж­ны точ­но знать на какую ноду выпол­нять запро­сы чте­ния и записи.

Redis Sentinel

Уже опи­сы­вал­ся выше, но ещё несколь­ко слов.

Как и в слу­чае с репли­ка­ци­цей Redis — име­ет одну Master Sentinel ноду, кото­рая име­ет при­о­ри­тет при при­ня­тии реше­ния о том, какую ноду Redis исполь­зо­вать в роли Master.

Т.е, в слу­чае с одним Масте­ром Redis и дву­мя слей­ва­ми, и если Master Sentinel рабо­та­ет на том же хосте, где Мастер Redis-а, и этот хост уми­ра­ет — Sentinel опре­де­ля­ет свой новый мастер-инстанс, затем два остав­ших­ся Sentinel-инстан­са при­ни­ма­ют реше­ние о том, какой из остав­ших­ся двух Redis-нод ста­нет новым масте­ром. При этом у мастер-инстан­са Sentinel будет при­о­ри­тет при при­ня­тии решения.

Сто­ит учи­ты­вать, что не все кли­ен­ты уме­ют рабо­тать с моде­лью Redis Sentinel, спи­сок кли­ен­тов — тут>>> https://redis.io/clients .

Redis Cluster

И самый пол­но­функ­ци­о­наль­ный вари­ант — Redis Cluster.

Несколь­ко мастер-инстан­сов, у каж­до­го один или более слей­вов (до 1000).

Выпол­ня­ет все зада­чи по шар­дин­гу, репли­ка­ции, failover, син­хро­ни­за­ции данных.

Тре­бу­ет как мини­мум 6 нод Reedis-а: три для масте­ров, и три для слейвов.

Уме­ет пере­на­прав­лять запро­сы от кли­ен­тов на нуж­ный мастер или слейв — но это тре­бу­ет под­держ­ки кла­сте­ра сами­ми кли­ен­та­ми Redis.