Arquitectura mestre-escravo

A **arquitectura mestre/escravo** (tamén denominada *supervisor/traballador*) é unha arquitectura de sistemas nos que un compoñente realiza labores de control, supervisión e coordinación (denominado mestre), e os restantes realizan tarefas específicas (denominados escravos), devolvendo os resultados ao compoñente mestre.

A aplicación deste tipo de arquitectura é bastante habitual no eido da programación paralela, permitindo obter grandes melloras de rendemento.

## Descrición 
O proceso de comunicación dun mestre cun escravo chámase *transacción*. Existen dous tipos:

* **Consulta-resposta.** O mestre inicia unha transacción cun dos seus escravos. Todos os escravos a escoitan, pero só aquel ao que vai dirixida a comunicación responde. A transacción pode involucrar o intercambio de varias mensaxes.
* **Difusión sen resposta.** O mestre inicia unha transacción para todos os escravos. Ningún escravo responde explicitamente, e o mestre asume que rematan nalgún momento. Pódese dar o caso de que un ou máis escravos non reciban correctamente a información e isto debe terse en conta cando se utiliza este tipo de transacción.

Nunha transacción mestre/escravo defínense certos parámetros para organizalas e garantilas:

* **Protocolo.** Para que dous compoñentes que están intercambiando información poidan comprenderse é necesario que se poñan de acordo no contido da información intercambiada. O conxunto de regras e convencións que rexen a comunicación denomínase protocolo.
* **Poleo.** O compoñente mestre interroga baixo un esquema programado a secuencia de escravos a disposición; cada escravo pode recibir diferentes tipos de transaccións correspondentes a unha ou varias tarefas. O tempo entre mensaxes para cada escravo ou transacción denomínase *poleo*.
* **TimeOut.** Cando o mestre inicia a transacción cun determinado escravo dentro do esquema consulta/resposta, pode suceder que o escravo non poida responderlle ao mestre; polo tanto, o mestre debe manexar un tempo de espera para a resposta do escravo, e se non hai resposta abortar esta transacción para reintentala ou para continuar co seu esquema de poleo previsto. Este tempo de agarda máximo denomínase t*imeout*.
* **Reintentos.** Cando un escravo non responde e o mestre aborta a transacción, debe ademais decidir que facer: se continuar co esquema de poleo previsto ou reintentar a transacción abortada. A cantidade de veces que se vai reintentar unha transacción denomínase *reintentos* ou *retries*.. Esta variante introduce varios mestres secundarios de maneira que se mantén o esquema xeral da arquitectura. Se durante a operación habitual de supervisión e control o mestre principal morre, é inmediatamente substituído por outro (facendo uso de *checkpoints*), minimizando o tempo no que o sistema deixa de estar operativo.
centro|442x442px|alt=Arquitectura mestre-escravo con reposto.|miniatura|Representación dunha arquitectura mestre-escravo con reposto.
* **Mestre con redundancia pasiva:** Estrutura que inclúe un ou varios mestres de reposto, co obxectivo de aumentar a dispoñibilidade. Esta variante, igual que no caso anterior, introduciríase un novo mestre, o cal estaría constantemente actualizado respecto dos datos do mestre principal. Deste xeito, se durante a operación habitual de supervisión e control o mestre principal morre, é inmediatamente substituído por outro que está xa listo para executarse, reducindo practicamente a cero o tempo no que o sistema deixa de estar operativo.
centro|466x466px|alt=Arquitectura mestre-escravo con redundancia pasiva.|miniatura|Representación dunha arquitectura mestre-escravo con redundancia pasiva.

Nalgúns sistemas, o compoñente mestre é elixido entre o grupo de compoñentes dispoñibles no arranque, que pasan a desenvolver o rol de escravos.

## Vantaxes e inconvenientes 
Entre as vantaxes da arquitectura mestre-escravo cómpre destacar a alta tolerancia a erros que posúe. Isto tradúcese en que, en caso de que algún escravo morra, o sistema apenas se verá afectado, e poderá seguir funcionando sen problemas. A tarefa non completada poderá ser asignada a outro escravo por parte do mestre, e o escravo que fallou poderá ser reiniciado ou substituído. Por outra banda, no caso de que o mestre morrese (que é o caso que máis afecta ao sistema, xa que supón unha maior penalización ou incluso poder provocar que deixe de funcionar por completo) pódese afrontar aplicando algunha das variantes que proporcionen un substituto para o mestre.

