分布式应用框架

MQ的优点：异步处理、应用解耦、流量削峰、日志处理、消息通讯

万级别单机吞吐量，可用性高，存在较低概率丢失消息的问题，社区较为不活跃，版本更新率低，高并发高负载支持性不太友好

activeMQ

万级别单机吞吐量，性能好，有后台管理界面，社区活跃，吞吐量会低一些，但较为主流

RabbitMQ

阿里公司出品，十万级别的单机吞吐量，源码基于java，支持分布式扩展，支持的topic量比较大，支持分布式事务，对使用存在一定的技术挑战

RocketMQ

十万级别单机吞吐量，一般配合大数据类的系统进行实时数据计算、日志采集。分布式支持性好，容易扩展，缺点为单机分区较多，轮询间隔长，不支持重试

Kafka

选型

1、保证一个消费者对应一个queue，要发送的消息和到达的消息肯定是有序的；2、kafka写入分区时指定一个key，消费者从分区取数据是有序的，如果是多线程环境下需要使用内存队列实现

1、消息的顺序问题

消费端自身保证幂等性。可采用的方案为：1、数据库唯一索引保证；2、记录全局唯一的消息ID，消费时检查ID是否被消费过，需要分布式锁的支持

2、消息的重复问题

1、生产端的ACK确认机制，支持失败重发；2、broker消息存储到磁盘进行持久化；3、消费端消费完成回调生产者

3、消息丢失问题

主要原因是消费速度跟不上。方案为：1、扩容消费端实例提升消费能力；2、系统服务降级

4、消息积压问题

MQ常见问题

分支主题

broker：消息队列服务进程，包含exchange、queue

exchange：消息队列交换机，按照一定的路由规则转发到某个queue，进行消息过滤与路由

queue：消息队列，存储的是消息，消息到达消息队列后给指定的消费者

producer：生产者，消息生成的客户端

consumer：消费者，消息被消费的客户端

基本架构

简单的收发模式，如果队列中有消息就拿出来消费，确认后从队列中删除消息

1、simple模式

资源竞争模式，消费者可能有多个同时监听同一个队列，争抢消费。高并发情况下可能会并发消费，需要使用开关（synchronize）保证

2、work工作模式

publish/subscribe模式，基于资源共享，通过交换机将的消息一起发送到与交换机绑定的队列

3、P/S发布订阅模式

生产者消息发送给路由器判断，路由后发送到匹配的消息队列

4、rounting路由模式

路由功能添加通配符匹配，是rounting路由模式的模糊匹配版本

5、topic主题模式

工作模式

1、单机方案

2、普通集群方案：多台机器启动多个rabbitmq实例，每个实例根据消费者的需要才进行同步queue元数据，此方案能有效提高吞吐量

3、镜像集群方案：创建的queue，无论是元数据还是消息都会被存储在多个实例上，每个实例自动同步。镜像模式下，每个节点都是queue的完整数据，存在较大的性能开销和网络带宽压力

部署方案

基于TCP长连接实现，采用信道方式传输，信道是建立在TCP上的虚拟链接

路由模式：fanout：广播模式；direct：路由精确匹配模式；topic：路由模糊匹配模式

其它

RabbitMQ基本原理

消息队列

zookeeper是一个分布式开源协调服务。为分布式应用提供一致性服务，可实现数据的发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、master选举、分布式锁和分布式队列等功能。可保证顺序一致性、原子性、可靠性、实时性、最终一致性。基于观察者模式设计的分布式管理框架，存储和管理注册节点的数据，当数据发生变化时通知注册者做出反应

1、一个领导者，多个追随者组成的集群；2、集群中只要有半数节点存活，就能正常提供服务；3、全局的数据具有一致性，每个追随者都保存了完整的数据副本；4、请求更新具有原子性，顺序性；5、实时性

文件系统+通知机制组成，提供了多层级的节点命名空间（Znode），节点都可设置关联数据。为保证高吞吐和低延迟，在内存中维护了这个树状目录结构，大小上限为1M。

恢复模式：服务启动或领导奔溃后，进入恢复模式

广播模式：消息广播

主从节点状态同步：基于原子广播机制，称为Zab协议。

特点

指zookeeper允许客户端的某个zone注册一个watcher监听，当服务端某个事件触发了这个watcher，将发送通知到注册的客户端，客户端根据通知状态和类型作出业务上的改变

1、客户端注册watcher

2、服务端处理watcher

3、客户端回调watcher

工作机制

特性：watcher的一次性、watche客户端回调串行、轻量级

watcher机制

通知机制

典型的分布式管理和协调框架，基于发布/订阅模式，通过对zookeeper中丰富的数据节点进行交叉使用，配合watcher事件通知机制，可非常方便的构建一系列分布式应用中涉及的核心功能

1、数据的发布/订阅：可实现数据配置中心的功能，znode存储数据，注册watcher，进行变更通知

2、负载均衡：用于服务注册成树形目录结构，维护服务可用列表，根据负载均衡算法（需要调用者自己实现）选择提供服务的服务器

3、命名服务：通过名字获取资源或服务的地址，利用ZK创建一个全局唯一路径

4、分布式协调/通知：监控znode节点，watcher机制

5、集群管理：首先明白集群管理的特性：是否有机器退出和加入；master选举。通过该目录下节点的新增和删除，代表机器的退出和加入；至于选举算法，可以根据机器加入的顺序，维护id列表，可选取编号最大的或最小的

