一、集群模式下一人一单问题具体指的是什么？

在集群模式下，”一人一单”问题指的是多个用户同时提交订单或请求时，需要确保每个用户只能被分配到一个订单或请求，并且不能发生订单或请求的重复分配的情况。

这个问题在分布式系统的应用中经常遇到，特别是在电商、餐饮外卖、共享经济等领域，当大量用户同时下单或请求资源时，保证每个用户的操作不会相互干扰，确保数据的一致性和正确性。

在解决这个问题时，可以使用以下方法：

  • 分布式锁：利用分布式锁来实现对资源的排他性访问。当一个用户要提交订单或请求时，先尝试获取一个全局唯一的锁，如果成功获取锁，则可以继续进行后续操作；如果获取锁失败，则表示有其他用户正在处理，当前用户需要等待一段时间后再进行尝试。常见的实现方式包括使用 Redis 的分布式锁或基于数据库的乐观锁等。
  • 去重机制：通过记录已处理的订单或请求信息，避免重复处理。可以使用分布式缓存（如 Redis）来保存已处理的订单或请求的唯一标识，每次有新订单或请求时，先查询缓存中是否存在，如果存在则视为重复，直接忽略；如果不存在，则进行处理并将唯一标识记录到缓存中。
  • 消息队列：使用消息队列来对订单或请求进行排队处理。当用户提交订单或请求时，将其发送到消息队列中，由多个消费者并发地从队列中获取任务进行处理。通过消息队列的特性，确保每个订单或请求只被一个消费者处理，避免重复分配。

二、如何解决超卖问题？

超卖问题是指在电商等业务场景中，出现了某个商品或资源被重复销售的情况，即超过了实际库存或可用数量。为了解决超卖问题，可以采取以下几种方法：

  • 库存扣减与校验：在用户下单时，对库存进行实时扣减。在扣减库存之前，需要先检查库存是否足够。如果库存不足，就不能接受新订单，或者将订单标记为等待状态，直到库存有足够的数量。这样可以确保每个订单都不会超过实际库存。

  • 分布式锁：使用分布式锁来保证对库存操作的原子性和排他性。当有多个请求同时到达时，只有一个请求能够成功获取锁，其他的请求需要等待。在获取到锁之后，进行库存扣减操作，并释放锁。这样可以避免多个请求同时进行库存扣减而导致超卖的问题。

三、RocketMQ和OpenFeign的应用场景，什么时候用哪个？

  • RocketMQ 是一个分布式消息中间件，主要用于解决高吞吐量、可靠性消息传输的需求。它采用了异步、高可靠、可扩展等特点，适用于需要在分布式系统中进行消息发布和订阅的场景。常见的应用场景包括异步通信、解耦系统、日志收集和分析、流量削峰填谷等。
  • OpenFeign 是一个声明式的服务调用客户端工具，主要用于简化微服务架构中服务之间的调用。它通过基于接口的方式定义服务调用，并提供了自动生成 HTTP 客户端的功能。OpenFeign 可以与服务注册中心（如 Eureka）和负载均衡器（如 Ribbon）等配合使用，方便地实现服务之间的通信和负载均衡。它适用于微服务架构中的服务消费者，可以方便地调用其他服务的 API。

综上所述，当我们需要在分布式系统中进行高可靠、高吞吐量的消息传输时，可以选择使用 RocketMQ。而当我们在微服务架构中需要方便地调用其他服务的 API 时，则可以选择使用 OpenFeign。具体使用哪个工具还需根据具体的业务需求和系统架构来确定。

四、结合项目讲讲哪里用到了代理模式？

数据库@Transactional注解用到了动态代理，通过动态代理+反射实现AOP功能。

五、怎么保证一个方法只启动一次？

1、懒汉式单例模式

在懒汉式单例模式中，通过延迟实例化的方式，在第一次调用这个方法时才创建对象，并将其保存起来。之后每次调用该方法时，直接返回已创建的对象。这样可以确保方法只被启动一次

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、使用标志变量

