# 1.介绍一下你在公司的职能
方面面试官了解目前岗位职能，日常工作(业务+技术点)
# 2.介绍一个你觉得最有价值的项目
# 2.1 业务层面介绍(业务栈)
# 2.2 技术层面介绍(技术栈)
这里可以引入自己非常熟悉的知识点，引导面试官下一个问题往这上面提问。
# 3.(前面引入)分布式事务在业务上如何落地的
# 4.(前面引入)Redis和DB一致性问题的解决方案
# 4.1 缓存读写策略
Cache Aside Pattern（旁路缓存模式)
读
读Cache,存在直接返回,不存在再从DB中读取并且放回Cache
写
先更新DB,然后直接删除Cache
Read/Write Through Pattern（读写穿透）
读
读Cache,存在直接返回,不存在再从DB中读取并且放回Cache
写
读Cache,不存在时直接更新DB。存在时更新Cache,然后进行Cache和DB同步更新。
Write Behind Pattern（异步缓存写入)
和读写穿透很相似,都是由Cache负责Cache和DB的读写更新.读写穿透是同步更新Cache和DB,但是异步缓存写入是只更新Cache,不直接更新DB,才用异步批量的方式更新DB。
此方式适合一些写入频繁，但是数据一致性要求不高场景。
# 4.2 Cache和DB操作顺序
- 先更新Cache,再更新DB
无法保证两次更新均成功,可能存在缓存中为新数据,但DB中仍然是旧数据
- 先更新DB,再更新缓存
并发情况下两个线程进行操作可能导致Cache和DB数据不一致问题。
假设请求 A 先操作数据库，请求 B 后操作数据库，但是可能存在请求 B 先写缓存，请求 A 后写缓存的情况，从而导致数据库与缓存之间的数据不一致。
- 先写DB,再删除Cache
业务如何保证写DB和删除Cache为原子操作,否则会出现写入DB但是Cache未做删除操作，导致数据一致性问题。
- 请求1从DB中读取数据A数据
- 请求2写操作更新DB中A数据,并且删除Cache中A数据
- 请求1将数据A写入Cache
- 先删除Cache,再更新DB
先删Cache,在写入DB之前，若有另外请求读取Cache未命中时,读取DB中‘旧’值将其更新回Cache,此时Cache中为旧值,DB中为新值。
- 请求1将Cache中数据A删除
- 请求2从Cache中读取A数据时未命中,查询DB并将其回写到Cache中
- 请求1继续将DB中A数据更新
# 4.3 保证一致性解决方案
- 采用延时双删策略
- 异步更新缓存策略(订阅binlog的同步机制)
- 混合存储优化方案
# 5.说一个你最了解中间件(Dubbo)
# 5.1 Dubbo设计观念(插件+微内核)
# 5.2 SPI
# 5.3 RPC调用原理
# 5.4 Dubbo序列化方式是否存在问题
# 6.解决的生产问题
# 6.1 Dubbo的热加载问题(版本bug)
# 6.2 单号生成方式导致问题
这个问题可以引入分布式下单号生成的几种方案。
# 7.消息队列是怎么使用的
# 7.1 推拉模式
消息队列核心应用场景:削峰、异步和解耦。那么在消息队列中消息模式有推拉模式。
Push模式
Push模式是服务端根据用户需要，有目的、定时将数据推送到客户端。
- [优点]对客户端要求第,方便客户端获取数据。
- [优点]及时性好，服务端及时向客户端推送消息，吞吐量大。
- [缺点]不能够保证发送成功,push采用广播模式
- [缺点]没有消息状态跟踪，客户端是否成功接收到信息无法得知，存在消息丢失问题。
- [缺点]针对性差,无法满足客户端定制化需求。
- [缺点]客户端消费能力弱时，容易造成消息对接
Pull模式
客户端主动向服务端获取信息。
- [优点]针对性强，可满足客户端定制化需求。
- [优点]信息传输量小,该次网络请求中只有客户端请求和服务端响应数据
- [优点]服务端压力较小,只是被动地响应客户端请求。客户端根据自身消费能力拉取。
- [缺点]实时性较差,对于服务端实时更新数据客户端无法感知,无法获得实时数据
- [缺点]对客户端要求较高