10.架构设计与分布式

1.什么是微服务

   但通常而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分一组小的服务，每个服务运行在其独立的自己的进程中，服务之间相互协调、互相配合，为用户提供最总价值。

服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）,

每个服务都围绕着具体的业务进行构建，并且能够被独立的构建在生产环境、类生产环境等。

另外，应避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，

可以使用不同的语言来编写服务，也可以使用不同的数据存储。

更多解释参考：

https://blog.csdn.net/u012702547/article/details/78004866

---

 2.微服务之间是如何独立通讯的？

微服务通信机制
    系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。

   每个微服务仅关注于完成一件任务并很好地完成该任务。
   围绕业务能力组织服务、自动化部署、智能端点、对语言及数据的去集中化控制。

• 将组件定义为可被独立替换和升级的软件单元。
• 以业务能力为出发点组织服务的策略。
• 倡导谁开发，谁运营的开发运维一体化方法。
• RESTful HTTP协议是微服务架构中最常用的通讯机制。
• 每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。
• 允许不同微服务采用不同的数据持久化技术。
• 微服务非常重视建立架构及业务相关指标的实时监控和日志机制，必须考虑每个服务的失败容错机制。
• 注重快速更新，因此系统会随时间不断变化及演进。可替代性模块化设计。

微服务通信方式：

       同步：RPC,REST等

           https://blog.csdn.net/crave_shy/article/details/81286137

       异步：消息队列，要考虑消息可靠传输，高性能，以及编程模型的变化等。

消息队列中间件如何选型

    1.协议：AMQP、STOMP、MQTT、私有协议等。
    2.消息是否需要持久化。
    3.吞吐量。
    4.高可用支持，是否单点。
    5.分布式扩展能力。
    6.消息堆积能力和重放能力。
    7.开发便捷，易于维护。
    8.社区成熟度。

RabbitMQ是一个实现了AMQP(高级消息队列协议)协议的消息队列中间件。

RabbitMQ支持其中的最多一次和最少一次两种。

网易蜂巢平台的服务架构，服务间通过RabbitMQ实现通信。

---

3.SpringCloud和Dubbo有哪些区别？

	Dubbo	SpringCloud
服务注册中心	Zookeeper	Eureka
服务调用方式	RPC	REST API
服务监控	Dubbo-monitor	Spring BootAdmin
断路器	不完善	Spring Cloud Netflix Hystrix
服务网关	无	Spring Cloud Netflix Zuul
分布式配置	无	Spring Cloud Config
服务跟踪	无	Spring Cloud Sleuth
消息总线	无	Spring Cloud Bus
数据流	无	Spring Cloud Stream
批量任务	无	Spring Cloud Task

    最大区别：SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。
    总体来说，两者各有优势。虽说后者服务调用的功能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的依赖，这在强调快速演化的微服务环境下，显得更加合适。
    品牌机与组装机的区别：很明显SpringCloud比dubbo的功能更强大，覆盖面更广，而且能够与SpringFramework、SpringBoot、SpringData、SpringBatch等其他Spring项目完美融合，这些对于微服务至关重要。使用Dubbo构建的微服务架构就像组装电脑、各环节我们选择自由度高，但是最总可能会因为内存质量而影响整体，但对于高手这也就不是问题。而SpringCloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性。
    在面临微服务基础框架选型时Dubbo与SpringCloud只能二选一。

---

4.SpringBoot和SpringCloud,请你谈谈对他们的理解？

• SpringBoot专注于快速方便的开发单个个体微服务。
• SpringCloud是关注全局的微服务协调、整理、治理的框架，它将SpringBoot开发的单体整合并管理起来。
• SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot，属于依赖关系。   

---

 5.什么是服务熔断？什么是服务降级？

      熔断机制是应对雪崩效应的一种微服务链路保护机制。

当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。

  在SpringCloud框架里熔断机制通过Hystrix实现，Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内调用20次，如果失败，就会启动熔断机制。熔断机制的注解是@HystrixCommand
        服务降级，一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。这样做，虽然水平下降，但好歹可用，比直接挂掉强。

更细参考

  https://blog.csdn.net/qq_37312838/article/details/82966209

---

 6.微服务的优缺点是什么？说下你在项目开发中碰到的问题
优点：

• 每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求。
• 开发简单，开发效率提高，一个服务可能就是专一的只干一件事。
• 微服务能够被小团队开发，这个团队可以是2到5个开发人员组成。
• 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
• 微服务能使用不同的语言开发。
• 易于第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成集成工具，如Jenkins、Hudson等。
• 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作体现价值。
• 微服务允许你融合最新技术。
• 微服务知识业务逻辑代码，不会和HTML和CSS其他界面组件混合。
• 每个微服务都有自己的存储能力，可以有自己的数据库，也可以由统一的数据库。

缺点：

• 开发人员要处理分布式系统的复杂性。
• 多服务运维难度，随着服务的增加，运维的压力也在增加。
• 系统部署依赖。
• 服务间通讯成本。
• 数据一致性。
• 系统集成测试。
• 性能监控.....

---

7.你所知道的微服务技术栈有哪些?

微服务的技术栈（各项功能的实现所使用的技术）具体如下：

微服务条目	落地的技术
服务开发	SpringBoot、Spring、SpringMVC
服务配置管理	Netfilx公司的Archaius、阿里的Diamond等
服务注册与发现	Eureka、Consul、Zookeeper
服务调用	RPC、Rest、gRPC
服务熔断器	Hystrix、Envoy等
负载均衡	Nginx、Ribbon
服务接口调用（ 客户端调用服务的简化工具）	Feign等
消息队列	Kafka、RabbitMQ、ActiveMQ等
服务配置中心管理	SpringCloudConfig、Chef等
服务路由（API网关）	Zuul等
服务监控	Zabbix、Naggios、Metrics、Spectator等
全链路追踪	Zipkin、Brave、Dapper等
服务部署	Docker、OpenStack、Kubernetes等
数据流操作开发包	SpringCloud Stream
事件消息总线	Spring Cloud Bus

---

8.Eureka和zookeeper都可以提供服务注册与发现的功能，请说说两个的区别？

Zookeeper保证了CP（C：一致性，P：分区容错性）

Eureka保证了AP（A：高可用）

     （1）当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的信息，但不能容忍直接down掉不可用。

也就是说，服务注册功能对高可用性要求比较高，但zk会出现这样一种情况，

当master节点因为网络故障与其他节点失去联系时，剩余节点会重新选leader。

问题在于，选取leader时间过长，30 ~ 120s，且选取期间zk集群都不可用，这样就会导致选取期间注册服务瘫痪。

在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够恢复，但是漫长的选取时间导致的注册长期不可用是不能容忍的。
     （2）Eureka保证了可用性，Eureka各个节点是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点仍然可以提供注册和查询服务。

    而Eureka的客户端向某个Eureka注册或发现是发生连接失败，则会自动切换到其他节点，只要有一台Eureka还在，就能保证注册服务可用，只是查到的信息可能不是最新的。

    除此之外，Eureka还有自我保护机制，如果在15分钟内超过85%的节点没有正常的心跳，那么Eureka就认为客户端与注册中心发生了网络故障，此时会出现以下几种情况：
           ①Eureka不在从注册列表中移除因为长时间没有收到心跳而应该过期的服务。
           ②Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点仍然可用）
           ③当网络稳定时，当前实例新的注册信息会被同步到其他节点。

因此，

  Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，

  而不会像Zookeeper那样使整个微服务瘫痪。
https://blog.csdn.net/zhengzhaoyang122/article/details/80142955 

---

9. Hjava自a实 一个LRU

让我们以用户信息的需求为例，来演示一下LRU算法的基本思路：

1.假设我们使用哈希链表来缓存用户信息，目前缓存了4个用户，这4个用户是按照时间顺序依次从链表右端插入的。

2.此时，业务方访问用户5，由于哈希链表中没有用户5的数据，我们从数据库中读取出来，插入到缓存当中。这时候，链表中最右端是最新访问到的用户5，最左端是最近最少访问的用户1。

3.接下来，业务方访问用户2，哈希链表中存在用户2的数据，我们怎么做呢？我们把用户2从它的前驱节点和后继节点之间移除，重新插入到链表最右端。这时候，链表中最右端变成了最新访问到的用户2，最左端仍然是最近最少访问的用户1。

4.接下来，业务方请求修改用户4的信息。同样道理，我们把用户4从原来的位置移动到链表最右侧，并把用户信息的值更新。这时候，链表中最右端是最新访问到的用户4，最左端仍然是最近最少访问的用户1。

5.后来业务方换口味了，访问用户6，用户6在缓存里没有，需要插入到哈希链表。假设这时候缓存容量已经达到上限，必须先删除最近最少访问的数据，那么位于哈希链表最左端的用户1就会被删除掉，然后再把用户6插入到最右端。

以上，就是LRU算法的基本思路。

---

LRU是Least Recently Used 的缩写，翻译过来就是“最近最少使用”，LRU缓存就是使用这种原理实现，简单的说就是缓存一定量的数据，当超过设定的阈值时就把一些过期的数据删除掉，比如我们缓存10000条数据，当数据小于10000时可以随意添加，当超过10000时就需要把新的数据添加进来，同时要把过期数据删除，以确保我们最大缓存10000条，那怎么确定删除哪条过期数据呢，采用LRU算法实现的话就是将最老的数据删掉，废话不多说，下面来说下Java版的LRU缓存实现

Java里面实现LRU缓存通常有两种选择，一种是使用LinkedHashMap，一种是自己设计数据结构，使用链表+HashMap

 http://www.cnblogs.com/lzrabbit/p/3734850.html

---

10.分布式集群下如何做到唯一序列号。

• 数据库自增长序列或字段
• UUID
• Redis生成ID，

     当使用数据库来生成ID性能不够要求的时候，我们可以尝试使用Redis来生成ID。这主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY来实现。

可以使用Redis集群来获取更高的吞吐量。假如一个集群中有5台Redis。可以初始化每台Redis的值分别是1,2,3,4,5，然后步长都是5

• 利用zookeeper生成唯一ID

zookeeper主要通过其znode数据版本来生成序列号，可以生成32位和64位的数据版本号，客户端可以使用这个版本号来作为唯一的序列号。很少会使用zookeeper来生成唯一ID。主要是由于需要依赖zookeeper，并且是多步调用API，如果在竞争较大的情况下，需要考虑使用分布式锁。因此，性能在高并发的分布式环境下，也不甚理想

http://www.cnblogs.com/haoxinyue/p/5208136.html

---

11.设计一个秒杀系统,30分钟没付款就自动关闭交易。

分流 – 限流–异步–公平性（只能参加一次）–用户体验（第几位，多少分钟，一抢完）
容错处理
Redis  队列  mysql
30分钟关闭 可以借助redis的发布订阅机制 在失效时进行后续操作，其他mq也可以
http://www.infoq.com/cn/articles/yhd-11-11-queuing-system-design

---

12.如何使用redis和zookeeper实现分布式锁?

有什么区别优缺点,会有什么问题,

分别适用什么

场景(延伸:如果知道redlock,讲讲他的算法实现,争议在哪里)

       分布式锁实现常见的有数据库锁(表记录)，redis缓存锁，基于zk（临时有序节点可以实现的）三种

使用Redis的 SETNX 命令可以实现分布式锁，

SETNX命令简介
命令格式
SETNX key value

将 key 的值设为 value，当且仅当 key 不存在。 
若给定的 key 已经存在，则 SETNX 不做任何动作。 
SETNX 是SET if Not eXists的简写。

返回值
返回整数，具体为 
- 1，当 key 的值被设置 
- 0，当 key 的值没被设置

使用SETNX实现分布式锁
多个进程执行以下Redis命令：

SETNX lock.foo <current Unix time + lock timeout + 1>

如果 SETNX 返回1，说明该进程获得锁，SETNX将键 lock.foo 的值设置为锁的超时时间（当前时间 + 锁的有效时间）。 
如果 SETNX 返回0，说明其他进程已经获得了锁，进程不能进入临界区。进程可以在一个循环中不断地尝试 SETNX 操作，以获得锁。

