Diseñe el servicio Google Drive: cree un servicio de almacenamiento en la nube para decenas de millones de usuarios activos diarios

Este artículo se publicó por primera vez en la cuenta oficial: ¡Más IA (power_ai), bienvenido a prestar atención, la programación y los productos secos de IA se entregarán a tiempo!

Los servicios de almacenamiento en la nube como Google Drive, Dropbox, Microsoft OneDrive y Apple iCloud se han vuelto muy populares en los últimos años. En este capítulo, se le pide que diseñe Google Drive.

Antes de sumergirnos en el diseño, tomemos un momento para entender Google Drive. Google Drive es un servicio de almacenamiento y sincronización de archivos que lo ayuda a almacenar documentos, fotos, videos y otros archivos en la nube. Puede acceder a sus archivos desde cualquier computadora, teléfono inteligente y tableta. Puede compartir fácilmente estos archivos con amigos, familiares y colegas[1]. Las Figuras 15-1 y 15-2 muestran cómo se ve Google Drive en el navegador y en la aplicación móvil, respectivamente.

Paso 1: comprender el problema y determinar el alcance del diseño

Diseñar Google Drive es un gran proyecto, por lo que es importante hacer preguntas para reducirlo.

Candidato : ¿Cuál es la función más importante?
Entrevistador : carga y descarga de archivos, sincronización de archivos y notificaciones.

Candidatos : ¿Es esta una aplicación móvil, una aplicación web o ambas?
Entrevistador : Ambos.

Candidatos : ¿Cuáles son los formatos de archivo admitidos?
Entrevistador : Cualquier tipo de documento.

Candidato : ¿Es necesario cifrar los archivos?
Entrevistador : Sí, los archivos almacenados deben estar encriptados.

Candidato : ¿Hay un límite de tamaño de archivo?
Entrevistador : Sí, el archivo debe ser menor o igual a 10 GB.

Candidato : ¿Cuántos usuarios tiene este producto?
Entrevistador : 10 millones de usuarios activos diarios.

En este capítulo, nos centraremos en las siguientes funciones:

• agregar archivos. La forma más fácil de agregar archivos es arrastrarlos y soltarlos en Google Drive.
• descargar archivo.
• Sincronice archivos en varios dispositivos. Cuando se agrega un archivo en un dispositivo, se sincroniza automáticamente con los otros dispositivos.
• Ver versiones históricas de un archivo.
• Comparta archivos con sus amigos, familiares y colegas.
• Envíe notificaciones cuando se editen, eliminen o compartan archivos con usted.

Las características no discutidas en este capítulo incluyen:

• Edición y colaboración en Google Docs. Google Docs permite que varias personas editen el mismo documento al mismo tiempo. Esto está más allá del alcance de nuestro diseño.

Además de aclarar los requisitos, también es muy importante comprender los requisitos no funcionales:

• fiabilidad. Para los sistemas de almacenamiento, la confiabilidad es extremadamente importante. La pérdida de datos es inaceptable.
• Velocidad de sincronización rápida. Si la sincronización de archivos lleva demasiado tiempo, los usuarios se impacientan y abandonan el producto.
• Uso de Ancho de Banda. Los usuarios no estarán contentos si el producto consume mucho ancho de banda de red innecesario, especialmente si tienen un plan de datos móviles.
• escalabilidad El sistema debe ser capaz de manejar un alto tráfico.
• alta disponibilidad. Cuando algunos servidores se desconectan, se ralentizan o experimentan errores de red inesperados, los usuarios aún deberían poder usar el sistema.

Cálculo aproximado

• Digamos que la aplicación tiene 50 millones de usuarios registrados y 10 millones de usuarios activos diarios.

• Los usuarios obtienen 10 GB de espacio libre.

• Supongamos que un usuario carga 2 archivos por día, con un tamaño de archivo promedio de 500 KB.

• La relación de lectura y escritura es de 1:1.

• Espacio total asignado: 50 millones * 10 GB = 500 PB

