Nous ne discuterons pas s'il s'agit d'un environnement PHP, JSP ou .NET ici. Nous regardons le problème du point de vue de l'architecture. La mise en œuvre du langage n'est pas un problème. L'avantage du langage réside dans la mise en œuvre plutôt que sur le bien ou le mauvais. Quelle que soit la langue que vous choisissez, l'architecture doit être confrontée.
1. Traitement de données massives
Comme nous le savons tous, pour certains sites relativement petits, la quantité de données n'est pas très importante. Sélectionner et mettre à jour peut résoudre les problèmes auxquels nous sommes confrontés. La charge elle-même n'est pas très grande et au plus quelques indices peuvent être effectués. Pour les grands sites Web, la quantité de données par jour peut être des millions. Si une relation multiple à plusieurs mal conçue n'est pas problématique au début, mais à mesure que l'utilisateur se développe, la quantité de données augmentera géométriquement. À l'heure actuelle, lorsque nous choisissons et mettons à jour un tableau (sans parler de la requête conjointe de plusieurs tables), le coût est très élevé.
2. Traitement de la concurrence des données
À un moment donné, le 2,0 CTO a une épée Shangfang, qui est du cache. Pour le cache, c'est également un gros problème lorsque une concurrence élevée et un traitement élevé sont effectués. Dans toute l'application, le cache est partagé à l'échelle mondiale. Cependant, lorsque nous apportons des modifications, si deux demandes ou plus nécessitent des mises à jour du cache en même temps, l'application mourra directement. Pour le moment, une bonne stratégie de traitement de concurrence de données et une stratégie de mise en cache sont nécessaires.
De plus, il s'agit du problème de blocage de la base de données. Peut-être que nous ne pensons généralement pas que la probabilité de blocages qui se produisent dans une concurrence élevée est très élevée et que la mise en cache du disque est un gros problème.
3. Problèmes de stockage de fichiers
Pour certains sites qui prennent en charge les téléchargements de fichiers 2.0, lorsque nous avons de la chance que la capacité du disque dur devienne de plus en plus grande, nous devons considérer davantage comment les fichiers doivent être stockés et indexés efficacement. Une solution courante consiste à stocker des fichiers par date et type. Cependant, lorsque le volume de fichiers est massif, si un disque dur stocke 500 g de fichiers triviaux, l'EI du disque est un énorme problème pendant la maintenance et l'utilisation. Même si votre bande passante est suffisante, votre disque peut ne pas répondre. Si le téléchargement est impliqué pour le moment, le disque sera facilement terminé.
Peut-être que l'utilisation de serveurs de stockage RAID et dédiés peut résoudre le problème actuel, mais il y a un autre problème qui est d'accès à des problèmes à divers endroits. Peut-être que notre serveur est à Pékin, peut-être à la vitesse d'accès du Yunnan ou de Xinteng? S'il est distribué, comment prévoit notre index et notre architecture de fichiers.
Nous devons donc admettre que le stockage de fichiers est un problème très difficile
4. Traitement des relations de données
Nous pouvons facilement planifier une base de données conforme à la troisième normale, qui est pleine de relations multiples à plusieurs et peut également remplacer la colonne Intentify par GUID. Cependant, à l'ère 2.0 où les relations multiples à plusieurs sont inondées, la troisième normale est la première qui devrait être abandonnée. La requête conjointe multi-table doit être efficacement minimisée.
5. Problème d'indexation des données
Comme nous le savons tous, l'indexation est la solution la plus bon marché et la plus simple pour améliorer les requêtes d'efficacité de la base de données. Cependant, dans le cas d'une mise à jour élevée, le coût de la mise à jour et de la suppression sera élevé et impensable. L'auteur a rencontré une situation où il faut 10 minutes pour terminer lors de la mise à jour d'un indice focalisé, donc pour le site, ceux-ci sont essentiellement insupportables.
L'indexation et la mise à jour sont une paire d'ennemis naturels. Les questions A, D et E sont les problèmes que nous devons prendre en compte lors de l'architecture, et peuvent également être les problèmes qui prennent le plus de temps.
6. Traitement distribué
Pour les sites Web 2.0, en raison de leur grande interactivité, l'effet obtenu par CDN est essentiellement 0, et le contenu est mis à jour en temps réel, ce qui est notre traitement régulier. Afin d'assurer la vitesse d'accès à divers endroits, nous devons faire face à un énorme problème, c'est-à-dire comment réaliser efficacement la synchronisation des données et mettre à jour et réaliser la communication en temps réel des serveurs à divers endroits est un problème qui doit être pris en compte.
7. Analyse des avantages et des inconvénients de l'Ajax
Le succès est Ajax, l'échec est Ajax, Ajax est devenu la tendance traditionnelle, et j'ai soudainement découvert que le post et la base basés sur XMLHTTP sont si faciles. Le client obtient ou publie les données sur le serveur et le serveur revient après avoir reçu la demande de données. Il s'agit d'une demande AJAX très normale. Cependant, lors du traitement de l'AJAX, si nous utilisons un outil de capture de paquets, le retour et le traitement des données sont clairs en un coup d'œil. Pour certaines demandes AJAX avec un volume de calcul élevé, nous pouvons construire un entrepreneur, qui peut facilement tuer un serveur Web.
8. Analyse de la sécurité des données
Pour le protocole HTTP, les paquets de données sont transmis en texte brut. Peut-être pouvons-nous dire que nous pouvons utiliser le cryptage, mais pour le problème G, le processus de chiffrement peut être un texte brut (par exemple, QQ que nous savons peut facilement juger de son chiffrement et rédiger efficacement une méthode de cryptage et de décryptage comme elle). Lorsque le trafic de votre site n'est pas très important, personne ne se souciera de vous, mais lorsque votre trafic apparaît, les soi-disant plug-ins et l'envoi de masse suivront les uns après les autres (les indices peuvent être vus de l'envoi de masse au début de QQ). Peut-être pouvons-nous dire beaucoup que nous pouvons utiliser des jugements de niveau supérieur ou même des HTTP pour y parvenir. Notez que lorsque vous effectuez ces traitements, vous paierez beaucoup de coûts de base de données, d'IO et de CPU. Pour certaines émissions de masse, c'est fondamentalement impossible. L'auteur peut déjà réaliser l'édition de masse pour l'espace Baidu et l'espace QQ. Il n'est pas difficile pour tout le monde de l'essayer.
9. Problèmes de synchronisation des données et de traitement des grappes
Lorsque l'un de nos serveurs de données est dépassé, nous devons faire des charges et des clusters basés sur des bases de données. C'est peut-être le problème le plus gênant. Les données sont basées sur la transmission du réseau. Le retard de données est un problème terrible et un problème inévitable. De cette façon, nous devons utiliser d'autres moyens pour assurer une interaction efficace en quelques secondes ou plus de ce retard. Par exemple, le hachage des données, la segmentation, le traitement du contenu et d'autres problèmes.
10. canaux de partage des données et tendances OpenAPI
OpenAPI est devenu une tendance inévitable, de Google, Facebook, MySpace aux campus à la maison, ce problème est en cours. Il peut conserver plus efficacement les utilisateurs et stimuler plus d'intérêts et permettre à plus de personnes de vous aider à faire le développement le plus efficace. Pour le moment, pour une plate-forme de partage de données efficace, la plate-forme de données ouverte devient une manière indispensable. Assurer la sécurité et les performances des données avec des interfaces ouvertes est un autre problème que nous devons sérieusement considérer.