1. ¿A qué se refiere específicamente el problema de una persona y una orden en modo cluster?
En el modo clúster, el problema "una persona, un pedido" se refiere a cuando varios usuarios envían pedidos o solicitudes al mismo tiempo. Es necesario asegurarse de que a cada usuario solo se le pueda asignar un pedido o solicitud, y que no se duplique la asignación. de pedidos o solicitudes pueden ocurrir .
Este problema se encuentra a menudo en la aplicación de sistemas distribuidos, especialmente en los campos del comercio electrónico, la restauración y la economía colaborativa. Cuando un gran número de usuarios realizan pedidos o solicitan recursos al mismo tiempo, se garantiza que las operaciones de cada usuario no interfiere entre sí, lo que garantiza
Al resolver este problema, puede utilizar los siguientes métodos:
- Bloqueos distribuidos: utilice bloqueos distribuidos para lograr acceso exclusivo a los recursos. Cuando un usuario quiere enviar un pedido o solicitud, primero intenta adquirir un candado único global. Si el candado se adquiere con éxito, puede continuar con operaciones posteriores; si no logra adquirir el candado, significa que otros usuarios están procesando. y el usuario actual tendrá que esperar un rato. Vuelve a intentarlo más tarde. Los métodos de implementación comunes incluyen el uso de bloqueos distribuidos de Redis o bloqueos optimistas basados en bases de datos.
- Mecanismo de deduplicación: evite el procesamiento duplicado registrando los pedidos procesados o solicitando información. El caché distribuido (como Redis) se puede utilizar para guardar el identificador único del pedido o solicitud procesado. Cada vez que hay un nuevo pedido o solicitud, primero verifique si existe en el caché. Si existe, se considerará como un duplicado y se ignora directamente; si no existe, entonces se procesa y el identificador único se registra en la caché.
- Cola de mensajes: utilice la cola de mensajes para poner en cola pedidos o solicitudes. Cuando un usuario envía un pedido o solicitud, se envía a la cola de mensajes y varios consumidores obtienen simultáneamente tareas de la cola para procesarlas. A través de las características de la cola de mensajes, se asegura que cada pedido o solicitud sea procesado por un solo consumidor para evitar distribuciones repetidas.
2. ¿Cómo solucionar el problema de sobreventa?
El problema de sobreventa se refiere a la situación en la que un determinado producto o recurso se vende repetidamente en escenarios comerciales como el comercio electrónico, es decir, excede el inventario real o la cantidad disponible. Para resolver el problema de sobreventa, existen varios métodos que puede seguir:
-
Deducción y verificación de inventario: cuando el usuario realiza un pedido, el inventario se deduce en tiempo real. Antes de deducir el inventario, debe verificar si el inventario es suficiente. Si no hay inventario suficiente, no se pueden aceptar nuevos pedidos o el pedido se marca como pendiente hasta que haya cantidades suficientes en stock. Esto garantiza que cada pedido no exceda el inventario real.
-
Cerraduras distribuidas: utilice cerraduras distribuidas para garantizar la atomicidad y exclusividad de las operaciones de inventario. Cuando llegan varias solicitudes al mismo tiempo, solo una solicitud puede adquirir con éxito el bloqueo y las demás solicitudes deben esperar. Después de adquirir el candado, realice la operación de deducción de inventario y libere el candado. Esto puede evitar el problema de sobreventa causado por múltiples solicitudes de deducción de inventario al mismo tiempo.
3. Escenarios de aplicación de RocketMQ y OpenFeign, ¿cuándo utilizar cuál?
- RocketMQ es un middleware de mensajes distribuidos, que se utiliza principalmente para resolver las necesidades de transmisión de mensajes confiable y de alto rendimiento. Adopta las características de asíncrono, alta confiabilidad, escalabilidad, etc., y es adecuado para escenarios que requieren publicación y suscripción de mensajes en sistemas distribuidos. Los escenarios de aplicación comunes incluyen comunicación asincrónica, sistemas desacoplados, recopilación y análisis de registros, reducción de picos de tráfico y llenado de valles, etc.
- OpenFeign es una herramienta de cliente de llamada de servicio declarativa, que se utiliza principalmente para simplificar las llamadas entre servicios en una arquitectura de microservicio. Define llamadas de servicio basadas en interfaces y proporciona la función de generar automáticamente clientes HTTP. OpenFeign se puede utilizar con centros de registro de servicios (como Eureka) y equilibradores de carga (como Ribbon) para lograr fácilmente la comunicación y el equilibrio de carga entre servicios. Es adecuado para consumidores de servicios en arquitectura de microservicios y puede llamar fácilmente a la API de otros servicios.
En resumen, cuando necesitamos una transmisión de mensajes altamente confiable y de alto rendimiento en un sistema distribuido, podemos optar por utilizar RocketMQ. Cuando necesitamos llamar fácilmente a las API de otros servicios en una arquitectura de microservicio, podemos optar por utilizar OpenFeign. La herramienta específica a utilizar debe determinarse en función de las necesidades comerciales específicas y la arquitectura del sistema.
4. Hablemos de dónde se utiliza el modelo de agencia según el proyecto.
La anotación @Transactional de la base de datos utiliza un proxy dinámico para implementar la función AOP a través de proxy dinámico + reflexión.
5. ¿Cómo garantizar que un método sólo se inicie una vez?
1. Patrón Singleton perezoso
En el patrón singleton diferido, mediante la creación de instancias retrasada, el objeto se crea y guarda cuando se llama a este método por primera vez. Cada vez que se llama a este método a partir de entonces, el objeto creado se devuelve directamente. Esto garantiza que el método sólo se inicie una vez.
public class Singleton {
private static Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
// 私有化构造函数，防止其他地方创建实例
private Singleton() {
// 初始化操作
}
// 其他方法
public void doSomething() {
// 方法逻辑
}
}
2. Utilice variables de bandera
Utilice una variable de bandera dentro del método con un valor inicial de falso. Cuando se llama al método por primera vez, la variable de bandera se establece en verdadero y se ejecuta la lógica correspondiente. Las llamadas posteriores primero verificarán el valor de la variable de bandera. Si es verdadero, regresará directamente y ya no ejecutará la lógica del método.
public class MyClass {
private boolean hasStarted = false;
public void startMethod() {
if (!hasStarted) {
// 执行方法的逻辑
hasStarted = true;
}
}
}
6. Muchas solicitudes, cada solicitud utiliza un hilo, cómo escribir archivos de registro al mismo tiempo
1. Utilice una biblioteca de registro segura para subprocesos
Elija una biblioteca de registro segura para subprocesos, como Log4j o Slf4j. Estas bibliotecas ya proporcionan mecanismos seguros para subprocesos para manejar la escritura de registros concurrentes.
2. Asigne archivos de registro independientes
Asigne un archivo de registro independiente a cada solicitud. Puede utilizar el identificador único de la solicitud o el ID del hilo como nombre del archivo de registro. De esta manera, cada solicitud tiene su propio archivo de registro, lo que evita problemas de concurrencia causados por varios subprocesos que escriben en el mismo archivo al mismo tiempo.
3. Utilice bloqueo de subprocesos o mecanismo de exclusión mutua.
Utilice un mecanismo de bloqueo de subprocesos o mutex en el bloque de código que escribe el archivo de registro para garantizar que solo un subproceso pueda realizar operaciones de escritura al mismo tiempo. synchronizedLos bloqueos de subprocesos se pueden implementar utilizando palabras clave o Lockinterfaces en Java .
public class Logger {
private static final Object lock = new Object();
public void writeLog(String message) {
synchronized (lock) {
// 写日志的逻辑
}
}
}
public class Logger {
private static final Lock lock = new ReentrantLock();
public void writeLog(String message) {
lock.lock();
try {
// 写日志的逻辑
} finally {
lock.unlock();
}
}
}
7. Si Session se usa en microservicios, cómo compartirlo.
En una arquitectura de microservicios, el uso del método tradicional de intercambio de sesiones puede enfrentar algunos desafíos, porque el concepto de diseño de los microservicios es que cada servicio es relativamente independiente y no tiene un estado compartido. Sin embargo, si realmente necesitas compartir sesiones entre microservicios, puedes considerar las siguientes opciones:
1. Utilice la gestión de sesiones centralizada
Todos los datos de la sesión se pueden almacenar en una ubicación central mediante la introducción de un servicio independiente dedicado a la gestión de sesiones. Cuando otros microservicios necesitan acceder a los datos de la sesión, pueden enviar solicitudes a este servicio para obtener o actualizar la información de la sesión. Esto garantiza la coherencia de los datos de la sesión entre varios microservicios.
2. Utilice autenticación basada en tokens
Convierta los datos de la sesión en Token y utilice Token para autenticación y autorización. Cuando el usuario inicia sesión correctamente, se genera y se devuelve al cliente un token que contiene la identidad del usuario. El cliente porta el Token en solicitudes posteriores de autenticación. El microservicio puede usar el token para verificar la identidad del usuario y obtener datos de sesión relevantes según sea necesario para lograr el intercambio.
3. Utilice caché distribuido ligero
Almacene los datos de la sesión en un sistema de caché distribuido, como Redis, Memcached, etc. Cada microservicio puede obtener y actualizar datos de la sesión accediendo al caché. Debido a que la caché está distribuida, los datos de la sesión se pueden compartir entre múltiples microservicios. Este enfoque es necesario para garantizar una alta disponibilidad y rendimiento del sistema de caché.
8. Una vez completado el pago, se devolverá el resultado de una notificación.
Cómo garantizar que los pedidos de los clientes se guarden en la base de datos:
- Los resultados de la notificación se devolverán después de 1 hora.
- Los resultados de la notificación se devolverán después de 1 día.
- Fallo de red, ningún resultado notificado directamente.
Solución:
- Notificación asincrónica: una vez completado el pago, se devuelve inmediatamente al cliente un resultado de pago exitoso y se inicia una tarea asincrónica para guardar la información del pedido en la base de datos. Esto puede evitar el retraso de esperar los resultados de las notificaciones y mejorar la experiencia del usuario. Las notificaciones asincrónicas se pueden implementar mediante colas de mensajes, principalmente utilizando la cola de retraso de RabbitMQ.
- Mecanismo de reintento: en respuesta a posibles fallas de red o fallas de notificación, el reintento se puede realizar dentro de un intervalo razonable. Cuando se detecta una falla en la notificación o un tiempo de espera, puede optar por reenviar la solicitud de notificación para asegurarse de que la información del pedido finalmente se guarde en la base de datos.
- Transacciones de la base de datos: al guardar información de pedidos en la base de datos, se pueden utilizar transacciones de la base de datos para garantizar la coherencia e integridad de los datos. Una vez completado el pago, se inicia una transacción en la base de datos, la información del pedido se inserta en la base de datos y se envía la transacción. Si se produce una excepción o un error durante el proceso de guardar, la transacción se puede revertir para garantizar que la información del pedido no se guarde en la base de datos.
- Estrategia de persistencia de la base de datos: elija una estrategia de persistencia de la base de datos adecuada para garantizar la confiabilidad de los datos. Se pueden utilizar copias de seguridad de bases de datos, replicación, agrupación en clústeres y otras tecnologías para evitar la pérdida o daño de los datos de los pedidos.
9. ¿Cómo diseñar y almacenar objetos en modo singleton en el clúster?
Utilice bloqueos distribuidos para resolver este problema. Cuando varios subprocesos acceden al modo singleton, utilice bloqueos distribuidos para garantizar la exclusión mutua de la creación y el acceso a objetos singleton. Al competir por los recursos de bloqueo, se garantiza que solo un nodo pueda crear y retener el objeto singleton, mientras que otros nodos esperan para adquirir el bloqueo.