• Consultas por segundo (QPS) para la API de subida: 10 millones * 2 subidas/24 horas/3600 segundos = ~240

• Pico QPS = QPS * 2 = 480

Paso dos: proponer un diseño de alto nivel y obtener la aprobación

Vamos a adoptar un enfoque ligeramente diferente al mostrar planos de alto nivel desde el principio. Comenzaremos con algo simple: construya todo en un solo servidor. Luego, escale gradualmente para admitir millones de usuarios. A través de este ejercicio, volverá a familiarizarse con algunos de los temas importantes tratados en este libro.

Comencemos con la configuración de un solo servidor que se detalla a continuación:

• Un servidor web para cargar y descargar archivos.
• Una base de datos que rastrea metadatos como datos de usuario, información de inicio de sesión, información de archivos, etc.
• Un sistema de almacenamiento para almacenar archivos. Asignamos 1 TB de espacio de almacenamiento para almacenar archivos.

Pasamos algunas horas configurando un servidor web Apache, una base de datos MySql y un directorio llamado *drive/ como raíz para almacenar los archivos cargados. Bajo el directorio drive/*, hay una serie de directorios, también conocidos como espacios de nombres. Cada espacio de nombres contiene todos los archivos cargados por ese usuario. El nombre de archivo en el servidor sigue siendo el mismo que el nombre de archivo original. Al concatenar espacios de nombres y rutas relativas, cada archivo o carpeta se puede identificar de forma única.

La figura 15-3 muestra el aspecto del directorio */drive* a la izquierda y una vista ampliada a la derecha.

interfaz API

¿Cómo es la interfaz API? Necesitamos principalmente 3 interfaces API: cargar archivos, descargar archivos y obtener revisiones de archivos.

1. Sube archivos a Google Drive

Se admiten dos tipos de cargas:

• Carga sencilla. Utilice este tipo de carga cuando el tamaño del archivo sea pequeño.
• La carga se puede reanudar. Utilice este tipo de carga cuando el tamaño del archivo sea grande y la probabilidad de interrupciones de la red sea alta.

Este es un ejemplo de una API de carga reanudable:

https://api.example.com/files/upload?uploadType=reanudable

parámetro:

• uploadType=reanudable
• data: el archivo local que se cargará.

Las cargas reanudables se logran en los siguientes 3 pasos [2]:

• Envíe una solicitud inicial de una URL reanudable.
• Cargue datos y monitoree el estado de carga.
• Si la carga se interrumpió, reanude la carga.

2. Descarga archivos de Google Drive

Ejemplo de API: https://api.example.com/files/download

parámetro:

• ruta: La ruta del archivo descargado.

Parámetro de ejemplo:
{ "ruta": "/recetas/sopa/mejor_sopa.txt" }

3. Obtenga la revisión del archivo

Ejemplo de API: https://api.example.com/files/list_revisions

parámetro:

• ruta: la ruta al archivo donde desea obtener el historial de revisiones.
• límite: El número máximo de revisiones a devolver.

Parámetros de ejemplo:
{ "ruta": "/recetas/sopa/mejor_sopa.txt", "límite": 20 }

Todas las interfaces API requieren autenticación de usuario y usan HTTPS. Secure Sockets Layer (SSL) protege la transmisión de datos entre clientes y servidores back-end.

Salir del modo de servidor único

A medida que se carguen más archivos, eventualmente verá la advertencia de espacio lleno que se muestra en la Figura 15-4.

¡Solo quedan 10 MB de almacenamiento! Esta es una emergencia ya que los usuarios ya no pueden cargar archivos. La primera solución que se me ocurre es fragmentar los datos para que se almacenen en varios servidores de almacenamiento. La figura 15-5 muestra un ejemplo de fragmentación basada en user_id .