https://blog.csdn.net/crg18438610577/article/details/89348845
Redis适用于对性能要求特别高的场景,  redis可以每秒执行10w次，内网延迟不超过1ms
缺点

     是数据存放于内存，宕机后锁丢失。
锁无法释放？

      使用Zookeeper可以有效的解决锁无法释放的问题，因为在创建锁的时候，客户端会在ZK中创建一个临时节点，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁。
非阻塞锁？

        使用Zookeeper可以实现阻塞的锁，客户端可以通过在ZK中创建顺序节点，并且在节点上绑定监听器，一旦节点有变化，Zookeeper会通知客户端，客户端可以检查自己创建的节点是不是当前所有节点中序号最小的，如果是，那么自己就获取到锁，便可以执行业务逻辑了。
不可重入？

        使用Zookeeper也可以有效的解决不可重入的问题，客户端在创建节点的时候，把当前客户端的主机信息和线程信息直接写入到节点中，下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样，那么自己直接获取到锁，如果不一样就再创建一个临时的顺序节点，参与排队。
单点问题？

      使用Zookeeper可以有效的解决单点问题，ZK是集群部署的，只要集群中有半数以上的机器存活，就可以对外提供服务。

分布式锁分析：

基于zk（临时有序节点可以实现的） 

http://www.hollischuang.com/archives/1716

---

13.如果有人恶意创建非法连接,怎么解决。

可以使用filter过滤处理

---

14·分布式事务的原理,优缺点,如何使用分布式事务,

2pc 3pc的区别,解决了哪些问题,

还有哪些问题没解决,如何解决,

你自己项目里涉及到分布式事务是怎么处理的。

什么是分布式事务

      分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

     简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。

  本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

分布式事务产生的原因

    从上面本地事务来看，我们可以看为两块，一个是service产生多个节点，另一个是resource产生多个节点。

service多个节点

    随着互联网快速发展，微服务，SOA等服务架构模式正在被大规模的使用，

举个简单的例子，一个公司之内，用户的资产可能分为好多个部分，比如余额，积分，优惠券等等。

在公司内部有可能积分功能由一个微服务团队维护，优惠券又是另外的团队维护 

 这样的话就无法保证积分扣减了之后，优惠券能否扣减成功。

resource多个节点

     同样的，互联网发展得太快了，我们的Mysql一般来说装千万级的数据就得进行分库分表，对于一个支付宝的转账业务来说，你给的朋友转钱，有可能你的数据库是在北京，而你的朋友的钱是存在上海，所以我们依然无法保证他们能同时成功。 

分布式事务的基础

    从上面来看分布式事务是随着互联网高速发展应运而生的，这是一个必然的我们之前说过数据库的ACID四大特性，已经无法满足我们分布式事务，这个时候又有一些新的大佬提出一些新的理论:

CAP

CAP定理，又被叫作布鲁尔定理。对于设计分布式系统来说(不仅仅是分布式事务)的架构师来说，CAP就是你的入门理论。

• C (一致性):对某个指定的客户端来说，读操作能返回最新的写操作。对于数据分布在不同节点上的数据上来说，如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强一致，如果有某个节点没有读取到，那就是分布式不一致。

• A (可用性)：非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。可用性的两个关键一个是合理的时间，一个是合理的响应。合理的时间指的是请求不能无限被阻塞，应该在合理的时间给出返回。合理的响应指的是系统应该明确返回结果并且结果是正确的，这里的正确指的是比如应该返回50，而不是返回40。

• P (分区容错性):当出现网络分区后，系统能够继续工作。打个比方，这里个集群有多台机器，有台机器网络出现了问题，但是这个集群仍然可以正常工作。

熟悉CAP的人都知道，三者不能共有，如果感兴趣可以搜索CAP的证明，在分布式系统中，网络无法100%可靠，分区其实是一个必然现象，如果我们选择了CA而放弃了P，那么当发生分区现象时，为了保证一致性，这个时候必须拒绝请求，但是A又不允许，所以分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。

对于CP来说，放弃可用性，追求一致性和分区容错性，我们的zookeeper其实就是追求的强一致。

对于AP来说，放弃一致性(这里说的一致性是强一致性)，追求分区容错性和可用性，这是很多分布式系统设计时的选择，后面的BASE也是根据AP来扩展。

顺便一提，CAP理论中是忽略网络延迟，也就是当事务提交时，从节点A复制到节点B，但是在现实中这个是明显不可能的，所以总会有一定的时间是不一致。同时CAP中选择两个，比如你选择了CP，并不是叫你放弃A。因为P出现的概率实在是太小了，大部分的时间你仍然需要保证CA。就算分区出现了你也要为后来的A做准备，比如通过一些日志的手段，是其他机器回复至可用。

BASE

    BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。是对CAP中AP的一个扩展

1. 基本可用:分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。

2. 软状态:允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。

3. 最终一致:最终一致是指经过一段时间后，所有节点数据都将会达到一致。

BASE解决了CAP中理论没有网络延迟，在BASE中用软状态和最终一致，保证了延迟后的一致性。BASE和 ACID 是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

分布式事务解决方案

   有了上面的理论基础后，这里介绍开始介绍几种常见的分布式事务的解决方案。

是否真的要分布式事务

   在说方案之前，首先你一定要明确你是否真的需要分布式事务？

  上面说过出现分布式事务的两个原因，其中有个原因是因为微服务过多。

我见过太多团队一个人维护几个微服务，太多团队过度设计，搞得所有人疲劳不堪，而微服务过多就会引出分布式事务，这个时候我不会建议你去采用下面任何一种方案，而是请把需要事务的微服务聚合成一个单机服务，使用数据库的本地事务。因为不论任何一种方案都会增加你系统的复杂度，这样的成本实在是太高了，千万不要因为追求某些设计，而引入不必要的成本和复杂度。

如果你确定需要引入分布式事务可以看看下面几种常见的方案。

2PC

  说到2PC就不得不聊数据库分布式事务中的 XA Transactions。 

在XA协议中分为两阶段:

第一阶段：事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.

第二阶段：事务协调器要求每个数据库提交数据，或者回滚数据。

优点： 尽量保证了数据的强一致，实现成本较低，在各大主流数据库都有自己实现，对于MySQL是从5.5开始支持。

缺点:

• 单点问题:事务管理器在整个流程中扮演的角色很关键，如果其宕机，比如在第一阶段已经完成，在第二阶段正准备提交的时候事务管理器宕机，资源管理器就会一直阻塞，导致数据库无法使用。

• 同步阻塞:在准备就绪之后，资源管理器中的资源一直处于阻塞，直到提交完成，释放资源。

• 数据不一致:两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能，比如在第二阶段中，假设协调者发出了事务commit的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了commit操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。

总的来说，XA协议比较简单，成本较低，但是其单点问题，以及不能支持高并发(由于同步阻塞)依然是其最大的弱点。

---

TCC

关于TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。 TCC事务机制相比于上面介绍的XA，解决了其几个缺点: 1.解决了协调者单点，由主业务方发起并完成这个业务活动。业务活动管理器也变成多点，引入集群。 2.同步阻塞:引入超时，超时后进行补偿，并且不会锁定整个资源，将资源转换为业务逻辑形式，粒度变小。 3.数据一致性，有了补偿机制之后，由业务活动管理器控制一致性 

对于TCC的解释:

• Try阶段：尝试执行,完成所有业务检查（一致性）,预留必须业务资源（准隔离性）

• Confirm阶段：确认执行真正执行业务，不作任何业务检查，只使用Try阶段预留的业务资源，Confirm操作满足幂等性。要求具备幂等设计，Confirm失败后需要进行重试。

• Cancel阶段：取消执行，释放Try阶段预留的业务资源 Cancel操作满足幂等性Cancel阶段的异常和Confirm阶段异常处理方案基本上一致。

举个简单的例子如果你用100元买了一瓶水， Try阶段:你需要向你的钱包检查是否够100元并锁住这100元，水也是一样的。

如果有一个失败，则进行cancel(释放这100元和这一瓶水)，如果cancel失败不论什么失败都进行重试cancel，所以需要保持幂等。

如果都成功，则进行confirm,确认这100元扣，和这一瓶水被卖，如果confirm失败无论什么失败则重试(会依靠活动日志进行重试)

对于TCC来说适合一些:

• 强隔离性，严格一致性要求的活动业务。

• 执行时间较短的业务

实现参考:ByteTCC:

https://github.com/liuyangming/ByteTCC/

本地消息表

本地消息表这个方案最初是ebay提出的 ebay的完整方案https://queue.acm.org/detail.cfm?id=1394128。

此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。 

对于本地消息队列来说核心是把大事务转变为小事务。还是举上面用100元去买一瓶水的例子。

