简历原文

抽查部分 

• 基本了解RabbitMQ、Elasticsearch等微服务技术，对分布式事务、分布式缓存等有所学习；
• 熟悉数据库的基本操作，写过C#与数据库交互的项目；

模拟问答

1.你是如何保障消息可靠性的

从消息生产者到交换机，用return回调保证消息可靠性，这是消息级可靠，放在消息中定义；

从交换机到队列，用confirm回调保障消息可靠性，这是对象级可靠，放在template中定义；

从交换机到队列，做消息的持久化；

以上是发送的可靠性保障。

然后消费的可靠保障，就设置消息重试，包括发送消息重试、消费者重试，还有重试失败后的入库。

2.es有哪些数据类型？

常见类型：

1. 数字类型：long integer short byte double float half_float scaled_float unsigned_long
2. 关键字：
      keyword  用于索引的关键字
      constant_keyword  始终包含相同值的关键字字段
      wildcard  可用于通配符模糊查询的关键字
3. 时间类型dates：包括date和date_nanos。
4. 别名alias
5. 文本text：分词查询的文本。

 对象关系类型：

1. object：单个JSON对象
2. nested：JSON对象数组
3. join：定义同一索引中的文档的父子关系

结构化类型：

1. geo-point：维度、经度
2. geo-shape：描述多边形等形状的
3. point：笛卡尔坐标点
4. shape：笛卡尔任意集合图形

3.你是用什么做分布式事务的，能介绍一下吗

我用的是Seata做分布式事务管理的。

Seata事务管理中有3个角色，分别是事务协调者TC(Transaction Coordinator)、事务管理器TM(Transaction Manager)还有资源管理器RM(Resource Manager)。可以简单理解为公司里的Boss、领导和员工。而公司一般有3中运营模式：

①XA模式

第一阶段

首先Boss定方向，要开始做项目了，叫领导们开始管员工，员工上班打卡（1.1开启全局事务  1.2调用分支  1.3注册分支事务）

然后员工开始做事（1.4执行业务sql，但不提交）

然后员工报告给boss（1.5报告事务状态）

第二阶段

然后领导说boss你看看着项目咱还要不要接着干，要不要重新干，要不要finish（2.1提交、回滚全局事务）

boss看项目的报表，看事情办的怎么样（2.2检查分支事务状态）

boss一看，哎呀这A组没办好啊，给我重新做！（①如果有失败，通知所有RM回滚事务）

或者boss一看，哎呀办的不错啊，好，项目做完了，放假放假，发奖金发奖金（②如果都成功，通知所有RM提交事务）

XA模式牺牲了可用性，保证了强一致性

这是什么意思呢？就是3个组程序组客户组扫地组在干活，程序组写完项目了，扫地组地也拖好了（RM执行分支业务sql），兴致勃勃的跑到办公室准备把结果告诉给boss，让他完结项目，领奖金假期了（TC提交事务），结果看到boss黑着脸在拉着A组员工一顿训，原来是客户组办事不力，全员摸鱼（RM中有的事务失败），好了，这下项目失败了，啥也别想了，假期泡汤了，奖金飞走了，啥也不说了，项目只能推倒重来了。

你说程序组扫地组气不气？气死了，把客户组成员祖宗十八代给*￥%^&，但你说他们咋想的？看到客户组成员后来陪着笑脸发了3天零食，看到客户小姐姐快要哭出来的眼睛，还是想，哎，咱还是一个team，对内对外都要一致，不一起搞出来项目还是不去找客户了

②AT模式

AT模式也大差不差。

第一阶段

boss投钱开始搞项目（1.1开启全局事务），叫领导开管（1.2调用分支），员工开始上班打卡（1.3注册分支事务），开始做事（1.4执行业务sql并提交），做完之后报告（1.5报告事务状态）

不同的地方在于，这次程序组客户组扫地组都留了个心眼，程序做完一部分代码就买一部分服务，客户组小姐姐陪完一个客户就拉到公司搞定一个，扫地组每天都勤勤恳恳扫地让老板看见……（1.4执行业务sql并提交）

第二阶段

第二阶段也大差不差，领导提议要不要继续下去（2.1提交、回滚全局事务），boss检查项目做的怎么样（2.2检查分支事务状态），boss觉得做的好项目就finish了（2.3提交）客户资料就放那垫桌角生灰去了（2.4删除log），做的不好就不干了/重新做（2.3回滚），顺便把客户绑回来叫他把程序吐出来（2.5恢复log数据）。

