面试话术

RabbitMq1、介绍一下rabbitmq2、如何保证消息确定消息发送成功，并且被消费成功，有什么保障措施3、如何保证消息不被重复消费4、RabbitMQ 宕机了怎么处理

授权话术1、你给我说一下授权认证（登陆注册）的逻辑2、说一下jwt3、说一下auth2.0机制

Nginx1、介绍一下nginx2、nginx如何处理http请求3、nginx常用命令4、什么是动静分离，为什么要动静分离5、如何保证nginx高可用6、nginx如何配置负载均衡

Redis1、介绍一下redis2、redis缓存雪崩和缓存穿透、缓存预热、缓存降级3、redis分布式锁4、redis主从复制5、redis集群6、除了redis，还了解哪些别的非关系型数据库7、redis数据同步8、介绍一下redis的pipeline9、介绍下redis中key的过期策略

工作流1、工作流话术

Spring1、介绍一下spring2、AOP的实现原理3、详细介绍下IOC容器4、`@Autowired` 和 `@Resource`的区别5、springbean的生命周期6、springbean的作用域7、事务的传播特性8、事务的隔离级别9、spring中都用了哪些设计模式10、spring中如何处理bean在线程并发时线程安全问题

SpringMvc1、介绍一下springMVC2、springMVC的执行流程3、springMVC接收前台参数的几种方式4、springMVC中的常用注解5、spring如何整合springMVC

Mybatis1、介绍一下mybatis，说一下它的优点和缺点是什么？2、**MyBatis与Hibernate有哪些不同**？3、#{}和${}的区别是什么？4、当实体类中的属性名和表中的字段名不一样 ，怎么办 ？5、通常一个Xml映射文件，都会写一个Dao接口与之对应，这个Dao接口的工作原理是什么？Dao接口里的方法，参数不同时，方法能重载吗？6、mybatis 如何执行批量插入?7、mybatis 如何获取自动生成的(主)键值?8、在mapper中如何传递多个参数?9、Mybatis有哪些动态sql？10、Xml映射文件中，除了常见的select|insert|updae|delete标签之外，还有哪些标签？11、Mybatis的Xml映射文件中，不同的Xml映射文件，id是否可以重复？12、Mybatis的一级、二级缓存？13、使用MyBatis的mapper接口调用时有哪些要求？14、mybatis plus 了解过么？和mybatis有啥区别？15、MyBatis框架及原理？

线程1、创建线程的方式2、线程都有哪些方法3、sleep和wait的区别4、介绍下你理解的线程中的锁5、线程池的原理6、线程池的核心参数都有哪些

锁1、介绍一下乐观锁和悲观锁2、介绍一下公平锁和非公平锁3、重入锁（递归锁）和不可重入锁（自旋锁）4、共享锁和独占锁5、synchronized和threadlocal的区别6、ConcurrentHashMap如何实现线程安全

Mysql1、解释一下单列索引和联合索引2、使用索引查询的优缺点3、mysql存储引擎都有哪些，有什么区别4、创建索引的原则5、如何查看查询语句索引是否生效6、有没有做过数据库建模，自己是设计表和模块7、左连接、右连接、内连接的区别8、 count(1)和count(*) 有什么区别9、mysql查询语句的优化？10、mysql批量插入5000条数据如何优化？11、mysql查询重复数据？12、了解过MySQL存储过程和视图吗，介绍一下13、where和having的区别14、数据库三范式介绍一下15、select语句的执行顺序16、mysql分库分表介绍下

linux1、linux常用命令2、服务器CPU一直100%，如何定位问题谈谈你能想到的思路

RabbitMq

1、介绍一下rabbitmq

RabbitMQ是Erlang语言开发的基于AMQP的一款消息中间件，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先发送给交换机，然后由交换机转发给对应的队列。对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的支持。

它里边有5种数据传递方式

第一种是简单模型，一个生产者，一个队列，一个消费者，队列只能被一个消费者监听，所以生产者将消息发给队列之后，只能有一个消费者收到消息

第二种是工作模型，一个生产者，一个队列，多个消费者，队列可以被多个消费者监听，但是生产者将消息发给队列之后，还是只能有一个消费者接收到消息

后边三种都叫订阅模型，这三种里边引入了交换机的概念，具体的区分是根据交换机的类型区分的，在这三种模式种，生产者把消息发送给交换机，交换机不负责存储消息，由交换机发送给指定的队列，消费者监听队列消费消息。

首先是fanout类型，这种叫广播模式，生产者将消息发送给交换机，交换机会将消息转发给所有绑定到到当前交换机的队列中，对应监听队列的消费者都能收到消息，但是，如果没有队列绑定到这个交换机，消息会被mq丢弃。

接着是direct类型，这种叫定向模式，也叫路由模式，这种模式中，队列在绑定交换机的时候，同时指定了自己的routing key，可以理解为一个路由标示，生产者在发送消息给交换机的时候，同时指定要发送给的routing key，这时候，交换机就会根据这个routing key来定向的发送给对应的队列，对应监听该routing key的队列的消费者就能收到消息，但是如果交换机没有找到对应的routing key，消息会被丢弃。

最后是topic模式，这种叫通配符模式，队列在绑定交换机的时候，同时指定了自己的routing key，生产者在发送消息给交换机的时候，同时指定要发送给的routing key 的通配符，一般这个routing key是由多个单词用.的方式隔开的，通配符中，#号可以匹配一个或者多个单词，*号只能匹配一个单词，例如生产者指定的通配符为a.#，可以匹配到的routing key有：a.b、a.b.c等，如果是a.*的话，只能匹配a.b或者是a.c这样的routing key。每个队列绑定到交换机的时候可以定义多个routing key，交换机会跟据指定的通配符，发送到匹配通配符的routing key 对应的队列中，对应的消费者就可以收到消息了，但是，如果没有符合通配符的routing key ，消息会被丢弃

