Soluciones tecnológicas de atención al cliente online
1. Encuesta
Esta es una solución relativamente antigua y simple, es decir, cuando el servicio al cliente en línea está chateando, aJax obtiene datos periódicamente en segundo plano. Se recibe el mensaje enviado, el mensaje se mostrará en el cuadro de chat.
La desventaja de esta tecnología es que la actualización en segundo plano es demasiado frecuente y muchas actualizaciones no devuelven datos, lo que resulta en una disminución del rendimiento.
2. Conexión larga
Esta tecnología se llama "sondeo largo". Se basa en la tecnología de sondeo, pero se ha mejorado. El cliente inicia una solicitud al servidor. El servidor no regresará directamente, pero bloqueará la solicitud y regresará hasta que el servidor lea el mensaje. En este momento, el cliente llama a la función de devolución de llamada para mostrar el mensaje leído.
El sistema de atención al cliente online aquí comentado se implementará utilizando esta tecnología.
Figura 2. Modelo de inserción de servidor basado en sondeo largo
Mensaje
Esta solución utiliza un subprograma como cliente, que utiliza TCP/IP o UDP sin conexión o incluso se utilizan protocolos de multidifusión para establecer comunicación con el servidor de claves intermedias del mensaje, y luego el servidor envía el mensaje al cliente. Puede elegir directamente entre productos de mensajería como iBus de SoftWired, MQSeries de IBM y WebLogic Event de BEA, o puede utilizar software de mensajería personalizado basado en sockets.
Tecnología Comet Commet es una solución "server push" que utiliza conexiones HTTP largas y no requiere que el navegador instale complementos. Tiene dos soluciones: método de sondeo largo basado en aJax; método de transmisión basado en iframe y htmlfile. Aquí, solo nos centramos en el método de sondeo largo basado en aJax.
Pushlet es un marco Comet de código abierto, que tiene mucho que aprender en términos de diseño. Puede usarse para desarrollar un sistema de servicio al cliente en línea que no sea a gran escala. En cuanto a los sistemas comerciales de atención al cliente en línea a gran escala, creo que todavía no son competentes.
Equilibrio de carga (implementación distribuida) Un sistema comercial formal de servicio al cliente en línea no se puede implementar en un solo servidor WEB. De esta manera, será difícil expandir el rendimiento y la capacidad, por lo que se debe permitir la implementación distribuida. , lograr acceso distribuido a través de equipos (o software) de equilibrio de carga.
Si se adopta la implementación distribuida, entonces implica la cuestión de dónde se almacenan los datos del chat. ¿Está almacenado en el servidor web o en la base de datos? Si es un servidor web único, debe almacenarse en el servidor web. El proceso es aproximadamente el siguiente:
1. y también guarda la base de datos).
2. La conexión larga correspondiente al servicio de atención al cliente obtiene los datos en el servidor web y luego los muestra en la página de servicio al cliente.
3. El servicio de atención al cliente responde al mensaje del chat y el sistema guarda los datos en el servidor web (también guarda la base de datos).
4. La conexión larga donde se encuentra el usuario obtiene los datos en el servidor web, y luego los muestra y procesa en la página del usuario.
Dado que obtener datos del servidor web es más eficiente que obtener datos de la base de datos, la lógica anterior es razonable. Sin embargo, en un entorno de implementación distribuida, hay varios servidores web, así que inicie en qué servidor debe hacerlo. ¿Se guardan los mensajes de chat? ¿O todos los servidores se guardan una vez? En un entorno distribuido, existen algunas tecnologías de sincronización de caché como JBossCache, pero para los sistemas de chat en línea, los requisitos en tiempo real son muy altos.
Otro, según consideraciones de seguridad, generalmente necesita colocar las funciones a las que acceden los usuarios en un clúster de servidores web y las funciones a las que accede el servicio al cliente en otro clúster de servidores web. aislarse para evitar ataques de piratas informáticos.
Esto plantea otra pregunta. Si el mensaje enviado por el usuario se coloca en el servidor web del usuario, ¿qué pasa si el servicio de atención al cliente obtiene el mensaje? De la misma forma, ¿qué pasa si el servidor web del usuario obtiene el mensaje correspondiente del servidor web de servicio al cliente?
¿Qué tal si lo ponemos en una base de datos? Coloque todos los registros de chat en la base de datos y tanto los usuarios como el servicio de atención al cliente obtendrán información del chat de la base de datos. En este caso, la carga en la base de datos será muy grande a medida que el número de usuarios continúe aumentando, la carga en la base de datos será cada vez mayor y, bajo usuarios grandes, el almacenamiento será muy frecuente. en la base de datos. Sería imprudente. También hay una consideración de seguridad. Generalmente, las funciones del usuario no se acceden directamente a la base de datos, sino que generalmente se transfieren a través de un servidor intermedio. Si la información del chat se obtiene de la base de datos, la eficiencia será aún menor.
Entonces, ¿pueden las dos partes establecer una conexión directamente y enviar mensajes en tiempo real como QQ? De hecho, esta es una tecnología relativamente antigua, que generalmente utiliza Socket o UDP para lograr la comunicación entre las dos partes. Las desventajas de este mecanismo son que el cliente puede necesitar utilizar un complemento de subprograma o un complemento ActiveX, lo que consume mucho rendimiento durante la comunicación. El punto más importante es que estas tecnologías se ven muy afectadas por la red. se puede utilizar normalmente en un entorno pero no en otro, es posible que no funcione correctamente. Por lo tanto, este artículo considera la implementación de un método de sondeo largo de Jax.
Aquí, sugiero que los datos del chat de servicio al cliente se lean desde la base de datos y los datos del chat del usuario se lean desde el servidor web. Esto se debe a que los datos de servicio al cliente son mucho menores que los de los usuarios. Leer los datos del chat directamente desde la base de datos tiene menos impacto en el rendimiento de la base de datos. Sin embargo, dado que la cantidad de usuarios es enorme, leerlos directamente desde la base de datos no puede cumplir con los requisitos. requisitos.
Entonces, ¿el servicio de atención al cliente escribe los datos de respuesta en el servidor web del servicio de atención al cliente o en el servidor web del usuario? Mi sugerencia es escribir en el servidor web del usuario, porque la cantidad de datos del usuario es muy grande. El rendimiento de los usuarios que obtienen datos del servidor web del usuario es mucho mayor que el de obtener datos del servidor web del servicio al cliente. Cada vez que el servicio al cliente envía un mensaje de chat, escribe datos en el servidor web del usuario. Aunque la eficiencia es baja, no afecta el rendimiento porque la cantidad de datos del servicio al cliente es pequeña.
Además, en una implementación distribuida, ¿se deben recordar los datos de todos los servidores web o de un servidor web específico? Sugiero escribir en un servidor web específico para evitar tener que escribir datos en todos los servidores web cada vez que el servicio al cliente envía un mensaje de chat. Esto afectará el rendimiento, pero a medida que la cantidad de servidores web continúa aumentando, el rendimiento disminuirá.
Entonces, ¿en qué servidor web específico escribe datos el servicio de atención al cliente? ¿Cómo sabe el usuario de qué servidor web específico obtener datos? En este caso, cuando el usuario inicia sesión y el servidor de equilibrio de carga lo asigna a un servidor específico, podemos registrar la IP de este servidor específico, y el servicio al cliente puede enviar mensajes a esta máquina, y el usuario también puede iniciar sesión desde El IP ha obtenido datos.