尚硅谷面试题——第一季（二）

MyBatis中实体属性与表中字段不对应

1. 书写SQL使用别名
2. 驼峰命名情况下，使用<setting name="mapUnderscreToCamelCase" value="true" />开启转换
3. 使用ResultMap手动转换

Linux系统常用服务类命令

centos6：

service
 - 注册在系统中的标准化程序
 - 有方便统一的管理方式
   - service 服务名 start
   - service 服务名 stop
   - service 服务名 restart
   - service 服务名 reload
   - service 服务名 status
- 查看服务的方法 /etc/init.d/服务名
- 通过chkconfig命令设置自启动
   - 查看服务 chkconfig --list|grep xxx
   - chkconfig --level 运行级别 服务名 on

centos7:

systemctl
 - 注册在系统中的标准化程序
 - 有方便统一的管理方式
   - systemctl 服务名 start
   - systemctl 服务名 stop
   - systemctl 服务名 restart
   - systemctl 服务名 reload
   - systemctl 服务名 status
- 查看服务的方法 /usr/lib/systemd/system
- 查看服务的命令
   - systemctl list-unit-files
   - systemctl --type service
- 通过systemctl命令设置自启动
   - 自启动:systemctl enable service_name
   - 不自启动：systemctl disable service_name

git分支相关命令

创建分支：

git branch <分支名>
git branch -v 查看分支

切换分支：

git checkout <分支名>
一步完成：git checkout -b <分支名>

合并分支：

先切换到主干 git checkout master
git merge <分支名>

删除分支：

先切换到主干 git checkou master
git branch -D <分支名>

redis持久化类型与区别

RDB：
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

Redis会单独创建爱你(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不尽兴任何I/O操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

优点：

• 节省磁盘空间
• 恢复速度快

缺点：

• 虽然Redis在fork时使用了写时复制技术，但是如果数据庞大时还是比较消耗性能。
• 在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会是最后一次快照后的所有修改。

AOF：
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，Redis启动之初就会读取该文件重新构建数据，换言之，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF同步频率设置：

• 始终同步：每次Redis的写入都会立刻记入日志
• 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失
• 不主动进行同步，把同步时机交给操作系统

# If unsure, use "everysec".

# appendfsync always
appendfsync everysec
# appendfsync no

rewrite：
AOF采用文件追加的方式，文件会越来越大。为避免出现此种情况，新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可使用命令bgrewriteaof

Redis如何实现重写？
AOF文件持续增长而过大时，会fork出一条新进程来讲文件重写（也是先写临时文件最后再rename），遍历新进程的内存中数据，每条记录有一条Set语句。重写aof文件的操作并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

何时重写？
重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为bash_size，如果Redis的AOF当前大小>= (base_size + base_size * 100%)（默认）且当前大小>= 64mb（默认）的情况下，Redis会对AOF进行重写。

优点：

• 备份机制更文件，丢失数据概率更低。
• 可读的日志文本，通过操作AOF文件，可以处理误操作。

缺点：

• 比RDB占用更多的磁盘空间。
• 恢复备份速度较慢。
• 每次读写都同步的话，有一定性能压力。
• 存在个别Bug，造成恢复不能。

MySQL什么时候适合创建索引

适合建索引：

1. 主键自动建立唯一索引
2. 频繁作为查询条件的字段应该创建索引
3. 查询中与它表关联的字段，外键关系建立索引
4. 单键/组合索引的选择问题，组合索引性价比更高
5. 查询中排序的字段，排序字段若通过索引去访问将大大提高排序速度
6. 查询中统计成分或者分组字段（先排序，再分组）

不适合建索引：

1. 表记录太少
2. 经常增删改的表或字段
3. Where条件里用不到的字段
4. 过滤性不好的不适合建索引（过滤性不好:性别；好：手机号）

Elasticsearch和Solr的区别

背景：它们都是基于Lucene搜索服务基础之上开发的高性能搜索服务器。（都是基于分词器构建倒排索引的方式进行查询）
开发语言：java
诞生时间：Solr，2004；Es，2010.

区别：

1. 当实时建立索引的时候，solr会产生io阻塞，而es不会，es查询性能要高于solr。
2. 在不断动态添加数据的时候，solr的检索效率会变得低下，而es则没有什么变化。
3. Solr利用zookeeper进行分布式管理，而Es自身带有分布式系统管理功能。Solr一般都是部署到Web服务器上，比如tomcat。启动Tomcat的时候需要配置tomcat与solr的关联。（Solr的本质是一个动态web项目）
4. Solr支持更多格式的数据【xml，json，csv等】，而es仅支持json文件格式。
5. Solr是传统搜索应用额有力解决方案，但是es更适用与新兴的实时搜索应用。

单纯的对已有数据进行检索的时候，solr效率更好，高于es。Solr官网提供额功能更多，而Es本身更注重于核心功能，高级功能多由第三方提供。

消息队列在项目中的使用

背景：在分布式系统中是如何处理高并发的。

由于在高并发的环境下在高并发的环境下，来不及同步处理yoghurt发送的请求，则会导致请求发生阻塞。比如说大量的insert，update之类的请求同时到达数据库MySQL，直接导致无数的行锁表锁，甚至会导致请求堆积很多，从而触发too many connections错误。使用消息队列可以解决【异步通信】。

1. 异步
   

2. 并行
   

3. 排队
   

消息队列在电商中的使用场景：