项目功能模块分为采购、销售、库存、商品、会员、订单、客服、评论、供应商，商家后台、营销、财务、用户、秒杀子系统实现了商品、订单、会员、库存、评论、供应商、商家后台、用户、秒杀、客服、采购我负责哪些、订单，商品，秒杀使用了技术栈后端Mysql 数据库Redis 缓存nacos 注册中心Mybatis 对象关系映射框架Docker 应用容器引擎Elasticsearch 搜索引擎RabbitMQ 消息队列Redisson 分布式锁Springsession 分布式缓存Centos7 (Linux)Nginx HTTP和反向代理web服务器SpringCloud 微服务架构Sleuth 链路追踪Sentinel 分布式系统的流量防卫兵Kubernetes 容器编排前端vue 前端框架Element 前端UI框架node.js 服务端的jsthymeleaf 模板引擎商城业务-订单服务通过lure脚本原子验证令牌和删除令牌Feign异步调用丢失请求头问题RequestContextHolder.getRequestAttributes();获取当前线程请求头信息(解决Feign异步调用丢失请求头问题)Redis 缓存缓存-缓存使用-缓存击穿、穿透、雪崩高并发下缓存失效问题-缓存穿透缓存穿透指查询一个一定不存在的数据解决：null结果缓存，并加入短暂过期时间高并发下缓存失效问题-缓存雪崩缓存雪崩是指在我们设置缓存时ky采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB,DB瞬时压力过重雪崩。解决：原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。高并发下缓存失效问题-缓存击穿对于一些设置了过期时间的key,如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。如果这个ky在大量请求同时进来前正好失效，那么所有对这个key的数据查询都落到db,我们称为缓存击穿。解决：加锁大量并发只让一个去查，其他人等待，查到以后释放锁其他人获取到锁，先查缓存，就会有数据，不用去dbRabbitMQ 消息队列消息丢失、积压、重复等解决方案保证消息可靠性消息丢失: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、每一个发送的消息都在数据库做好记录。定期将失败的消息再次发送遍