No discutiremos si se trata de un entorno PHP, JSP o .NET aquí. Miramos el problema desde la perspectiva de la arquitectura. Implementar el lenguaje no es un problema. La ventaja del lenguaje radica en la implementación en lugar de lo bueno o malo. No importa qué idioma elija, la arquitectura debe enfrentar.
1. Procesamiento de datos masivos
Como todos sabemos, para algunos sitios relativamente pequeños, la cantidad de datos no es muy grande. Seleccionar y actualizar puede resolver los problemas que enfrentamos. La carga en sí no es muy grande, y como máximo se pueden hacer algunos índices. Para sitios web grandes, la cantidad de datos por día puede ser de millones. Si una relación mal diseñada de muchos a muchos no es problemática en la etapa inicial, pero a medida que el usuario crece, la cantidad de datos crecerá geométricamente. En este momento, cuando elegimos y actualizamos una tabla (sin mencionar la consulta conjunta de múltiples tablas), el costo es muy alto.
2. Procesamiento de concurrencia de datos
En algún momento, el 2.0 CTO tiene una espada Shangfang, que es caché. Para el caché, también es un gran problema cuando se realizan una alta concurrencia y un alto procesamiento. En toda la aplicación, el caché se comparte a nivel mundial. Sin embargo, cuando hacemos modificaciones, si dos o más solicitudes requieren actualizaciones del caché al mismo tiempo, la aplicación morirá directamente. En este momento, se necesita una buena estrategia de procesamiento de concurrencias de datos y una estrategia de almacenamiento en caché.
Además, es el problema de punto muerto de la base de datos. Tal vez no sentimos que generalmente no consideramos que la probabilidad de que ocurran un punto muerto en alta concurrencia es muy alta, y el almacenamiento en caché de disco es un gran problema.
3. Problemas de almacenamiento de archivos
Para algunos sitios que admiten la carga de archivos 2.0, cuando tenemos suerte de que la capacidad del disco duro se haga más grande y más grande, deberíamos considerar más cómo los archivos deben almacenarse e indexar de manera efectiva. Una solución común es almacenar archivos por fecha y tipo. Sin embargo, cuando el volumen del archivo es masivo, si un disco duro almacena 500 g de archivos triviales, entonces el IO del disco es un gran problema durante el mantenimiento y el uso. Incluso si su ancho de banda es suficiente, su disco puede no responder. Si la carga está involucrada en este momento, el disco terminará fácilmente.
Quizás el uso de RAID y servidores de almacenamiento dedicados puede resolver el problema actual, pero hay otro problema que son los problemas de acceso en varios lugares. ¿Quizás nuestro servidor está en Beijing, tal vez en la velocidad de acceso de Yunnan o Xinteng? Si se distribuye, ¿cómo se debe planificar nuestro índice de archivos y arquitectura?
Entonces tenemos que admitir que el almacenamiento de archivos es un problema muy difícil
4. Procesamiento de relaciones de datos
Podemos planificar fácilmente una base de datos que se ajuste a la tercera normal, que está llena de relaciones de muchas a muchos y también puede reemplazar la columna de la sangría con GUID. Sin embargo, en la era de 2.0 donde se inundan las relaciones de muchas a muchos, la tercera normal es la primera que debería ser abandonada. La consulta de juntas múltiples debe minimizarse de manera efectiva.
5. Problema de indexación de datos
Como todos sabemos, la indexación es la solución más económica y más fácil para mejorar las consultas de eficiencia de la base de datos. Sin embargo, en el caso de una alta actualización, el costo de actualización y eliminación será alto e impensable. El autor encontró una situación en la que tarda 10 minutos en completarse al actualizar un índice enfocado, por lo que para el sitio, estos son básicamente insoportables.
La indexación y la actualización son un par de enemigos naturales. Las preguntas A, D y E son los problemas que debemos considerar al hacer arquitectura, y también pueden ser los problemas que toman más tiempo.
6. Procesamiento distribuido
Para los sitios web de 2.0, debido a su alta interactividad, el efecto logrado por CDN es básicamente 0, y el contenido se actualiza en tiempo real, que es nuestro procesamiento regular. Para garantizar la velocidad de acceso en varios lugares, necesitamos enfrentar un gran problema, es decir, cómo realizar efectivamente la sincronización de datos y actualizar y realizar la comunicación en tiempo real de los servidores en varios lugares es un problema que debe considerarse.
7. Análisis de los pros y los contras de AJAX
El éxito es AJAX, el fracaso es Ajax, Ajax se ha convertido en la tendencia principal, y de repente descubrí que Post y se basa en XMLHTTP es muy fácil. El cliente obtiene o publica los datos en el servidor, y el servidor regresa después de recibir la solicitud de datos. Esta es una solicitud AJAX muy normal. Sin embargo, al procesar AJAX, si usamos una herramienta de captura de paquetes, el retorno y el procesamiento de datos son claros de un vistazo. Para algunas solicitudes de AJAX con alto volumen computacional, podemos construir un contratista, que puede matar fácilmente a un servidor web.
8. Análisis de seguridad de datos
Para el protocolo HTTP, los paquetes de datos se transmiten en texto plano. Tal vez podamos decir que podemos usar el cifrado, pero para el problema G, el proceso de cifrado puede ser texto plano (por ejemplo, QQ que sabemos que puede juzgar fácilmente su cifrado y escribir efectivamente un método de cifrado y descifrado como este). Cuando el tráfico de su sitio no es muy grande, nadie se preocupará por usted, pero cuando surja su tráfico, los llamados complementos y el llamado envío de masas seguirán uno tras otro (las pistas se pueden ver desde el envío de masas al comienzo de QQ). Quizás podamos decir mucho que podemos usar juicios de nivel superior o incluso HTTP para lograr esto. Tenga en cuenta que cuando realice este procesamiento, pagará muchos costos de base de datos, IO y CPU. Para algunas transmisiones masivas, es básicamente imposible. El autor ya puede realizar una publicación masiva para el espacio de Baidu y el espacio QQ. No es difícil para todos probarlo.
9. Problemas de sincronización de datos y procesamiento de clúster
Cuando uno de nuestros servidores de bases de datos está abrumado, necesitamos hacer cargas y grupos basados en bases de datos. Este puede ser el problema más problemático. Los datos se basan en la transmisión de red. El retraso de los datos es un problema terrible y un problema inevitable. De esta manera, debemos usar otros medios para garantizar una interacción efectiva en unos pocos segundos o más de este retraso. Por ejemplo, hash de datos, segmentación, procesamiento de contenido y otros problemas.
10. Canales de intercambio de datos y tendencias de OpenApi
Openapi se ha convertido en una tendencia inevitable, desde Google, Facebook, Myspace hasta campus en casa, se está considerando este problema. Puede retener de manera más efectiva a los usuarios y estimular más intereses y permitir que más personas lo ayuden a hacer el desarrollo más efectivo. En este momento, para una plataforma efectiva para compartir datos, la plataforma de Abierto de Datos se convierte en una forma indispensable. Asegurar la seguridad y el rendimiento de los datos con interfaces abiertas es otro problema que debemos considerar seriamente.