1、redis的使用，不仅仅是做缓存。还有别的什么作用。
Redis适用的场景：
1 取最新N个数据的操作
使用list数据结构
2 排行榜应用，获取Top N 操作
使用sort set数据结构
3 需要精确设定过期时间的应用
4 计数器应用：如，INCR和DECR命令
5 Uniq操作，获取某段时间内所有数据排重值：适用Set数据类型
6 pub/sub 发布/订阅 构建实时消息系统
使用：pubish subscribse PSubscribe命令
7 构建队列系统
使用list可以构建队列系统，使用sort set 甚至可以构建优先级队列
8 做为缓存使用
2、Restful风格多个参数怎么传，能否做表单提交
要解决传入多个参数的问题，有几个思路：
1. 封装对象，把要传的多个参数封装成一个对象传入
2. 在访问路径中嵌入变量，使用@PathVariable注解，在请求路径中写 “/demo/{1}/{2}”，然后在请求路径中相应的位置替换为要穿的参数即可，这种也只适用于包装类，如String。
3. 改变请求的content type，使用content-type: application/x-www-form-urlencoded，这种使用form表单提交的形式，可以传入两个参数，要结合使用@FormParam注解
3、dubbo的ip是怎么分配的？上线的时候不会冲突吗？
承载dubbo服务的机器多IP时，需要指定dubbo服务需要绑定到的IP(dubbo.protocol.host),确保登记到注册中心的提供者或者消费者的IP之间可以互相ping通. 此IP与具体环境有关，上生产环境时，需要进行增量配置
4、Redis有哪些数据结构? set结构的应用场景
String list set hash zset
Set 就是一个集合，集合的概念就是一堆不重复值的组合。利用 Redis 提供的 Set 数据结构，可以存储一些集合性的数据。比如在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。因为 Redis 非常人性化的为集合提供了求交集、并集、差集等操作，那么就可以非常方便的实现如共同关注、共同喜好、二度好友等功能
5、项目中是如何解决Session共享的
（1）session复制
tomcat的session复制，可以实现session共享
优点：不需要额外开发，只需搭建tomcat集群即可
缺点：tomcat 是全局session复制，集群内每个tomcat的session完全同步（也就是任何时候都完全一样的) 在大规模应用的时候，用户过多，集群内tomcat数量过多，session的全局复制会导致集群性能下降， 因此，tomcat的数量不能太多，5个以下为好。
（2）session绑定
当用户A第一次访问系统时，tomcat1对其进行服务，那么，下次访问时仍然让tomcat1对其进行服务
（3）使用redis集中管理session
可以将用户的会话保存在redis中，每次从redis中查询用户信息，就可以很好的解决会话共享问题。如图：
6、sql怎么建立索引
首先创建一个表：create table t1 (id int primary key,username varchar(20),password varchar(20));
创建单个索引的语法：create index 索引名 on 表名（字段名）
索引名一般是：表名_字段名
给id创建索引：create index t1_id on t1(id);
创建联合索引的语法：create index 索引名 on 表名（字段名1，字段名2）
给username和password创建联合索引：create index t1_username_password on t1(username,password)
7、spring框架的aop和ioc在项目中的应用场景
AOP 用来封装横切关注点，具体可以在下面的场景中使用:
Authentication 权限、Caching 缓存、Context passing 内容传递、Error handling 错误处理
Lazy loading 懒加载、Debugging 调试、logging, tracing, profiling and monitoring 记录跟踪优化校准、Performance optimization 性能优化、Persistence 持久化、Resource pooling 资源池、Synchronization 同步、Transactions 事务
原理：AOP 是面向切面编程，是通过代理的方式为程序添加统一功能，集中解决一些公
共问题。
好处：1.各个步骤之间的良好隔离性2.源代码无关性
IOC: 当某个角色需要另外一个角色协助的时候，在传统的程序设计过程中，通常由调用
者来创建被调用者的实例。但在 spring 中创建被调用者的工作不再由调用者来完成，因此称为控制反转。创建被调用者的工作由 spring 来完成，然后注入调用者 。
IOC 本质上是一个容器，已 MAP 对 IOC 简单举例，服务器加载配置文件，由 xml 文档
解析工具读取 bean 的 ID，获取 class，使用反射创建对象，以 K-V 的形式存入 MAP，K 是 ID，V 是反射创建的对象。获取对象可以调用 context.getBean（K）的方式。
8、数据库中存储引擎，存储过程，视图，触发器分别
存储引擎说白了就是如何存储数据、如何为存储的数据建立索引和如何更新、查询数据等技术的实现方法。因为在关系数据库中数据的存储是以表的形式存储的，所以存储引擎也可以称为表类型（即存储和操作此表的类型）。
存储过程可以说是一个记录集吧，它是由一些 T-SQL 语句组成的代码块，这些 T-SQL
语句代码像一个方法一样实现一些功能（对单表或多表的增删改查），然后再给这个代码块
取一个名字，在用到这个功能的时候调用他就行了。
好处：
1.由于数据库执行动作时，是先编译后执行的。然而存储过程是一个编译过的代
码块，所以执行效率要比 T-SQL 语句高。
2.一个存储过程在程序在网络中交互时可以替代大堆的 T-SQL 语句，所以也能降低网络的通信量，提高通信速率。
3.通过存储过程能够使没有权限的用户在控制之下间接地存取数据库，从而确保数据的安全。
视图是一种虚拟表，可以对视图进行增删查改 。可以将一个表多个表组合成一个视图。对视图的修改不影响基本表。
触发器（trigger）就是事先为某张表绑定好一段代码，当表中的某些内容发生改变的时候（增删改）系统会自动触发代码执行，无需自已执行，就像js的单击双击事件一样，当事件产生了就触发函数，执行代码。
9、乐观锁和悲观锁的解释及其应用场景
悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。
使用场景
两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。
10、redis的持久化方式及其优缺点对比
RDB方式按照一定的时间间隔对数据集创建基于时间点的快照。
AOF方式记录Server收到的写操作到日志文件，在Server重启时通过回放这些写操作来重建数据集。
两钟方案各自的优缺点
RDB优点
RDB是Redis数据集的基于时间点的紧凑的副本，非常适合于备份场景。非常适合于灾难恢复。与AOF相比RDB在数据集较大时能够以更快的速度恢复。
RDB缺点
若需在Redis停止工作时（例如意外断电）尽可能保证数据不丢失，那么RDB不是较好的方案。
AOF优点
使用AOF方式时Redis持久化更可靠：有三种不同的fsync策略供选择：no fsync at all、fsync every second、 fsync at every query。默认为fsync every second此时的写性能仍然很好，且最坏的情况下可能丢失一秒钟的写操作。
AOF日志是append only方式产生的日志，因此不存在随机访问问题以及意外断电时造成的损毁问题。即使出于某种原因（如磁盘满）日志以一个写了一半的命令结尾，仍可以使用redis-check-aof工具快速进行修复。
AOF缺点
同样的数据集AOF文件要比RDB文件大很多。
根据使用的fsync方式不同AOF可能比RDB慢很多。
11、如何解决数据高并发，流程是怎么样的，如何保证高效率处理高并发
1、尽量将请求的页面静态化 静态化的页面为.html(.htm等)不需要web服务器重新加载项解析，只需要生成一次，以后每次都直接下载到客户端，效率高很多。javaWeb静态化的技术有freemark和Velocity等。
2、fastDFS图片服务器：
将网站系统的web服务器、数据库服务器、图片和文件服务器分开，通过将服务器专业化分工，以提高网站访问速度。因为图片和文件在下载的时候无论是IIS、Apache等服务器都会有很大压力。
3、数据缓存服务器 redis
可以设置专门的数据缓存服务器，将大量数据放到缓存数据区，在访问量少得时候存入数据，减少连接直接操作数据库的开销。
4、数据库集群、库表散列（数据库的各种优化、数据库的拆分）
5、镜像
镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。
6、负载均衡（nginx）
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的高端解决办法。
7、最新：CDN加速技术（这个比镜像更好用）
CDN的全称是内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可以就近取得所需的内容，提高用户访问网站的响应速度。
12、项目的最大访问量是怎样测试出来的，如何进行压力测试
对自己所负责模块进行单元测试，然后交给公司测试人员进行测试。一般压力测试都是
测试人员做，Visual Studio 自带的工具，还有 Loader Runner（LR），轻量级的工具有 Apache
项目中的 ApacheBench。
13、什么是rpc？如何搭建rpc框架？
我们在做一个访问量不大的项目的时候,一台服务器部署上一个应用+数据库也就够了.那么访问量稍微大一点之后呢,为了解决用户反馈的卡,反应慢的情况,我们就上集群.架设nginx,部署多个服务,由nginx负责把请求转发到其他服务上,这样就解决了用户说的卡慢问题.过了一段时间之后呢,我们发现数据库已经扛不住了,应用服务完好,数据库有时候宕机. 那这个时候呢,我们就上数据库读写分离,再架设几台数据库服务器,做主从,做分库分表. 然后数据库也不宕机了,服务又恢复了流畅.又过了一段时间,公司事业增增日上,服务访问量越来越高,且大部分都是查询, 吸取之前宕机且为了办证数据库的健壮性,我们这个时候又加上了缓存, 把用户高频次访问的数据放到缓存里.后来,项目功能越来越多,整个项目也愈发庞大,修改一个类就需要全盘上传,切换nginx重启,这样的发布流程越来越长,越来越繁杂.然后我们开始把模块拆分,用户信息分个项目,订单系统分一个项目.这样就达到了,用户模块代码修改的时候,只需要更新用户信息服务就好了.但是还是需要切换顶层的nginx.把要重启的服务的流量切到可用服务上. 这个时候我们就想到RPC，那么RPC解决了什么呢? 所有的服务在启动的时候注册到一个注册机里面,然后顶层处理在接收到nginx的请求时,去注册机找一个可用的服务,并调用接口. 这样子呢,在不加新功能的时候,顶层处理服务我们就不需要动了， 那修改了用户信息项目的时候,我们只需要一个个更新用户信息项目的服务群就好了，这样的话,无论是扩展还是服务的健壮性都妥妥的了。
