java - 高并发的后台如何处理数据库的更新与插入操作

Question

今天忽然想到一个问题对于高并发条件下，后台对数据的更新和实例化是怎么进行的？ 1、直接插入数据库，然后更新缓存？这样这个更新操作将会有IO阻塞风险吧、 2、直接更新缓存，然后使用消息队列更新数据库？只能...

天蓬老师 · Answer

Piscine intermédiaire, cache, redis, c'est ce que ça veut dire de toute façon
Si la piscine est bloquée, juste + unité de traitement ; c'est comme un petit homme maigre avec une petite bouche de cerise, mangeant dans un pot, peu importe la taille du bol, trouvez dix gars minces avec la bouche cerise ou un gros gars avec la bouche ouverte

;

Mise à jour :

如果真的高并发的话，首先先确定高并发是持久还是偶尔暴涨的；
1，如果暴涨的话，使用二级池还是可以缓解的；具体实现：应用=>redis=>数据库三层方式解决；一般推荐redis与数据库可或两台处理；应用一台；加一台分发+逆向代理或动静态分流；实现应用+数据的双层池；1*Reverse&HTTP+1*Redis+1*DataBase

2，如果持久高并发，应结合您应用拓扑结构上，考虑使用集群从逻辑、应用层、分层降低单点的应用压力；具体实现：
    1，同大1，特点简单；1*Reverse+n*HTTP+n/y*Redis+N/x*DataBase+1*MainDataBase；
    2，应用模块化；单台服务为应用+数据库，前端使用逆向代理实现负载平衡，后端使用一台服务器实现全数据同步；特点，比较粗暴适合应用全部逻辑层都负载很平均都很高的情况；劣势是，可能为了适应负载点高部分，负载点低部分的性能会浪费掉；1*Reverse+n*Service+1*MainDataBase；
    3，根据应用的逻辑分层，例如用户+逻辑1+逻辑2+订单+论坛这种方法，每种逻辑一台服务器；这种分发需要比较细致、全面的负载测试；但是再次大规模拓容比较费力；而且需要很强的负载预估能力；具体实现同2，只是中间部分每台服务器仅负担应用单层负载；特点，可以很精确的适应应用；劣势是：忒复杂；1*Reverse+N*1Service+N*2Service+N*3Service...+N*Redis+N*DataBase+*MainDataBase；
    
    以上几种方法，个人认为应从实际出发选择适合自己的拓容方式；只有优劣选择，没有孰好孰坏；仅此...**楼歪了～怎么说道负载均衡了？**

黄舟 · Answer

Cela ne peut pas être évité directement lors de l'écriture des opérations. Si vous considérez toujours les "cas extrêmes", vous passerez à côté du problème.

高洛峰 · Answer

Écrivez d'abord dans le cache, puis conservez-le sur le disque. L'auteur craint-il que le serveur de cache raccroche et provoque une perte de données ?
Dans les environnements de production généraux, qu'il s'agisse d'un serveur d'applications, d'un serveur de base de données ou d'un serveur de cache, ce ne sera pas et ne devrait pas être un serveur autonome. Au moins, c'est une structure maître-esclave. Si l'un échoue, l'autre. prendra le relais Lorsque la charge est normale, la probabilité qu'une seule machine tombe en panne n'est pas très élevée, encore moins que deux machines tombent en panne en même temps. Semblable à Redis, il peut être utilisé comme cluster, donc si le déploiement est normal. , la possibilité de ce problème est assez faible.
L'affiche peut aller se renseigner sur la CAP théorie Selon votre description, l'effet que vous souhaitez obtenir est similaire à ce que CAP explique. Il n'y a pas de solution absolument parfaite.

巴扎黑 · Answer

Merci pour l'invitation, mais je n'ai aucune expérience dans la gestion de ce problème, je ne peux donc en parler que théoriquement

Tout d'abord, la mise en cache est inévitable. Le répertoire de cache sert à stocker temporairement les éléments qui ne peuvent pas être traités pour prolonger le temps d'attente. Par exemple, une simultanéité élevée et soudaine de 10 minutes provoque une accumulation de problèmes qui doivent être résolus grâce à la mise en cache, le contenu de 10 minutes peut être traité en une demi-heure. Bien sûr, il y a une hypothèse ici, c'est-à-dire qu'après 10 minutes de concurrence élevée, il n'y aura pas trop de problèmes à résoudre.

Alors la question est : que se passe-t-il si la vitesse d'afflux ultérieur est encore très élevée et ne peut pas être traitée du tout ? Je viens d'apprendre un mot récemment, la contre-pression. La manière la plus directe de gérer la contre-pression est de supprimer une partie du contenu. Bien sûr, pour les données, vous ne voulez certainement pas les supprimer, vous ne pouvez donc penser aux moyens que du point de vue de l'efficacité du traitement, utilisez donc de nombreuses technologies de traitement simultanées telles que l'expansion, le clustering et le déchargement

