面试题：Java接口与抽象类在高并发分布式系统设计模式中的考量

Java接口与抽象类在该场景下的应用难点

接口应用难点：
- 接口只定义方法签名，没有方法实现。在高并发分布式电商秒杀系统中，对于商品库存扣减、订单生成等复杂操作，每个实现类都需要重复实现通用逻辑，如加锁、事务管理等，这可能导致代码冗余。
- 接口无法保存状态，而在处理库存扣减和订单生成时，可能需要记录一些中间状态信息，如已扣减库存数量等，接口难以满足这种需求。
抽象类应用难点：
- 抽象类不能被实例化，在分布式环境下，可能需要根据不同的节点或业务场景创建不同的实例，抽象类在灵活性上有所欠缺。
- 抽象类单继承的特性限制了其扩展性，如果一个类已经继承了某个抽象类，就无法再继承其他抽象类，在复杂的业务场景中可能无法满足多方面抽象的需求。

利用它们设计高效、线程安全且具有良好扩展性架构的方法

定义基础抽象类：
- 创建一个抽象类，例如AbstractSeckillService，在其中定义一些通用的模板方法，如库存扣减的基本逻辑、订单生成的通用步骤等。这些方法可以部分实现，将一些需要具体业务实现的部分定义为抽象方法。例如：

public abstract class AbstractSeckillService {
    // 通用库存扣减逻辑
    protected boolean deductStock(Product product, int quantity) {
        // 加锁逻辑，确保线程安全
        synchronized (product) {
            if (product.getStock() >= quantity) {
                product.setStock(product.getStock() - quantity);
                return true;
            }
            return false;
        }
    }

    // 抽象方法，由具体业务实现
    public abstract boolean generateOrder(User user, Product product, int quantity);
}

使用接口实现扩展：
- 定义多个接口，如StockDeductionStrategy和OrderGenerationStrategy，用于定义不同的库存扣减策略和订单生成策略。具体的实现类可以实现这些接口，并继承AbstractSeckillService。例如：

public interface StockDeductionStrategy {
    boolean deduct(Product product, int quantity);
}

public interface OrderGenerationStrategy {
    boolean generate(User user, Product product, int quantity);
}

public class DefaultStockDeductionStrategy implements StockDeductionStrategy {
    @Override
    public boolean deduct(Product product, int quantity) {
        // 具体扣减逻辑
    }
}

public class DefaultOrderGenerationStrategy implements OrderGenerationStrategy {
    @Override
    public boolean generate(User user, Product product, int quantity) {
        // 具体订单生成逻辑
    }
}

public class SeckillServiceImpl extends AbstractSeckillService
        implements StockDeductionStrategy, OrderGenerationStrategy {
    @Override
    public boolean generateOrder(User user, Product product, int quantity) {
        // 调用接口方法实现订单生成
        return generate(user, product, quantity);
    }

    @Override
    public boolean deduct(Product product, int quantity) {
        // 调用抽象类中的通用扣减逻辑或自定义扣减逻辑
        return deductStock(product, quantity);
    }
}

涉及的设计模式

模板方法模式：
- 在AbstractSeckillService抽象类中，通过定义通用的模板方法，将一些通用的业务逻辑封装起来，而将具体的实现延迟到子类。如deductStock方法是通用的库存扣减模板，子类可以在继承后根据具体业务调整实现。
策略模式：
- 通过定义StockDeductionStrategy和OrderGenerationStrategy接口，不同的实现类可以代表不同的库存扣减策略和订单生成策略。具体的秒杀服务类可以根据业务需求选择不同的策略实现类，提高了代码的灵活性和可维护性。

应对分布式环境下的一致性问题

分布式锁：
- 使用分布式锁，如基于Redis的分布式锁，确保在分布式环境下同一时间只有一个节点能够进行库存扣减和订单生成操作。例如，在执行库存扣减前，先获取分布式锁：

public boolean tryDeductStock(Product product, int quantity) {
    Jedis jedis = new Jedis("localhost", 6379);
    String lockKey = "product:" + product.getId() + ":lock";
    String requestId = UUID.randomUUID().toString();
    boolean locked = jedis.set(lockKey, requestId, "NX", "EX", 10) != null;
    if (locked) {
        try {
            return deductStock(product, quantity);
        } finally {
            if (requestId.equals(jedis.get(lockKey))) {
                jedis.del(lockKey);
            }
        }
    }
    return false;
}

消息队列：
- 引入消息队列，如Kafka，将订单生成等操作异步化。当库存扣减成功后，发送一条消息到消息队列，由专门的消费者来处理订单生成，这样可以避免在高并发情况下直接处理订单生成导致的一致性问题。同时，消息队列可以保证消息的顺序性，有助于保证业务操作的一致性。
分布式事务：
- 采用分布式事务框架，如Seata，来保证库存扣减和订单生成在分布式环境下的一致性。Seata通过TC（Transaction Coordinator）、TM（Transaction Manager）和RM（Resource Manager）协同工作，实现分布式事务的管理。在库存扣减和订单生成操作开始前，TM向TC申请开启一个全局事务，RM在执行本地操作时向TC注册分支事务，最后由TC来协调各个分支事务的提交或回滚。

星途面试题库

面试题：Java接口与抽象类在高并发分布式系统设计模式中的考量

知识考点

面试题答案

Java接口与抽象类在该场景下的应用难点

利用它们设计高效、线程安全且具有良好扩展性架构的方法

涉及的设计模式

应对分布式环境下的一致性问题