Te quedas despierto toda la noche configurando la fragmentación de la base de datos y supervisándola de cerca. Todo empezó a funcionar sin problemas de nuevo. Ha apagado el fuego, pero todavía le preocupa la posible pérdida de datos en caso de que falle el servidor de almacenamiento. Preguntas y tu amigo gurú del back-end, Frank, te dice que muchas empresas líderes como Netflix y Airbnb usan Amazon S3 para el almacenamiento. “Amazon Simple Storage Service (Amazon S3) es un servicio de almacenamiento de objetos que proporciona escalabilidad, disponibilidad de datos, seguridad y rendimiento líderes en la industria” [3]. Decide investigar un poco para ver si encaja bien.

Después de mucha lectura, tiene una sólida comprensión del sistema de almacenamiento S3 y decide almacenar sus archivos en S3. Amazon S3 admite la replicación dentro de la región y entre regiones. Una región es un área geográfica donde Amazon Web Services (AWS) tiene centros de datos. Como se muestra en la figura 15-6, los datos se pueden replicar dentro de la misma región (izquierda) y entre regiones (derecha). Para evitar la pérdida de datos y garantizar la disponibilidad, los archivos redundantes se almacenan en varias regiones. Los cubos son como carpetas en un sistema de archivos.

Con sus archivos en S3, finalmente puede dormir en paz sin preocuparse por la pérdida de datos. Para evitar problemas similares en el futuro, decide realizar más investigaciones sobre las áreas que podrían mejorarse. Aquí hay algunas áreas que encontrarás:

• Equilibrador de carga: agregue un equilibrador de carga para distribuir el tráfico de red. Un equilibrador de carga garantiza que el tráfico se distribuya de manera uniforme y, si un servidor web deja de funcionar, redistribuirá el tráfico.

• Servidores web: después de agregar un balanceador de carga, puede agregar o eliminar fácilmente más servidores web en función de la carga de tráfico.

• Base de datos de metadatos: Mueva la base de datos fuera del servidor para evitar un único punto de falla. Al mismo tiempo, configure la replicación y fragmentación de datos para cumplir con los requisitos de disponibilidad y escalabilidad.

• Almacenamiento de archivos: Amazon S3 se utiliza para el almacenamiento de archivos. Para garantizar la disponibilidad y la durabilidad, los archivos se replican en dos regiones geográficas separadas.

Después de aplicar las mejoras anteriores, ha desacoplado con éxito el servidor web, la base de datos de metadatos y el almacenamiento de archivos de un solo servidor. El diseño actualizado se muestra en la Figura 15-7.

conflicto de sincronización

Con un gran sistema de almacenamiento como Google Drive, los conflictos de sincronización ocurren de vez en cuando. Un conflicto ocurre cuando dos usuarios modifican el mismo archivo o carpeta al mismo tiempo. ¿Cómo resolvemos este conflicto? Nuestra política es que la versión procesada primero gana y la versión procesada en último lugar recibe conflictos. La Figura 15-8 muestra un ejemplo de un conflicto de sincronización.

En la Figura 15-8, el Usuario 1 y el Usuario 2 intentaron actualizar el mismo archivo al mismo tiempo, pero nuestro sistema procesó primero el archivo del Usuario 1. La operación de actualización del usuario 1 transcurre sin problemas, pero el usuario 2 encuentra un conflicto de sincronización. ¿Cómo resolvemos el conflicto para el usuario 2? Nuestro sistema presenta dos copias del mismo archivo: la copia local del Usuario 2 y la última versión del servidor (Figura 15-9). El usuario 2 puede elegir fusionar los dos archivos o sobrescribir una versión con la otra.

Mantener los documentos sincronizados es un desafío cuando varios usuarios están editando el mismo documento al mismo tiempo. Los lectores interesados ​​pueden consultar las referencias [4][5].

Diseño de alto nivel

La figura 15-10 muestra nuestro diseño de alto nivel propuesto. Examinemos cada componente del sistema.

Usuario : un usuario utiliza la aplicación a través de un navegador o una aplicación móvil.