Les éléments ci-dessus sont des compréhensions personnelles, utilisant des mots familiers, pas assez professionnels, et sont uniquement à titre de référence

ringa_lee · Answer

C'est un gros problème, et il existe différentes solutions pour une concurrence élevée dans différents scénarios.

Par exemple, Weibo est hautement simultané, et le système financier est également hautement simultané. Le premier n'est pas un gros problème même en cas de perte d'informations, tandis que le second a des exigences strictes en matière de persistance des informations.

De plus, s'agit-il d'une lecture ou d'une écriture à haute concurrence ?

S'agit-il d'une concurrence élevée sur une certaine période de temps ou d'une concurrence élevée et continue ?

Comment les gens peuvent-ils répondre si les prérequis ne sont pas énoncés ?

PHPz · Answer

C'est en fait une bonne question.
S'il s'agit d'une opération de lecture, il ne devrait y avoir aucun problème, car pour la plupart des bases de données actuelles, les données sont principalement mises à jour lors de l'écriture (Copie lors de l'écriture), car la plupart des bases de données grand public actuelles peuvent déjà très bien fonctionner au niveau de la base de données. La haute concurrence prend en charge la lecture simultanée. La clé est de savoir comment garantir la cohérence des données pour les opérations d'écriture et garantir que le cache est également mis à jour lorsque les données sont mises à jour. Ceci est garanti par la théorie ACID de la base de données.
Pour les opérations d'écriture, l'ACID de la base de données Internet actuelle est particulièrement cohérent. Il parle de la cohérence ultime des données, plutôt que de la cohérence traditionnelle. Cela peut garantir que les demandes des utilisateurs peuvent recevoir une réponse rapide. Cet article est une introduction au CAP, http://blog.csdn.net/starxu85... Pour référence
Votre question correspond en fait à la vente flash "Double Eleven", avec des milliers de personnes ou plus Si vous souhaitez Si vous prenez un produit supplémentaire, si la base de données écrit fréquemment, cela entraînera inévitablement le verrouillage de la table et le blocage d'autres opérations. Heureusement, certaines bases de données disposent d'optimisations de performances pour ce scénario (comme le nouveau AliSQL open source basé sur MySQL et optimisé pour). ventes flash), ces requêtes peuvent être mises en file d'attente dans le cache de la base de données, puis mises à jour immédiatement pour garantir une simultanéité élevée. Bien entendu, il existe d’autres supports théoriques au milieu, comme les niveaux d’eau hauts et bas, les pools de threads, etc.
Ce qui précède est mon humble opinion. Je ne suis pas un DBA professionnel. S'il y a des erreurs théoriques, vous pouvez y ajouter des éléments.

伊谢尔伦 · Answer

Ce problème soulevé par l'affiche est courant dans la plupart des applications, et il n'a pas grand-chose à voir avec le fait que le système ait une concurrence élevée. J'ai déjà pensé à des problèmes similaires
Une brève discussion sur la mise en cache (2)
. Laissez-moi en parler d'abord. Cache, dans la plupart des cas, notre programme devrait en fait avoir une "faible dépendance" vis-à-vis du cache ?
Ma compréhension est que l'exactitude des données de notre. Le programme réside dans Dans la plupart des cas, il ne sera pas jugé par les données du cache. Par exemple, le « prix du produit sur la page de détails du produit » est en fait les données du cache, mais le prix total lorsque nous générons le. l'ordre doit être saisi dans la base de données. Vérifiez-le. Bien sûr, je parle de la plupart des cas, mais il existe quelques cas où l'exactitude des données n'est pas si stricte (par exemple, l'abstraction, le nombre de prix de consolation peut être chargé dans le cache à l'avance, et les besoins commerciaux ultérieurs peuvent être directement répercutés via les prix dans le cache. Calculés en fonction de la quantité, car selon les affaires générales, les prix de consolation sont des avantages supplémentaires qui profitent aux commerçants, comme une réduction de 5 yuans pour les achats supérieurs. 100. Même si le cache échoue à ce moment, le rafraîchir à nouveau aura peu d'impact sur le commerçant)

Existe-t-il un moyen d'assurer une forte cohérence entre la base de données et le cache ? Ce processus implique des transactions distribuées, et les deux parties implémentent le protocole X/Open XA, mais redis ce protocole n'a pas encore été implémenté, et à cause de cela. nécessite beaucoup de temps pour verrouiller les ressources dans l'ensemble de la distribution, cette méthode n'est donc pas recommandée (une éventuelle cohérence peut également provoquer une incohérence des données pendant un certain temps, ce qui augmentera considérablement la complexité de Redis)

Donc, dans les situations courantes, nous nous assurons généralement d'abord que les données de la base de données sont correctes, puis mettons à jour le cache de manière synchrone/invalide/asynchrone