当然，在生产中使用的时候，为了避免mq宕掉等造成消息丢失的问题，我们都会配置持久化措施，在rabbitmq里，需要将交换机持和队列和消息持久化，这样消息就会被持久化到磁盘中，不会因为突发的断电等情况导致消息丢失

2、如何保证消息确定消息发送成功，并且被消费成功，有什么保障措施

解析：这里不用背，这里的问法会有很多中，这道题中问了两部分

第一部分是确保发送成功，还可以被问成：消息发送失败了怎么办，或者如何保证消息可靠传输

第二部分是确保消费成功，还可以被问成：消息消费时，发生异常了，消息已经被消费了，怎么办等

首先，需要确保消息被发送成功，rabbitmq中提供了事物和confirm的机制，事物的话，就类似于数据库的事物，开启，执行，提交，如果过程中发生任何异常，就会触发回滚机制，我们可以在回滚中加入一些逻辑处理，重新发送或者日志记录，同时配置生产者确认的机制，就是在消息发送之后，该消息会被指定唯一的ID，如果有消息成功被交换机转发到队列之后，mq会给生产者发送ack确认，如果没有队列接收消息，那么会发送错误回执消息给生产者，生产者可以尝试重试发送，或者日志记录。通过这些可以看出，mq会增加一些保障性措施，必然会导致性能有一些下降，如果要保证消息的严格一致性，那么可以配置这些，如果消息不重要，或者允许有丢失的情况，那么可以不用配置，这样的话能提升mq的性能。

其次就是，消息确保发送成功之后，还要确保消息被消费成功，因为在消费者端，如果消息消费时发生异常，又没有做一些处理，那么消息就会丢失，这种情况，可以采取两种方式解决

第一种就是消费端配置手动ACK确认机制，消息被消费完成的时候，手动确认告诉mq消费成功，mq才会删除消息，如果消息被接收了，但是mq没有收到ack确认，那么消息在mq中会变为unacked状态，我们可以通过项目日志或者mq面板监控，当消费者断开连接之后，消息会重新回到队列中，消费者重新连接之后，会再次收到消息。

第二种就是可以结合数据库解决，生产者端发送成功之后，可以在数据库中存储发送的消息和发送时间，并标记状态为未消费状态，消费者端消费完成之后，标记mysql中数据的状态为已经消费。消费者端通过定时任务去数据库跑批检索超时未被消费的消息并重新发送，这种方式可以很好的解决消费失败的问题，但是增加了生产者和消费者之间的耦合度，以及会造成消息重复消费的问题，我们可以在保证消息发送成功的基础上，将上述逻辑放在消费者端，生产者正常发送消息，消费者在收到消息之后，存储到myqsl中，标记状态为未消费，同时ack通知mq确认，然后再消费消息，消息消费成功之后，改变mysql状态为已消费，消费端同时配置定时任务跑批检索数据库，定时重新执行超时未消费的消息。

以上的解决办法都是需要根据实际的业务需求来的，如果消息需要保证强一致性，不能出现任何差错，那么就需要按照前面说的添加对应的配置

我们项目中的mq主要用于数据同步使用的，mysql数据发生变化之后，需要同步到es索引库以及静态化页面中，这里我们配置了生产者确认模式，和消费者手动ack确认机制。

3、如何保证消息不被重复消费

我们可以在生产者端，发送消息时，数据的变动部分，进行md5加密处理，同时配置上一个唯一id，每次发送的数据的唯一id是递增的，相当于版本号的功能，在消费者端，收到消息之后，首先去数据库匹配一下md5值如果数据库中记录的当前记录已经被消费，那么就不进行消费，如果发现数据库没有记录当前消息，或者记录的状态没有被消费，那么才会重新消费该消息

4、RabbitMQ 宕机了怎么处理

RabbitMQ 提供了持久化的机制，将内存中的消息持久化到硬盘上，即使重启 RabbitMQ，消息也不会丢失。持久化队列和非持久化队列的区别是，持久化队列会被保存在磁盘中，固定并持久的存储，当 Rabbit 服务重启后，该队列会保持原来的状态在RabbitMQ 中被管理，而非持久化队列不会被保存在磁盘中，Rabbit 服务重启后队列就会消失。非持久化比持久化的优势就是，由于非持久化不需要保存在磁盘中，所以使用速度就比持久化队列快。即是非持久化的性能要高于持久化。而持久化的优点就是消息会一直存在，不会随服务的重启或服务器的宕机而消失。使用的时候需要根据实际需求来判断具体如何使用。

授权话术

1、你给我说一下授权认证（登陆注册）的逻辑

这块来说就比较简单了，我们提供的注册功能有用户名密码注册，手机号注册，微信登陆绑定注册功能

用户名密码注册登陆 我们系统规定的是用户名不得重复，注册的时候，会去做一下重复校验，向后台提交注册信息的时候，密码都会经过md5加密传输，到后台会首先用加密工具生成32位的盐值，然后把用户名通过md5加密之后，用户名的md5和密码的md5和盐值结合之后，生成md5值，然后一起存入数据库，用户登录的时候，按照首先根据用户名去数据库查找用户，找出来用户之后，根据相同的逻辑计算加密之后的密码和数据库的密码对比，对比一致则登陆成功 手机号注册登陆（推荐使用，方便快捷） 这里用到了阿里的短信服务功能，注册的时候，手机号码校验通过之后，向用户手机发送验证码，后台将验证码和手机号对应关系存入redis，用户提交注册之后，验证码跟redis中对比即可 微信登陆绑定系统用户注册 这里结合微信登陆使用的，微信登陆之后，如果发现对应openid没有绑定系统用户，需要提示用户去绑定，然后才能注册

常识：微信开发，有两个平台，

微信开放平台，主要用于app端以及web端扫码登录等开发，app中，微信登陆，微信支付，微信分享等

微信公众平台，主要用于微信网页开发，公众号开发，公众号中网页登陆，微信分享，微信支付等