1.当你扣钱的时候，你需要在你扣钱的服务器上新增加一个本地消息表，你需要把你扣钱和写入减去水的库存到本地消息表放入同一个事务(依靠数据库本地事务保证一致性。

2.这个时候有个定时任务去轮询这个本地事务表，把没有发送的消息，扔给商品库存服务器，叫他减去水的库存，到达商品服务器之后这个时候得先写入这个服务器的事务表，然后进行扣减，扣减成功后，更新事务表中的状态。

3.商品服务器通过定时任务扫描消息表或者直接通知扣钱服务器，扣钱服务器本地消息表进行状态更新。

4.针对一些异常情况，定时扫描未成功处理的消息，进行重新发送，在商品服务器接到消息之后，首先判断是否是重复的，如果已经接收，在判断是否执行，如果执行在马上又进行通知事务，如果未执行，需要重新执行需要由业务保证幂等，也就是不会多扣一瓶水。

本地消息队列是BASE理论，是最终一致模型，适用于对一致性要求不高的。实现这个模型时需要注意重试的幂等。

---

MQ事务

      在RocketMQ中实现了分布式事务，实际上其实是对本地消息表的一个封装，将本地消息表移动到了MQ内部，下面简单介绍一下MQ事务，

如果想对其详细了解可以参考:

https://www.jianshu.com/p/453c6e7ff81c。 

 基本流程如下: 第一阶段Prepared消息，会拿到消息的地址。

第二阶段执行本地事务。

第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。消息接受者就能使用这个消息。

如果确认消息失败，在RocketMq Broker中提供了定时扫描没有更新状态的消息，如果有消息没有得到确认，会向消息发送者发送消息，来判断是否提交，在rocketmq中是以listener的形式给发送者，用来处理。 

如果消费超时，则需要一直重试，消息接收端需要保证幂等。如果消息消费失败，这个就需要人工进行处理，因为这个概率较低，如果为了这种小概率时间而设计这个复杂的流程反而得不偿失

---

Saga事务

Saga是30年前一篇数据库伦理提到的一个概念。其核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。 Saga的组成：

每个Saga由一系列sub-transaction Ti 组成 每个Ti 都有对应的补偿动作Ci，补偿动作用于撤销Ti造成的结果,这里的每个T，都是一个本地事务。 可以看到，和TCC相比，Saga没有“预留 try”动作，它的Ti就是直接提交到库。

Saga的执行顺序有两种：

T1, T2, T3, ..., Tn

T1, T2, ..., Tj, Cj,..., C2, C1，其中0 < j < n Saga定义了两种恢复策略：

向后恢复，即上面提到的第二种执行顺序，其中j是发生错误的sub-transaction，这种做法的效果是撤销掉之前所有成功的sub-transation，使得整个Saga的执行结果撤销。 向前恢复，适用于必须要成功的场景，执行顺序是类似于这样的：T1, T2, ..., Tj(失败), Tj(重试),..., Tn，其中j是发生错误的sub-transaction。该情况下不需要Ci。

这里要注意的是，在saga模式中不能保证隔离性，因为没有锁住资源，其他事务依然可以覆盖或者影响当前事务。

还是拿100元买一瓶水的例子来说，这里定义

T1=扣100元 T2=给用户加一瓶水 T3=减库存一瓶水

C1=加100元 C2=给用户减一瓶水 C3=给库存加一瓶水

我们一次进行T1,T2，T3如果发生问题，就执行发生问题的C操作的反向。 上面说到的隔离性的问题会出现在，如果执行到T3这个时候需要执行回滚，但是这个用户已经把水喝了(另外一个事务)，回滚的时候就会发现，无法给用户减一瓶水了。这就是事务之间没有隔离性的问题

可以看见saga模式没有隔离性的影响还是较大，可以参照华为的解决方案:从业务层面入手加入一 Session 以及锁的机制来保证能够串行化操作资源。也可以在业务层面通过预先冻结资金的方式隔离这部分资源， 最后在业务操作的过程中可以通过及时读取当前状态的方式获取到最新的更新。

具体实例:可以参考华为的servicecomb

最后

还是那句话，能不用分布式事务就不用，如果非得使用的话，结合自己的业务分析，看看自己的业务比较适合哪一种，是在乎强一致，还是最终一致即可。最后在总结一些问题,大家可以下来自己从文章找寻答案:

1. ACID和CAP的 CA是一样的吗？

2. 分布式事务常用的解决方案的优缺点是什么？适用于什么场景？

3. 分布式事务出现的原因？用来解决什么痛点？

https://yq.aliyun.com/webinar/join/185?spm=5176.8067841.0.0.RL4GDa

---

15.什么是一致性hash

   一致性hash是一种分布式hash实现算法。满足平衡性 单调性 分散性 和负载。
http://blog.csdn.net/cywosp/article/details/23397179/

一、Redis集群的使用
    我们在使用Redis的时候，为了保证Redis的高可用，提高Redis的读写性能，最简单的方式我们会做主从复制，组成Master-Master或者Master-Slave的形式，或者搭建Redis集群，进行数据的读写分离，类似于数据库的主从复制和读写分离。如下所示：  

同样类似于数据库，当单表数据大于500W的时候需要对其进行分库分表，当数据量很大的时候（标准可能不一样，要看Redis服务器容量）我们同样可以对Redis进行类似的操作，就是分库分表。

假设，我们有一个社交网站，需要使用Redis存储图片资源，存储的格式为键值对，key值为图片名称，value为该图片所在文件服务器的路径，我们需要根据文件名查找该文件所在文件服务器上的路径，数据量大概有2000W左右，按照我们约定的规则进行分库，规则就是随机分配，我们可以部署8台缓存服务器，每台服务器大概含有500W条数据，并且进行主从复制，示意图如下：

由于规则是随机的，所有我们的一条数据都有可能存储在任何一组Redis中，例如上图我们用户查找一张名称为”a.png”的图片，由于规则是随机的，我们不确定具体是在哪一个Redis服务器上的，因此我们需要进行1、2、3、4，4次查询才能够查询到（也就是遍历了所有的Redis服务器），这显然不是我们想要的结果，有了解过的小伙伴可能会想到，随机的规则不行，可以使用类似于数据库中的分库分表规则：按照Hash值、取模、按照类别、按照某一个字段值等等常见的规则就可以出来了！好，按照我们的主题，我们就使用Hash的方式。

二、为Redis集群使用Hash
可想而知，如果我们使用Hash的方式，每一张图片在进行分库的时候都可以定位到特定的服务器，

示意图如下：

上图中，假设我们查找的是”a.png”，由于有4台服务器（排除从库），因此公式为hash(a.png) % 4 = 2 ，可知定位到了第2号服务器，这样的话就不会遍历所有的服务器，大大提升了性能！

三、使用Hash的问题
上述的方式虽然提升了性能，我们不再需要对整个Redis服务器进行遍历！但是，使用上述Hash算法进行缓存时，会出现一些缺陷，主要体现在服务器数量变动的时候，所有缓存的位置都要发生改变！

试想一下，如果4台缓存服务器已经不能满足我们的缓存需求，那么我们应该怎么做呢？很简单，多增加几台缓存服务器不就行了！假设：我们增加了一台缓存服务器，那么缓存服务器的数量就由4台变成了5台。那么原本hash(a.png) % 4 = 2 的公式就变成了hash(a.png) % 5 = ？ ， 可想而知这个结果肯定不是2的，这种情况带来的结果就是当服务器数量变动时，所有缓存的位置都要发生改变！换句话说，当服务器数量发生改变时，所有缓存在一定时间内是失效的，当应用无法从缓存中获取数据时，则会向后端数据库请求数据（还记得上一篇的《缓存雪崩》吗？）！

同样的，假设4台缓存中突然有一台缓存服务器出现了故障，无法进行缓存，那么我们则需要将故障机器移除，但是如果移除了一台缓存服务器，那么缓存服务器数量从4台变为3台，也是会出现上述的问题！

所以，我们应该想办法不让这种情况发生，但是由于上述Hash算法本身的缘故，使用取模法进行缓存时，这种情况是无法避免的，为了解决这些问题，Hash一致性算法（一致性Hash算法）诞生了！

四、一致性Hash算法的神秘面纱
一致性Hash算法也是使用取模的方法，只是，刚才描述的取模法是对服务器的数量进行取模，而一致性Hash算法是对2^32取模，什么意思呢？简单来说，一致性Hash算法将整个哈希值空间组织成一个虚拟的圆环，如假设某哈希函数H的值空间为0-2^32-1（即哈希值是一个32位无符号整形），整个哈希环如下：  

整个空间按顺时针方向组织，圆环的正上方的点代表0，0点右侧的第一个点代表1，以此类推，2、3、4、5、6……直到2^32-1，也就是说0点左侧的第一个点代表2^32-1， 0和2^32-1在零点中方向重合，我们把这个由2^32个点组成的圆环称为Hash环。

下一步将各个服务器使用Hash进行一个哈希，具体可以选择服务器的IP或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置，这里假设将上文中四台服务器使用IP地址哈希后在环空间的位置如下：  

接下来使用如下算法定位数据访问到相应服务器：将数据key使用相同的函数Hash计算出哈希值，并确定此数据在环上的位置，从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器！

例如我们有Object A、Object B、Object C、Object D四个数据对象，经过哈希计算后，在环空间上的位置如下： 

根据一致性Hash算法，数据A会被定为到Node A上，B被定为到Node B上，C被定为到Node C上，D被定为到Node D上。

五、一致性Hash算法的容错性和可扩展性
现假设Node C不幸宕机，可以看到此时对象A、B、D不会受到影响，只有C对象被重定位到Node D。一般的，在一致性Hash算法中，如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器（即沿着逆时针方向行走遇到的第一台服务器）之间数据，其它不会受到影响，如下所示：

下面考虑另外一种情况，如果在系统中增加一台服务器Node X，如下图所示：

此时对象Object A、B、D不受影响，只有对象C需要重定位到新的Node X ！一般的，在一致性Hash算法中，如果增加一台服务器，则受影响的数据仅仅是新服务器到其环空间中前一台服务器（即沿着逆时针方向行走遇到的第一台服务器）之间数据，其它数据也不会受到影响。

综上所述，一致性Hash算法对于节点的增减都只需重定位环空间中的一小部分数据，具有较好的容错性和可扩展性。

六、Hash环的数据倾斜问题
一致性Hash算法在服务节点太少时，容易因为节点分部不均匀而造成数据倾斜（被缓存的对象大部分集中缓存在某一台服务器上）问题，例如系统中只有两台服务器，其环分布如下： 

此时必然造成大量数据集中到Node A上，而只有极少量会定位到Node B上。为了解决这种数据倾斜问题，一致性Hash算法引入了虚拟节点机制，即对每一个服务节点计算多个哈希，每个计算结果位置都放置一个此服务节点，称为虚拟节点。具体做法可以在服务器IP或主机名的后面增加编号来实现。

例如上面的情况，可以为每台服务器计算三个虚拟节点，于是可以分别计算 “Node A#1”、“Node A#2”、“Node A#3”、“Node B#1”、“Node B#2”、“Node B#3”的哈希值，于是形成六个虚拟节点：

同时数据定位算法不变，只是多了一步虚拟节点到实际节点的映射，例如定位到“Node A#1”、“Node A#2”、“Node A#3”三个虚拟节点的数据均定位到Node A上。这样就解决了服务节点少时数据倾斜的问题。在实际应用中，通常将虚拟节点数设置为32甚至更大，因此即使很少的服务节点也能做到相对均匀的数据分布。

七、总结
上文中，我们一步步分析了什么是一致性Hash算法，主要是考虑到分布式系统每个节点都有可能失效，并且新的节点很可能动态的增加进来的情况，如何保证当系统的节点数目发生变化的时候，我们的系统仍然能够对外提供良好的服务，这是值得考虑的！

https://blog.csdn.net/bntX2jSQfEHy7/article/details/79549368

---

16.什么是restful,讲讲你理解的restul,11如何设计一个良好的API、

RESTful是一种针对Web，iOS，Android和第三方开发者变为平等的角色通过一套API来共同消费Server提供的服务的协议。

REST 指的是一组架构约束条件和原则。

满足这些约束条件和原则的应用程序或设计就是 RESTful。

https://www.jianshu.com/p/0e0ed296d2a3

---

17.如何设计建立和保持100w的长连接。

服务器内核调优(tcp，文件数)，客户端调优，框架选择(netty)

---

18.解释什么是MESI协议(缓存一致性),

      MESI是四种缓存段状态的首字母缩写，任何多核系统中的缓存段都处于这四种状态之一。

我将以相反的顺序逐个讲解，因为这个顺序更合理：
失效（Invalid）缓存段，要么已经不在缓存中，要么它的内容已经过时。

为了达到缓存的目的，这种状态的段将会被忽略。一旦缓存段被标记为失效，那效果就等同于它从来没被加载到缓存中。
共享（Shared）缓存段，它是和主内存内容保持一致的一份拷贝，在这种状态下的缓存段只能被读取，不能被写入。多组缓存可以同时拥有针对同一内存地址的共享缓存段，这就是名称的由来。
独占（Exclusive）缓存段，和S状态一样，也是和主内存内容保持一致的一份拷贝。

区别在于，如果一个处理器持有了某个E状态的缓存段，那其他处理器就不能同时持有它，所以叫“独占”。这意味着，如果其他处理器原本也持有同一缓存段，那么它会马上变成“失效”状态。
已修改（Modified）缓存段，属于脏段，它们已经被所属的处理器修改了。如果一个段处于已修改状态，那么它在其他处理器缓存中的拷贝马上会变成失效状态，这个规律和E状态一样。此外，已修改缓存段如果被丢弃或标记为失效，那么先要把它的内容回写到内存中——这和回写模式下常规的脏段处理方式一样。

---

19.说说你知道的几种Hash算法,简单的也可以。

     哈希(Hash)算法,即散列函数。 它是一种单向密码体制,即它是一个从明文到密文的不可逆的映射,只有加密过程,没有解密过程。 同时,哈希函数可以将任意长度的输入经过变化以后得到固定长度的输出
MD4 ,MD5 ,SHA
http://blog.jobbole.com/106733/

---

20.什么是paxos算法,什么是zab协议.

   Paxos算法是一种基于消息传递的一致性算法。
什么是 zab 协议。
     ZAB 是 Zookeeper 原子广播协议的简称
     整个ZAB协议主要包括消息广播和崩溃恢复两个过程，进一步可以分为三个阶段，

分别是：
    发现 Discovery
    同步 Synchronization
    广播 Broadcast
组成ZAB协议的每一个分布式进程，

都会循环执行这三个阶段，将这样一个循环称为一个主进程周期。
https://zzzvvvxxxd.github.io/2016/08/09/ZAB/

http://baike.baidu.com/item/Paxos 

---

21.一个在线文档系统,文档可以被编辑,如何防止多人同时对同一份文档进行编辑更新。

    可应用版本或时间戳，如A、B、C同时读取某条记录，但都不一定要修改或都有可能修改，这时就可用版本或时间戳了，若A先修改(在数据库中同一条记录不可能被多条语句同时修改的，看以并发，实际是有顺序的），则版本版本或时间戳马上会变的，这时若B修改，每个修改都需要有这样的条件 Where 主键= 主键值 AND 版本 = 之前读取的版本，若返回影响行数为0，则表示已被别人修改过了（则可以客户端相应的提示，如记录已被其他人修改，再刷新再试等等这类）

---

22.线上系统突然变得异常缓慢,你如何查找问题.

   逐级排查（网络，磁盘，内存，cpu），数据库，日志，中间件等也可通过监控工具排查。

---

23.Dubbo的原理,有看过源码么,数据怎么流转的,怎么实现集群,负载均衡,服务注册和发现,重试转发,快速失败的策略是怎样的

     Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
Cluster 实现集群
在集群负载均衡时，Dubbo提供了多种均衡策略，缺省为random随机调用。
Random LoadBalance：随机，按权重比率设置随机概率。
RoundRobin LoadBalance：轮循，按公约后的权重比率设置轮循比率。
LeastActive LoadBalance：最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。

使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance：一致性Hash，相同参数的请求总是发到同一提供者。

当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
快速失败，只发起一次调用，失败立即报错。
https://my.oschina.net/u/1378920/blog/693374

---

24.一次RPC请求的流程是什么.

1）服务消费方（client）调用以本地调用方式调用服务；
2）client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
3）client stub找到服务地址，并将消息发送到服务端；
4）server stub收到消息后进行解码；
5）server stub根据解码结果调用本地的服务；
6）本地服务执行并将结果返回给server stub；
7）server stub将返回结果打包成消息并发送至消费方；
8）client stub接收到消息，并进行解码；
9）服务消费方得到最终结果。

---

25.自己实现过rpc么,原理可以简单讲讲. RPC要解决什么问题。

参考

http://blog.jobbole.com/92290/

---

26.异步模式的用途和意义。

异步模式使用与服务器多核，并发严重的场景
可提高服务吞吐量大，不容易受到冲击，可以采用并发策略，提高响应时间
缓存数据过期后的更新如何设计。
失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
命中：应用程序从cache中取数据，取到后返回。
更新：先把数据存到数据库中，成功后，再让缓存失效。

---

27.编程中自己都怎么考虑一些设计原则的,比如开闭原则,以及在工作中的应用。

开闭原则（Open Close Principle） 
     一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。 
里氏代换原则（Liskov Substitution Principle） 
     子类型必须能够替换掉它们的父类型。 
依赖倒转原则（Dependence Inversion Principle） 
     高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

即针对接口编程，不要针对实现编程 
接口隔离原则（Interface Segregation Principle） 
       建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少 
组合/聚合复用原则 
        说要尽量的使用合成和聚合，而不是继承关系达到复用的目的 
迪米特法则（Law Of Demeter） 
          迪米特法则其根本思想，是强调了类之间的松耦合，类之间的耦合越弱,越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成影响，也就是说，信息的隐藏促进了软件的复用。 
单一职责原则（Single Responsibility Principle） 
          一个类只负责一项职责，应该仅有一个引起它变化的原因 
http://www.banzg.com/archives/225.html

---

28.MVC模式,即常见的MVC框架。

MVC 模式，即常见的 MVC 框架。 
SSM SSH SSI等

模型（Model）：负责存储系统的中心数据。

视图（View）：将信息显示给用户（可以定义多个视图）。

控制器（Controller）：处理用户输入的信息。负责从视图读取数据，控制用户输入，并向模型发送数据，是应用程序中处理用户交互的部分。负责管理与用户交互交互控制。

---

29.应用服务器怎么监控性能,各种方式的区别.

生产上跑的应用，怎么监控其是否运行正常，除了基础环境的监控外，还需要监控使用端口的网络状态，日志是否实时更新。下面分别介绍

1.监控网络状态

常见的网络状态有四种，ESTABLISHED 表示正在通信，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭，LISTEN侦听来自远方的TCP端口的连接请求；其中CLOSE_WAIT状态必须要监控，表示端口被动关闭，可使用如下的语句记录下ClOSE_WAIT状态的个数，如下图：

netstat -n|grep 1521|awk '/^tcp/ {++S[$NF]} END {for(a in S) if(a == "CLOSE_WAIT") print a,S[a]}'
监控ClOSE_WAIT状态的个数，当超过一定的值，系统告警

2.应用日志的最后修改时间监控

有时候进程出现假死，无法对外提供服务，如果只监控基础环境无法知道交易是否正常，可以监控日志最后修改时间，可使用如下的语句

'stat "${file}"|awk '$1 -eq "Modify:"{print $2" "$3}'
file为日志文件，上面的语句会输出modify的最后时间，与系统时间比较，如果超过多长时间未更新，报警提示。

应用日志的监控还可更进一步，实时查看应用日志是否有输出交易成功的日志，可以取日志最新输出几行进行分析。

---

30.如何设计一套高并发支付方案,架构如何设计

 

http://www.360doc.com/content/17/1015/00/30466290_695002481.shtml

---

31.如何实现负载均衡,有哪些算法可以实现

【协议层】http重定向协议实现负载均衡
 原理：根据用户的http请求计算出一个真实的web服务器地址，并将该web服务器地址写入http重定向响应中返回给浏览器，由浏览器重新进行访问。

如图：

优点：比较简单
缺点：浏览器需要零次请求服务器才能完成一次访问，性能较差。
http重定向服务器自身的处理能力可能成为瓶颈。
使用http302响应重定向，有可能使搜索引擎判断为SEO作弊，降低搜索排名。

【协议层】dns域名解析负载均衡
原理：在DNS服务器上配置多个域名对应IP的记录。例如一个域名www.baidu.com对应一组web服务器IP地址，域名解析时经过DNS服务器的算法将一个域名请求分配到合适的真实服务器上。

如图：

• 优点：将负载均衡的工作交给了DNS，省却了网站管理维护负载均衡服务器的麻烦，同事许多DNS还支持基于地理位置的域名解析，将域名解析成距离用户地理最近的一个服务器地址，加快访问速度吗，改善性能。 缺点：目前的DNS解析是多级解析，每一级DNS都可能化缓存记录A，当摸一服务器下线后，该服务器对应的DNS记录A可能仍然存在，导致分配到该服务器的用户访问失败。 DNS负载均衡的控制权在域名服务商手里，网站可能无法做出过多的改善和管理。 不能够按服务器的处理能力来分配负载。DNS负载均衡采用的是简单的轮询算法，不能区分服务器之间的差异，不能反映服务器当前运行状态，所以其的负载均衡效果并不是太好。 可能会造成额外的网络问题。为了使本DNS服务器和其他DNS服务器及时交互，保证DNS数据及时更新，使地址能随机分配，一般都要将DNS的刷新时间设置的较小，但太小将会使DNS流量大增造成额外的网络问题。

【协议层】反向代理负载均衡
原理：反向代理处于web服务器这边，反向代理服务器提供负载均衡的功能，同时管理一组web服务器，它根据负载均衡算法将请求的浏览器访问转发到不同的web服务器处理，处理结果经过反向服务器返回给浏览器。

如图：

• 例如：浏览器访问请求的地址是反向代理服务器的地址114.100.80.10，反向代理服务器收到请求，经过负载均衡算法后得到一个真实物理地址10.0.03，并将请求结果发给真实无服务，真实服务器处理完后通过反向代理服务器返回给请求用户。 优点：部署简单，处于http协议层面。 缺点：使用了反向代理服务器后，web 服务器地址不能直接暴露在外，因此web服务器不需要使用外部IP地址，而反向代理服务作为沟通桥梁就需要配置双网卡、外部内部两套IP地址。

【网络层】IP负载均衡
原理：在网络层通过修改目标地址进行负载均衡。
如图：

•    用户访问请求到达负载均衡服务器，负载均衡服务器在操作系统内核进程获取网络数据包，根据算法得到一台真实服务器地址，然后将用户请求的目标地址修改成该真实服务器地址，数据处理完后返回给负载均衡服务器，负载均衡服务器收到响应后将自身的地址修改成原用户访问地址后再讲数据返回回去。类似于反向服务器负载均衡。
     
     优点：在响应请求时速度较反向服务器负载均衡要快。
     缺点：当请求数据较大（大型视频或文件）时，速度较慢。

【链路层】数据链路层负载均衡
原理：在数据链路层修改Mac地址进行负载均衡。

如图：

    负载均衡服务器的IP和它所管理的web 服务群的虚拟IP一致；
    负载均衡数据分发过程中不修改访问地址的IP地址，而是修改Mac地址；
    通过这两点达到不修改数据包的原地址和目标地址就可以进行正常的访问。

   优点：不需要负载均衡服务器进行地址的转换。
               数据响应时不需要经过负载均衡服务器。
    缺点：负载均衡服务器的网卡带宽要求较高。

   目前连路程负载均衡是特别常见的一种手段，典型的产品有LVS（Linux Virtual Server）。
 

算法实现
常见的负载均衡算法包括轮询法、随机法、源地址哈希法、加权轮询法、加权随机法、最小连接法等。具体实现如下：

https://blog.csdn.net/LianXu3344/article/details/82907799

---

32.Zookeeper的用途,选举的原理是什么.

Leader选举机制是保证分布式数据一致性的关键所在，在zk集群中有两种情况需要进入leader选举: 
1.服务器初始化启动 
2.服务器运行期间无法与leader保持连接

（leader服务器挂掉了）

在zk中投票的实体Vote，但是每次投票的信息都是基于id与zxid，但是有些校验的判断需要用到其他的信息，

Vote的属性如下 
     version：版本信息，重写equals的时候使用 
     id：被推荐的leader的sid也就是myid 
     zxid：被推荐的leader的事务id 
     electionEpoch：逻辑时钟，用来判断多个投票是否在同一个选举周期中，该值在服务端是一个自增序列，每次进入新的一轮投票后，都会对该值进行加1操作 
    peerEpoch：被推荐leader的epoch 
   state：当前服务器的状态 
如果要进行leader选举的话，至少需要两台服务器，一台服务器也无法投票

服务器启动时期的leader选举流程（假设三台服务器）

1.每台服务器发出一个投票 
        由于是初始化启动，所有的服务器都会选取自己为leader进行投票，每次投票的信息否是Vote，但是PK的时候比较的信息还是sid与zxid两个信息。因为是初始化启动，S1启动时无法进行选举，当S2启动时，有两台服务器了，就可以互相通信了，可以先执行选举 
2.接收来自各个服务器的投票 
      集群中每个服务器除了投票以外还要接收其他服务器的投票，首先判断该选票的有效性，如果有效的选票才会接着处理 
3.处理投票 
     针对其他服务器的选票，服务器都需要将别人的选票与自己的选票进行PK。 
PK规则主要有两个： 
    1.优先对比zxid，zxid较大的服务器优先作为leader 
    2.如果zxid想的，则对比sid，sid大的作为leader 
假设S1的sid与zxid为（1,0），S2的sid与zxid（2，0）（都是初次启动，zxid都为0） 
S1内部比较： 
     zxid相等，比较sid，S2的sid大，所以S1更新选票，改投S2为leader，重新将选票发给其他服务器 
S2内部比较： 
    同上规则，S2还是将选票给自己，然后再把选票发给其他服务器 
4.统计投票 
     每次投票后，服务器都会统计投票信息，如果有超过半数的机器有相同的投票，那么就可以选举出leader。这次是三台机器，两台都选S2，所以S2为leader 
5.改变服务器状态 
     一旦确定了leader，每个服务器都需要更新自己的状态，定位自己的角色，根据角色更新成不同的状态

服务器运行期间的leader选举

服务器运行期间的leader选举与启动时的选举只有前两步不一样，后面的都是一样的逻辑操作。 
1.变更服务器状态(因为是运行期间) 
    Leader挂掉以后，剩下的能参加选举的服务器（主要是Follower）将会把自己的服务器状态改为LOOKING，然后进去选举Leader过程。 
2.每个服务器开始选举Leader 
    与初始化启动类似，主要信息还是sid与zxid，第一次都是选自己为leader，将选票发送到其他服务器 
3.其他步骤与启动时一致（接收选票，处理选票，统计选票，更改状态）

https://blog.csdn.net/liuj2511981/article/details/42460069

---

33.Zookeeper watch机制原理。

      一个zk的节点可以被监控，包括这个目录中存储的数据的修改，子节点目录的变化，一旦变化可以通知设置监控的客户端，这个功能是zookeeper对于应用最重要的特性，通过这个特性可以实现的功能包括配置的集中管理，集群管理，分布式锁等等。

       watch机制官方说明：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。

zookeeper机制的特点 

   1)  一次性的触发器（one-time trigger)

     当数据改变的时候，那么一个Watch事件会产生并且被发送到客户端中。但是客户端只会收到一次这样的通知，如果以后这个数据再次发生改变的时候，之前设置Watch的客户端将不会再次收到改变的通知，因为Watch机制规定了它是一个一次性的触发器。           

         当设置监视的数据发生改变时，该监视事件会被发送到客户端，例如，如果客户端调用了 getData("/znode1", true) 并且稍后 /znode1 节点上的数据发生了改变或者被删除了，客户端将会获取到 /znode1 发生变化的监视事件，而如果 /znode1 再一次发生了变化，除非客户端再次对 /znode1 设置监视，否则客户端不会收到事件通知。

  2)发送给客户端（Sent to the client）     

       这个表明了Watch的通知事件是从服务器发送给客户端的，是异步的，这就表明不同的客户端收到的Watch的时间可能不同，但是ZooKeeper有保证：当一个客户端在看到Watch事件之前是不会看到结点数据的变化的。例如：A=3，此时在上面设置了一次Watch，如果A突然变成4了，那么客户端会先收到Watch事件的通知，然后才会看到A=4。

       Zookeeper 客户端和服务端是通过 Socket 进行通信的，由于网络存在故障，所以监视事件很有可能不会成功地到达客户端，监视事件是异步发送至监视者的，Zookeeper 本身提供了保序性(ordering guarantee)：即客户端只有首先看到了监视事件后，才会感知到它所设置监视的 znode 发生了变化(a client will never see a change for which it has set a watch until it first sees the watch event). 网络延迟或者其他因素可能导致不同的客户端在不同的时刻感知某一监视事件，但是不同的客户端所看到的一切具有一致的顺序。

   3).被设置Watch的数据（The data for which the watch was set）

         这意味着 znode 节点本身具有不同的改变方式。你也可以想象 Zookeeper 维护了两条监视链表：

       数据监视和子节点监视(data watches and child watches) 

       getData() and exists() 设置数据监视，getChildren() 设置子节点监视。 或者，你也可以想象 Zookeeper 设置的不同监视返回不同的数据，getData() 和 exists() 返回 znode 节点的相关信息，而 getChildren() 返回子节点列表。

       因此， setData() 会触发设置在某一节点上所设置的数据监视(假定数据设置成功)，而一次成功的 create() 操作则会出发当前节点上所设置的数据监视以及父节点的子节点监视。一次成功的 delete() 操作将会触发当前节点的数据监视和子节点监视事件，同时也会触发该节点父节点的child watch。

