以下的知识点全部输出思维导图
- MySQL（6月27日前完成80%， 周末输出部分重点图例）
Redis（补充思维导图- 6月28日到7月4日）
Spring Cloud（7月5日到7月11日 - 补充思维导图）
- JVM（跟Redis，Spring Coloud一起复习）
设计模式（每日进行）
并发编程（每天学习）
- RocketMQ（7月12日到7月18日）
事务消息
死信队列
延迟队列
思维导图
技术上面有什么难点，是怎么解决这些难点的
Nginx如何实现负载均衡
SpringBoot（7月19日到7月27日， 循环依赖？starter等，基础）
SpringMVC（过滤器，基础注解等）
项目整理，结合已有知识体系扩展
最重要的项目模块（结合设计模式）
Redis是单线程还是多线程，这个需要研究透彻
1、处理消息堆积问题
直接手动清除不必要的消息
后期增大messageQueue和Consumer机器，增加并行消费线程。提高消费速度。
2、使用建造者模式开发支付申请模块（微信特约商户，支付宝商户代申请）
支付宝代签约：https://opendocs.alipay.com/apis/api_50/alipay.open.agent.mini.create
使用原型模式设计设备注册流程
3、fegin远程调用，包含降级处理
提高第三方支付效率。
相关的appid，appsecret，会根据商户号存储在缓存服务中，缓存服务内会将数据存储在redis当中，先从redis中获取appid等配置信息，如果没有，再从数据库当中进行获取。
修改了商户的appid信息，会删除原来的redis缓存，然后更新数据表中对应的数据；
后面就会发送一条MQ消息，缓存服务消费MQ的消息，重新往redis中写入新的数据。
mqtt和rocketmq
会员累计购买达到指定金额，会派发红包，累计指定积分，积分兑换礼品。
使用的是MQ的事务消息，保证了消息的不丢失
交易失败，订单状态为未支付，自动退款。。。（弹簧柜，不出货->已取消；重力柜，已出货-> 未支付（支付分可以进行手动催收））
记录交易失败的原因
重力柜下单完整流程（生成订单，扣减库存，扣减金额，通知出货， 订单取消，订单退款）
扫码开门前的一些判断信息，从Redis缓存中获取。如果存在缓存，说明未支付，黑名单等。如果不存在缓存，需要查询对应的数据表，有记录，说明未支付，黑名单等，无记录，则说明可以执行下一步的下单操作。
每一次记录的变更，会先将缓存删除，然后更新数据库，最后重新写入缓存。保证缓存和数据库的双写一致性。
（如果是更新缓存，然后再更新数据库，可能这一步骤里面，更新数据库失败了，但是更新缓存成功，那就会存在不一致的情况。如果是直接删除缓存，然后更新数据库，即使更新数据库失败，后面重新写入的缓存，也是从数据库中获取到旧值写入到缓存里面的，数据库和缓存的数据还是保持一致）。
—以上保证数据库缓存双写一致性的方案 ， 针对的是 读写不并发的场景。
如果业务存在读写并发场景，可能会存在数据不一致的情况。
因为，写请求在先删除缓存之后，读请求并发去读取缓存，会发现缓存未命中，此时，会直接获取数据库的旧值，写入缓存。然后写请求更新数据库成功，数据库的值为新值。 此时 缓存和数据库不一致。
弹簧柜下单完整流程（生成订单，扣减库存，扣减金额，通知出货，订单取消，订单退款）
（延迟发送一个查询订单出货状态的MQ）监听是否完成出货，如果扣减了金额不出货，则需要完成自动退款
（延迟发送一个查询订单出货状态的MQ）监听是否完成出货，如果没有扣减金额，则需要自动完成取消
（延迟发送一个查询订单出货状态的MQ）订单正常出货，检查订单支付状态，状态未更新，则自动更新，异步推送消费成功的通知。
支付中心调用订单中心，更新订单状态，如果更新失败，直接回滚，退回支付金额。
支付中心使用MQ是为了消息重发吗？处理失败，消息重新消费5次
支付中心->可靠消息服务->订单中心
多线程负责多数据的归档统计，（分布式调度处理）
订单分账模块
分账消息， Producer发送消息丢失， Consumer拉取消息丢失，（具体什么场景下，Recosumer.later）？
会员中心模块，，订单拆分模块（单独的服务，redis pub sub订阅机制）
https://www.cnblogs.com/dengguangxue/p/11537466.html
https://artisan.blog.csdn.net/article/details/105940406
https://blog.csdn.net/u011489043/article/details/78780255
为什么使用redis pub/sub机制，而不是MQ机制？
基于这个场景，使用频率不会太高，然后，关于创建订单回调与完结订单回调的逻辑其实都是在一个服务里面的，MQ更多是应用在服务之间的异步调用当中。MQ的集群模式下，消息的消费也是随机一个消费者进行消费的。
订单拆分服务只有单独的一个微服务，一切的逻辑都是在此进行处理，关键的步骤是在
（1）进行创建订单业务回调处理后，触发订单拆分服务pub一个关于该笔订单的创建状态消息到订单创建channel，然后再由本服务去消费channel里的消息，触发去执行完结订单的操作；
（2）在进行完结订单业务回调处理后，再触发订单拆分服务pub一个关于该笔订单的完结状态消息到订单完结channel，然后再有本服务区消费channel里的消息，触发去执行下一笔拆分订单的操作；
（3） 第（1）（2）步骤反复循环执行，直到所有的拆分订单的订单状态都为已支付，就会终止循环。
（每一次回调就会实时更新数据库订单状态，单条记录，只更新订单状态，更新快）。
补偿机制，支付分催收，可以从未完结的拆分订单下继续进行支付，同样会走redis pub/sub机制去处理。
部署mysql读写分离架构，主要设计一个从库负责报表的数据查询
重构支付中心模块（设计模式， 建造者模式，单例模式，工厂模式，策略模式）
一级缓存：对于历史收入，历史订单，销售趋势，历史销售排行
二级缓存（Redis）：今日订单的实时更新，一笔新订单生成，MQ异步推送至缓存服务，完成对应机构的实时订单信息的变化。
三级缓存（JVM）：本地缓存，存储近1小时前的一些热点数据，如果redis数据访问不到，则访问本地的JVM缓存。
优惠券服务， 存在多套规则设置商品的优惠（机构，设备，用户使用次数，用户充值金额，用户等级等等）—缓存存储信息
数据库缓存双写一致性问题（了解）
使用阻塞队列完成订单拆分功能
MQ：监控设备状态 （实时监控温度状态（报警处理），货道商品数量）。
网上查阅有关设备监控的知识。
单例模式：支付宝支付参数配置
微信订阅消息推送
消息订阅通知服务
数据大屏，（缓存，商品修改，订单生成等事件mq推送，实时更新数据大屏信息）
Java基础源码（彤哥读源码）
计算机网络
面试连环炮整理
基本源码阅读
Dubbo
SPI思想
Zookeeper
ZAB协议
应用场景
分布式锁
存储+通知
容器技术Docker
Linux基础命令
算法（剑指offer相关算法题）
事务在抛出异常后的回滚，如果捕获了异常，事务会不会回滚
已知的儒猿面经
晋升制度是什么样的
每年的调薪次数，调薪比例
五险一金缴纳比例
公司的具体项目介绍，项目成果
公司使用的技术栈有哪些
是否有定期的技术分享交流，按照什么样的形式
我也希望 ， 下一份工作，公司可以给我提供一个技术快速成长的平台，可以有大量的技术挑战，
我也想是，接下来，往架构师的方向去发展，多思考一些业务架构，基础架构，提升自己的技术栈，和解决业务难题的能力，设计优秀的系统的架构能力
个人有什么缺点，有什么优点？
自我介绍
项目介绍
项目需求确认，时间规划，项目迭代
项目负责模块：订单，会员，支付中心，负责微信支付宝，第三方支付对接，重力柜购买流程，弹簧柜购买流程（分布式事务-（tcc-seate，最终一致性消息事务）怎么写？）
创建订单支付，分布式锁？那一个部分加了分布式锁（扣减库存）
java集合， hashMap，coucurrentHashMap
线上生产环境优化
若有收获，就点个赞吧
0 人点赞