Servidor de fragmentos : un servidor de fragmentos carga fragmentos en el almacenamiento en la nube. El almacenamiento en bloque, también conocido como almacenamiento a nivel de bloque, es una tecnología para almacenar archivos de datos en entornos de nube. Un archivo se puede dividir en varios bloques, cada bloque tiene un valor hash único, almacenado en nuestra base de datos de metadatos. Cada bloque se trata como un objeto independiente y se almacena en nuestro sistema de almacenamiento (S3). Para reconstruir un archivo, los fragmentos se concatenan en un orden específico. En cuanto al tamaño de fragmento, nos referimos a Dropbox: establece un tamaño máximo de fragmento de 4 MB [6].

Almacenamiento en la nube : un archivo se divide en partes más pequeñas y se almacena en el almacenamiento en la nube.

Almacenamiento en frío : el almacenamiento en frío es un sistema informático que se utiliza para almacenar datos inactivos, lo que significa que no se ha accedido a los archivos durante un largo período de tiempo.

Equilibrador de carga : un equilibrador de carga distribuye las solicitudes de manera uniforme entre los servidores API.

Servidores API : estos servidores son responsables de casi todo, excepto del proceso de carga. El servidor API se utiliza para la autenticación de usuarios, la gestión de perfiles de usuarios, la actualización de metadatos de archivos, etc.

Base de Datos de Metadatos : Almacena metadatos de usuarios, archivos, bloques, versiones, etc. Tenga en cuenta que los archivos se almacenan en la nube y la base de datos de metadatos solo contiene metadatos.

Almacenamiento en caché de metadatos : algunos metadatos se almacenan en caché para una recuperación rápida.

Servicio de notificación : este es un sistema de editor/suscriptor que permite enviar datos desde un servicio de notificación a los clientes cuando ocurren ciertos eventos. En nuestro caso particular, cuando se agrega/edita/elimina un archivo en otro lugar, el servicio de notificación notifica a los clientes relevantes para que puedan obtener los últimos cambios.

Cola de copia de seguridad fuera de línea : si el cliente está fuera de línea y no puede extraer los últimos cambios del archivo, la cola de copia de seguridad fuera de línea almacena esta información para que los cambios se puedan sincronizar cuando el cliente está en línea.

Hemos discutido el diseño de alto nivel de Google Drive. Algunos de estos componentes son complejos y merecen una mirada más cercana; los discutimos en detalle en nuestra inmersión profunda.

Paso 3 - Diseño de profundidad

En esta sección, veremos más de cerca lo siguiente: servidor de fragmentos, base de datos de metadatos, proceso de carga, proceso de descarga, servicio de notificación, ahorro de espacio de almacenamiento y manejo de fallas.

bloque de servidor

Para archivos grandes que se actualizan con frecuencia, enviar el archivo completo para cada actualización puede consumir mucho ancho de banda. Proponemos dos optimizaciones para minimizar el tráfico de red transmitido:

• Sincronización incremental. Cuando se modifica un archivo, solo se sincronizan los bloques modificados en lugar de sincronizar todo el archivo usando el algoritmo de sincronización [7][8].
• compresión. La compresión de bloques puede reducir significativamente el tamaño de los datos. Por lo tanto, comprimimos los bloques usando un algoritmo de compresión según el tipo de archivo. Por ejemplo, usamos gzip y bzip2 para comprimir archivos de texto. La compresión de imágenes y videos requiere diferentes algoritmos de compresión.

En nuestro sistema, los servidores de fragmentos hacen el trabajo pesado de cargar archivos. Los servidores de fragmentos procesan los archivos de los clientes, los dividen en fragmentos, los comprimen y los cifran. En lugar de cargar el archivo completo en el sistema de almacenamiento, solo se transfieren los fragmentos modificados.

La figura 15-11 muestra cómo funciona el servidor de fragmentos cuando se agregan nuevos archivos.

