1. Antecedentes
El sistema de afiliación es un sistema básico que está estrechamente relacionado con el proceso principal de realización de pedidos en todas las líneas de negocio de la empresa. Si el sistema de membresía falla, los usuarios no podrán realizar pedidos y el alcance del impacto será en todas las líneas de negocios de la empresa. Por lo tanto, el sistema de membresía debe garantizar un alto rendimiento y alta disponibilidad, y proporcionar servicios básicos estables y eficientes.
Con la fusión de Tongcheng y eLong, cada vez más sistemas necesitan abrir sistemas de membresía multiplataforma como Tongcheng APP, eLong APP, Tongcheng WeChat Mini Program y eLong WeChat Mini Program. Por ejemplo, en la comercialización cruzada de los applets de WeChat, un usuario compra un boleto de tren y desea enviarle un sobre rojo del hotel en este momento, lo que requiere consultar la relación de membresía unificada del usuario. Debido a que el boleto de tren usa el sistema de membresía de Tongcheng y el hotel usa el sistema de membresía de eLong, solo después de encontrar el número de tarjeta de membresía de eLong correspondiente, se puede colocar el sobre rojo en la cuenta del miembro. Además del marketing cruzado mencionado anteriormente, hay muchos escenarios que necesitan consultar la relación de membresía unificada, como el centro de pedidos, el nivel de membresía, el kilometraje, el sobre rojo, los viajes frecuentes, el nombre real y varias actividades de marketing, etc. Por lo tanto, el volumen de solicitudes del sistema de membresía es cada vez mayor, y la concurrencia es cada vez mayor. El feriado del Primero de Mayo de este año tiene un segundo TPS concurrente de más de 20,000. Bajo el impacto de una cantidad tan grande de tráfico, ¿cómo logra el sistema de membresía un alto rendimiento y una alta disponibilidad? En esto se centra este artículo.
2. Solución de alta disponibilidad ES
1. Arquitectura de clúster activo-en espera de doble centro ES
Después de la integración de Tongcheng y eLong, el número total de miembros de todos los sistemas en toda la plataforma supera los mil millones. Con un volumen de datos tan grande, la dimensión de consulta de la línea de negocio también es relativamente complicada. Algunas líneas comerciales se basan en números de teléfono móvil, algunas se basan en WeChat unionid y otras se basan en números de tarjeta eLong, etc. para consultar la información de los miembros. Con base en una cantidad tan grande de datos y tantas dimensiones de consulta, elegimos ES para almacenar relaciones de membresía unificadas. Los clústeres de ES son muy importantes en toda la arquitectura del sistema de membresía, entonces, ¿cómo garantizar la alta disponibilidad de ES?
En primer lugar, sabemos que el clúster ES en sí mismo garantiza una alta disponibilidad, como se muestra en la siguiente figura:
cuando un nodo del clúster ES deja de funcionar, el fragmento de réplica correspondiente a otros nodos se actualizará a un fragmento principal para continuar brindando servicios. Pero incluso eso no es suficiente. Por ejemplo, los clústeres de ES se implementan en la sala de computadoras A, y ahora la sala de computadoras A pierde energía repentinamente, ¿qué debo hacer? Por ejemplo, si falla el hardware del servidor, la mayoría de las máquinas en el clúster ES están inactivas, ¿qué debo hacer? O de repente hay un evento de venta flash muy popular, que trae una ola de tráfico muy grande, matando directamente el clúster ES, ¿qué debo hacer? Ante estas situaciones, ¿dejar que los hermanos de operación y mantenimiento se apresuren a la sala de cómputo para solucionarlas? Esto es muy poco realista, porque el sistema de membresía afecta directamente el proceso principal de realizar pedidos para todas las líneas de negocio de la empresa, y el tiempo de recuperación de fallas debe ser muy corto.Si se requiere la intervención manual de los hermanos de operación y mantenimiento, el tiempo será demasiado largo, lo cual es absolutamente intolerable. ¿Cómo hacer la alta disponibilidad de ES? Nuestra solución es la arquitectura de clúster activo-en espera de doble centro ES.
Tenemos dos aulas de informática, a saber, la sala de informática A y la sala de informática B. Implementamos el clúster principal de ES en la sala de computadoras A e implementamos el clúster de respaldo de ES en la sala de computadoras B. La lectura y escritura del sistema miembro están todas en el clúster principal de ES, y los datos se sincronizan con el clúster de reserva de ES a través de MQ. En este momento, si el clúster principal de ES colapsa, a través de la configuración unificada, la lectura y escritura del sistema miembro se cambiará al clúster de reserva de ES en la sala de computadoras B, de modo que incluso si el clúster principal de ES está inactivo, la conmutación por error se puede realizar. logrado en poco tiempo Asegurar el funcionamiento estable del sistema de membresía. Finalmente, después de que se recupere la falla del clúster principal ES, encienda el interruptor para sincronizar los datos durante la falla del clúster principal ES. Después de que los datos estén sincronizados y sean consistentes, cambie la lectura y escritura del sistema miembro al principal ES grupo.
2. Arquitectura de tres clústeres de aislamiento de tráfico ES
Parece que no debería haber mayor problema si los clústeres activos y en espera de doble centro ES logran este paso, pero una terrible conmoción en el tráfico el año pasado nos hizo cambiar de opinión. Era un día festivo y cierta empresa lanzó una campaña de marketing. En una solicitud de usuario, el sistema de membresía fue llamado más de 10 veces, lo que provocó que los tps del sistema de membresía se dispararan y casi explotaron el clúster ES. Este incidente nos aterrorizó y nos hizo darnos cuenta de que debemos priorizar a las personas que llaman e implementar estrategias más refinadas de aislamiento, ruptura de circuitos, degradación y limitación de corriente. Primero, clasificamos todas las llamadas y las dividimos en dos tipos de solicitudes. La primera categoría son las solicitudes que están estrechamente relacionadas con el proceso principal de realizar un pedido. Estas solicitudes son muy importantes y deben garantizarse con alta prioridad. La segunda categoría está relacionada con las actividades de marketing, este tipo de solicitud tiene una característica, tienen una gran cantidad de solicitudes y un alto tps, pero no afecta el proceso principal de realizar un pedido. En base a esto, construimos otro clúster de ES, que se usa especialmente para manejar solicitudes de picos de marketing de alto tps, de modo que esté aislado del clúster de ES principal y no afectará el proceso de pedido del usuario debido al impacto de tráfico de un cierto actividad de marketing proceso. Como se muestra abajo:
3. Optimización y mejora de la profundidad del clúster ES
Después de hablar sobre la arquitectura de alta disponibilidad de los clústeres activos y en espera de doble centro de ES, expliquemos en profundidad la optimización del clúster principal de ES. Durante un período de tiempo, nos sentíamos particularmente miserables, es decir, cada vez que comíamos, el grupo de ES comenzaba a llamar a la policía, lo que nos hacía sentir nerviosos cada vez que comíamos, temiendo que el grupo de ES no pudiera manejarlo solo, y el toda la compañía volaría por los aires. Entonces, ¿por qué llamar a la policía tan pronto como sea la hora de comer? Debido a que el tráfico es relativamente grande, la cantidad de subprocesos ES se dispara, la CPU sube y aumenta el tiempo de consulta, que se transmite a todas las personas que llaman, lo que da como resultado una gama más amplia de retrasos. Entonces, ¿cómo resolver este problema? Al profundizar en el clúster ES, encontramos los siguientes problemas:
- La carga de ES no es razonable y el problema del punto de acceso es grave. Hay docenas de nodos en el clúster principal de ES. Algunos nodos implementan demasiados fragmentos, mientras que otros implementan pocos fragmentos. Como resultado, algunos servidores están muy cargados. Cuando el tráfico alcanza su punto máximo, se emiten advertencias frecuentes.
- El tamaño del grupo de subprocesos ES está configurado demasiado alto, lo que hace que la CPU se dispare. Sabemos que cuando se configura el grupo de subprocesos de ES, la cantidad de subprocesos generalmente se establece en la cantidad de núcleos de CPU del servidor. Incluso si la presión de consulta de ES es alta y es necesario aumentar la cantidad de subprocesos, es mejor no para exceder "cpu core * 3/2 + 1". Si la cantidad de subprocesos se establece demasiado, la CPU alternará con frecuencia entre varios contextos de subprocesos, desperdiciando una gran cantidad de recursos de la CPU.
- La memoria asignada por el fragmento es demasiado grande, 100 g, lo que ralentiza la consulta. Sabemos que el índice ES debe asignar la cantidad de fragmentos de manera razonable y controlar el tamaño de la memoria de un fragmento dentro de los 50 g. Si la memoria asignada por un fragmento es demasiado grande, la consulta se ralentizará, se incrementará el consumo de tiempo y el rendimiento se verá seriamente afectado.
- El campo de tipo cadena se configura con campos dobles, que son tanto texto como palabra clave, lo que duplica la capacidad de almacenamiento. La consulta de la información de los miembros no necesita puntuarse según el grado de relevancia, se puede consultar directamente según la palabra clave, por lo que el campo de texto se puede eliminar por completo, lo que puede ahorrar una gran parte del espacio de almacenamiento y mejorar el rendimiento.
- ES consulta, usa filtro, no consulta. Debido a que la consulta calculará la puntuación de relevancia de los resultados de búsqueda, lo que consume más CPU, y la consulta de información de miembros no necesita calcular la puntuación, y esta parte de la pérdida de rendimiento se puede evitar por completo.
- Para ahorrar potencia informática de ES, ordene los resultados de búsqueda de ES en la memoria jvm del sistema miembro.
- Agregar clave de enrutamiento. Sabemos que una consulta ES distribuirá la solicitud a todos los fragmentos, agregará los datos después de que todos los fragmentos devuelvan los resultados y, finalmente, devolverá los resultados a la persona que llama. Si ya sabemos de antemano en qué fragmentos se distribuyen los datos, podemos reducir una gran cantidad de solicitudes innecesarias y mejorar el rendimiento de las consultas.
Después de la optimización anterior, los resultados son muy notables, la CPU del clúster ES se reduce considerablemente y el rendimiento de las consultas mejora considerablemente. El uso de CPU del clúster ES:
el consumo de tiempo de interfaz del sistema miembro:
3. Solución de caché Redis de membresía
Durante mucho tiempo, el sistema de membresía no se ha almacenado en caché. Hay dos razones principales: primero, el rendimiento del clúster ES mencionado anteriormente es muy bueno, con más de 30,000 transacciones simultáneas por segundo, y las 99 líneas toman alrededor de 5 milisegundos , que es suficiente para hacer frente a varios problemas difíciles. En segundo lugar, algunas empresas requieren coherencia en tiempo real en la relación vinculante de los miembros, y la membresía es un sistema antiguo que se ha desarrollado durante más de 10 años, y es un sistema distribuido compuesto por muchas interfaces y muchos sistemas. Por lo tanto, mientras haya una interfaz que no se considere en su lugar y el caché no se actualice a tiempo, dará lugar a datos sucios, lo que dará lugar a una serie de problemas, tales como: los usuarios no pueden ver los pedidos de WeChat, APP y niveles de membresía de WeChat, kilometraje, etc. No hay fusión, WeChat y APP no pueden cruzar el mercado, etc. Entonces, ¿por qué necesita volver a almacenar en caché? Es debido a la actividad de caja ciega de boletos aéreos este año, la concurrencia instantánea que trae es demasiado alta. Aunque el sistema de membresía está sano y salvo, todavía existen temores persistentes. Para estar seguros, finalmente decidimos implementar una solución de almacenamiento en caché.
1. La solución al problema de inconsistencia de los datos de caché de Redis causados por ES casi un segundo de retraso
En el proceso de creación de una solución de caché de membresía, encontré un problema causado por ES, que provocaría inconsistencias en los datos almacenados en caché. Sabemos que los datos de operación de ES son casi en tiempo real. Si agrega un documento a ES, puede verificarlo de inmediato, pero no puede encontrarlo. Debe esperar 1 segundo antes de poder verificarlo. Como se muestra en la siguiente figura: ¿
Por qué el mecanismo casi en tiempo real de ES provoca inconsistencias en los datos de caché de redis? Específicamente, supongamos que un usuario cierra sesión en su cuenta de APP. En este momento, ES debe actualizarse para eliminar la relación vinculante entre la cuenta de APP y la cuenta de WeChat. La actualización de datos de ES es casi en tiempo real, es decir, puede consultar los datos actualizados después de 1 segundo. Y dentro de este 1 segundo, hay una solicitud para consultar la relación de vinculación de membresía del usuario. Primero verifica en el caché de redis y descubre que no hay nadie, luego verifica en ES y lo encuentra, pero lo que encuentra es el Datos antiguos antes de la actualización. Finalmente, la solicitud actualiza los datos antiguos consultados en el caché de redis y los devuelve. De esta manera, después de 1 segundo, los datos de membresía del usuario en ES se actualizan, pero los datos en el caché de redis aún son datos antiguos, lo que genera inconsistencias entre el caché de redis y los datos de ES. Como se muestra en la siguiente figura:
Ante este problema, ¿cómo solucionarlo? Nuestra idea es agregar un bloqueo simultáneo distribuido de redis de 2 segundos al actualizar los datos de ES, para garantizar la consistencia de los datos almacenados en caché y luego eliminar los datos almacenados en caché del miembro en redis. Si hay una solicitud para consultar datos en este momento, primero obtenga el bloqueo distribuido y descubra que la identificación del miembro ha sido bloqueada, lo que indica que los datos recién actualizados por ES aún no han entrado en vigencia, luego, después de consultar los datos en este momento , el caché redis no se actualizará y regresará directamente. Esto evita el problema de inconsistencia de los datos almacenados en caché. Como se muestra en la figura a continuación:
la solución anterior parece no ser un problema a primera vista, pero un análisis cuidadoso aún puede generar inconsistencias en los datos almacenados en caché. Por ejemplo, antes de que la solicitud de actualización agregue un bloqueo distribuido, hay exactamente una solicitud de consulta para adquirir un bloqueo distribuido, pero no hay ningún bloqueo en este momento, por lo que puede continuar actualizando la memoria caché. Pero justo antes de actualizar el caché, el hilo se bloqueó. En ese momento, llegó la solicitud de actualización, se agregó un bloqueo distribuido y se eliminó el caché. Cuando la solicitud de actualización completa la operación, el hilo de la solicitud de consulta cobra vida. En este momento, ejecuta el caché de actualización y escribe los datos sucios en el caché. ¿Lo encontraste? El quid principal del problema es que existe un conflicto de concurrencia entre "eliminar caché" y "actualizar caché". Siempre que sean mutuamente excluyentes, el problema se puede resolver. Como se muestra abajo:
Después de implementar la solución de almacenamiento en caché, según las estadísticas, la tasa de aciertos de caché es superior al 90%, lo que alivia en gran medida la presión sobre ES, y el rendimiento general del sistema de membresía ha mejorado considerablemente.
2. Arquitectura multiclúster de doble centro de Redis
A continuación, echemos un vistazo a cómo garantizar la alta disponibilidad del clúster de Redis. Como se muestra en la siguiente figura:
En cuanto a la alta disponibilidad del clúster de Redis, hemos adoptado un modelo de múltiples clústeres de doble centro. Implemente un conjunto de clústeres de Redis en la sala de computadoras A y la sala de computadoras B, respectivamente. Al actualizar los datos almacenados en caché, escriba dos veces, y solo si los clústeres redis en ambas salas de computadoras se escriben correctamente, devolverá el éxito. Al consultar datos almacenados en caché, consulte cerca en la sala de computadoras para reducir la demora. De esta manera, incluso si la sala de computadoras A falla en su totalidad, la sala de computadoras B aún puede brindar servicios completos a los miembros.
4. Solución de base de datos maestra de miembros de alta disponibilidad
Como se mencionó anteriormente, los datos de relación vinculante de todos los miembros de la plataforma existen en ES, mientras que los detalles de registro de los miembros existen en bases de datos relacionales. Al principio, la base de datos utilizada por los miembros era SqlServer, hasta que un día, un DBA se acercó a nosotros y nos dijo que una sola base de datos SqlServer ha almacenado más de mil millones de datos de miembros, y el servidor ha alcanzado su límite físico y no se puede expandir más. . De acuerdo con la tendencia de crecimiento actual, no pasará mucho tiempo antes de que toda la base de datos de SqlServer colapse. Piénselo, qué tipo de escenario de desastre es ese: cuando la base de datos de membresía colapsa, el sistema de membresía colapsa; cuando el sistema de membresía colapsa, todas las líneas de negocios de la empresa colapsan. Pensar en ello me da escalofríos, y es tan refrescante que inmediatamente comenzamos el trabajo de migrar la base de datos.
1. Solución de clúster de partición de centro dual MySql
Después de la investigación, elegimos la solución de clúster MySql con subtabla y subbase de datos de doble centro, como se muestra en la siguiente figura: los
miembros tienen un total de más de mil millones de datos y dividimos la base de datos principal de miembros en más de 1000. fragmentos, y los dividió por igual en cada fragmento En el orden de millones, es suficiente para usar. El clúster MySql adopta la arquitectura de maestro 1 y esclavos 3. La biblioteca maestra se coloca en la sala de computadoras A y la biblioteca esclava se coloca en la sala de computadoras B. Los datos se sincronizan entre las dos salas de computadoras a través de una línea dedicada y el retraso está dentro de 1 milisegundo. El sistema miembro lee y escribe datos a través de DBRoute, y los datos escritos se enrutan a la sala de computadoras A donde se encuentra el nodo maestro, y los datos leídos se enrutan a la sala de computadoras local, a la que se puede acceder cerca para reducir las demoras en la red. De esta manera, el uso de una arquitectura de clúster MySql de doble centro mejora enormemente la disponibilidad Incluso si la sala de computadoras A colapsa en su totalidad, el Esclavo en la sala de computadoras B puede actualizarse a Maestro para continuar brindando servicios.
Después de que se construyó el clúster MySql de doble centro, realizamos una prueba de esfuerzo. Después de la prueba, la segunda concurrencia puede alcanzar más de 20,000, y el tiempo promedio de consumo es de 10 milisegundos, y el rendimiento cumple con el estándar.
2. Plan de migración sin problemas para la base de datos principal de miembros
El siguiente trabajo es cambiar el almacenamiento subyacente del sistema de membresía de SqlServer a MySql. Este es un trabajo muy arriesgado y presenta principalmente las siguientes dificultades:
- El sistema de membresía no se puede detener por un momento. Para completar el cambio de SqlServer a MySql sin detenerse, es como cambiar las ruedas de un automóvil de alta velocidad.
- El sistema de membresía se compone de muchos sistemas e interfaces. Después de todo, se ha desarrollado durante más de 10 años. Debido a razones históricas, se ha dejado atrás una gran cantidad de interfaces antiguas y la lógica es intrincada. Tantos sistemas deben clasificarse uno por uno, y el código de la capa DAL debe reescribirse sin ningún problema, de lo contrario, será catastrófico.
- La migración de datos debe ser perfecta, no solo la migración de más de mil millones de datos en stock, sino que también los datos en tiempo real deben sincronizarse sin problemas con mysql. Además, además de garantizar el rendimiento en tiempo real de la sincronización de datos, también es necesario garantizar la exactitud de los datos y la consistencia de los datos de SqlServer y MySql.
Con base en los puntos débiles anteriores, diseñamos una solución técnica de "sincronización completa, sincronización incremental y conmutación de tráfico en escala de grises en tiempo real".
En primer lugar, para garantizar un cambio de datos sin interrupciones, se adopta un esquema de doble escritura en tiempo real. Debido a la complejidad de la lógica comercial y las diferencias técnicas entre SqlServer y MySql, en el proceso de escritura doble de mysql, es posible que la escritura no tenga éxito y, una vez que falle, los datos de SqlServer y MySql serán inconsistentes, lo cual es absolutamente no permitido. Por lo tanto, la estrategia que adoptamos es escribir en SqlServer principalmente durante la ejecución de prueba y luego escribir en MySql de forma asincrónica a través del grupo de subprocesos. Si la escritura falla, vuelva a intentarlo tres veces. Si aún falla, registre el registro y luego verifique manualmente Continúe con la doble escritura hasta que se ejecute durante un período de tiempo y no haya una falla de doble escritura. A través de la estrategia anterior, la corrección y la estabilidad de la operación de doble escritura se pueden garantizar en la mayoría de los casos.Incluso si hay una inconsistencia entre los datos de SqlServer y MySql durante la ejecución de prueba, los datos de MySql se pueden construir completamente de nuevo en base a SqlServer, porque cuando diseñemos la estrategia de doble escritura, nos aseguraremos de que SqlServer pueda escribir correctamente, es decir, que los datos en SqlServer sean los más completos y correctos. Como se muestra en la figura a continuación:
Después de hablar sobre la doble escritura, echemos un vistazo a cómo escalar en gris los "datos de lectura". La idea general es escalar gradualmente el tráfico a través de la plataforma A / B. Al principio, el 100% del tráfico lee la base de datos SqlServer y luego corta gradualmente el tráfico para leer la base de datos MySql. Primero, el 1%, si hay no hay problema, luego libera gradualmente el tráfico y finalmente el 100% Todo el tráfico pasa por la base de datos MySql. En el proceso de tráfico gradual en escala de grises, se requiere un mecanismo de verificación. Solo cuando la verificación es correcta, el tráfico puede ampliarse aún más. Entonces, ¿cómo se implementa este mecanismo de verificación? La solución es usar un subproceso asíncrono para comparar si los resultados de la consulta de SqlServer y MySql son consistentes en una solicitud de consulta. Si no son consistentes, registre el registro y verifique manualmente la causa de la inconsistencia hasta que el problema de inconsistencia se resuelva por completo. y, a continuación, escalar gradualmente el tráfico en escala de grises. Como se muestra en la siguiente figura:
Por lo tanto, el proceso general de implementación es el siguiente:
En primer lugar, en medio de una noche oscura y ventosa, cuando el tráfico es mínimo, complete la sincronización completa de datos de SqlServer a la base de datos MySql. Luego, habilite la doble escritura, en este momento si hay un registro de usuario, se escribirá dos veces en las dos bases de datos en tiempo real. Luego, entre la sincronización completa y la habilitación de doble escritura en tiempo real, las dos bases de datos aún tienen una diferencia en los datos durante este período, por lo que se necesita una sincronización incremental nuevamente para completar los datos y evitar la inconsistencia de los datos. El resto del tiempo se dedica a monitorear varios registros para ver si hay un problema con la doble escritura, para ver si la comparación de datos es consistente, etc. Este período de tiempo es el que consume más tiempo y el más propenso a problemas. Si algunos problemas son serios y causan inconsistencias en los datos, debe comenzar de nuevo, construir la base de datos MySql nuevamente basada en SqlServer en su totalidad y luego volver a Gray el tráfico hasta el final, el 100% del tráfico está en escala de grises a MySql. En este punto, ya ha terminado. La lógica de escala de grises está fuera de línea, y todas las lecturas y escrituras se cambian al clúster de MySql.
3. Esquema de clúster activo/en espera de MySql y ES
Después de este paso, siento que la biblioteca de miembros principal debería estar bien, pero una falla grave del componente dal nos hizo cambiar de opinión. Esa falla fue terrible. Muchas aplicaciones en la empresa no pudieron conectarse a la base de datos, y la cantidad de pedidos creados se desplomó. Esto nos hizo darnos cuenta de que, incluso si la base de datos es buena, la anomalía del componente dal aún puede hacer que el sistema de membresía falle. colgar. Por lo tanto, volvemos a heterogeneizar heterogéneamente la fuente de datos de la base de datos maestra de miembros y escribimos dos veces los datos en ES, como se muestra a continuación:
Si el componente dal falla o la base de datos MySql se cuelga, puede cambiar la lectura y escritura a ES, y espere a que MySql se recupere, y luego escriba los datos Sincronice en MySql, y finalmente cambie la lectura y escritura a la base de datos MySql. Como se muestra abajo:
5. Gestión anormal de las relaciones con los miembros
El sistema de membresía no solo debe garantizar la estabilidad y la alta disponibilidad del sistema, sino también la precisión y exactitud de los datos. Por ejemplo, una falla concurrente distribuida hace que la cuenta de la aplicación de un usuario se vincule a la cuenta del subprograma WeChat de otra persona, lo que tendrá un impacto muy negativo. En primer lugar, una vez que las dos cuentas están vinculadas, los pedidos de hotel, billete de avión y billete de tren realizados por los dos usuarios pueden verse entre sí. Piénselo, otros pueden ver sus reservas de hotel, ¿se quejará si no es popular? Además de poder ver los pedidos de otras personas, también puedes operar pedidos. Por ejemplo, un usuario ve un pedido de boletos aéreos reservado por otra persona en el centro de pedidos de la APP, piensa que no es su propio pedido, por lo que cancela el pedido. Esto traerá quejas muy graves de los clientes, como todos sabemos, la tarifa de cancelación de los boletos aéreos es bastante alta, lo que no solo afecta el viaje normal del usuario, sino que también genera pérdidas económicas relativamente grandes, lo cual es muy malo.
Para estas cuentas de miembros anormales, las clasificamos en detalle, identificamos estas cuentas a través de una lógica muy compleja y que quema el cerebro, y llevamos a cabo una optimización y administración profundas de la interfaz de miembros, bloqueamos las lagunas relevantes en la capa de lógica de código y completó la cuenta del miembro anormal Trabajo de gobierno. Como se muestra abajo:
6. Perspectivas: control de flujo más refinado y estrategias de degradación
Cualquier sistema no puede garantizar al 100% que no habrá problemas, por lo que debemos tener un diseño orientado a fallas, es decir, una estrategia más refinada de control de flujo y degradación.
1. Estrategia de control de tráfico más refinada
Control de puntos de acceso. Para el escenario de facturación fraudulenta, el mismo id de miembro tendrá una gran cantidad de solicitudes repetidas, formando cuentas calientes, cuando el acceso de estas cuentas supere el umbral establecido, se implementará la estrategia de limitación de tráfico.
Reglas de control de flujo basadas en la cuenta que llama. Esta estrategia es principalmente para evitar el gran tráfico causado por el error de código de la persona que llama. Por ejemplo, en una solicitud de usuario, la persona que llama llama a la interfaz de membresía muchas veces en un bucle, lo que resulta en un aumento repentino en el tráfico del sistema de membresía muchas veces. Por lo tanto, es necesario establecer reglas de control de flujo para cada cuenta que llama e implementar una política de limitación de flujo cuando se excede el umbral.
Reglas de control de flujo global. Nuestro sistema de membresía puede soportar más de 30,000 tps de solicitudes concurrentes por segundo. Si en este momento, viene un tráfico terrible, con tps de hasta 100,000, es mejor dejar que esta ola de tráfico mate todas las bases de datos de miembros y es Rápido falla el tráfico que excede la tolerancia del sistema de membresía, al menos las solicitudes de miembros dentro de 30,000 tps pueden responderse normalmente, y todo el sistema de membresía no colapsará.
2. Una estrategia de rebajas más refinada
Degradación basada en el tiempo de respuesta promedio. La interfaz miembro también depende de otras interfaces.Cuando el tiempo de respuesta promedio de llamar a otras interfaces excede el umbral, ingresa al estado casi degradado. Si el tiempo de respuesta promedio de las solicitudes entrantes en los siguientes 1 s continúa excediendo el umbral, en la próxima ventana de tiempo, el fusible se cortará automáticamente.
Degradación basada en el número de valores atípicos y la proporción de valores atípicos. Cuando ocurre una excepción en otras interfaces de las que depende la interfaz miembro, si la cantidad de excepciones dentro de 1 minuto excede el umbral, o si la relación entre la cantidad total de excepciones y el rendimiento por segundo excede el umbral, ingresa al estado degradado y se fusiona automáticamente dentro de la próxima ventana de tiempo.
Actualmente, nuestro mayor problema es la gestión de las cuentas de llamadas de los miembros. En la empresa, si desea llamar a la interfaz de miembros, debe solicitar una cuenta de llamada. Registraremos los escenarios de uso de la cuenta y estableceremos las reglas para el control de flujo y las estrategias de degradación. Pero en el proceso de uso real, el colega que solicitó la cuenta puede cambiar a otro departamento. En este momento, también puede llamar al sistema de membresía. Para evitar problemas, no volverá a solicitar la cuenta de miembro, pero usar directamente la cuenta anterior. Esto hace que sea imposible para nosotros juzgar los escenarios de uso específicos de una cuenta de miembro, y es imposible implementar un control de flujo más refinado y estrategias de degradación. Por lo tanto, a continuación, ordenaremos todas las cuentas de llamadas una por una. Esta es una tarea muy grande y engorrosa, pero no hay salida, por lo que debemos hacerlo bien.