正按这个流程走呢，结果第二天扫地组出去度假了，地没拖好，boss进门滑了一跤，摔进了icu，好，项目又泡汤了。

AT模式牺牲了一致性，保证了可用性

接下来该咋办？程序组呆在家里突突突、博德之门3去了，客户组出去陪小姐姐了，扫地组哭天喊地去了，项目搞完了把我晾在一边，拿着我的工资享受，还把我给摔了，躺在病床上的boss越想越气，越想越气，于是把呼吸机的管拔了，拄着拐杖一瘸一拐的来到公司，直接把客户资料和服务器都烧了。

AT模式在事务失败的情况下，保证了微服务对外提供服务，但最终的状态一致性无法保证。一旦出问题，还是要把之前处理好的业务推倒重来。

③TCC模式

 就点拨一句，TCC就相当于员工影分身，一个分身3个，一个人干活，一个人准备成功情况给boss报喜，一个准备失败了赶紧删资料跑路。

优点是一致性、可用性都很高，缺点是代码量很大

4.你说你学习了分布式缓存，你们处理了缓存穿透问题吗

我们碰到了缓存穿透问题，并作了相应处理。

缓存穿透说的是这样一个问题：如果一个数据在各个多级缓存包括数据库中，比如Redis和MySQL中都没有，那么我在查询的时候每次都会进入数据库查询，这就会造成资源被占用，恶意利用可能会导致服务器崩溃。

一种解决方法是将这个key值置null放入缓存。但这样空占空间，最后可能导致业务数据都没地方放。

还有一种比较合理成熟的方案，就是采用布隆过滤器。

布隆过滤器将传输进来的数据根据算法，映射到一个二进制向量/位图上。

我们将所有已有的数据传入，根据哈希算法，映射到位图上。接下来传入其他数据，再用哈希算法检验，如果得出结果为1，则说明有数据，则放行访问；如果结果为0，说明没有，则直接返回。

值得注意的是，只有一个哈希算法时，检验结果可能很不准确，大量不存在的数据可能还是能访问到穿透的地方。这时候我们可以引入更多的不同的哈希算法，来进行检验，增加数据的准确性。

但过多的哈希算法，又会带来性能的下降。所以我们一般用适当数量的哈希算法。

5.有没有做过数据库优化，怎么做呢

就拿MySQL来说吧。对于需要优化的，查询慢的数据库，分三种情况讨论：

1. 单条SQL运行慢
2. 部分SQL运行慢
3. 整个SQL运行慢

单条SQL运行慢

对于第一种情况，单条SQL运行慢，一般有两种常见原因：

1. 未正常创建或使用索引
2. 表中数据量太多了

首先，我们检查是否正常创建了索引；

然后，检查是否正常触发了索引查询。

以下情况不能触发索引，应该避免：

1. 在 where 子句中使用 != 或者 <> 操作符，查询引用进行的是全表扫描；

2. 前导模糊查询时触发的时全索引扫描或全表扫描，因为它不能利用索引的顺序、得一个个去找。也就是查询时不能用这样的字段： '%XX' 或 '%XX%'；

3. 带有条件or，or条件中不是每个列都有索引时。这时候必须在每个列上面都加上索引才能触发索引查询；

4. 在 where 子句中对字段进行表达式操作。

以下技巧可以优化索引查询的速度：

1. 尽量使用主键查询，而非其他索引，因为主键查询不会触发回表查询；

2. 查询语句尽可能简单，大语句拆小语句，减少锁时间；

3. 尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型；

4. 用 exists 替代 in 查询；

5. 避免在索引列上使用 is null 和 is not null。

其次，对于数据量过大的数据库，我们可以作数据拆分。

数据拆分分为垂直拆分和水平拆分。

垂直拆分一般这样来拆分：

• 把不常用的字段单独放在一张表；

• 把 text，blog 等大字段拆分出来放在附表中；

• 经常组合查询的列放在一张表中。

表的行数一般超过200万行时，查询就会变慢。这时候就可以拆分成多个表来存放数据。 这就是水平拆分。

部分SQL运行慢

为了定位这些慢查询的SQL，我们可以开启慢查询分析。

整个SQL运行慢

我们可以进行读写分离。

6.简单介绍一下你这个C#数据库项目

我这是一个自动拨叉脚整形机项目，从前端WPF界面输入数据，然后传入后端，存入数据库；还可以从前端输入拨叉数据，然后调用机器学习模型，得到预测结果显示到WPF界面上。