项目面试问题

最新推荐文章于 2024-10-31 00:04:25 发布

Tony_yitao

最新推荐文章于 2024-10-31 00:04:25 发布

阅读量518

点赞数 10

文章标签：面试

本文链接：https://blog.csdn.net/tony_yitao/article/details/141635176

版权

一、需求和解决方案（以商城项目为例）

没有最优方案，只有最适合方案。业务量和业务需求不同，需要的方案也会不同。某个方案在某种业务背景下合适，放到另外一个业务需求下可能并不合适。

（一）减库存和支付订单的顺序问题

1.先扣减库存再支付

如果有人恶意刷单不支付订单会影响商品正常售卖。这种情况针对客户端可以限制每个IP每天的下单数量；针对服务器端当用户下订单并扣减库存后立马锁定库存，半个小时如果用户没有支付订单或者订单支付失败则自动释放库存给其他用户购买。

2.先支付再扣减库存

如果用户已经支付，后面库存不够给用户发货了就需要给用户退款，这会给用户造成很不好的体验。针对这种情况可以借助消息中间件来实现支付和扣减库存的解耦，当用户支付成功后发送支付成功的消息到MQ，当订单服务监听消息队列中支付成功的消息后扣减库存。

二、亮点/难点

（一）遇到的问题，分析方法，解决方案、上线情况

star（situation、task、action、result），遇到什么问题？在完成什么任务时遇到这个问题的？遇到问题后的行动是什么？执行行动后上线后的结果是什么？

（二）案例一：缓存

在开发完XXX服务进行压测时发现，当QPS达到5000时整个服务的响应时间在3s左右，这个响应时间对用户来说是不能接受的，因此尝试通过加Redis缓存来提高系统响应时间，在把数据加入缓存时对数据进行了分析，只把请求频率比较高的数据加入缓存以保证缓存的高速响应。上线之后发现整个系统的响应时间由原来的3s左右变成了50ms左右，数据响应时间整整提高5倍左右。

（三）案例二：Hystrix隔离策略

在使用SpringCloud Alibaba体系下的Feign组件进行RPC远程服务调用时，Hystrix熔断组件的隔离级别应该设置成SEMAPHORE而不是THREAD，前者是信号量隔离模式后者是线程池隔离模式（Hystrix组件默认的隔离模式），在线程池隔离模式下当前服务是拿不到远程服务的实例的因此无法完成远程服务中方法的调用，因为THREAD里面是通过ThreadLocal实现的，而ThreadLocal是线程私有的，所以在当前服务的主线程中拿不到子线程中的远程服务的实例。而SEMAPHORE是线程共享的设计思想，因此主线程可以拿到子线程中远程服务的实例并完成远程服务中目标方法的调用。

三、分布式锁

分布式锁的实现有四种方式：Mysql、etcd、Redis、Zookeeper，最后两种方式使用较多。

（一）Redis实现分布式锁（高性能）

如果要实现高性能的分布式锁就选择通过Redis来实现，其缺陷是如果只是在单个机器上实现分布式锁，这台机器宕机那么其中的锁业务就会瘫痪。因此，一般情况下是本着“一主二从三哨兵”的原则在多态机器上实现分布式锁，但是在多台机器上实现分布式锁会存在数据一致性问题，就是用户1在主节点上已经加锁成功，其锁资源还没有及时同步到从节点就挂了，那么用户2又可以从从节点获取到锁资源，其实用户1此时已经持有了Redis的锁资源还未释放，这个时候用户2再获取到锁资源是不合理的，这就是Redis实现分布式锁虽然高性能但存在的问题。