3.各种watch触发的情况总结

       可以注册watcher的方法：

                    getData、exists、getChildren。

       可以触发watcher的方法：

               create、delete、setData。

       连接断开的情况下触发的watcher会丢失。

       一个Watcher实例是一个回调函数，被回调一次后就被移除了。如果还需要关注数据的变化，需要再次注册watcher。

         New ZooKeeper时注册的watcher叫default watcher，它不是一次性的，只对client的连接状态变化作出反应。

4.实现永久监听

       由于zookeeper是一次性监听，所以我们必须在wather的process方法里面再设置监听。一个方法如下：

       以下逻辑是实现的是生产者和消费者模型，消费者监听某一路径下面子节点的变化，当生产者有消息发送过来的时候，在该节点下面创建一个子节点，然后把消息放到该子节点里面，这会触发消费者的process方法被调用，然后消费者取到该节点下面的子节点(顺便设置一个再监听该节点的子节点)，然后取出子节点的内容，做处理，然后删除该子节点。

https://blog.csdn.net/java_green_hand0909/article/details/84196864

---

34.后台系统怎么防止请求重复提交。

             可以通过token值进行防止重复提交，存放到redis中，在表单初始化的时候隐藏在表单中，添加的时候在移除。

     判断这个状态即可防止重复提交。

