分布式服务

高可用(HA)：直白来说就是系统不会因为某台机器，或某个实例挂了，就不能提供服务了。高可用需要做到分布式、负载均衡、自动侦查、自动切换、自动恢复等。 高吞吐： 单位时间内，能传输的数据量，

两阶段提交协议 两阶段提交协议是协调所有分布式原子事务参与者，并决定提交或取消（回滚）的分布式算法。 （1）协议参与者 在两阶段提交协议中，系统一般包含两类机器（或节点）

什么是高可用性? 高可用（HA）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。 服务器的可用性是指单位时间内（通常一年），服务器可以正常工作的时

对于系统的稳定性，人为因素占比最大，所以我们在这方面下工夫最多。 研发流程方面 尽可能把所有流程都流程化、标准化、自动化，减少人为的过多的干预。 上线流程：测试（自测、CR、QA测试）、预

我们一般的应对策略是缓存、降级和限流！ 缓存 缓存的目的是提升系统访问速度和增大系统能处理的容量，可谓是抗高并发流量的银弹； 本地缓存，控制单机请求量很有效，如果分布式缓存承压的情况下也可

常用限流算法 计数器算法 单位时间内设定限频阈值，如果访问超过该阈值则拒绝。实现简单，缺点是容易在小突发流量情况下，拒绝很多请求，影响服务可用性 漏桶算法(Leaky Bucket) 漏桶

什么是session？ 服务器为每个用户创建一个会话，存储用户的相关信息，以便多次请求能够定位到同一个上下文。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中

Zab（Zookeeper Atomic Broadcast）是为ZooKeeper协设计的崩溃恢复原子广播协议，它保证zookeeper集群数据的一致性和命令的全局有序性。 ZAB协议的

服务注册是针对服务端的，服务启动后需要注册，分为几个部分：启动注册、定时续期、退出撤销 服务发现 服务发现是针对调用端的，一般分为两类问题：存量获取、增量侦听 客户端发现模式

1、统一命名服务 统一命名服务的命名结构图如下所示： 在分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务。 类似于域名与ip之间对应关系，ip不容易记住，而域名容易记住

ZooKeeper是一项集中式服务，用于维护配置信息，命名，提供分布式同步和提供组服务。 ZooKeeper简单，分布式，可靠且快速。 维护配置信息：

通过全局唯一ID 根据业务的操作和内容生成一个全局ID，在执行操作前先根据这个全局唯一ID是否存在，来判断这个操作是否已经执行。如果不存在则把全局ID存储到redis中，继续执行业务。

轮循 Round Robin 这种方法会将收到的请求循环分配到服务器集群中的每台机器，即有效服务器。如果使用这种方式，所有的标记进入虚拟服务的服务器应该有相近的资源容量 以及负载相同的应用

一般来说是不用保证顺序的。但是有的时候可能确实是需要严格的顺序保证。给大家举个例子，你服务A调用服务B，先插入 -> 再删除。可能会变成先删除 -> 再插入。 怎么破圈 业务逻辑上解决。一

Dubbo 的两大设计原则 Dubbo 使用“微内核+插件”的设计模式。内核只负责组装插件(扩展点)，Dubbo 的功能都是由插件实现的，无限开放性设计架构，也就是 Dubbo 的所有功能

在 Dubbo 支持哪些通信协议？我们讲过不少了，这里额外补充次常用的两种。 protostuff protostuff 的使用：可以直接使用封装好的 ProtostuffIOUtil

支持的通信协议和序列化协议都参考如下哈。 dubbo协议 默认就是走dubbo协议的。 hessian序列化协议，单一长连接，TCP协议传输，NIO异步通信，适合大并发小数据量的服务调用，

从实现角度说：Dubbo 是RPC框架，负责Client和Service之间通讯。 从编码角度说：Dubbo将服务器间的调用变得跟本地方法调用一样简单（invoke实现），让我们能不关注底

可以，因为刚开始初始化的时候，消费者会将提供者的地址等信息拉取到本地缓存，所以注册中心挂了可以继续通信。具体看看架构流程中的第4步。 Dubbo 架构图： 流程如下： 服务的Contain

在我们的业务系统中，Redis缓存通常被用在数据库前面，作为数据读取的缓冲，使得I/O 操作不至于直接落在数据库上。以商品详情页为例，假如卖家修改了商品信息，并写回到数据库