项目功能模块分为采购、销售、库存、商品、会员、订单、客服、评论、供应商，商家后台、营销、财务、用户、秒杀子系统

实现了商品、订单、会员、库存、评论、供应商、商家后台、用户、秒杀、客服、采购

我负责哪些、订单，商品，秒杀
使用了技术栈
后端
Mysql 数据库
Redis 缓存
nacos 注册中心
Mybatis 对象关系映射框架
Docker 应用容器引擎
Elasticsearch 搜索引擎
RabbitMQ 消息队列
Redisson 分布式锁
Springsession 分布式缓存
Centos7 (Linux)
Nginx HTTP和反向代理web服务器
SpringCloud 微服务架构
Sleuth 链路追踪
Sentinel 分布式系统的流量防卫兵
Kubernetes 容器编排

前端
vue 前端框架
Element 前端UI框架
node.js 服务端的js
thymeleaf 模板引擎

商城业务-订单服务
通过lure脚本原子验证令牌和删除令牌
Feign异步调用丢失请求头问题
RequestContextHolder.getRequestAttributes();
获取当前线程请求头信息(解决Feign异步调用丢失请求头问题)


Redis 缓存
缓存-缓存使用-缓存击穿、穿透、雪崩

高并发下缓存失效问题-缓存穿透
缓存穿透指查询一个一定不存在的数据
解决：
null结果缓存，并加入短暂过期时间

高并发下缓存失效问题-缓存雪崩
缓存雪崩是指在我们设置缓存时ky采用了相同的过期时间，
导致缓存在某一时刻同时失效，
请求全部转发到DB,DB瞬时压力过重雪崩。
解决：
原有的失效时间基础上增加一个随机值，比如1-5分钟
随机，这样每一个缓存的过期时间的重复率就会降低，
就很难引发集体失效的事件。

高并发下缓存失效问题-缓存击穿
对于一些设置了过期时间的key,如果这些key可能
会在某些时间点被超高并发地访问，是一种非常“热
点”的数据。
如果这个ky在大量请求同时进来前正好失效，那么
所有对这个key的数据查询都落到db,我们称为缓存
击穿。
解决：
加锁
大量并发只让一个去查，其他人等待，查到以后释放锁
其他人获取到锁，先查缓存，就会有数据，不用去db


RabbitMQ 消息队列
消息丢失、积压、重复等解决方案

保证消息可靠性

消息丢失:
1.由于网络问题没有抵达服务器
解决方案:
做好容错方法(try-catch),发送消息可能会网络失败，失败后要有重试机制，可记录到数据库，采用定期扫描重发的方式
保证消息一定会发送出去，每一个消息都可以做好日志记录（给数据库保存每一个消息的详细信息）
定期扫描数据库将失败的消息再发送一遍
2.消息抵达Broker,Broker要将消息写入磁盘（持久化）才算成功。此时Brokeri尚未持久化完成，宕机。
解决方案:
publishert也必须加入确认回调机制，确认成功的消息，修改数据库消息状态
3.自动ACK的状态下。消费者收到消息，但没来得及消息然后宕机
解决方案：
一定开后手动ACK,消费成功才移除，失败或者没来得及处理就noAck井重新入队

消息重复:
1.成功消费，ack时宕机，消息由unacked变为ready,Broker又重新发送
2.消息消费失败，由于重试机制，自动又将消息发送出去
解决方案:
消费者的业务消费接口应该设计为幂等性的。比如扣库存有工作单的状态标志
使用防重表(redis/mysql)),发送消息每一个都有业务的唯一标识，处理过就不用处理
rabbitMQ的每一个消息都有redelivered字段，可以获取是否是被重新投递过来的，而不是第一次投递过来的

消息积压:
1.消费者宕机积压
2.消费者消费能力不足积压
3.发送者发送流量太大
解决方案:
上线更多的消费者，进行正常消费
上线专门的队列消费服务，将消息先批量取出来，记录数据库，离线慢慢处理

柔性事务-可靠消息+最终一致性方案
防止消息丢失：
1、做好消息确认机制(pulisher,consumer[手动ack])
2、每一个发送的消息都在数据库做好记录。定期将失败的消息再次发送遍