• Los archivos se cortan en trozos más pequeños.
• Cada bloque se comprime mediante un algoritmo de compresión.
• Por seguridad, cada bloque se cifra antes de enviarse al almacenamiento en la nube.
• Cargue fragmentos en el almacenamiento en la nube.

La figura 15-12 ilustra la sincronización incremental, lo que significa que solo los bloques modificados se transfieren al almacenamiento en la nube. El "Bloque 2" y el "Bloque 5" resaltados representan los bloques modificados. Con la sincronización incremental, solo estos dos fragmentos se cargan en el almacenamiento en la nube.

Los servidores Chunk nos permiten ahorrar tráfico de red al proporcionar sincronización y compresión incrementales.

Requisitos de alta consistencia

Nuestro sistema requiere una fuerte consistencia por defecto. Es inaceptable que diferentes clientes muestren diferentes archivos al mismo tiempo. El sistema debe proporcionar una gran consistencia para la caché de metadatos y la capa de la base de datos.

La caché de memoria adopta el modelo de coherencia eventual de forma predeterminada, lo que significa que diferentes réplicas pueden tener datos diferentes. Para lograr una fuerte consistencia, debemos asegurarnos de lo siguiente:

• La copia en caché es coherente con los datos de la base de datos principal.
• Invalide la memoria caché en las escrituras de la base de datos para asegurarse de que la memoria caché y la base de datos tengan el mismo valor.

Es fácil lograr una fuerte consistencia en una base de datos relacional porque mantiene las propiedades ACID (atomicidad, consistencia, aislamiento, durabilidad) [9]. Sin embargo, las bases de datos NoSQL no admiten las propiedades ACID de forma predeterminada. Las propiedades ACID deben introducirse mediante programación en la lógica de sincronización. En nuestro diseño, elegimos una base de datos relacional porque admite ACID de forma nativa.

base de datos de metadatos

La figura 15-13 muestra el diseño del esquema de la base de datos. Tenga en cuenta que esta es una versión muy simplificada, ya que solo incluye las tablas más importantes y los campos interesantes.

Usuario : la tabla de usuarios contiene información básica sobre el usuario, como nombre de usuario, correo electrónico, foto de perfil, etc.

Dispositivo : la tabla de dispositivos almacena información del dispositivo. Push_id se utiliza para enviar y recibir notificaciones push móviles. Tenga en cuenta que un usuario puede tener varios dispositivos.

Espacio de nombres : un espacio de nombres es el directorio raíz del usuario.

Archivo : la tabla de archivos almacena todo lo relacionado con el archivo más reciente.

File_version : Almacena el historial de versiones del archivo. Las líneas existentes son de solo lectura para preservar la integridad del historial de revisión del archivo.

Block : Almacena todo lo relacionado con los bloques de archivos. Los archivos de cualquier versión se pueden refactorizar concatenando todos los bloques en el orden correcto.

proceso de carga

Hablemos de lo que sucede cuando un cliente carga un archivo. Para comprender mejor este proceso, dibujamos el diagrama de secuencia que se muestra en la figura 15-14.

En la Figura 15-14, se envían dos solicitudes en paralelo: agregar metadatos del archivo y cargar el archivo al almacenamiento en la nube. Ambas solicitudes son del Cliente 1.

• Agregar metadatos de archivos.
  1. El cliente 1 envía una solicitud para agregar metadatos para un nuevo archivo.
  2. Almacene los metadatos de los archivos nuevos en la base de datos de metadatos y cambie el estado de carga del archivo a "pendiente".
  3. Notificación El servicio de notificación está agregando un nuevo archivo.
  4. El servicio de notificación notifica al cliente relevante (Cliente 2) que el archivo se está cargando.