---

35.描述一个服务从发布到被消费的详细过程

（1）服务提供者暴露一个服务的详细过程

服务提供者暴露服务的主过程：

首先ServiceConfig类拿到对外提供服务的实际类ref（如HelloWorldImpl），然后通过ProxyFactory的getInvoker()方法使用ref生成一个AbstractProxyInvoker实例，到这一步就完成具体服务到Invoker的转化。接下来就是Invoker转换到Exporter的过程。

Dubbo处理服务暴露的关键就在Invoker转换到Exporter的过程(如上图中的红色部分)，下面我们以Dubbo和RMI这两种典型协议的实现来进行说明：

Dubbo的实现

Dubbo协议的Invoker转为Exporter发生在DubboProtocol类的export方法，它主要是打开socket侦听服务，并接收客户端发来的各种请求，通讯细节由Dubbo自己实现。

RMI的实现

RMI协议的Invoker转为Exporter发生在RmiProtocol类的export方法，

它通过Spring或Dubbo或JDK来实现RMI服务，通讯细节这一块由JDK底层来实现，这就省了不少工作量。

（2）服务消费者消费一个服务的详细过程

服务消费的主过程：

 

首先ReferenceConfig类的init方法调用Protocol的refer方法生成Invoker实例(如上图中的红色部分)，这是服务消费的关键。

接下来把Invoker转换为客户端需要的接口(如：HelloWorld)。

https://blog.csdn.net/qq_33827112/article/details/79627319

---

38.讲讲你理解的服务治理。

互联网架构演变
一体架构
在计算机软件发展早期，一般桌面软件都是采用这种架构，不管是界面还是业务处理还是数据处理都放到一个包中。这种其实谈不上架构，但也可以说是很好的架构，因为它足够简单。

mvc架构
但随着浏览器的出现便产生了web应用，web应用的特点是界面部分是显示在浏览器中，服务处理是在服务容器中的，页面显示一般用css+js+html技术来处理，而后端可以用java、php等语言，这就产生了前后端分离。

对于web系统，一体架构难以满足前后端分离的开发需求，因而便产生了MVC架构。

MVC才算的上真正意义上的架构，因为它除了解决了前后端分离问题，还引入了一种全新的开发模式，用一种业务逻辑、数据、界面显示分离的方法组织代码，使得整个应用层次更加分明，而且各个层次之间不但减低了耦合性，还提高了各个层次的可重用性。

但随着应用规模的不断扩大，应用模块不断增加，整个应用也显得越来越臃肿，维护起来也更加困难，因此便又产生了多应用架构。

多应用架构
多应用架构很简单，就是把原来的应用按照业务特点拆分成多个应用。比如一个大型电商系统可能包含用户系统、商品系统、订单系统、评价系统等等，我们可以把他们独立出来形成一个个单独的应用。多应用架构的特点是应用之间各自独立 ，不相互调用。

多应用虽然解决了应用臃肿问题，但应用之间相互独立，有些共同的业务或代码无法复用。

分布式架构
对于一个大型的互联网系统，一般会包含多个应用，而且应用之间往往还存在共同的业务，并且应用之间还存在调用关系。除此之外 ，对于大型的互联网系统还有一些其它的挑战，比如如何应对急剧增长的用户，如何管理好研发团队快速迭代产品研发，如何保持产品升级更加稳定等等 。

因此，为了使业务得到很好的复用，模块更加容易拓展和维护，我们希望业务与应用分离，某个业务不再属于一个应用，而是作为一个独立的服务单独进行维护。应用本身不再是一个臃肿的模块堆积，而是由一个个模块化的服务组件组合而成。

服务化

服务化的特点

上面介绍的分布式架构即服务化。我们再总结一下，服务化主要有如下特点：

• 应用按业务拆分成服务
• 各个服务均可独立部署
• 服务可被多个应用共享
• 服务之间可以通信

服务化的好处

那么企业采用服务化有哪些好处呢？

• 架构上系统更加清晰
• 核心模块稳定，以服务组件为单位进行升级，避免了频繁发布带来的风险
• 开发管理方便
• 单独团队维护、工作分明，职责清晰
• 业务复用、代码复用
• 非常容易拓展

服务化实现方式

如果要实现服务化的话，最常用的方式就是利用RPC框架。因为服务组件一般分布在不同的服务器上，所以要实现服务化需要解决的第一个问题就是RPC**远程服务调用**。类似于RPC方案有很多，比如：

• Java RMI
• WebService
• Hessian
• Http
• Thrift
• … …

服务化面临的挑战

上面提到要实现服务化首先需要解决远程服务调用问题，除此之外，还有很多其他问题需要解决。

• 服务越来越多，配置管理复杂
• 服务间依赖关系复杂
• 服务之间的负载均衡
• 服务的拓展
• 服务监控
• 服务降级
• 服务鉴权
• 服务上线与下线
• 服务文档
• … …

服务治理

上面提到了服务化，其实要想服务化，服务治理是关键。那么有没有好的服务治理方案呢？答案是有的，而且很多人都在用这个框架，他就是-dubbo。dubbo就是一个带有服务治理功能的RPC框架。

dubbo提供了一套较为完整的服务治理方案，所以企业如果要实现服务化的话，dubbo 是很好的一个选择。这里简单介绍一下dubbo服务治理相关方案。

服务发现注册
服务治理领域最重要的问题就是服务发现与注册。dubbo中引入了一个注册中心的概念，服务的注册与发现主要就依赖这个服务中心。

dubbo注册中心服务注册发现的具体过程：

• 服务提供者启动，向注册中心注册自己提供的服务
• 消费者启动，向注册中心订阅自己需要的服务
• 注册中心返回服务提供者的列表给消费者
• 消费者从服务提供者列表中，按照软负载均衡算法，选择一台发起请求

服务监控

集群容错

负载均衡

• Random Loadbalance
• RoundRobin
• LeastActive
• ConsistentHash

dubbo服务治理优势

• 注册中心只负责注册查找，不负责请求转发，压力小
• 注册中心宕机影响消费者，消费者本地缓存服务地址列表
• 注册中心对等集群，宕掉一台自动切换到另外 一台
• 服务提供者无状态，可动态部署，注册中心负责推送
• 统计无压力，本地内存中累计次数，每分钟发送注册中心
• 消费者调用服务者，自动软负载均衡
• 通过服务中心可追踪依赖关系
• 监控中心为扩容和降级提供依据
• 可启用acl机制进行鉴权
• 与Spring整合，接入简单松耦合
• 多种序列化协议支持

dubbo的不足

• 消费者仍需要依赖配置中心
• 消费者仍需要依赖jar包配置provider
• 提供者文档管理功能缺失
• 无统一入口
• 不支持OAuth2.0
• 内部鉴权不方便管理
• 无外部应用鉴权
• 接口基本裸奔，无法直接对外暴露服务
• IT治理不方便

---

微服务

现在很多人都在谈微服务，那么到底什么是微服务呢？这里谈谈我对微服务的理解。

微服务有两个核心：

• 微：服务的粒度要细，即服务要细化到API
• 服务：提供好服务，要让用户感到好用(要做到这一点很不容易)

上面两个核心总结起来，可以用下面这幅图表示：

从上面这幅图看出，微服务特别简单（好的架构就应该简单），我们把服务再拆分成一个个API，API是一个完整的功能。然后我们把API扔到一个“云上”，然后用户就可以到“云上”获取所有API的服务，这个“云”保证能提供好的服务。

我们可以看到，有了微服务之后，服务对用户来说变得特别简单，而且上面dubbo的不足之处在微服务这里都解决了。使用者不再需要依赖任何jar包，不再需要去注册中心查找服务，不再去做鉴权处理，不用担心服务挂掉，不用担心不会使用服务，所有的问题这个“云”都解决了。这也是微服务的核心之一，提供好服务。

说到这里，大家就应该大体知道该怎么做微服务了，图中的“云”是关键。下面我们就慢慢拨开这朵云。

微服务的实现

微服务的关键是服务网关，所以，上面提到的“云”就是服务网关。要做微服务，我们先定义一下微服务需要具备的特点。

微服务的特点

服务需要再细化成API（服务接口——>服务API）

• 每个服务由一组API组成
• 以API形式对外提供统一格式的服务
• 使用者无需任何配置，直接调用（http）
• 完整的API文档
• API服务安全可靠稳定

微服务要解决的问题

上面提到了，dubbo还存在一些问题 ，其实dubbo存在的问题 就是 微服务要解决的问题，这里 再总结一下。当然，dubbo和微服务的侧重点不一样，dubbo侧重于内部接口之间的RPC，而微服务则侧重于对外提供服务。