web端微信扫码登录 微信开放平台注册开发者帐号，并拥有一个已审核通过的网站应用，并获得相应的AppID和AppSecret。申请微信登录且通过审核后，可开始接入流程。就是你的网站要想实现微信扫码登陆功能首先要在微信备案通过，它才会给你个AppID和AppSecret。 1、用户点击网站微信登陆图标。 2、网站带上AppID和回调域名参数请求微信OAuth2.0授权登陆。 3、第二步通过后，微信返回二维码供用户扫码。 4、用户扫码确定授权。 5、微信带上code参数回调java后端回调地址。 6、java后端获取到code后，在带上带上AppID和AppSecret和code再去调微信接口获取access_token。 7、获取access_token后就可以解析用户的一些基本信息，比如：微信用户头像、用户名、性别、城市等一些基本参数。

微信app登陆 因为是app登陆，需要用到微信开放平台的接入功能，微信登陆采用的auth2.0的验证机制，在开放平台里注册了账号并通过企业认证，获取了AppID 和 AppSecret之后，第一步我们的服务器先获取code，传给移动端，移动端跟微信交互，用户确认授权之后，然后移动端请求我们后台获取用户信息，我们后台会先去用code获取access_token，然后在通过access_token获取用户信息，同时会返回用户的openId，我们会根据这个openId去我们的数据库查，是否已经获取过用户信息，如果获取过用户信息，看一下最后获取时间，因为每3天更新一次，所以这里会看一下是否需要重新获取如果没有获取过用户信息，会通过access_token获取用户信息，提示绑定系统用户，access_token失效时间为2个小时，因为微信有接口请求次数限制，2小时之内不会再去请求微信的access_token

因为我们系统是微服务架构，所以这里使用jwt实现了单点登录，因为平台有很多，有web端、管理端，还有一个清结算平台，实现单点登录会更方便用户使用，登录之后，给用户颁发了一个token令牌，每次请求的时候，都会在请求头里携带这个token，经过我们的网关的时候，会对这个token做一个权限认证，认证通过，然后才能请求到我们的微服务具体的接口

2、说一下jwt

微服务集群中的每个服务，对外提供的都是Rest风格的接口。而Rest风格的一个最重要的规范就是：服务的无状态性，即：

服务端不保存任何客户端请求者信息客户端的每次请求必须具备自描述信息，通过这些信息识别客户端身份，一般这里就是token登陆令牌

这样做的话，会有很多好处，比如

客户端请求不依赖服务端的信息，任何多次请求不需要必须访问到同一台服务服务端的集群和状态对客户端透明服务端可以任意的迁移和伸缩减小服务端存储压力

我们项目中也是采用的无状态登陆，使用token作为身份认证的令牌，这个token就是使用jwt生成的，jwt类型的token分为三部分，头部，载荷，签名，头部存储一些识别信息，载荷存储一些用户的基本字段，我们存储的是id的username，签名是通过头部和载荷外加RAS非对称加密生成的

3、说一下auth2.0机制

其实就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。

令牌（token）与密码（password）的作用是一样的，都可以进入系统，但是还是有一些差异的。

（1）令牌是短期的，到期会自动失效，用户自己无法修改。密码一般长期有效，用户不修改，就不会发生变化。

（2）令牌可以被数据所有者撤销，会立即失效。以上例而言，屋主可以随时取消快递员的令牌。密码一般不允许被他人撤销。

（3）令牌有权限范围（scope），比如只能进小区的二号门。对于网络服务来说，只读令牌就比读写令牌更安全。密码一般是完整权限。

有了这些设计，保证了令牌既可以让第三方应用获得权限，同时又随时可控，不会危及系统安全。这就是 OAuth 2.0 的优点。

注意，只要知道了令牌，就能进入系统。系统一般不会再次确认身份，所以令牌必须保密，泄漏令牌与泄漏密码的后果是一样的。这也是为什么令牌的有效期，一般都设置得很短的原因。

具体来说，auth2.0一共分成四种授权类型

第一种是授权码模式，这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。比如A应用想要获取B应用的用户数据，A会首先访问B的授权页面，用户点击确认授权之后，B会请求A配置的回调地址，同时附带上授权码code，A可以通过这个code向B申请登录令牌access_token，获取到登录令牌之后，然后就可以向B应用请求用户信息数据了。最常见的就是微信登陆等第三方登录都用的这种方式。

还有就是隐藏式、密码式、客户端凭证等三种模式，我这边就是大概了解了一下，实际没有使用过。

Nginx

1、介绍一下nginx

Nginx 是一个高性能的 HTTP 和反向代理服务器，具有反向代理和负载均衡以及动静分离等功能

我先来说说反向代理功能吧

反向代理是指以代理服务器来接受用户的请求，然后将请求，分发给内部网络上的服务器，并将从服务器上得到的结果返回给用户，此时代理服务器对外就表现为一个反向代理服务器。 反向代理总结就一句话就是：代理端代理的是服务端。

反向代理的话，只需要配置对应的server模块就行了，里面配置上server_name和对应监听的端口，然后在配置location路径转发规则就行，当然也可以配置代理静态资源

再来说说负载均衡吧，负载均衡即是代理服务器将接收的请求均衡的分发到各服务器中，负载均衡主要解决网络拥塞问题，提高服务器响应速度，服务就近提供，达到更好的访问质量，减少后台服务器大并发压力，同时还可以保证服务端的高可用。常用的nginx的负载均衡策略有轮训、权重、iphash、最少连接数，默认的策略就是轮训

负载均衡这里需要配置upstream模块，在upstream中配置好当前的负载均衡规则，然后配置好每个server对应的ip端口即可，在server模块配置的转发规则就时向这个upstream上转发就行了

2、nginx如何处理http请求

Nginx这块的处理时结合多进程机制和异步机制 ，异步机制使用的是异步非阻塞方式

首先呢是多进程机制

服务器每当收到一个客户端请求时，就有服务器主进程 （ master process ）生成一个 子进程（ worker process ）出来和客户端建立连接进行交互，直到连接断开，该子进程就结束了。

