1、Nginx如何保证请求参数不丢
在nginx中添加请求头的参数,表示每次请求时,携带请求者的请求头信息,访问服务器.
2、数据库的优化策略
1.优化sql语句(多表操作)
原则:尽可能根据主键查询,尽可能少用关联查询.
2.创建索引(对经常查询的数据创建索引)
3.添加缓存(Redis/MemCache)
4.定期进行数据转储(将一些查询较少的数据保存到历史表,让当前表维护可控的数据量)
5.分库分表(需要大量的数据库服务器)
3、什么是Mycat
是一个数据库中间件,实现读写分离,分库分表和数据库故障迁移.
4、什么是Redis,运行在哪里
开源的内存中的数据结构存储系统,可以用做数据库,缓存和消息中间件
基于C语言开发,运行时在内存中,运行速度很快
5、Redis中的数据持久化策略
如果使用时允许丢失部分数据(少量的)则使用RDB模式,它的效率高,也是redis默认的策略,如果不允许丢失数据则采用AOF模式,它的安全性高,但是效率较低.
6、Redis中的内存维护（淘汰）策略
1.为数据设定超时时间
2.动态的将不用的数据删除.(LRU算法)
3.LFU算法
7、Hash一致性
1.均衡性
尽可能均匀分片节点中的数据
2.单调性
实现数据的动态迁移
3.分散性
由于分布式原因,导致不能获取全部节点信息,使得一个key有多个位置
4.负载
是分散性另一种表现形式.表现为一个位置有多个key
8、怎么解决跨域问题?
1.利用javascript中src属性实现跨域.
2.客户端定义回调函数 callback=hello
3.服务端程序封装特定的JSON格式，callback(JSON)执行回调函数
4.JSONP就是基于这个原理实现的.
9、HttpClient和JSONP的区别
JSONP的特点:
1>JSONP可以解决主流浏览器的跨域问题
2>需要通过三步实现跨域/javascript-src开放策略/回调函数/数据封装
3>JSONP请求是由浏览器解析ajax生成的跨域请求
4>调用层级只需要调用服务器端3层即可
5>JSONP只支持GET请求
6>JSONP安全性低
HlttpClient特点:
1>java中http请求的开发工具包.在任何地方都能使用
2>HttpClient是由业务层,执行发起的http请求
3>调用层级5层(前台2层-->后台3层)
4>支持全部http请求方式get/post (7种请求)
5>httpClient支持系统之间的调用,不经过浏览器,相对安全
10、zookkper如果宕机后,消费者能否正确消费
答案:可以
因为当zookkper会动态的向客户端更新服务列表信息.当当zookkper宕机后,由于之前已经同步了当zookkper的服务列表信息,所以客户端可以按照自己已经缓存的清单进行访问.如果在这个期间服务端程序发现宕机现象,那么则访问故障机时由于不能通信,则等待超时时间,则访问下一台服务器.
如果这时,所有的服务端程序都宕机,则整个服务陷入瘫痪.
11、知道RPC协议吗
RPC调用的规则可以传输java对象.底层实现时将数据转化流,并且该流经过加密处理.并且rpc内部使用UTF-8编码格式（传输的java对象必须序列化）
12、什么是微服务架构？
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
13、拓展：CAP定理
CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。它是分布式系统中最核心最重要的理论。
分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了如下归纳：
一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
CAP理论就是说在分布式系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，要么选择CP要么选择AP，没有分布式系统能同时保证这三点。
14、ZooKeeper和Eureka对比
Eureka本身是Netflix开源的一款提供服务注册和发现的产品，并且提供了相应的Java封装。在它的实现中，节点之间相互平等，部分注册中心的节点挂掉也不会对集群造成影响，即使集群只剩一个节点存活，也可以正常提供发现服务。哪怕是所有的服务注册节点都挂了，Eureka Clients（客户端）上也会缓存服务调用的信息。这就保证了我们微服务之间的互相调用足够健壮。
Zookeeper主要为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。曾经是Hadoop项目中的一个子项目，用来控制集群中的数据，目前已升级为独立的顶级项目。很多场景下也用它作为Service发现服务解决方案。
对比
根据著名的CAP定理（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性CAP这三个特性在任何分布式系统中不能同时满足，最多同时满足两个CP或者AP）。
ZooKeeper
Zookeeper是基于CP来设计的，即任何时刻对Zookeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是它不能保证每次服务请求的可用性。从实际情况来分析，在使用Zookeeper获取服务列表时，如果zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将无法获得数据。所以说，Zookeeper不能保证服务可用性。
诚然，在大多数分布式环境中，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是zookeeper设计成CP的原因。但是对于服务发现场景来说，情况就不太一样了：针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。因为对于服务消费者来说，能消费才是最重要的——拿到可能不正确的服务实例信息后尝试消费一下，也好过因为无法获取实例信息而不去消费。（尝试一下可以快速失败，之后可以更新配置并重试）所以，对于服务发现而言，可用性比数据一致性更加重要——AP胜过CP。
Eureka
而Spring Cloud Netflix在设计Eureka时遵守的就是AP原则。Eureka Server也可以运行多个实例来构建集群，解决单点问题，但不同于ZooKeeper的选举leader的过程，Eureka Server采用的是Peer to Peer对等通信。这是一种去中心化的架构，无master/slave区分，每一个Peer都是对等的。在这种架构中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的serviceUrl指向其他节点。每个节点都可被视为其他节点的副本。
如果某台Eureka Server宕机，Eureka Client的请求会自动切换到新的Eureka Server节点，当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会进行replicateToPeer（节点间复制）操作，将请求复制到其他Eureka Server当前所知的所有节点中。
一个新的Eureka Server节点启动后，会首先尝试从邻近节点获取所有实例注册表信息，完成初始化。Eureka Server通过getEurekaServiceUrls()方法获取所有的节点，并且会通过心跳续约的方式定期更新。默认配置下，如果Eureka Server在一定时间内没有接收到某个服务实例的心跳，Eureka Server将会注销该实例（默认为90秒，通过eureka.instance.lease-expiration-duration-in-seconds配置）。当Eureka Server节点在短时间内丢失过多的心跳时（比如发生了网络分区故障），那么这个节点就会进入自我保护模式。
总结
ZooKeeper基于CP，不保证高可用，如果zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将无法获得数据。Eureka基于AP，能保证高可用，即使所有机器都挂了，也能拿到本地缓存的数据。作为注册中心，其实配置是不经常变动的，只有发版（发布新的版本）和机器出故障时会变。对于不经常变动的配置来说，CP是不合适的，而AP在遇到问题时可以用牺牲一致性来保证可用性，既返回旧数据，缓存数据。
所以理论上Eureka是更适合作注册中心。而现实环境中大部分项目可能会使用ZooKeeper，那是因为集群不够大，并且基本不会遇到用做注册中心的机器一半以上都挂了的情况。所以实际上也没什么大问题。
15、自我保护模式
什么是自我保护模式？默认配置下，如果Eureka Server每分钟收到心跳续约的数量低于一个阈值（instance的数量(60/每个instance的心跳间隔秒数)自我保护系数），并且持续15分钟，就会触发自我保护。在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该Eureka Server节点就会自动退出自我保护模式。它的设计哲学前面提到过，那就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。该模式可以通过eureka.server.enable-self-preservation = false来禁用，同时eureka.instance.lease-renewal-interval-in-seconds可以用来更改心跳间隔。
16、Ribbon的负载均衡策略
常见提供的负载均衡算法有三种：
轮询(默认)
随机
响应时间
17、服务熔断机制
家里电表都有个断路器（俗称电闸），当使用的电器很多，用电巨大（例如功率过大、短路等），当电流过载时，电路就会升温，甚至烧断电路，引起火灾。有了这个断路器，我们及时拉闸，就不会造成严重后果了。
断路器可以实现快速失败，如果它在一段时间内检测到许多失败，如超时，就会强迫其以后的多个调用快速失败，不再请求所依赖的服务，从而防止应用程序不断地尝试执行可能会失败的操作，这样应用程序可以继续执行而不用等待修正错误，或者浪费CPU时间去等待长时间的超时。断路器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。
断路器模式像是那些容易导致错误的操作的一种代理。这种代理能够记录最近调用发生错误的次数，然后决定使用允许操作继续，或者立即返回错误。
18、什么是脑裂现象
说明:在集群的机制中,由主机进行选举,当主机在进行选举时如果连续3次出现平票的结果时,则可能引发脑裂现象.
问题:出现脑裂现象的概率是多少?答:1/8=12.5%
如何有效降低脑裂现象:可以通过增加主机的数量来有效降低脑裂的发生
19、（情景题）
小张在双11前夜误操作将Redis服务器执行了flushAll命令.问项目经理应该如何解决
A:痛批一顿,让其提交离职申请.
B:批评教育,让其深刻反省,并且请主管捏脚.
C:项目经理快速解决.并且通知全部门注意.
解决方案:
修改aof文件中的命令.删除flushAll之后重启redis即可
20、缓存雪崩
高并发的环境下.大量的用户访问服务器.redis中有大量的数据在同一时间超时(删除).
解决方案:不要同一时间删除数据.
21、缓存穿透
特点:用户高并发环境下,访问数据库中根本不存在的数据.
影响:由于用户高并发访问,则数据库可能存在宕机的风险.
22、缓存击穿
说明:由于用户高并发的访问.访问的数据刚开始有缓存,但是由于特殊原因导致缓存失效.(数据’‘单个’’)
23、什么是 spring cloud？
spring cloud 是一系列框架的有序集合。它利用 spring boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 spring boot 的开发风格做到一键启动和部署。
24、Dubbo的核心配置：
1）、启动时检查依赖的服务是否可用，不可用时抛异常 check=true
2）、集群容错 失败自动切换，当出现失败，重试其他服务器
3）、负载均衡策略：随机、轮询、一致性hash、压力最小
4）、多协议：dubbo、rmi、hessian、redis
5）、服务分组、隐式传参等
Dubbo支持bubbo：//协议（基于TCP-IP协议进行封装）长连接，NIO异步传输，用的是NIO的Netty框架，Dubbo目前不支持分布式事务
25、Dubbo的核心功能？
主要就是如下3个核心功能：
Remoting：网络通信框架，提供对多种NIO框架抽象封装，包括“同步转异步”和“请求-响应”模式的信息交换方式。
Cluster：服务框架，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
Registry：服务注册，基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
26、Dubbo的注册中心集群挂掉，发布者和订阅者之间还能通信么？
可以的，启动dubbo时，消费者会从zookeeper拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用。
27、dubbo和springcloud的区别?
Dubbo 定位服务治理、Spirng Cloud 是微服务整体解决方案（全家桶），解决微服务中的各种问题。
Dubbo简介
Dubbo是由阿里巴巴开源的一个高性能优秀的服务框架，可以通过高性能的RPC实现服务的输入输出，可以和spring框架无缝集成。
Dubbo是一款高性能，轻量级的开源Java RPC框架，提供了三大核心能力：面向接口的远程方法调用、智能容错和负载均衡、服务自动注册和发现。
Dubbo的负载均衡：利用@Reference(loadbalance=”consistenthash”)hash一致性原则
@Reference(loadbalance=”leastactive”)挑选压力最小的
@Reference(loadbalance=”random”)采用随机算法
@Reference(loadbalance=”roundrobin”)采用轮询策略
28、Dubbo实现跨域访问，负载均衡
Rpc远程调用协议，dubbo是一个高性能，透明化的rpc框架
核心：
- provider: 服务提供者
- consumer: 服务消费者
- container: dubbo容器，依赖于spring容器
- register: 注册中心 zookeeper/redis/multicast/simple
- monitor: 监听器
运行原理: - 启动容器,相当于在启动Dubbo的Provider
- 启动后会去注册中心进行注册.注册所有可以提供的服务列表
- 在Consumer启动后会去Registry中获取服务列表和Provider的地址.进行订阅.
- 当Provider有修改后,注册中心会把消息推送给Consummer
- 使用了观察者设计模式(又叫发布/订阅设计模式)
- 根据获取到的Provider地址,真实调用Provider中功能.
- 在Consumer方使用了代理设计模式.创建一个Provider方类的一个代理对象.通过代理对象获取Provider中真实功能,起到保护 Provider真实功能的作用.
- Consumer和Provider每隔1分钟向Monitor发送统计信息,统计信息包含,访问次数,频率等.
步骤 - 先导入jar包
- 在yml配置文件中添加关于dubbo的配置：指定dubbo的包路径，接口对应的名称，对应的zookeeper连接地址，指定dubbo的协议类型，指定端口号
- 添加dubbo接口，定义公共接口
- 构建生产者，业务层添加@Service注解
- 构建消费者，控制层添加@Reference注解
29、如何使用Mycat实现数据库的读写分离、高可用？怎么区分是读操作还是写操作？
mycat的 schema.xml配置文件，配置读写分离和双机热备。
读写分离：
writehost下配置两个readhost；schema.xml配置文件中，balance参数配置读操作发送给主机（节点），balance=0的时候，所有的读操作会发往writehost主机；balance=1时，所有的读操作发往readhost和闲置的主节点中；writeType配置写操作发往writehost主机。
用shell工具连接mycat服务器，用SQLyog连接数据库方便配置，主从挂载，默认条件下，数据库是不能充当主库的，需要开启二进制日志文件，在/etc/my.cof中配置主库的二进制日志文件（数据库服务id号），配置从库的二进制日志文件，在数据库主库查看show master status;从库向主库挂载，配置主库的IP，端口，账号密码，二进制日志文件，二进制日志文件的存储位置；start slave启动主从状态。
30、Redis集群搭建实现高并发
第一步先整合redis，在pom配置文件中导入redis依赖包，创建一个redis.properties配置文件来连接redis；编写一个redis的配置类，封装redis的信息，（端口号，IP等信息），创建一个工具API来封装JSON和对象之间的相互转换，方便后续调用。
先定义一个自定义注解@CacheFind，定义切面方法CacheAOP，切入点表达式用@annotation(包名.注解名称) 按照注解的方式去拦截用户请求，通知方法用环绕通（@Around）,在需要实现缓存处理的业务方法上添加自定义的注解，引入redis集群，在查询数据时，先进行判断，看是否第一次访问该数据，第一次访问时访问数据库，从数据库拿到数据之后，将数据转化为json字符串之后利用redis命令存储到redis，下次需要数据从缓存中取，即可实现缓存的功能
31、Nginx反向代理、负载均衡（并发能力强3-5万次/秒）
Nginx反向代理是服务端代理，保护真实服务器信息，用户不清楚真实目标服务器是谁，用户通过反向代理服务器获取资源，而不是直接访问真实服务器。在本地虚拟机电脑配置nginx，修改本机的host文件，测试项目的反向代理功能是否可以正常实现，在nginx的nginx.conf配置文件修改http协议，添加对应的server服务，配置Tomact的负载均衡
nginx常见的负载均衡方式
轮询（默认）策略，权重策略，iphash策略，还有down属性，备用机策略，nginx高可用配置。