• 统一入口
• 安全控制：防刷限流
• 统一鉴权：应用鉴权、用户鉴权、OAuth鉴权、ACL
• 协议转换：http、dubbo、Protobuf
• API配置管理
• API上线、下线
• API与服务接口映射
• 监控与报警
• 整体架构的可拓展、高并发、分布式
• 服务容器自动收缩、扩容

---

实现方案

• 负载均衡层：nginx/lvs/F5

微服务层 

• 高性能服务网关
• 统一入口、API配置管理、分流鉴权、服务监控、协议转换
• API映射、OAuth2.0、API文档管理
• 分布式、可拓展

• 服务治理层 
  • 成熟的服务治理框架dubbo
  • MQ服务之间解耦
• 弹性云 
  • 服务docker化
  • 基于访问压力的实时集群调度与管理

弹性云
这里简单介绍一下弹性云的概念，微服务要想提供好服务，保证API不能挂掉并且有好的性能，需要很高的运维要求。这里的弹性云便是自动化运维解决方案，对访问压力进行监控，根据监控解决调度应用的发布和回收。

 

https://blog.csdn.net/suifeng3051/article/details/53992560

---

39.如何做到接口的幕等性。

口的幂等性实际上就是接口可重复调用，在调用方多次调用的情况下，接口最终得到的结果是一致的。有些接口可以天然的实现幂等性，比如查询接口，对于查询来说，你查询一次和两次，对于系统来说，没有任何影响，查出的结果也是一样。

除了查询功能具有天然的幂等性之外，增加、更新、删除都要保证幂等性。那么如何来保证幂等性呢？

全局唯一ID
如果使用全局唯一ID，就是根据业务的操作和内容生成一个全局ID，在执行操作前先根据这个全局唯一ID是否存在，来判断这个操作是否已经执行。如果不存在则把全局ID，存储到存储系统中，比如数据库、redis等。如果存在则表示该方法已经执行。

从工程的角度来说，使用全局ID做幂等可以作为一个业务的基础的微服务存在，在很多的微服务中都会用到这样的服务，在每个微服务中都完成这样的功能，会存在工作量重复。另外打造一个高可靠的幂等服务还需要考虑很多问题，比如一台机器虽然把全局ID先写入了存储，但是在写入之后挂了，这就需要引入全局ID的超时机制。

使用全局唯一ID是一个通用方案，可以支持插入、更新、删除业务操作。但是这个方案看起来很美但是实现起来比较麻烦，下面的方案适用于特定的场景，但是实现起来比较简单。

去重表
这种方法适用于在业务中有唯一标的插入场景中，比如在以上的支付场景中，如果一个订单只会支付一次，所以订单ID可以作为唯一标识。这时，我们就可以建一张去重表，并且把唯一标识作为唯一索引，在我们实现时，把创建支付单据和写入去去重表，放在一个事务中，如果重复创建，数据库会抛出唯一约束异常，操作就会回滚。

插入或更新
这种方法插入并且有唯一索引的情况，比如我们要关联商品品类，其中商品的ID和品类的ID可以构成唯一索引，并且在数据表中也增加了唯一索引。这时就可以使用InsertOrUpdate操作。在mysql数据库中如下：

insert into goods_category (goods_id,category_id,create_time,update_time) 
       values(#{goodsId},#{categoryId},now(),now()) 
       on DUPLICATE KEY UPDATE
       update_time=now()

多版本控制
这种方法适合在更新的场景中，比如我们要更新商品的名字，这时我们就可以在更新的接口中增加一个版本号，来做幂等

boolean updateGoodsName(int id,String newName,int version);

在实现时可以如下

update goods set name=#{newName},version=#{version} where id=#{id} and version<${version}

状态机控制
这种方法适合在有状态机流转的情况下，比如就会订单的创建和付款，订单的付款肯定是在之前，这时我们可以通过在设计状态字段时，使用int类型，并且通过值类型的大小来做幂等，比如订单的创建为0，付款成功为100。付款失败为99

在做状态机更新时，我们就这可以这样控制

update `order` set status=#{status} where id=#{id} and status<#{status}

以上就是保证接口幂等性的一些方法。

https://blog.csdn.net/wangyan9110/article/details/70953273

---

40.如何做限流策略,令牌梯和漏斗算法的使用场景。

• 限流算法

        令牌桶算法
        漏桶算法

• 应用级限流

          限制总并发数/连接/请求数
          限制接口的总并发/请求数
          限流接口每秒的请求数
          平滑限流接口的请求数
              平滑突发限流（SmoothBursty）
              平滑预热限流（SmoothWarmingUp）
在开发高并发的系统时，有很多手段来保护系统，如缓存、降级和限流等。缓存可以提升系统的访问速度，降级可以暂时屏蔽掉非核心业务，使得核心业务不受影响。限流的目的通过对并发访问进行限速，一旦达到一定的速率就可以拒绝服务（定向到错误页或告知资源没有了）、排队等待（如秒杀、评论、下单等）、降级（直接返回兜底数据、如商品库存默认有货）。

常见的限流方式有：限制总并发数（数据库连接池、线程池）、限制瞬时并发数（如Nginx的limit_conn模块）、限制时间窗口的平均速率（如Guava的RateLimiter、Nginx的limit_req模块）、限制远程接口的调用速率、限制MQ的消费速率等。从应用的层面上来讲，又可以分为：接入层限流、应用层限流和分布式限流等。

 令牌桶算法

漏桶算法 

 

限制总并发数/连接/请求数

对于一个应用来说，总会有一个TPS/QPS的阀值，如果超过了阀值，则系统就会变得非常慢跟甚至无法响应。因此需要对系统进行过载保护，避免大量请求击垮系统。

 限制接口的总并发/请求数

https://blog.csdn.net/fouy_yun/article/details/81025984

---

41.dubbo的泛化调用怎么实现的,如果是你,你会怎么做.

    dubbo泛化实现方式主要用于服务器端没有API借口及横型类元的情况，参数及返回值中的所有POJO均使用Map表示，通常用于框架集成。比如：实现一个通用的远程服务，可通过实现GenenricService接口实现所有服务请求。
如如下服务实现：

https://blog.csdn.net/u010317829/article/details/52151054

https://blog.csdn.net/qq_24462991/article/details/82795235

高并发架构解决方案总结。

https://yq.aliyun.com/articles/652450

---

42.dubbo相关题

https://blog.csdn.net/Y0Q2T57s/article/details/83005376

---

43.zookeeper 是什么？

• zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，是google chubby的开源实现，是hadoop和hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。

---

44.zookeeper 都有哪些功能？

• 集群管理:监控节点存活状态、运行请求等。
• 主节点选举:主节点挂掉了之后可以从备用的节点开始新一轮选主,主节点选举说的就是这个选举的过程,使用zookeeper可以协助完成这个过程。
• 分布式锁: zookeeper提供两种锁:独占锁、共享锁。独占锁即一次只能有一个线程使用资源,共享锁是读锁共享,读写互斥,即可以有多线线程同时读同一个资源,如果要使用写锁也只能有一个线程使用。zookeeper可以对分布式锁进行控制。
• 命名服务:在分布式系统中,通过使用命名服务,客户端应用能够根据指定名字来获取资源或服务的地址,提供者等信息。

---

45.zookeeper 有几种部署模式？

zookeeper有三种部署模式:

• 单机部署：一台集群上运行；
• 集群部署:多台集群运行;
• 伪集群部署:一台集群启动多个zookeeper实例运行,

---

46.zookeeper 怎么保证主从节点的状态同步？

• zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做zab协议。
• zab协议有两种模式
• 分别是恢复模式(选主) 和 广播模式(同步)。
• 当服务启动或者在领导者崩溃后, zab就进入了恢复模式,当领导者被选举出来,且大多数server完成了和leader的状态同步以后,恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。

---

47.集群中为什么要有主节点？

• 在分布式环境中,有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算,提高性能,所以就需要主节点

---

48.集群中有 3 台服务器，其中一个节点宕机，这个时候 zookeeper 还可以使用吗？

• 可以继续使用，单数服务器只要没超过一半的服务器宕机就可以继续使用。

---

49.说一下 zookeeper 的通知机制？

• 客户端端会对某个znode建立一个watcher事件，当该znode发生变化时，这些客户端 会收到zookeeper的通知，然后客户端可以根据znode变化来做出业务上的改变。

---

50.分布式架构

cap理论

1. 可用性
2. 一致性
3. 分区容忍性：对网络断开的容忍度，有点像鲁棒性
4. 拜占庭将军问题

Raft 算法

• 有leader、follower、candidate

同步流程

1. 由客户端提交数据到Leader节点。
2. 由Leader节点把数据复制到集群内所有的Follower节点。如果一次复制失败，会不断进行重试。
3. Follower节点们接收到复制的数据，会反馈给Leader节点。
4. 如果Leader节点接收到超过半数的Follower反馈，表明复制成功。于是提交自己的数据，并通知客户端数据提交成功。
5. 由Leader节点通知集群内所有的Follower节点提交数据，从而完成数据同步流程。

zookeeper

Zab（Zookeeper Atomic Broadcast）协议,有两种模式：

              它们分别是：恢复模式（选主）和广播模式（同步）。

              有两种算法：1. basic paxos；2. fast paxos（默认）

1. 文件系统：zookeeper的通知机制、分布式锁、队列管理、配置管理都是基于文件系统的。
2. 分布式锁：有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。
3. 独占锁：将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的distribute_lock 节点就释放出锁。
4. 控制时序锁：/distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除。
5. 队列管理，分为同步队列、非同步队列
6. 数据复制的好处

• 容错：一个节点出错，不致于让整个系统停止工作，别的节点可以接管它的工作；
• 提高系统的扩展能力 ：把负载分布到多个节点上，或者增加节点来提高系统的负载能力；
• 提高性能：让客户端本地访问就近的节点，提高用户访问速度。

Spring cloud

• 网关：zuul
• 分布式版本化配置 config
• 服务注册和发现：Eureka，配置时需要注意多久刷新列表一次，多久监测心跳等。
• service-to-service 调用
• 负载均衡：Ribbon；在生成RestTemplate的bean时，通过@LoadBalanced注解可以使得RestTemplate的调用
• 断路器：Hystrix
• 监控：spring admin。在启动类上加@EnableAdminServer注解。

---

 51.谈谈你对webservice理解

   WebService是一种跨编程语言和跨操作系统平台的远程调用技术。

   XML+XSD,SOAP和WSDL就是构成WebService平台的三大技术

   SOAP协议 = HTTP协议 + XML数据格式

　WebService开发可以分为服务器端开发和客户端开发两个方面

WebService 的工作调用原理

   对客户端而言，我们给这各类WebService客户端API传递wsdl文件的url地址，这些API就会创建出底层的代理类，我调用 这些代理，就可以访问到webservice服务。代理类把客户端的方法调用变成soap格式的请求数据再通过HTTP协议发出去，并把接收到的soap 数据变成返回值返回。对服务端而言，各类WebService框架的本质就是一个大大的Servlet，当远程调用客户端给它通过http协议发送过来 soap格式的请求数据时，它分析这个数据，就知道要调用哪个java类的哪个方法，于是去查找或创建这个对象，并调用其方法，再把方法返回的结果包装成 soap格式的数据，通过http响应消息回给客户端。

---

 52.什么是 SOA，谈谈你的 SOA 的理解。service orientied architecture？

SOA 是指为了解决在 Internet 环境下业务集成的需要，通过连接能完成特定任务的独立功能

实体实现的一种软件系统架构。

1) 软件系统架构：SOA 不是一种语言，也不是一种具体的技术而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它更像一种模式(Pattern)。因此它与很多已有的软件技术比如面向对象技术，是互补的而非互斥的。它们分别面向不同的应用场景，用来满足不同的特定需求。

2) SOA 的使用范围：需求决定同时也限制功能。SOA 并不是包治百病的万灵丹，它最主要的应用场合在于解决在 Internet 环境下的不同商业应用之间的业务集成问题。系统与系统之间的服务调用

---

53 .KeepAlive是用来干什么的？这样的好处是什么？

默认http1.1协议的请求头是默认开启keepalive