使用进程的好处是各个进程之间相互独立，不需要加锁，减少了使用锁对性能造成影响，同时降低编程的复杂度，降低开发成本。接着呢就是采用独立的进程，可以让进程互相之间不会影响 ，如果一个进程发生异常退出时，其它进程正常工作， master 进程则很快启动新的 worker 进程，确保服务不会中断，从而将风险降到最低。缺点是操作系统生成一个子进程需要进行 内存复制等操作，在资源和时间上会产生一定的开销。当有大量请求时，会导致系统性能下降

还有就是异步非阻塞机制

每个工作进程 使用 异步非阻塞方式 ，可以处理多个客户端请求 。

当某个工作进程接收到客户端的请求以后，调用 IO 进行处理，如果不能立即得到结果，就去 处理其他请求 （这就是非阻塞 ）；而 客户端 在此期间也 无需等待响应 ，可以去处理其他事情（这就是异步 ）。

当 IO 返回时，就会通知此工作进程 ；该进程得到通知，暂时挂起 当前处理的事务去响应客户端请求 。

3、nginx常用命令

启动：nginx

当我们修改配置了之后，重启：nginx -s reload

停止nginx：nginx -s stop

4、什么是动静分离，为什么要动静分离

这个我理解的来说就是把前端静态资源和后台请求分离开，主要就是为了提升静态资源的访问速度，一般前后端分离的项目用的居多，分离之后，我们可以把静态资源放入cdn中去，可以实现用户的就近访问，同时还提供了更大的带宽。

5、如何保证nginx高可用

因为nginx是我们所有项目的入口，必须要保证nginx的高可用，这里一般都用的nginx集群，并同时加入了keepalive来做的双机热备处理，通过请求一个vip（virtual ip：虚拟ip）来达到请求真实IP地址的功能，而VIP能够在一台机器发生故障时候，自动漂移到另外一台机器上，从来达到了高可用的功能

6、nginx如何配置负载均衡

Redis

1、介绍一下redis

Redis是一个非关系数据库，我们项目中主要用它来存储热点数据的，减轻数据库的压力，单线程纯内存操作，采用了非阻塞IO多路复用机制，就是单线程监听，我们项目中使用springdata-redis来操作redis

我们项目中使用redis的地方很多，比方说首页的热点数据，数据字典里的数据等都用热地说存储来提高访问速度

redis呢有5种数据类型，string、list、hash、set、zset，我们常用的有string、list和hash，一些简单的key-value类型的都存储在string类型中，比如一些系统开关之类的，是否开放注册等，还有一些存储在hash中，比如我们的首页的推荐数据和热门数据，都是用hash来存储的，一个固定的字符串作为key，每条数据的id作为field，对应的数据作为value存储

redis还有两种持久化方式，一个是RDB，这也是redis默认的持久化方式，这种方式是以快照的方式存储数据，在固定的时间段内如果有多少变化，那么就会生成快照存储到磁盘上，redis 在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。对于 RDB 方式，redis 会单独创建一个子进程来进行持久化，而主进程是不会进行任何 IO 操作的，这样就确保了 redis 极高的性能。 这种方式的优点呢就是快，但是如果没等到持久化开始redis宕机了，那么就会造成数据丢失

还有一种是AOF，是即时性的持久化方式，是将 redis 执行过的所有写指令记录下来，在下次 redis 重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。AOF的方式会导致性能下降

两种方式可以同时开启，当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。

我们项目中使用的持久化方式就是默认的RDB，因为我们存储的数据首先来说不是很重要的数据，如果丢失了，还可以从数据库加载到，主要用的就是性能这块

2、redis缓存雪崩和缓存穿透、缓存预热、缓存降级

缓存雪崩

我们可以简单的理解为：由于原有缓存失效，新缓存还没有存入到redis的期间

比方说：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

解决办法：

加最多的解决方案就是锁，或者队列的方式来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。还有一个简单方案就是缓存失效时间分散开，不设置固定的实效时间，采用随机失效的策略来解决

缓存穿透：

缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空，这就相当于进行了两次无用的查询。像这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题

解决办法

最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法，如果一个查询返回的数据为空，不管是数据不存在，还是系统故障，我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

缓存预热：

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

操作方式：

1、直接写个缓存刷新页面，上线时手工操作下；

2、数据量不大，可以在项目启动的时候自动进行加载；

然后就是缓存更新：

1、定时去清理过期的缓存；

2.、当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存

缓存降级：

当访问量剧增、服务出现问题，比如响应时间慢或不响应，或者非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有问题的服务。redis可以帮助系统实现数据降级载体，系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。降级的最终目的是保证核心服务可用，即使是有损的。

3、redis分布式锁

这个分布式锁这里，我们原来传统的项目都在单台服务器上部署用java里的锁synchronized这个同步锁就行，但是他这个是针对对象的锁，但是我们分布式的项目需要把项目部署到多台服务器上，每台服务器的对象都不同，所以就得考虑用分布式锁，这块实现起来也比较简单，其实这个锁就是redis中的一个key-value的一对值，在使用的时候吧，首先使用setnx方法进行尝试加锁，并可以设置过期时间，如果返回1则代表加锁成功，然后立即对这个锁设置一个实效时间，防止服务宕机，锁一致存在，在处理完业务逻辑之后，删除锁就行了，其他线程就可以获取锁进行业务了

4、redis主从复制

通过持久化功能，Redis保证了即使在服务器重启的情况下也不会损失（或少量损失）数据，因为持久化会把内存中数据保存到硬盘上，重启会从硬盘上加载数据。但是由于数据是存储在一台服务器上的，如果这台服务器出现硬盘故障等问题，也会导致数据丢失。为了避免单点故障，通常的做法是将数据库复制多个副本以部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务。为此， Redis 提供了复制功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。

Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步，配置非常简单，只需要在从节点配置slave of主节点的ip即可，如果有密码，还需要配置上密码，从节点只能读数据，不能写数据

全量同步主要发生在初次同步的时候，大概的步骤是

从服务器连接主服务器，发送SYNC命令；主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