Entre os inconvenientes máis problemáticos, destaca a necesidade de que as tarefas a levar a cabo polo sistema sexan independentes, para poder facer unha distribución das mesmas entre os escravos. Ademais, esa distribución debería facer un uso intelixente das capacidades dos escravos, para permitir maximizar o rendemento global do sistema. Así, se se desprega unha arquitectura cun elevado número de escravos e un só mestre, onde haxa moitas comunicacións entre este e aqueles, o mestre pode sufrir problemas de saturación, e ó ser o compoñente principal do sistema, isto traduciríase nunha redución directa do rendemento do mesmo. A saturación (ou baixo rendemento) do mestre é tanto máis probable cantas máis responsabilidades se lle asignen, polo que un sistema no que o mestre, ademais de distribuír tarefas entre os escravos, se encargue de procesar os datos devoltos por estes, facendo algún tipo de cómputo global con eles, incrementa o risco de ofrecer unha latencia máis elevada do agardado.

## Exemplos 
En termos xerais, a arquitectura mestre/escravo é apropiada para a construción de sistemas en tempo real, que precisan garantir o tempo de resposta. Tamén se atopa con frecuencia en sistemas embebidos, que se poden construír combinando a arquitectura en repositorio ou a arquitectura en pipeline coa mestre/escravo.

En ocasións úsase esta arquitectura para estruturar a parte dos sistemas que se ocupa da replicación da información; así, en replicación de bases de datos, a base de datos mestre considérase a fonte autorizada, e as bases de datos escravas sincronízanse con ela.

Ademais de organizar a relación entre compoñentes software dos sistemas informáticos, a organización mestre/escravo está presente no eido da informática tamén a nivel físico:
* Os periféricos conectados a un bus nun equipo informático funcionan habitualmente como escravos dun mestre (controlador).
* Os discos ríxidos que usan ATA en paralelo organízanse tamén nun esquema mestre-escravo.
* O paquete RMPI da linguaxe de programación R é un estándar de modelos de programación mestre/escravo.
* Na plataforma Macintosh, reiniciar no Modo Orientado a Disco permite que un ordenador actúe como un disco duro externo doutro dispositivo, converténdose nun escravo deste.
Alén dos exemplos propios do eido da informática, o esquema de funcionamento subxacente a esta arquitectura está presente noutras situacións do mundo real:
* Un reloxo mestre que proporciona un sinal de tempo é usado para sincronizar varios reloxos escravos nunha rede de reloxos.
* A gravación múltiple de casetes e CDs consiste nun mestre reproducindo que dirixe aos escravos que gravan en paralelo.
* Algúns sistemas hidráulicos e pneumáticos usan un cilindro mestre para controlar un ou varios cilindros escravos.
* No transporte ferroviario, cando se usa un control de trens de unidades múltiples, as locomotoras secundarias actúan como escravas da primeira locomotora (mestre).

## Polémica 
No mundo anglosaxón, e especialmente nos EUA, a palabra mestre (*master*) ten unha carga histórico-cultural negativa, especialmente cando se contrapón á palabra escravo (*slave*), que se traduciría mais fielmente coma "amo". En 2003, o condado de Os Ánxeles en California pediu aos seus fabricantes, subministradores e contratistas que non usasen as palabras "amo" (*master*) e "escravo" (*slave*) nos seus produtos. Esta controvertida decisión foi baseada na "sensibilidade e diversidade cultural do condado de Os Ánxeles". Debido as queixas sobre a decisión, o condado aclarou que "só era unha petición".

En maio de 2014, un usuario de Github enviou unha petición  sobre substituír os termos mestre/escravo de django, o framework de Python, pola nomenclatura líder/seguidor, ou alternativamente primario/réplica. Segue habendo unha discusión activa sobre o tema.

## Notas 
## Véxase tamén 
### Outros artigos 
* Arquitectura software
* Peer-to-peer
* Bus (informática)
* SCSI
* Serial ATA