3年经验面试题汇总+自我解答（每天更新一点）

一.微服务之间是如何独立通讯的？

同步：

1 Rest Http协议

2 RPC TCP协议

异步：

二. 项目中缓存如何使用的？为什么要用缓存？缓存使用不当会造成什么后果？

使用方向：

字典项 、菜单配置、系统参数、登录token、session

要用缓存原因：

高性能

对于一个请求，耗时几百毫秒查出一个结果，然后这个操作员就用了一次，这很浪费。

而同一个不经常改变的结果，从缓存取，只需要几毫秒。

高并发

redis官方测评数据，每秒10W左右的读写，而mysql远远达不到这个数量。

不当的后果？

缓存与数据库双写不一致问题
如何保证缓存与数据库的双写一致性。
1 读请求和写请求串行化，串到一个内存队列里去。（串行可以解决不一致情况，但是会导致系统吞吐量降低，用比正常多几倍的机器去支撑线上的一个请求）
2 Cache Aside Pattern
最经典的缓存+数据库读写的模式。

• 读的时候先读缓存，没有的话就读数据库，然后取出数据放入缓存，同时返回响应。
• 更新的时候，先更新数据库，然后删除缓存。（为什么是删除缓存，而不更新缓存？原因：复杂业务中，你缓存的这个值，并不是直接对应数据库里面的值，而是可能经过某些运算后，才存入的值。另外，你这个数据是不是冷数据：数据库里更新多，读少，缓存没被频繁访问，此时用到再去算缓存比较合适）（当然，先更新再删除，如果删除失败仍然会导致数据不一致问题，这个时候，可以采用先删除后更新的方案）

三. 为什么进行分库分表？（涉及到高并发的时候，原来公司在数据库层面使用什么方案）分库分表用过哪些中间件？这些中间件有什么有趣点？你原来公司是怎么进行数据库水平或者垂直拆分的？

为什么进行分库分表？

分表：

单一表的数据量太大，达到几百万的时候，sql执行性能就会变差，这个时候就需要把一个表的数据拆到多个表中。

分库：

以一般经验来看，一个数据库最多支撑2000并发，就需要扩容，这个时候把一个数据库的数据拆分到多个多个库中，承受的并发将提高多倍

分库分表用过哪些中间件？

DDS 华为自研

没有开源，这个就不多说了

Sharding-jdbc

当当网开源的，属于client层方案，支持分库分表，读写分离，分布式ID生成，柔性事务

Mycat

是阿里的Cobar改良而来，属于proxy层方案

他们有什么优缺点？

首先，Mycat和Sharding-jdbc这两种中间件，我并没有用过

根据网上的回答，整理一下

ShardingJdbc:

优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能高，缺点在于耦合，如果遇到升级，各个系统都需要重新升级再发布，各个系统都耦合Sharding-Jdbc的依赖

Mycat

这种proxy层的缺点在于需要部署，自己运维一套中间件，运维成本高，好处是对于各个项目是透明的，如果遇到升级，自己中间件那里搞就行

我原来公司如何进行水平或者垂直拆分数据库的

水平拆分和垂直拆分同时用。

首先使用垂直拆分，化为两个模块，一个是基本不变的公共资源库，里面存放菜单 字典 系统参数之类的数据

然后把第一次水平拆分称为一级分库，根据新政区划这个字段，把全国的数据划分为几部分，然后放到不同的库里。

但是有的进行一级分库之后，从省份来看，有的省份的数据依然是大的，这个时候就进行二级分库，也就是把省里的数据进行第二次水平拆分。我们制定一个二级分库字段，进行hash一下均匀分散，这样可以平均分配每个库的数据量和请求压力

四开发流程有哪些步骤

1. 需求分析
2. 设计文档（powerdesigner设计好数据模型，然后建表，分析需要多少个类，先起好名字）
3. 详设文档（后端接口开发，先提前写好伪代码，精确到对应entity和三层结构）
4. 编码开发（补充详细逻辑，完成后端接口开发，本地postman自测，然后再开发前台）
5. showcase
6. 测试
7. 改Bug