还有就是增量同步，主要发生在redis的工作过程中，Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

5、redis集群

Redis本身就支持集群操作redis_cluster，集群至少需要3主3从，且每个实例使用不同的配置文件，主从不用配置，集群会自己选举主数据库和从数据库，为了保证选举过程最后能选出leader，就一定不能出现两台机器得票相同的僵局，所以一般的，要求集群的server数量一定要是奇数，也就是2n+1台，并且，如果集群出现问题，其中存活的机器必须大于n+1台，否则leader无法获得多数server的支持，系统就自动挂掉。所以一般是3个或者3个以上的奇数节点。

Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。哨兵的作用就是监控redis主、从数据库是否正常运行，主数据库出现故障自动将从数据库转换为主数据库

我们公司搭建的redis集群是用的ruby脚本配合搭建的，我们一共搭建了6台服务器，3主3备，他们之间通信的原理是有一个乒乓协议进行通信的，我再给你说下一他们往里存储数据的机制吧，其实这个redis搭建好集群以后每个节点都存放着一个hash槽，每次往里存储数据的时候，redis都会根据存储进来的key值算出一个hash值，通过这个hash值可以判断到底应该存储到哪一个哈希槽中，取的时候也是这么取的，这就是我了解的redis集群

6、除了redis，还了解哪些别的非关系型数据库

有memacache，MongoDB这些，以及redis这几个都是非关系型数据库

memacache是纯内存型的，只支持简单的字符串数据，并且value值最大只能是1MB，而且所有的数据都只能存储在内存中，如果服务宕机或者关机重启，数据就会丢失，没有持久化功能

MongoDB的话是存储的数据都在磁盘上，功能比较多，不过性能没有其他两种好

而redis呢，支持的数据类型比较多，而且速度也非常快，value最大可以支持到512MB，而且既可以把数据存储在内存里，也可以持久化到磁盘上，重启之后还可以把磁盘中的数据重新加载到内存里，从性能以及数据安全上来说，都比memacache和MongoDB好一些

7、redis数据同步

这一块主要是跟mysql数据同步吧，mysql数据可能会发生变动，那么redis就要跟数据库的数据保持一致我们实际去使用的时候，是在数据发生变动的地方，比如增删改的时候，新奇一个线程，然后将变动的数据更新到redis中，根据不同的场景需求，也可以在数据变动时，把redis里的数据删掉，下一次用户查询的时候，发现redis中没有数据，就会重新去数据库加载一遍，这样也可以实现同步的效果

8、介绍一下redis的pipeline

pipeline的话，就是可以批量执行请求的命令

我们都知道redis是单线程的，在执行命令的时候，其他客户端是阻塞状态的，如果在高并发的时候，其实是会影响一定效率的，所以redis提供了pipeline，可以让我们批量执行命令，大大的减少了IO阻塞以及访问效率

因为pipeline是批量执行命令，我们一般会结合redis的事物去使用，它也符合事务的ACID特性，MULTI开启事物，EXEC执行，DISCARD清除事物状态，回到非事物状态，在使用前，还可以结合WATCH监控来使用，如果我们在执行一组命令的过程中，不想让其中的某个值被其他客户端改动，就可以使用WATCH，使用了之后，如果被改动，事务会自动回滚，可以很好的保证我们批量执行命令的时候，数据的准确性，在使用完成之后，可以使用UNWATCH解除监控。

9、介绍下redis中key的过期策略

定时删除：在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时间来临时，对key进行删除

惰性删除：key过期的时候不删除，每次从数据库获取key的时候去检查是否过期，若过期，则删除，返回null

定期删除：每隔一段时间执行一次删除过期key操作

redis 过期策略是：定期删除+惰性删除。

所谓定期删除，指的是 redis 默认是每隔 100ms 就随机抽取一些设置了过期时间的 key，检查其是否过期，如果过期就删除。

工作流

1、工作流话术

工作流这块儿。嗯，实际在工作中使用的时候，activiti用的居多，当然还有一些其他的工作流引擎，嗯，在网上看了也大概看了一下，其他的像JBPM以及workflow等用的情况来讲不是很多，所以说activity目前来讲用的比较多的，它最新的版本是5.0，那他在用的时候在数据库里边儿需要，嗯，有23张表，然后在23张表里边儿会记录着所有的这些工作都是相关流程相关所有的数据。

在用的时候呢，首先就是要配置它的23张表，在数据库先创建了一下这些表。然后呢，去加载activity的配置文件。这里加载那会有两种方式，嗯，我在写这个demo的时候，而写的是用spring去加载他的一个xml配置文件，这配置文件里边儿，他就跟spring去整合其他的一些框架的时候是一样的，这个xml里边儿配置了一些这个它的的一个核心的引擎的管理器ProcessEngineConfiguration，还有一些它的数据库连接啊等等。然后给他放到了spring的配置文件中。

然后就是需要去定义一个流程。这里呢，我使用的是一个eclipse的插件，通过画流程图的方式去定义了一个简单的理由请假的流程。然后生成了一个zip的压缩包。

接下来呢，需要把这个流程部署到Activity中。通过processEngine获取到Deployment部署的类，定义一个流程名称，然后将这个压缩包，部署到activity中。这时会返回一个流程id

然后需要去启动流程实例。流程部署好了呢，如果说实际有人去发起一个请假流程，这时候需要去启动一个新的流程实例，每个流程实例会有一个独立的id。这个流程上还可以设计一些流程变量。可以是全局的，也可以是局部的。这些变量会在整个流程当中。根据它的性质去向下传递。它后台会有一个taskservice会去数据库检索待处理的任务。然后去处理就就行。处理完成之后，嗯，后边儿这个流程示例会继续向下一个节点去进行。下一个节点收到任务之后，同样通过taskservice去处理。最终直到这个任务被执行完。

总结来看呢，这个activity通过代码的方式简化了实际工作当中一些流程性的问题。当然它这里边儿还会有一些复杂的流程。包括，如何去呃多人同时处理任务呀，以及一些复杂的节点等等，大致这就是我了解的activity工作流。

