商城系统难点

一、商品秒杀

1.秒杀系统的两个问题：

高并发和超卖

2.高并发问题的解决办法：

高并发就是同一时间，请求量极大，如果全都访问数据库的话，数据库压力过大，查询会变慢甚至会导致服务挂掉，我们采用的是加入了缓存，使用redis作为缓存服务器，这样可以极大的降低数据库压力

3.redis造成的缓存雪崩问题：

缓存雪崩就是缓存服务器挂了，请求瞬间都打到了数据库里，这里要保证redis服务高可用，采用的方式是搭建集群的方式

4.redis造成的缓存击穿问题：

缓存击穿问题就是有用户恶意地访问一些数据库不存在的数据，数据不存在则不会往缓存里放，这个时候可以对空数据进行缓存，等他再次访问的时候，我们把这个空数据返回给他，缓存时间要设置短一些，避免有数据后长时间无法获取；或者对短时间内多次访问一些不存在的数据，我们可以禁用他的IP

5.超卖问题的解决方式：

提前把秒杀商品的库存数量缓存到redis中，如果有用户下单，先在redis里进行预扣减库存，当用户支付在扣减数据库里的库存，如果一定时间内没有支付再还原库存；还可以使用RocketMQ发送创建订单的消息，对它们进行排队，将前面的订单创建成功，后面的创建失败

6.为什么要使用RocketMQ？

它是远程消息队列，支持事务，可以保障消息不丢失

7.还了解过哪些其它的消息队列？

kafka,rabbitmq等

二、分布式事务

1.什么是分布式事务？为什么要使用分布式事务？

分布式事务就是在分布式系统使用事务。当设计了多个服务的数据存储，这个时候每个服务的变化都要成功才算整个业务流的成功，只要有一个失败了，则整体算做失败，这时候就需要使用分布式事务来解决数据的ACID特性

2.项目中哪里用到了分布式事务？

在创建订单扣减库存的时候使用了分布式事务，因为订单表和商品表在不同的微服务模块中

3.用了什么分布式框架？

阿里巴巴的seata分布式框架

4.分布式事务和分布式锁的区别：

分布式事务是解决流程化的问题，分布式锁是解决资源占用问题

5.什么是数据一致性？

（1）数据更新成功返回客户端之后，所有节点的数据保持一致，没有中间状态

（2）强一致性:时刻保证数据一致性

（3）最终一致性:一段时间后保证数据一致性

（4）允许存在部分数据不一致:弱数据一致性

6.什么是cap定理？

web服务无法同时满足cap定理

c一致性(Consistency):更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，不能存在中间状态。

a 可用性(Availability):系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果，

p 分区容错性(Partition tolerance):即使出现单个组件无法可用，操作依然可以完成

7.分布式事务有哪些解决方案？

（1）2pc:二阶段提交，强一致性设计，引入一个事务协调者的角色来协调管理各参与者(也可称之为各本地资源)的提交和回滚，二阶段分别指的是准备和提交两个阶段。同步阻塞，存在长事务风险。
                                          准备提交阶段-提交阶段

（2）3pc:在2pc之后多加入预提交阶段，和超时。预提交阶段主要是询问事务参与者是否能正常有条件的执行。
                                 准备提交阶段-预提交阶段-提交阶段

（3）Tcc:2PC 和 3PC 都是数据库层面的，而 TCC 是业务层面的分布式事务，需要自己实现Try-Confirm-Cancel三个方法，存在代码入侵业务紧耦合问题。

Try 指的是预留，即资源的预留和锁定

Confirm 指的是确认操作，这一步其实就是真正的执行了

Cancel指的是撤销操作，可以理解为把预留阶段的动作撤销了

8.什么是消息事务？

RocketMQ很好支持消息事务,本地执行事务前发送消息，本地事务失败则丢弃消息，本地执行成功，消息订阅方执行本地事务，成功之后消费消息。