6、master选举：确定机器的地位，通过一定的选举算法实现

7、分布式锁：基于zk的一致性文件系统，通过创建一个znode节点，创建成功获取锁成功，业务完成删除节点释放锁

8、分布式队列：同步队列：创建临时目录节点并监听数量；先进先出队列：出入队都有编号，可删除最小序号的节点进行消费即可

应用场景

1、全局递增的唯一ID表示所有的提议，根据数据库的两阶段提交过程来完成事物顺序的一致性

2、主节点的作用：分布式的环境中，有些业务逻辑只需在某个节点中进行，其它的节点共享这个结果，可大大减少重复计算，提高性能

3、跟dubbo有什么关系：zk可作为dubbo的服务注册中心，协调调度服务列表资源，提供负载均衡和命名服务等功能

常见问题

zookeeper

netty是一个异步事件驱动的网络程序应用框架，用于快速开发可维护单高性能协议服务器和客户端。netty是基于NIO的，封装了JDK的NIO，使用起来方便。特点是非阻塞高并发、零拷贝传输快、封装性好

典型的应用场景是dubbo使用netty作为基础通信组件、rocketMQ也是如此

原因：TCP是以流的方式处理数据的，一个完整的包可能分多次发送，也可能小包封装成一个大的数据包发送。系统级别的原因：应用程序写入的字节大小大于套接字发送缓冲区的大小，就会发生拆包；小于就会发生粘包现象

解决方案：消息定长；包尾增加特殊字符分割；将消息拆分为消息头和消息体

TCP粘包/拆包

传统的数据发送实现方式为：1、数据从磁盘读取到内核的read buffer；2、数据从内核缓冲区读取到用户应用缓冲（JVM堆内存）；3、数据从用户应用缓冲拷贝到内核的socket buffer；4、数据从内核的socket buffer拷贝到网卡接口缓冲区

上述2、3步骤都是可省的，即数据能再内核中直接拷贝不经过用户缓冲，直接将数据从read buffer拷贝到网卡接口。这需要底层操作系统的支持

零拷贝原理

基本原理：聚合了多路复用器selector，当线程要进行数据读取时，没有数据可用的情况下可执行其它任务，达到非阻塞的目的。同时，通过selector的单独IO处理，避免了多线程竞争导致IO线程频繁挂起阻塞

1、IO模型（如何收发数据）

基于主从的reactors多线程模型。reactor模型是指基于单独的线程监听事件和分发事件，另外一个线程执行响应

2、线程处理模型（如何处理数据）

高性能设计

netty

特点：高并发、库存有限、业务简单、恶意请求

前端：页面资源静态化，按钮控制，答题验证码等

nginx：检验恶意请求，负载均衡，动静分离

业务层：集群业务

redis：分布式锁、热点数据缓存

mq：削峰限流，消费者根据消费能力获取消息

方案

原则：前台请求尽量少，后台数据尽量少，调用链路尽量短；访问拦截、分流、动静分离；库存策略、热点数据缓存、限流降级

秒杀系统设计

为解决单点服务器容量和性能瓶颈而采取的优化手段，将业务进行拆分成不同的子业务，分布在不同的物理机器上执行。服务间通过远程调用协调工作，对外提供服务。有水平扩展和垂直拆分两种实现形式

集群是多台不同的物理主机部署相同应用或服务模块，通过负载均衡向外提供服务。具有可扩展性、高可用性；具有负载均衡、集群容错两大能力。

提升系统的整体性能和吞吐量，保证分布式系统的容错性。同时也应尽量应用并发编程、高性能网络框架等提升单机性能

设计理念

按角色分工，分主节点和从节点。主节点通过人工设定产生并对所有的从节点协调管理，需要采用冷备热备主节点并有切换能力

中心化

角色平等，不是没有中心而是节点自由选举产生中心。但可能产生“脑裂”问题，是指一个集群因网络问题被切断通信，会产生两个集群各自工作导致严重的数据冲突和错误

去中心化

设计思路

C：一致性，指多个数据副本之间能够保持的严格的一致的特性

A：可用性，指系统提供的服务必须保证可用的状态，每次请求都能保证获取到非错误的回应（不需保证数据的及时性）

P：分区容错性，指分布式系统在遇到任何网络分区故障时，仍能对外提供一致性和可用性的服务，除非整个网络环境都发生了故障

注意：分区容错性我们是必须要满足的，强一致性和可用性只能2选1。即分布式系统之间发生网络故障时，仍要提供服务

CPA定理

1、基本可用：指分布式系统发生不可预知的故障时，允许损失部分可用性，但不等同于系统不可用。比如说：服务降级、响应时间上增加

2、软状态：指系统中允许数据存在中间状态，并任务该系统的中间状态不会影响系统的可用性，允许数据副本存在更新延迟

3、最终一致性：强调系统中的所有数据副本，在一定的时间同步后都能达到一致性的状态。保障的是数据能最终一致，不需实时保证数据的一致性

注意：BASE理论时对CAP理论一致性和可用性权衡的结果，是互联网分布式系统实践的结论。核心思想为，即使无法做到最终一致性，但可采用适当的方式使系统达到最终一致性

最终一致性通过分布式事务保证，可采用本地事务消息、独立消息服务的最终一致性来保证

BASE理论

分布式

分布式架构设计

分布式应用框架