Spring

1、介绍一下spring

关于Spring的话，我们平时做项目一直都在用，不管是使用ssh还是使用ssm，都可以整合。Spring里面主要的就三点，也就是核心思想，IOC控制反转，DI依赖注入，AOP切面编程

我先来说说IOC吧，IOC就是spring里的控制反转，把类的控制权呢交给spring来管理，我们在使用的时候，在spring的配置文件中，配置好bean标签，以及类的全路径，如果有参数，然后在配置上相应的参数。这样的话，spring就会给我们通过反射的机制实例化这个类，同时放到spring容器当中去。

我们在使用的时候，需要结合DI依赖注入使用，把我们想使用的类注入到需要的地方就可以，依赖注入的方式有构造器注入、getset注入还有注解注入。我们现在都使用@autowired或者@Resource注解的方式注入。

然后就是AOP切面编程，他可以在不改变源代码的情况下对代码功能的一个增强。我们在配置文件中配置好切点，然后去实现切面的逻辑就可以实现代码增强，这个代码增强，包括在切点的执行前，执行中，执行后都可以进行增强逻辑处理，不用改变源代码，这块我们项目中一般用于权限认证、日志、事务处理这几个地方。

2、AOP的实现原理

这块呢，我看过spring的源码，底层就是动态代理来实现的，所谓的动态代理就是说 AOP 框架不会去修改字节码，而是每次运行时在内存中临时为方法生成一个 AOP 对象，这个 AOP 对象包含了 ，目标对象的全部方法，并且在特定的切点做了增强处理，并回调原对象的方法。

Spring AOP 中的动态代理主要有两种方式，JDK 动态代理和 CGLIB 动态代理：

JDK 动态代理只提供接口的代理，不支持类的代理。核心InvocationHandler 接口和 Proxy 类，InvocationHandler 通过 invoke()方法反射来调用目标类中的代码，动态地将横切逻辑和业务编织在一起；接着，Proxy 利用InvocationHandler 动态创建一个符合接口的的实例，生成目标类的代理对象。 如果代理类没有实现 InvocationHandler 接口，那么 Spring AOP 会选择使用 CGLIB 来动态代理目标类。CGLIB（Code Generation Library），是一个代码生成的类库，可以在运行时动态的生成指定类的一个子类对象，并覆盖其中特定方法并添加增强代码，从而实现 AOP。CGLIB 是通过继承的方式做的动态代理，因此如果某个类被标记为 final，那么它是无法使用 CGLIB 做动态代理的。不过在我们的业务场景中没有代理过final的类，基本上都代理的controller层实现权限以及日志，还有就是service层实现事务统一管理

3、详细介绍下IOC容器

Spring 提供了两种 IoC 容器，分别为 BeanFactory 和 ApplicationContext

BeanFactory 是基础类型的 IoC 容器，提供了完整的 IoC 服务支持。简单来说，BeanFactory 就是一个管理 Bean 的工厂，它主要负责初始化各种 Bean，并调用它们的生命周期方法。

ApplicationContext 是 BeanFactory 的子接口，也被称为应用上下文。它不仅提供了 BeanFactory 的所有功能，还添加了对 i18n（国际化）、资源访问、事件传播等方面的良好支持。

他俩的主要区别在于，如果 Bean 的某一个属性没有注入，则使用 BeanFacotry 加载后，在第一次调用 getBean() 方法时会抛出异常，但是呢ApplicationContext 会在初始化时自检，这样有利于检查所依赖的属性是否注入。

因此，在实际开发中，通常都选择使用 ApplicationContext

4、@Autowired 和 @Resource的区别

@Autowired 默认是按照类型注入的，如果这个类型没找到，会根据名称去注入，如果在用的时候需要指定名称，可以加注解@Qualifier("指定名称的类")

@Resource注解也可以从容器中注入bean，默认是按照名称注入的，如果这个名称的没找到，就会按照类型去找，也可以在注解里直接指定名称@Resource(name="类的名称")

5、springbean的生命周期

生命周期这块无非就是从创建到销毁的过程

spring容器可以管理 singleton 作用域 Bean 的生命周期，在此作用域下，Spring 能够精确地知道该 Bean 何时被创建，何时初始化完成，以及何时被销毁。

而对于 prototype 作用域的 Bean，Spring 只负责创建，当容器创建了 Bean 的实例后，Bean 的实例就交给客户端代码管理，Spring 容器将不再跟踪其生命周期。每次客户端请求 prototype 作用域的 Bean 时，Spring 容器都会创建一个新的实例，并且不会管那些被配置成 prototype 作用域的 Bean 的生命周期。

整体来说就4个步骤：实例化bean，属性赋值，初始化bean，销毁bean

首先就是实例化bean，容器通过获取BeanDefinition对象中的信息进行实例化 然后呢就是属性赋值，利用依赖注入完成 Bean 中所有属性值的配置注入 接着就是初始化bean，如果在配置文件中通过 init-method 属性指定了初始化方法，则调用该初始化方法。 最后就是销毁bean，和init-method一样，通过给destroy-method指定函数，就可以在bean销毁前执行指定的逻辑

6、springbean的作用域

Spring 容器中的 bean 可以分为 5 个范围：

（1）singleton：单例模式，使用 singleton 定义的 Bean 在 Spring 容器中只有一个实例，这也是 Bean 默认的作用域。 controller、service、dao层基本都是singleton的

（2）prototype：原型模式，每次通过 Spring 容器获取 prototype 定义的 Bean 时，容器都将创建一个新的 Bean 实例。

（3）request：在一次 HTTP 请求中，容器会返回该 Bean 的同一个实例。而对不同的 HTTP 请求，会返回不同的实例，该作用域仅在当前 HTTP Request 内有效。

（4）session：在一次 HTTP Session 中，容器会返回该 Bean 的同一个实例。而对不同的 HTTP 请求，会返回不同的实例，该作用域仅在当前 HTTP Session 内有效。