• Sube archivos al almacenamiento en la nube.
  2.1 El cliente 1 carga el contenido del archivo en el servidor de fragmentos.
  2.2 Los servidores de fragmentos cortan los archivos en fragmentos, los comprimen, cifran esos fragmentos y los suben al almacenamiento en la nube.
  2.3 Una vez que se carga el archivo, Cloud Storage activa la devolución de llamada de finalización de la carga. La solicitud se envía al servidor API.
  2.4 Cambie el estado del archivo a "Subido" en la base de datos de metadatos.
  2.5 Notificación El estado del archivo del servicio de notificación ha cambiado a "Cargado".
  2.6 El servicio de notificación notifica al cliente correspondiente (Cliente 2) que el archivo se ha cargado por completo.

Cuando se edita un archivo, el flujo es similar, por lo que no repetiremos la descripción.

proceso de descarga

El proceso de descarga se activa cuando se agregan o editan archivos en otro lugar. ¿Cómo sabe un cliente que otro cliente ha agregado o editado un archivo? Hay dos formas de que el cliente lo sepa:

• Si el cliente A está en línea y otro cliente cambia el archivo, el servicio de notificación le notificará al cliente A que algo ha cambiado, por lo que debe extraer los datos más recientes.

• Si el cliente A se desconecta mientras otro cliente cambia el archivo, los datos se guardarán en la memoria caché. Cuando el cliente fuera de línea vuelve a estar en línea, extraerá los últimos cambios.

Una vez que el cliente sabe que el archivo ha sido modificado, primero solicita los metadatos a través del servidor API y luego descarga los fragmentos para construir el archivo. La figura 15-15 muestra el proceso detallado. Tenga en cuenta que, debido a limitaciones de espacio, en la figura solo se muestran los componentes más importantes.

1. El servicio de notificación le dice al cliente 2 que un archivo en alguna parte ha cambiado.
2. Una vez que el Cliente 2 sabe que hay una nueva actualización disponible, envía una solicitud para obtener los metadatos.
3. El servidor API llama a la base de datos de metadatos para obtener los metadatos modificados.
4. Los metadatos se devuelven al servidor API.
5. El cliente 2 obtiene los metadatos.
6. Una vez que el cliente recibe los metadatos, envía una solicitud al servidor de fragmentos para descargar el fragmento.
7. Los servidores de fragmentos primero descargan fragmentos del almacenamiento en la nube.
8. Cloud Storage devuelve fragmentos a servidores de fragmentos.
9. El Cliente 2 descarga todos los bloques nuevos para reconstruir el archivo.

servicio de notificaciones

Para mantener la consistencia del archivo, cualquier cambio de archivo realizado localmente debe notificarse a otros clientes para reducir los conflictos. El servicio de notificación fue construido para este propósito. En un alto nivel, los servicios de notificación permiten que se transmitan datos a los clientes cuando ocurren eventos. Aquí hay algunas opciones:

• sondeo largo. Dropbox usa sondeos largos [10].
• WebSocket. WebSocket proporciona una conexión persistente entre el cliente y el servidor. La comunicación es bidireccional.

Aunque ambas opciones funcionan bien, elegimos el sondeo largo por dos razones:

• La comunicación con los servicios de notificación no es bidireccional. El servidor envía información sobre los cambios en los archivos al cliente, pero no al revés.
• WebSocket es adecuado para la comunicación bidireccional en tiempo real, como las aplicaciones de chat. Con Google Drive, las notificaciones son poco frecuentes y no hay un gran flujo de datos.

Con el sondeo largo, cada cliente establece una conexión de sondeo largo con el servicio de notificación. Si se detecta un cambio en el archivo, el cliente cerrará la conexión de sondeo largo. Cerrar la conexión significa que el cliente debe conectarse al servidor de metadatos para descargar los últimos cambios. Inmediatamente después de que se recibe una respuesta o se agota el tiempo de conexión, el cliente envía una nueva solicitud para mantener abierta la conexión.

ahorrar espacio de almacenamiento

Para respaldar el historial de versiones de archivos y garantizar la confiabilidad, se almacenan varias versiones del mismo archivo en varios centros de datos. Si realiza copias de seguridad de las revisiones de todos los archivos con frecuencia, el espacio de almacenamiento puede llenarse rápidamente. Proponemos tres técnicas para reducir los costes de almacenamiento:

• Deduplicación de bloques de datos. Eliminar bloques redundantes a nivel de cuenta es una manera fácil de ahorrar espacio. Dos bloques son idénticos si tienen el mismo hash.
• Adopte una estrategia inteligente de copia de seguridad de datos. Se pueden aplicar dos estrategias de optimización:
  • Establecer límites: Podemos establecer límites en el número de versiones almacenadas. Si se alcanza el límite, la versión más antigua será reemplazada por una versión más nueva.
  • Guarde solo versiones valiosas: algunos archivos pueden editarse con frecuencia. Por ejemplo, guardar cada versión editada de un documento muy modificado puede significar que el archivo se guarde más de 1000 veces en un corto período de tiempo. Para evitar copias innecesarias, podemos limitar el número de versiones guardadas. Le damos más peso a las versiones recientes. La experimentación puede ayudar a encontrar el número óptimo de versiones guardadas.
• Mueva los datos que se usan con poca frecuencia al almacenamiento en frío. Los datos fríos son datos que no se han activado durante meses o años. El almacenamiento en frío como Amazon S3 Glacier [11] es mucho más económico que S3.

Solución de problemas

Las fallas pueden ocurrir en sistemas a gran escala y debemos emplear estrategias de diseño para tratarlas. Su entrevistador podría estar interesado en cómo maneja las siguientes fallas del sistema:

• Falla del balanceador de carga: si un balanceador de carga falla, el balanceador de carga en espera se activa y se hace cargo del tráfico. Los balanceadores de carga generalmente se monitorean mediante latidos, que son señales periódicas enviadas entre balanceadores de carga. Si un balanceador de carga no envía un latido durante un período de tiempo, se considera defectuoso.

• Fallo del servidor de fragmentos: si un servidor de fragmentos falla, otros servidores asumen las tareas pendientes o pendientes.

• Error de almacenamiento en la nube: los depósitos de S3 se replican varias veces en diferentes regiones. Si los archivos no están disponibles en una región, se pueden obtener de otras regiones.

• Fallo del servidor API: es un servicio sin estado. Si un servidor API falla, el equilibrador de carga redirige el tráfico a otros servidores API.

• Error de caché de metadatos: los servidores de caché de metadatos se replican varias veces. Si un nodo deja de funcionar, aún puede acceder a otros nodos para obtener datos. Iniciaremos un nuevo servidor de caché para reemplazar el nodo fallido.

• Fallo en la base de datos de metadatos.

  • Falla del nodo maestro: si el nodo maestro falla, promueva uno de los nodos esclavos como el nuevo nodo maestro e inicie un nuevo nodo esclavo.
  • Falla del nodo esclavo: si un nodo esclavo falla, puede usar otro nodo esclavo para operaciones de lectura e iniciar otro servidor de base de datos para reemplazar el nodo fallido.

• Fallo del servicio de notificación: cada usuario en línea mantiene una conexión de sondeo largo con el servidor de notificación. Por lo tanto, cada servidor de notificaciones está conectado con muchos usuarios. Según la presentación de Dropbox en 2012 [6], cada máquina tiene más de 1 millón de conexiones abiertas. Si el servidor falla, se pierden todas las conexiones de sondeo largo, por lo que el cliente debe volver a conectarse a otro servidor. Aunque un servidor puede mantener muchas conexiones abiertas, no puede volver a conectar todas las conexiones perdidas a la vez. Restablecer conexiones con todos los clientes perdidos es un proceso relativamente lento.

• Fallo en la cola de copia de seguridad sin conexión: la cola se replica varias veces. Si falla una cola, es posible que los consumidores de la cola deban volver a suscribirse a la cola de respaldo.

Paso 4 - Resumen