keepalive是在TCP中一个可以检测死连接的机制，作用是保持socket长连接不被断开，属于tcp层的功能，并不属于应用层。 

先看keepalive的用法：有三个参数，开放给应用层使用

sk->keepalive_probes：探测次数，重试次数
sk->keepalive_time 探测的心跳间隔，TCP链接在多少秒之后没有数据报文传输启动探测报文
sk->keepalive_intvl 探测间隔，未收到回复时，重试的时间间隔

 

使用keepalive 主要是为了减少TCP三次握手与关闭时带来的TIME_WAIT的时延，为了减少网络开销，使用keepalive来在建立的一个TCP连接上执行多个HTTP请求，这样可以带来很好的用户体验。

如果服务器端设置的keepalive，长时间没有得到客户端的响应，nginx会根据定时器的实际情况将该条连接断开。当有多条连接的时候，nginx就需要维护多个定时器，nginx的方法是：
   设置一个超时时间，然后将这个时间放入到rbtree里面，每次要进行epoll_wait等待的时候，都需要设置超时时间，此时只要寻找rbtree当中最小的超时时间（绝对时间，不是时间段）即可

https://segmentfault.com/a/1190000016637212

---

54.分布式session设置

分析：

 

 

 

 同步：

 

redis

 

 

什么是session？

    服务器为每个用户创建一个会话，存储用户的相关信息，以便多次请求能够定位到同一个上下文。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当用户请求来自应用程序的 Web 页时，如果该用户还没有会话，则 Web 服务器将自动创建一个 Session 对象。当会话过期或被放弃后，服务器将终止该会话。

Web开发中，web-server可以自动为同一个浏览器的访问用户自动创建session，提供数据存储功能。最常见的，会把用户的登录信息、用户信息存储在session中，以保持登录状态。

什么是session一致性问题？

只要用户不重启浏览器，每次http短连接请求，理论上服务端都能定位到session，保持会话。

分布式session

单服务器web应用中，session信息只需存在该服务器中，这是我们前几年最常接触的方式，但是近几年随着分布式系统的流行，单系统已经不能满足日益增长的百万级用户的需求，集群方式部署服务器已在很多公司运用起来，当高并发量的请求到达服务端的时候通过负载均衡的方式分发到集群中的某个服务器，这样就有可能导致同一个用户的多次请求被分发到集群的不同服务器上，就会出现取不到session数据的情况，于是session的共享就成了一个问题。

如上图，假设用户包含登录信息的session都记录在第一台web-server上，反向代理如果将请求路由到另一台web-server上，可能就找不到相关信息，而导致用户需要重新登录。

Session一致性解决方案

1.session复制（同步）

 

思路：多个web-server之间相互同步session，这样每个web-server之间都包含全部的session

优点：web-server支持的功能，应用程序不需要修改代码

不足：

• session的同步需要数据传输，占内网带宽，有时延

• 所有web-server都包含所有session数据，数据量受内存限制，无法水平扩展

• 有更多web-server时要歇菜

2.客户端存储法 

思路：服务端存储所有用户的session，内存占用较大，可以将session存储到浏览器cookie中，每个端只要存储一个用户的数据了

优点：服务端不需要存储

缺点：

• 每次http请求都携带session，占外网带宽

• 数据存储在端上，并在网络传输，存在泄漏、篡改、窃取等安全隐患

• session存储的数据大小受cookie限制

“端存储”的方案虽然不常用，但确实是一种思路。

3.反向代理hash一致性

 思路：web-server为了保证高可用，有多台冗余，反向代理层能不能做一些事情，让同一个用户的请求保证落在一台web-server上呢？

 

 

方案一：四层代理hash

反向代理层使用用户ip来做hash，以保证同一个ip的请求落在同一个web-server上

 

方案二：七层代理hash

反向代理使用http协议中的某些业务属性来做hash，例如sid，city_id，user_id等，能够更加灵活的实施hash策略，以保证同一个浏览器用户的请求落在同一个web-server上

优点：

• 只需要改nginx配置，不需要修改应用代码

• 负载均衡，只要hash属性是均匀的，多台web-server的负载是均衡的

• 可以支持web-server水平扩展（session同步法是不行的，受内存限制）

不足：

• 如果web-server重启，一部分session会丢失，产生业务影响，例如部分用户重新登录

• 如果web-server水平扩展，rehash后session重新分布，也会有一部分用户路由不到正确的session

session一般是有有效期的，所有不足中的两点，可以认为等同于部分session失效，一般问题不大。

对于四层hash还是七层hash，个人推荐前者：让专业的软件做专业的事情，反向代理就负责转发，尽量不要引入应用层业务属性，除非不得不这么做（例如，有时候多机房多活需要按照业务属性路由到不同机房的web-server）。

 

4.后端统一集中存储

 

思路：将session存储在web-server后端的存储层，数据库或者缓存

优点：

• 没有安全隐患

• 可以水平扩展，数据库/缓存水平切分即可

• web-server重启或者扩容都不会有session丢失

不足：增加了一次网络调用，并且需要修改应用代码

对于db存储还是cache，个人推荐后者：session读取的频率会很高，数据库压力会比较大。如果有session高可用需求，cache可以做高可用，但大部分情况下session可以丢失，一般也不需要考虑高可用。

     保证session一致性的架构设计常见方法：

• session同步法：多台web-server相互同步数据

• 客户端存储法：一个用户只存储自己的数据

• 反向代理hash一致性：四层hash和七层hash都可以做，保证一个用户的请求落在一台web-server上

• 后端统一存储：web-server重启和扩容，session也不会丢失

---

55.了解SOA，微服务吗？

1. 微服务相比于SOA更加精细，微服务更多的以独立的进程的方式存在，互相之间并无影响；
2. 微服务提供的接口方式更加通用化，例如HTTP RESTful方式，各种终端都可以调用，无关语言、平台限制；
3. 微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合；

而微服务架构大体是从互联网企业兴起的，由于大规模用户，对分布式系统的要求很高，如果像企业计算那样的系统，伸缩就需要多个容纳续续多多的服务的系统实例，前面通过负载均衡使得多个系统成为一个集群。

那么就倾向采用以子系统为分割，不同的子系统采用自己的架构，那么各个服务运行自己的Web容器中，当需要增加计算能力的时候，只需要增加这个子系统或服务的实例就好了，当升级的时候，可以不影响别的子系统。这种组织方式大体上就被称作微服务架构。
微服务与SOA相比，更强调分布式系统的特性，比如横向伸缩性，服务发现，负载均衡，故障转移，高可用。互联网开发对服务治理提出了更多的要求，比如多版本，比如灰度升级，比如服务降级，比如分布式跟踪，这些都是在SOA实践中重视不够的。
Docker容器技术的出现，为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似Node.js或Spring Boot的技术跑在自己的进程中。可能在几十台计算机中运行成千上万个Docker容器，每个容器都运行着服务的一个实例。随时可以增加某个服务的实例数，或者某个实例崩溃后，在其他的计算机上再创建该服务的新的实例。

---

56.分布式系统如何负载均衡？如何确定访问的资源在哪个服务器上？

     一.轮询

     二.随机

      三.最小响应时间

     四. 最小并发数

     五.哈希

---

57.设计一个分布式负载均衡缓冲系统，如何快速定位到是那个服务器

使用key分段、一致性hash

---

58.如何保证缓冲区和数据库之间的强一致性

使用加锁

1、引用缓存的好处
        1）提高性能；2）减缓数据库压力；3）提高系统并发处理能力

2、引用缓存的问题
        1）处理逻辑变得复杂；2）使用不当，容易引起缓存和数据库数据不一致的问题

3、数据不一致的原因
        缓存操作与数据库操作不是原子操作，当一方操作成功、另一方操作失败时就会造成数据不一致问题

4、不同情况下常用处理方法
        1）简单逻辑处理：与数据库简单的一次性交互，可根据数据库/缓存的操作结果，来判断缓存/数据库是否要执行相应操作，如图：

a、增：db-->cache：数据库插入成功，添加到缓存

b、删：cache-->db：先删缓存，在删数据库

c、改：db-->cache：先改数据库，在改缓存

d、查：cache-->db-->cache：先查缓存，没有则查库添加到缓存

2）复杂逻辑处理：一个service中有多次数据库交互，并且由于spring事务传播性不同有时只在最外层事务提交时提交（spring默认事务传播性）

a、增：db：只插入数据库

b、删：cache-->db：先删缓存，再删数据库

c、改：cache-->db：先删缓存，再删数据库

d、查：cache-->db-->cache：先查缓存，没有则查库添加到缓存

注：

1）还可以通过设置标志位，在外层回滚缓存的做法，由于该方法会使缓存操作与业务操作耦合性过大，此处不做介绍；

2）如上操作cache与db的理由，未详细解释，如有需要可回复评论探讨；

3）该篇博文主要用于讨论解决数据库与缓存不一致问题，对于高并发下造成的线程安全问题，后续讨论。。。
 

---

59.介绍完整的分布式中间件有哪些，各自的应用场景和作用。

分布式：一个业务被拆成多个子业务，部署在多台服务器上

中间件：将具体业务和底层逻辑解耦的软件

目前应用较多消息队列有ActiveMQ，RabbitMQ，Kafka，RocketMQ，ons，它们又可以被称作是消息中间件。

消息中间件解决的就是分布式系统之间消息传递的问题。

https://www.cnblogs.com/kaixinyufeng/p/8615258.html

---

60.双11秒杀活动，你的技术架构设计思路。

https://blog.csdn.net/github_37048196/article/details/83573935

       核心思想：层层过滤

       尽量将请求拦截在上游，降低下游的压力

       充分利用缓存与消息队列，提高请求处理速度以及削峰填谷的作用

---

61.单点登录怎么实现

           单点登录在现在的系统架构中广泛存在，他将多个子系统的认证体系打通，实现了一个入口多处使用，而在架构单点登录时，也会遇到一些小问题，在不同的应用环境中可以采用不同的单点登录实现方案来满足需求.

　　当用户第一次访问系统A的时候，因为还没有登录，会被引导到认证系统中进行登录，根据用户提供的登录信息，认证系统进行身份检验，

 如果通过检验，就会返回给用户一个凭据--ticket；然而当用户访问别的应用的时候，就会讲ticket带上，作为自己的认证凭据，应用系统接收到这个应用凭据之后会把ticket送到认证系统中进行检验，检查ticket的合法性。

如果通过校验，那么用户就可以在不用再次登录的情况下访问应用系统B和应用系统C了；

一、共享Session

共享Session可谓是实现单点登录最直接、最简单的方式。将用户认证信息保存于Session中，即以Session内存储的值为用户凭证，这在单个站点内使用是很正常也很容易实现的，而在用户验证、用户信息管理与业务应用分离的场景下即会遇到单点登录的问题，在应用体系简单，子系统很少的情况下，可以考虑采用Session共享的方法来处理这个问题。

   这个架构我使用了基于Redis的Session共享方案。

将Session存储于Redis上，然后将整个系统的全局Cookie Domain设置于顶级域名上，这样SessionID就能在各个子系统间共享。

这个方案存在着严重的扩展性问题，首先，ASP.NET的Session存储必须为SessionStateItemCollection对象，而存储的结构是经过序列化后经过加密存储的。并且当用户访问应用时，他首先做的就是将存储容器里的所有内容全部取出，并且反序列化为SessionStateItemCollection对象。这就决定了他具有以下约束：

1、  Session中所涉及的类型必须是子系统中共同拥有的（即程序集、类型都需要一致），这导致Session的使用受到诸多限制；

2、  跨顶级域名的情况完全无法处理；

二、基于OpenId的单点登录

这种单点登录将用户的身份标识信息简化为OpenId存放于客户端，当用户登录某个子系统时，将OpenId传送到服务端，服务端根据OpenId构造用户验证信息，多用于C/S与B/S相结合的系统，流程如下：

由上图可以看到，这套单点登录依赖于OpenId的传递，其验证的基础在于OpenId的存储以及发送。

　　　1、当用户第一次登录时，将用户名密码发送给验证服务；

　　　2、验证服务将用户标识OpenId返回到客户端；

　　   3、客户端进行存储；

　　　4、访问子系统时，将OpenId发送到子系统；

