design patterns - software - Patrón de diseño: sistema de notificación
patrones de diseño pdf (4)
Estoy trabajando en un sitio web que utilizará las características de las redes sociales (como facebook, por ejemplo).
Me gustaría implementar un sistema de notificación que muestre cosas como "X te agregó como amigo", "Te invito a la fiesta", "Z ha tomado el último examen" ... y no sé cómo hacerlo .
Me pregunto cuál es la mejor solución:
- Solución 1, también conocida como "registro".
Una tabla dedicada "notificación". Agrego filas en esta tabla cada vez que surge algo similar a una notificación (agregar amigo, responder preguntas, etc.). La tabla "notificación" tiene campos que contienen información diferente, de acuerdo con el tipo de notificación que se agrega a la tabla.
Bueno : fácil de codificar, separación entre la función de notificación y las características "normales", no demasiado consumo de recursos cuando necesito leer la tabla.
Malo : la tabla de notificaciones crecerá probablemente muy grande (creo que añadiré 10k filas / día en la tabla), información "duplicada": las informaciones en la tabla de notificaciones se pueden encontrar en todas las demás tablas usando la comparación fecha / lista / lo que sea.
- Solución 2, también conocida como "mira en todas partes".
Cada vez que necesito mostrar la lista de notificaciones o mostrar cuántas notificaciones nuevas hay, miro toda la tabla en cuestión, comparo la fecha / etc para saber si sucedió algo nuevo desde la última vez que el usuario marcó la notificación.
Bueno : no es una tabla demasiado grande en comparación con la solución 1, no hay "redundancia" de información.
Malo : tengo miedo debido al número de usuarios (~ 1k +), hace que el servidor explote porque consume recursos / tiempo, es un poco difícil de codificar / mantener.
¿Puede decirme qué piensa mejor y por qué, o tiene una solución que no imaginé?
Gracias =)
Editar: digamos que uso un diseño de base de datos realmente básico: los usuarios tienen amigos, pueden hacer cuestionarios. 1 tabla para lista de usuarios, lista de preguntas, 1 pregunta de tabla <-> relación de usuario, 1 usuario de tabla <-> amistad. Cada vez que un usuario visita su propio perfil, puede ver lo que sucedió: nueva pregunta <-> relación del usuario, nuevo usuario <-> relación del usuario, etc. ¿Cómo diseñaría una notificación como esa?
Cree una cola de sistema, cada mensaje agregado a esta cola tiene una lista de "consumidores" y el contenido. La bomba de mensajes principal procesa cada mensaje y envía el mensaje a todos los consumidores.
Digamos que 2 personas se hacen amigos. Agrega un mensaje a la cola del sistema principal que A es amigo de B y los consumidores son ambos A y B. Cuando su mensaje "bomba" (procesador) ve este mensaje, lo agrega a la cola de A y la cola de B. Entonces ahora el usuario A y el usuario B tienen un nuevo mensaje de que son amigos. A su vez, cada usuario tiene un procesador de mensajes, por lo que cuando ve un mensaje llamado "Soy amigo de [alguien]" procesa esto como agregar una nueva entrada al "muro" visible para los amigos de A que "A es amigo de B ", etc.
Esto es demasiado simplista, pero con suerte muestra cómo las colas de mensajes se pueden usar para esto (se usa un sistema muy similar al marco de la interfaz de usuario de Windows), por lo que ya existe un ejemplo y hay muchos patrones de cola de mensajes sincronizados que puede usar.
El resto depende de ti para diseñar.
En la actualidad, los servidores como Amazon están proporcionando un marco de notificación. Entonces, si usa la notificación de Amazon, puede que no tenga que preocuparse por las estructuras de la tabla.
Espero que esto ayude a otros a buscar soluciones similares.
Realmente esto cae bajo el ¿cómo diseño un automóvil? tipo pregunta categoría ...
La implementación depende del diseño, dónde irá en el futuro y el entorno en el que implementará. Puede elegir una implementación de Twitter, un sistema de XML respaldado por SAN, bases de datos relacionales, Hadoop y toneladas de otros.
Un buen conocimiento de las tecnologías web, la experiencia, la prueba y el error es la única manera en que puede diseñar cualquier función con la certeza de que lo está haciendo de la manera correcta (ish).
¿Cuáles son sus necesidades de rendimiento? Niveles de tráfico? ¿Requisitos de usuario? ¿Desea distribuir más tarde (a través de webhooks, por ejemplo?).
Tu pregunta debe ser más específica.
Personalmente , tengo una tabla de "tipos de notificación" que actúa como una enumeración ... y luego una tabla de notificaciones de usuario <> que maneja la relación entre la notificación y el usuario.
Con una buena codificación, puede empalmar la tabla de notificación <> de usuario en muchos servidores e ingresar el ID de usuario o similar ... y replicar la tabla de tipos en cada uno de esos nodos para la memoria caché / referencia local. Algo como eso.
Sugiero usar notificaciones simples. Sin tipo de notificación u otra cosa.
Notificaciones
-carné de identidad
-mensaje
-href (Enlace para ir cuando el usuario hace clic en la notificación)
-receptorUsuario
-fecha
Ejemplo de uso: John (34) le gustó una foto de María (47). (Estamos enviando notificaciones a Mary)
INSERT INTO Notifications(message,href,receiverUser, date) VALUES (''John liked your photo'', ''link of the photo'', 47, 01.11.2014)