在方法内部使用一个标志变量，初始值为false。方法第一次被调用时，将标志变量设置为true，并执行对应的逻辑。之后的调用，先检查标志变量的值，如果为true则直接返回，不再执行方法的逻辑。

public class MyClass {private boolean hasStarted = false;public void startMethod() {if (!hasStarted) {// 执行方法的逻辑hasStarted = true;}}}

六、很多个请求，每个请求用一个线程，如何同时写日志文件

1、使用线程安全的日志库

选择一个线程安全的日志库，如Log4j或Slf4j，这些库已经提供了线程安全的机制来处理并发写日志的情况。

2、分配独立的日志文件

为每个请求分配一个独立的日志文件，可以使用请求的唯一标识符或者线程ID作为日志文件的名称。这样每个请求都有自己的日志文件，避免了多个线程同时写入同一个文件造成的并发问题。

3、使用线程锁或互斥机制

在写入日志文件的代码块中使用线程锁或互斥机制，确保同一时间只有一个线程能够执行写入操作。可以使用Java中的synchronized关键字或者Lock接口来实现线程锁。

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();}}}

七、如果在微服务里面用Session，如何共享

在微服务架构中，使用传统的Session共享方式可能会面临一些挑战，因为微服务的设计理念是每个服务都是相对独立的，没有共享状态。然而，如果确实需要在微服务之间进行Session共享，可以考虑以下几种方案：

1、使用集中式Session管理

可以通过引入一个独立的、专门负责Session管理的服务，将所有的Session数据存储在一个中心位置。其他微服务在需要访问Session数据时，可以向该服务发送请求，获取或更新Session信息。这样可以确保Session数据在各个微服务之间的一致性。

2、使用Token-Based身份验证

将Session数据转换为Token，并使用Token进行身份验证和授权。当用户登录成功后，生成一个包含用户身份标识的Token，并将其返回给客户端。客户端在后续的请求中携带Token进行身份验证。微服务可以使用该Token验证用户身份，并根据需要获取相关Session数据，从而实现共享。

3、使用轻量级的分布式缓存

将Session数据存储在一个分布式缓存系统中，例如Redis、Memcached等。各个微服务可以通过访问缓存来获取和更新Session数据。由于缓存是分布式的，因此可以跨多个微服务共享Session数据。这种方式需要确保缓存系统的高可用性和性能。

八、支付完成之后，会返回通知结果问题

如何保证客户订单保存在数据库中：

  1. 1个小时之后才返回通知结果 。
  2. 1天之后才返回通知结果。
  3. 网络故障，直接没有通知结果 。

解决方法：

  • 异步通知：在支付完成后，立即返回一个成功的支付结果给客户端，同时启动一个异步任务，负责将订单信息保存到数据库中。这样可以避免等待通知结果的时间延迟，提高用户体验。异步通知可以使用消息队列进行实现，主要是使用RabbitMQ的延迟队列。
  • 重试机制：针对可能出现的网络故障或通知失败的情况，可以在合理的间隔时间内进行重试。当检测到通知失败或超时时，可以选择重新发送通知请求，确保订单信息最终保存到数据库中。
  • 数据库事务：在保存订单信息到数据库时，可以使用数据库事务来确保数据的一致性和完整性。在支付完成后，开启一个数据库事务，将订单信息插入到数据库中，并提交事务。如果在保存过程中发生异常或错误，可以回滚事务，保证订单信息没有被保存到数据库中。
  • 数据库持久化策略：选择合适的数据库持久化策略，确保数据的可靠性。可以使用数据库的备份、复制、集群等技术来防止订单数据的丢失或损坏。

九、单例模式的对象在集群中如何去设计存放？

使用分布式锁来解决这个问题，多个线程去访问单例模式的时候使用分布式锁保证单例对象的创建和访问的互斥性。通过竞争锁资源来确保只有一个节点能够创建并持有单例对象，其他节点则等待获取锁。