　　　5、子系统将OpenId转发到验证服务；

　　　6、验证服务将用户认证信息返回给子系统；

　　　7、子系统构建用户验证信息后将授权后的内容返回给客户端。

这套单点登录验证机制的主要问题在于他基于C/S架构下将用户的OpenId存储于客户端，在子系统之间发送OpenId，而B/S模式下要做到这一点就显得较为困难。为了处理这个问题我们将引出下一种方式，这种方式将解决B/S模式下的OpenId的存储、传递问题。

三、基于Cookie的OpenId存储方案

我们知道，Cookie的作用在于充当一个信息载体在Server端和Browser端进行信息传递，而Cookie一般是以域名为分割的，例如a.xxx.com与b.xxx.com的Cookie是不能互相访问的，但是子域名是可以访问上级域名的Cookie的。即a.xxx.com和b.xxx.com是可以访问xxx.com下的Cookie的，于是就能将顶级域名的Cookie作为OpenId的载体。

验证步骤和上第二个方法非常相似：

　　1、  在提供验证服务的站点里登录；

　　2、  将OpenId写入顶级域名Cookie里；

　　3、  访问子系统（Cookie里带有OpenId）

　　4、  子系统取出OpenId通过并向验证服务发送OpenId

　　5、  返回用户认证信息

　　6、  返回授权后的内容

在以上两种方法中我们都可以看到通过OpenId解耦了Session共享方案中的类型等问题，并且构造用户验证信息将更灵活，子系统间的验证是相互独立的，但是在第三种方案里，我们基于所有子系统都是同一个顶级域名的假设，而在实际生产环境里有多个域名是很正常的事情，那么就不得不考虑跨域问题究竟如何解决。

四、B/S多域名环境下的单点登录处理

在多个顶级域名的情况下，我们将无法让各个子系统的OpenId共享。处理B/S环境下的跨域问题，我们首先就应该想到JSONP的方案。

验证步骤如下：

　　1、  用户通过登录子系统进行用户登录；

　　2、  用户登录子系统记录了用户的登录状态、OpenId等信息；

　　3、  用户使用业务子系统；

　　4、  若用户未登录业务子系统则将用户跳转至用户登录子系统；

　　5、  用户子系统通过JSONP接口将用户OpenId传给业务子系统；

　　6、  业务子系统通过OpenId调用验证服务；

　　7、  验证服务返回认证信息、业务子系统构造用户登录凭证；（此时用户客户端已经与子业务系统的验证信息已经一一对应）

　　8、  将用户登录结果返回用户登录子系统，若成功登录则将用户跳转回业务子系统；

　　9、  将授权后的内容返回客户端；

五、安全问题

经过以上步骤，跨域情况下的单点登录问题已经可以得到解决。而在整个开发过程初期，我们采用用户表中纪录一个OpenId字段来保存用户OpenId，而这个机制下很明显存在一些安全性、扩展性问题。这个扩展性问题主要体现在一个方面：OpenId的安全性和用户体验的矛盾。

整个单点登录的机制决定了OpenId是会出现在客户端的，所以OpenId需要有过期机制，假如用户在一个终端登录的话可以选择在用户每次登录或者每次退出时刷新OpenId，而在多终端登录的情况下就会出现矛盾：当一个终端刷新了OpenId之后其他终端将无法正常授权。而最终，我采用了单用户多OpenId的解决方案。每次用户通过用户名/密码登录时，产生一个OpenId保存在Redis里，并且设定过期时间，这样多个终端登录就会有多个OpenId与之对应，不再会存在一个OpenId失效所有终端验证都失效的情况。

---

59.下面这种讲解能不能帮你彻底理解cookie，session，token？

1、很久很久以前，Web 基本上就是文档的浏览而已， 既然是浏览，作为服务器， 不需要记录谁在某一段时间里都浏览了什么文档，每次请求都是一个新的HTTP协议， 就是请求加响应， 尤其是我不用记住是谁刚刚发了HTTP请求， 每个请求对我来说都是全新的。这段时间很嗨皮。

2、但是随着交互式Web应用的兴起，像在线购物网站，需要登录的网站等等，马上就面临一个问题，那就是要管理会话，必须记住哪些人登录系统， 哪些人往自己的购物车中放商品， 也就是说我必须把每个人区分开，这就是一个不小的挑战，因为HTTP请求是无状态的，所以想出的办法就是给大家发一个会话标识(session id), 说白了就是一个随机的字串，每个人收到的都不一样， 每次大家向我发起HTTP请求的时候，把这个字符串给一并捎过来， 这样我就能区分开谁是谁了

3、这样大家很嗨皮了，可是服务器就不嗨皮了，每个人只需要保存自己的session id，而服务器要保存所有人的session id ！ 如果访问服务器多了， 就得由成千上万，甚至几十万个。

这对服务器说是一个巨大的开销 ， 严重的限制了服务器扩展能力， 比如说我用两个机器组成了一个集群， 小F通过机器A登录了系统， 那session id会保存在机器A上， 假设小F的下一次请求被转发到机器B怎么办？ 机器B可没有小F的 session id啊。

有时候会采用一点小伎俩： session sticky ， 就是让小F的请求一直粘连在机器A上， 但是这也不管用， 要是机器A挂掉了， 还得转到机器B去。

那只好做session 的复制了， 把session id 在两个机器之间搬来搬去， 快累死了。

 

 

后来有个叫Memcached的支了招： 把session id 集中存储到一个地方， 所有的机器都来访问这个地方的数据， 这样一来，就不用复制了， 但是增加了单点失败的可能性， 要是那个负责session 的机器挂了， 所有人都得重新登录一遍， 估计得被人骂死。

 

 

也尝试把这个单点的机器也搞出集群，增加可靠性， 但不管如何， 这小小的session 对我来说是一个沉重的负担

4、于是有人就一直在思考， 我为什么要保存这可恶的session呢， 只让每个客户端去保存该多好？

可是如果不保存这些session id , 怎么验证客户端发给我的session id 的确是我生成的呢？如果不去验证，我们都不知道他们是不是合法登录的用户， 那些不怀好意的家伙们就可以伪造session id , 为所欲为了。

嗯，对了，关键点就是验证 ！

比如说， 小F已经登录了系统， 我给他发一个令牌(token)， 里边包含了小F的 user id， 下一次小F 再次通过Http 请求访问我的时候， 把这个token 通过Http header 带过来不就可以了。

不过这和session id没有本质区别啊， 任何人都可以可以伪造， 所以我得想点儿办法， 让别人伪造不了。

那就对数据做一个签名吧， 比如说我用HMAC-SHA256 算法，加上一个只有我才知道的密钥， 对数据做一个签名， 把这个签名和数据一起作为token ， 由于密钥别人不知道， 就无法伪造token了。

 

这个token 我不保存， 当小F把这个token 给我发过来的时候，我再用同样的HMAC-SHA256 算法和同样的密钥，对数据再计算一次签名， 和token 中的签名做个比较， 如果相同， 我就知道小F已经登录过了，并且可以直接取到小F的user id , 如果不相同， 数据部分肯定被人篡改过， 我就告诉发送者： 对不起，没有认证。

 

Token 中的数据是明文保存的（虽然我会用Base64做下编码， 但那不是加密）， 还是可以被别人看到的， 所以我不能在其中保存像密码这样的敏感信息。当然， 如果一个人的token 被别人偷走了， 那我也没办法， 我也会认为小偷就是合法用户， 这其实和一个人的session id 被别人偷走是一样的。

这样一来， 我就不保存session id 了， 我只是生成token , 然后验证token ， 我用我的CPU计算时间获取了我的session 存储空间 ！

解除了session id这个负担， 可以说是无事一身轻， 我的机器集群现在可以轻松地做水平扩展， 用户访问量增大， 直接加机器就行。 这种无状态的感觉实在是太好了！

Cookie

    cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。

cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。

Session

   session 从字面上讲，就是会话。这个就类似于你和一个人交谈，你怎么知道当前和你交谈的是张三而不是李四呢？对方肯定有某种特征（长相等）表明他就是张三。

session 也是类似的道理，服务器要知道当前发请求给自己的是谁。为了做这种区分，服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。至于客户端怎么保存这个“身份标识”，可以有很多种方式，对于浏览器客户端，大家都默认采用 cookie 的方式。

服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。

Token在Web领域基于Token的身份验证随处可见。在大多数使用Web API的互联网公司中，tokens 是多用户下处理认证的最佳方式。

以下几点特性会让你在程序中使用基于Token的身份验证

1. 无状态、可扩展
2. 支持移动设备
3. 跨程序调用
4. 安全

那些使用基于Token的身份验证的大佬们

大部分你见到过的API和Web应用都使用tokens。例如Facebook, Twitter, Google+, GitHub等。

Token的起源

在介绍基于Token的身份验证的原理与优势之前，不妨先看看之前的认证都是怎么做的。

基于服务器的验证

我们都是知道HTTP协议是无状态的，这种无状态意味着程序需要验证每一次请求，从而辨别客户端的身份。

在这之前，程序都是通过在服务端存储的登录信息来辨别请求的。这种方式一般都是通过存储Session来完成。

随着Web，应用程序，已经移动端的兴起，这种验证的方式逐渐暴露出了问题。尤其是在可扩展性方面。

基于服务器验证方式暴露的一些问题

1. Seesion：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。
2. 可扩展性：在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。
3. CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。
4. CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。

在这些问题中，可扩展行是最突出的。因此我们有必要去寻求一种更有行之有效的方法。

基于Token的验证原理

基于Token的身份验证是无状态的，我们不将用户信息存在服务器或Session中。

这种概念解决了在服务端存储信息时的许多问题

NoSession意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。

基于Token的身份验证的过程如下:

1. 用户通过用户名和密码发送请求。
2. 程序验证。
3. 程序返回一个签名的token 给客户端。
4. 客户端储存token,并且每次用于每次发送请求。
5. 服务端验证token并返回数据。

每一次请求都需要token。token应该在HTTP的头部发送从而保证了Http请求无状态。我们同样通过设置服务器属性Access-Control-Allow-Origin:* ，让服务器能接受到来自所有域的请求。

需要主要的是，在ACAO头部标明(designating)*时，不得带有像HTTP认证，客户端SSL证书和cookies的证书。

实现思路：

 

 

1. 用户登录校验，校验成功后就返回Token给客户端。
2. 客户端收到数据后保存在客户端
3. 客户端每次访问API是携带Token到服务器端。
4. 服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码

当我们在程序中认证了信息并取得token之后，我们便能通过这个Token做许多的事情。

我们甚至能基于创建一个基于权限的token传给第三方应用程序，这些第三方程序能够获取到我们的数据（当然只有在我们允许的特定的token）

 

Tokens的优势

无状态、可扩展

在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。

如果我们将已验证的用户的信息保存在Session中，则每次请求都需要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时，可能会造成一些拥堵。

但是不要着急。使用tokens之后这些问题都迎刃而解，因为tokens自己hold住了用户的验证信息。

安全性

请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作。

token是有时效的，一段时间之后用户需要重新验证。我们也不一定需要等到token自动失效，token有撤回的操作，通过token revocataion可以使一个特定的token或是一组有相同认证的token无效。

可扩展性

Tokens能够创建与其它程序共享权限的程序。例如，能将一个随便的社交帐号和自己的大号(Fackbook或是Twitter)联系起来。当通过服务登录Twitter(我们将这个过程Buffer)时，我们可以将这些Buffer附到Twitter的数据流上(we are allowing Buffer to post to our Twitter stream)。

使用tokens时，可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据，我们可以通过建立自己的API，得出特殊权限的tokens。

多平台跨域

我们提前先来谈论一下CORS(跨域资源共享)，对应用程序和服务进行扩展的时候，需要介入各种各种的设备和应用程序。

Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.

只要用户有一个通过了验证的token，数据和资源就能够在任何域上被请求到。

Access-Control-Allow-Origin: * 

基于标准创建token的时候，你可以设定一些选项。我们在后续的文章中会进行更加详尽的描述，但是标准的用法会在JSON Web Tokens体现。

最近的程序和文档是供给JSON Web Tokens的。它支持众多的语言。这意味在未来的使用中你可以真正的转换你的认证机制。