（5）global-session：全局作用域，在一个全局的 HTTP Session 中，容器会返回该 Bean 的同一个实例。

7、事务的传播特性

解读：事务的传播特性发生在事务方法与非事物方法之间相互调用的时候，在事务管理过程中，传播行为可以控制是否需要创建事务以及如何创建事务

属性名称值描 述PROPAGATION_REQUIREDrequired支持当前事务。如果 A 方法已经在事务中，则 B 事务将直接使用。否则将创建新事务，默认就是这个PROPAGATION_SUPPORTSsupports支持当前事务。如果 A 方法已经在事务中，则 B 事务将直接使用。否则将以非事务状态执行PROPAGATION_MANDATORYmandatory支持当前事务。如果 A 方法没有事务，则抛出异常PROPAGATION_REQUIRES_NEWrequires_new将创建新的事务，如果 A 方法已经在事务中，则将 A 事务挂起PROPAGATION_NOT_SUPPORTEDnot_supported不支持当前事务，总是以非事务状态执行。如果 A 方法已经在事务中，则将其挂起PROPAGATION_NEVERnever不支持当前事务，如果 A 方法在事务中，则抛出异常PROPAGATION.NESTEDnested嵌套事务，底层将使用 Savepoint 形成嵌套事务

8、事务的隔离级别

Spring 事务的本质其实就是数据库对事务的支持，没有数据库的事务支持，spring是无法提供事务功能的。真正的数据库层的事务提交和回滚是通过 binlog实现的。隔离级别有四种

Read uncommitted (读未提交)：读未提交，允许另外一个事务可以看到这个事务未提交的数据，最低级别，任何情况都无法保证。 Read committed (读已提交)：保证一个事务修改的数据提交后才能被另一事务读取，而且能看到该事务对已有记录的更新，可避免脏读的发生。 Repeatable read (可重复读)：保证一个事务修改的数据提交后才能被另一事务读取，但是不能看到该事务对已有记录的更新，可避免脏读、不可重复读的发生。 Serializable (串行化)：一个事务在执行的过程中完全看不到其他事务对数据库所做的更新，可避免脏读、不可重复读、幻读的发生。

9、spring中都用了哪些设计模式

（1）工厂模式：BeanFactory就是简单工厂模式的体现，用来创建对象的实例；

（2）单例模式：Bean默认为单例模式。

（3）代理模式：Spring的AOP功能用到了JDK的动态代理和CGLIB字节码生成技术；

（4）模板方法：用来解决代码重复的问题。比如. RestTemplate, JmsTemplate, JpaTemplate。

（5）观察者模式：定义对象键一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都会得到通知被制动更新，如Spring中listener的实现–ApplicationListener。

10、spring中如何处理bean在线程并发时线程安全问题

在一般情况下，只有无状态的 Bean 才可以在多线程环境下共享，在 Spring 中，绝大部分 Bean 都可以声明为 singleton 作用域，因为 Spring 对一些 Bean 中非线程安全状态采用 ThreadLocal 进行处理，解决线程安全问题。

ThreadLocal 和线程同步机制都是为了解决多线程中相同变量的访问冲突问题。同步机制采用了“时间换空间”的方式，仅提供一份变量，不同的线程在访问前需要获取锁，没获得锁的线程则需要排队。而 ThreadLocal 采用了“空间换时间”的方式。

ThreadLocal 会为每一个线程提供一个独立的变量副本，从而隔离了多个线程对数据的访问冲突。因为每一个线程都拥有自己的变量副本，从而也就没有必要对该变量进行同步了。ThreadLocal 提供了线程安全的共享对象，在编写多线程代码时，可以把不安全的变量封装进 ThreadLocal。

我们项目中的拦截器里就有这样的逻辑，在我们微服务中，网关进行登录以及鉴权操作，具体的微服务中需要用到token去解析用户信息，我们就在拦截器的preHandler里定义了threadlocal，通过token解析出user的信息，后续controller以及service使用的时候，直接从threadlocal中取出用户信息的，在拦截器的afterCompletion方法中清理threadlocal中的变量，避免变量堆积消耗内存

SpringMvc

1、介绍一下springMVC

springmvc是一个视图层框架，通过MVC模型让我们很方便的接收和处理请求和响应。我给你说说他里边的几个核心组件吧

它的核心控制器是DispatcherServlet，他的作用是接收用户请求，然后给用户反馈结果。它的作用相当于一个转发器或中央处理器，控制整个流程的执行，对各个组件进行统一调度，以降低组件之间的耦合性，有利于组件之间的拓展

接着就是处理器映射器（HandlerMapping）：他的作用是根据请求的URL路径，通过注解或者XML配置，寻找匹配的处理器信息

还有就是处理器适配器（HandlerAdapter）：他的作用是根据映射器处理器找到的处理器信息，按照特定执行链路规则执行相关的处理器，返回ModelAndView

最后是视图解析器（ViewResolver）：他就是进行解析操作，通过ModelAndView对象中的View信息将逻辑视图名解析成真正的视图View返回给用户

接下来我给你说下springmvc的执行流程吧

2、springMVC的执行流程

（1）用户发送请求至前端控制器 DispatcherServlet；

（2） DispatcherServlet 收到请求后，调用 HandlerMapping 处理器映射器，请求获取 Handle；

（3）处理器映射器根据请求 url 找到具体的处理器，生成处理器对象及处理器拦截器(如果有则生成)一并返回给 DispatcherServlet；

（4）DispatcherServlet 调用 HandlerAdapter 处理器适配器；

（5）HandlerAdapter 经过适配调用 具体处理器(Handler，也叫后端控制器)；

（6）Handler 执行完成返回 ModelAndView；

（7） HandlerAdapter 将 Handler 执 行 结 果 ModelAndView 返 回 给DispatcherServlet；

（8）DispatcherServlet 将 ModelAndView 传给 ViewResolver 视图解析器进行解析；

（9）ViewResolver 解析后返回具体 View；

