分布式应用框架
2022-03-11 00:31:26 0 举报AI智能生成
分布式应用框架
作者其他创作
大纲/内容
消息队列
MQ的优点：异步处理、应用解耦、流量削峰、日志处理、消息通讯
选型
activeMQ
万级别单机吞吐量，可用性高，存在较低概率丢失消息的问题，社区较为不活跃，版本更新率低，高并发高负载支持性不太友好
RabbitMQ
万级别单机吞吐量，性能好，有后台管理界面，社区活跃，吞吐量会低一些，但较为主流
RocketMQ
阿里公司出品，十万级别的单机吞吐量，源码基于java，支持分布式扩展，支持的topic量比较大，支持分布式事务，对使用存在一定的技术挑战
Kafka
十万级别单机吞吐量，一般配合大数据类的系统进行实时数据计算、日志采集。分布式支持性好，容易扩展，缺点为单机分区较多，轮询间隔长，不支持重试
MQ常见问题
1、消息的顺序问题
1、保证一个消费者对应一个queue，要发送的消息和到达的消息肯定是有序的；2、kafka写入分区时指定一个key，消费者从分区取数据是有序的，如果是多线程环境下需要使用内存队列实现
2、消息的重复问题
消费端自身保证幂等性。可采用的方案为：1、数据库唯一索引保证；2、记录全局唯一的消息ID，消费时检查ID是否被消费过，需要分布式锁的支持
3、消息丢失问题
1、生产端的ACK确认机制，支持失败重发；2、broker消息存储到磁盘进行持久化；3、消费端消费完成回调生产者
4、消息积压问题
主要原因是消费速度跟不上。方案为：1、扩容消费端实例提升消费能力；2、系统服务降级
RabbitMQ基本原理
分支主题
基本架构
broker：消息队列服务进程，包含exchange、queue
exchange：消息队列交换机，按照一定的路由规则转发到某个queue，进行消息过滤与路由
queue：消息队列，存储的是消息，消息到达消息队列后给指定的消费者
producer：生产者，消息生成的客户端
consumer：消费者，消息被消费的客户端
工作模式
1、simple模式
分支主题
简单的收发模式，如果队列中有消息就拿出来消费，确认后从队列中删除消息
2、work工作模式
分支主题
资源竞争模式，消费者可能有多个同时监听同一个队列，争抢消费。高并发情况下可能会并发消费，需要使用开关（synchronize）保证
3、P/S发布订阅模式
分支主题
publish/subscribe模式，基于资源共享，通过交换机将的消息一起发送到与交换机绑定的队列
4、rounting路由模式
分支主题
生产者消息发送给路由器判断，路由后发送到匹配的消息队列
5、topic主题模式
分支主题
路由功能添加通配符匹配，是rounting路由模式的模糊匹配版本
部署方案
1、单机方案
2、普通集群方案：多台机器启动多个rabbitmq实例，每个实例根据消费者的需要才进行同步queue元数据，此方案能有效提高吞吐量
3、镜像集群方案：创建的queue，无论是元数据还是消息都会被存储在多个实例上，每个实例自动同步。镜像模式下，每个节点都是queue的完整数据，存在较大的性能开销和网络带宽压力
其它
基于TCP长连接实现，采用信道方式传输，信道是建立在TCP上的虚拟链接
路由模式：fanout：广播模式；direct：路由精确匹配模式；topic：路由模糊匹配模式
zookeeper
zookeeper是一个分布式开源协调服务。为分布式应用提供一致性服务，可实现数据的发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、master选举、分布式锁和分布式队列等功能。可保证顺序一致性、原子性、可靠性、实时性、最终一致性。基于观察者模式设计的分布式管理框架，存储和管理注册节点的数据，当数据发生变化时通知注册者做出反应
特点
分支主题
1、一个领导者，多个追随者组成的集群；2、集群中只要有半数节点存活，就能正常提供服务；3、全局的数据具有一致性，每个追随者都保存了完整的数据副本；4、请求更新具有原子性，顺序性；5、实时性
文件系统+通知机制组成，提供了多层级的节点命名空间（Znode），节点都可设置关联数据。为保证高吞吐和低延迟，在内存中维护了这个树状目录结构，大小上限为1M。
主从节点状态同步：基于原子广播机制，称为Zab协议。
恢复模式：服务启动或领导奔溃后，进入恢复模式
广播模式：消息广播
通知机制
watcher机制
指zookeeper允许客户端的某个zone注册一个watcher监听，当服务端某个事件触发了这个watcher，将发送通知到注册的客户端，客户端根据通知状态和类型作出业务上的改变
工作机制
1、客户端注册watcher
2、服务端处理watcher
3、客户端回调watcher
特性：watcher的一次性、watche客户端回调串行、轻量级
应用场景
典型的分布式管理和协调框架，基于发布/订阅模式，通过对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的服务注册中心，协调调度服务列表资源，提供负载均衡和命名服务等功能
netty
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拷贝到网卡接口。这需要底层操作系统的支持
高性能设计
1、IO模型（如何收发数据）
分支主题
基本原理：聚合了多路复用器selector，当线程要进行数据读取时，没有数据可用的情况下可执行其它任务，达到非阻塞的目的。同时，通过selector的单独IO处理，避免了多线程竞争导致IO线程频繁挂起阻塞
2、线程处理模型（如何处理数据）
基于主从的reactors多线程模型。reactor模型是指基于单独的线程监听事件和分发事件，另外一个线程执行响应
分布式架构设计
秒杀系统设计
特点：高并发、库存有限、业务简单、恶意请求
方案
前端：页面资源静态化，按钮控制，答题验证码等
nginx：检验恶意请求，负载均衡，动静分离
业务层：集群业务
redis：分布式锁、热点数据缓存
mq：削峰限流，消费者根据消费能力获取消息
原则：前台请求尽量少，后台数据尽量少，调用链路尽量短；访问拦截、分流、动静分离；库存策略、热点数据缓存、限流降级
分布式
为解决单点服务器容量和性能瓶颈而采取的优化手段，将业务进行拆分成不同的子业务，分布在不同的物理机器上执行。服务间通过远程调用协调工作，对外提供服务。有水平扩展和垂直拆分两种实现形式
集群是多台不同的物理主机部署相同应用或服务模块，通过负载均衡向外提供服务。具有可扩展性、高可用性；具有负载均衡、集群容错两大能力。
设计理念
提升系统的整体性能和吞吐量，保证分布式系统的容错性。同时也应尽量应用并发编程、高性能网络框架等提升单机性能
设计思路
中心化
按角色分工，分主节点和从节点。主节点通过人工设定产生并对所有的从节点协调管理，需要采用冷备热备主节点并有切换能力
去中心化
角色平等，不是没有中心而是节点自由选举产生中心。但可能产生“脑裂”问题，是指一个集群因网络问题被切断通信，会产生两个集群各自工作导致严重的数据冲突和错误
CPA定理
C：一致性，指多个数据副本之间能够保持的严格的一致的特性
A：可用性，指系统提供的服务必须保证可用的状态，每次请求都能保证获取到非错误的回应（不需保证数据的及时性）
P：分区容错性，指分布式系统在遇到任何网络分区故障时，仍能对外提供一致性和可用性的服务，除非整个网络环境都发生了故障
注意：分区容错性我们是必须要满足的，强一致性和可用性只能2选1。即分布式系统之间发生网络故障时，仍要提供服务
BASE理论
1、基本可用：指分布式系统发生不可预知的故障时，允许损失部分可用性，但不等同于系统不可用。比如说：服务降级、响应时间上增加
2、软状态：指系统中允许数据存在中间状态，并任务该系统的中间状态不会影响系统的可用性，允许数据副本存在更新延迟
3、最终一致性：强调系统中的所有数据副本，在一定的时间同步后都能达到一致性的状态。保障的是数据能最终一致，不需实时保证数据的一致性
注意：BASE理论时对CAP理论一致性和可用性权衡的结果，是互联网分布式系统实践的结论。核心思想为，即使无法做到最终一致性，但可采用适当的方式使系统达到最终一致性
最终一致性通过分布式事务保证，可采用本地事务消息、独立消息服务的最终一致性来保证
0 条评论
下一页