En este capítulo, proponemos un diseño de sistema para admitir Google Drive. La consistencia fuerte, el bajo ancho de banda de la red y la sincronización rápida hacen de este un diseño interesante. Nuestro diseño consta de dos procesos: la gestión de metadatos de archivos y la sincronización de archivos. El servicio de notificaciones es otra parte importante del sistema. Utiliza sondeos largos para mantener a los clientes sincronizados con los cambios de archivos.

Como cualquier pregunta de entrevista de diseño de sistema, no hay soluciones perfectas. Cada empresa tiene sus limitaciones únicas y debe diseñar un sistema que se ajuste a esas limitaciones. Es importante comprender las ventajas y desventajas de sus opciones de diseño y tecnología. Si tiene unos minutos más, puede hablar sobre diferentes opciones de diseño.

Por ejemplo, podemos cargar archivos al almacenamiento en la nube directamente desde el cliente en lugar de pasar por un servidor de fragmentos. La ventaja de este método es que hace que la carga de archivos sea más rápida porque los archivos solo necesitan transferirse una vez al almacenamiento en la nube. En nuestro diseño, los archivos se transfieren primero a servidores fragmentados y luego al almacenamiento en la nube. Sin embargo, el nuevo enfoque tiene algunas desventajas:

• En primer lugar, se debe implementar la misma lógica de fragmentación, compresión y cifrado en diferentes plataformas (iOS, Android, Web). Esto es propenso a errores y requiere mucho esfuerzo de ingeniería. En nuestro diseño, toda esta lógica se implementa en un lugar centralizado: el servidor de fragmentos.
• En segundo lugar, la implementación de la lógica de cifrado en el lado del cliente no es lo ideal, ya que el lado del cliente se puede piratear o manipular fácilmente.

Otro desarrollo interesante del sistema es mover la lógica en línea/fuera de línea a un servicio separado. Lo llamamos el Servicio de Presencia. Al sacar el servicio de presencia del servidor de notificaciones, otros servicios pueden integrar fácilmente la funcionalidad en línea/fuera de línea.

¡Felicitaciones por llegar tan lejos! Dése una charla de ánimo ahora. ¡bien hecho!

Referencias

[1] Google Drive: https://www.google.com/drive/

[2] Subir datos de archivo: https://developers.google.com/drive/api/v2/manage-uploads

[3] Amazon S3: https://aws.amazon.com/s3

[4] Sincronización diferencial: https://neil.fraser.name/writing/sync/

[5] Explicación de YouTube de sincronización diferencial: https://www.youtube.com/watch?v=S2Hp_1jqpY8

[6] Cómo extender Dropbox: https://youtu.be/PE4gwstWhmc

[7] Tridgell, A. y Mackerras, P. (1996). El algoritmo rsync.

[8] Librería. (Dakota del Norte). Recuperado el 18 de abril de 2015, de https://github.com/librsync/librsync

[9] ÁCIDO: https://en.wikipedia.org/wiki/ACID

[10] Libro blanco de seguridad de Dropbox: https://www.dropbox.com/static/business/resources/Security_Whitepaper.pdf

[11] Glaciar de Amazon S3: https://aws.amazon.com/glacier/faqs/

Hola, soy Shisan, un conductor veterano que se ha desarrollado durante 7 años y una empresa extranjera durante 5 años en Internet durante 2 años. Puedo vencer a Ah San y Lao Mei, y también me han arruinado los comentarios de relaciones públicas. A lo largo de los años, trabajé a tiempo parcial, comencé un negocio, me hice cargo del trabajo privado y mezclé el trabajo. Ganó dinero y perdió dinero. En el camino, mi sentimiento más profundo es que no importa lo que aprendas, debes seguir aprendiendo. ¡Mientras puedas perseverar, es fácil lograr adelantar en las curvas! Así que no me preguntes si es demasiado tarde para hacer lo que hago ahora. Si aún no tiene una dirección, puede seguirme [cuenta pública: Más IA (power_ai)], donde a menudo compartiré información de vanguardia y conocimientos de programación para ayudarlo a acumular capital para tomar curvas y adelantar.