（10）DispatcherServlet 对 View 进行渲染视图（即将模型数据填充至视图中）

（11）DispatcherServlet 响应用户。

3、springMVC接收前台参数的几种方式

1、如果传递参数的时候，通过ur1拼接的方式，直接拿对象接收即可，或者string、 int 2、如果传递参数的时候，传到后台的是js对象，那么必须使用对象接收，并且加@requestBody，使用requestBody之后，传递的参数至少要有一个，并且所有传的参数都要在后台对象里存在 3、get的请求方式，所有的参数接收都使用普通对象或者string、int 4、在用form表单提交的时候，所有的参数接收都使用普通对象或者string、int

4、springMVC中的常用注解

@RequestMapping：指定类或者方法的请求路径，可以使用method字段指定请求方式

@GetMapping、@PostMapping：规定了请求方式的方法的请求路径

@RequestParam：接收单一参数的

@PathVariable：用于从路径中接收参数的

@CookieValue：用于从cookie中接收参数的

@RequestBody：用于接收js对象的，将js对象转换为Java对象

@ResponseBody：返回json格式数据

@RestController：用在类上，等于@Controller+@ResourceBody两个注解的和，一般在前后端分离的项目中只写接口时经常使用，标明整个类都返回json格式的数据

等等

5、spring如何整合springMVC

简单的说 springMVC在ssm中整合 就是 在 web.xml 里边配置springMVC的核心控制器:DispatcherServlet; 它就是对指定后缀进行拦截;然后在springMVC.xml里边配置扫描器，可以扫描到带@controller注解的这些类，现在用springMVC都是基与注解式开发， 像@service，@Repository @Requestmapping，@responsebody 啦这些注解标签 等等 都是开发时用的，每个注解标签都有自己的作用;它还配置一个视图解析器，主要就是对处理之后的跳转进行统一配置，有页面的路径前缀和文件后缀 ，如果有上传相关的设置，还需要配置上multpart的一些配置，比如单个文件最大的大小，以及最大请求的大小，大致就是这些

Mybatis

1、介绍一下mybatis，说一下它的优点和缺点是什么？

Mybatis是一个半ORM（对象关系映射）的持久层框架,它内部封装了JDBC，开发时只需要关注SQL语句本身，不需要花费精力去处理加载驱动、创建连接、创建statement等繁杂的过程,使用时直接编写原生态sql。

优点：

1：基于SQL语句编程，相当灵活，不会对应用程序或者数据库的现有设计造成任何影响，SQL写在XML 里，解除sql与程序代码的耦合，便于统一管理，提供XML标签，支持编写动态SQL语句，并可重用；

2：很好的与各种数据库兼容；

3：提供映射标签，支持对象与数据库的ORM字段关系映射，提供对象关系映射标签，支持对象关系组件维护。

4：与JDBC相比，消除了JDBC大量冗余的代码，不需要手动开关连接，能够与Spring很好的集成

缺点：

1：SQL语句的编写工作量较大，尤其当字段多、关联表多时，对开发人员编写SQL语句的功底有一定要求；

2：SQL语句依赖于数据库，导致数据库移植性差，不能随意更换数据库；

2、MyBatis与Hibernate有哪些不同？

首先Hibernate是一个完全面向对象的持久层框架，mybatis是一个半自动化的持久层框架。

开发方面： hibernate开发中，sql语句已经被封装，直接可以使用，加快系统开发， Mybatis 属于半自动化，sql需要手工完成，稍微繁琐，但是如果对于庞大复杂的系统项目来说，复杂的sql语句较多，选择hibernate 就不是一个好方案。

sql优化方面：Hibernate 自动生成sql,有些语句较为繁琐，会多消耗一些性能， Mybatis 手动编写sql，可以避免不需要的查询，提高系统性能；

对象管理方面：Hibernate 是完整的对象-关系映射的框架，开发工程中，无需过多关注底层实现，只要去管理对象即可；Mybatis 需要自行管理 映射关系。

缓存方面：Hibernate的二级缓存配置在SessionFactory生成的配置文件中进行详细配置，然后再在具体的表-对象映射中配置是那种缓存，MyBatis的二级缓存配置都是在每个具体的表-对象映射中进行详细配置，这样针对不同的表可以自定义不同的缓存机制。

总之：Mybatis 小巧、方便、高效、简单、直接、半自动化；Hibernate 强大、方便、高效、复杂、间接、全自动化

3、#{}和${}的区别是什么？

#{}是预编译处理，${}是字符串替换。

Mybatis在处理#{}时，会将sql中的#{}替换为?号，调用PreparedStatement的set方法来赋值；

Mybatis在处理${}时，就是把${}替换成变量的值。

使用#{}可以有效的防止SQL注入，提高系统安全性。

4、当实体类中的属性名和表中的字段名不一样 ，怎么办 ？

第一种方法：通过在查询的sql语句中定义字段名的别名，让字段名的别名和实体类的属性名一致；

第二种方法：通过来映射字段名和实体类属性名的一一对应的关系；

第三种方法：在实体类通过@Column注解也可以实现；

5、通常一个Xml映射文件，都会写一个Dao接口与之对应，这个Dao接口的工作原理是什么？Dao接口里的方法，参数不同时，方法能重载吗？

Dao接口即Mapper接口。接口的全限名，就是映射文件中的namespace的值；接口的方法名，就是映射文件中Mapper的Statement的id值；接口方法内的参数，就是传递给sql的参数。

Mapper接口是没有实现类的，当调用接口方法时，接口全限名+方法名拼接字符串作为key值，可唯一定位一个MapperStatement。在Mybatis中，每一个

select * fromuser_user_t whereuser_name = #{0} anduser_area=#{1}

（2）第二种： 使用 @param 注解:

public interface usermapper {

user selectuser(@param(“username”) string username,@param(“hashedpassword”) string hashedpassword);

}

然后,就可以在xml像下面这样使用(推荐封装为一个map,作为单个参数传递给mapper):