分布式系统简单理解(以此目录为大纲开始学习)
1、集群:同一个业务,部署在多个服务器上(不同的服务器运行相同的代码,干同一件事)
2、分布式:一个系统分拆多个子模块,部署在不同的服务器上(不同的服务器,运行不同的代码,协同完成相同功能)
3、分布式一致性:
CAP理论:最多只能同时满足其中两项,
- C:数据一致性(Consistency):所以节点拥有数据的最新版本。又分为强一致性、弱一致性、最终一致性。
- A:可用性(Avaliablity),集群中一部分节点故障后,集群整理是否还能响应客户端的读写请求,对数据更新具备高可用性
- P:分区容错性(Partition tolerance):容忍网络出现分区,分区之间出现网络不可达。以实际效果而言,分区相当于对通信的时限要求,系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择
![]()
分布式一致性:
- 强一致性:数据更新成功后,任意时刻所有副本中的数据都是一致的,一般采用同步的方式实现。
- 弱一致性:数据更新成功后,系统不承诺立即可以读到最新写入的值,也不承诺具体多久之后可以读到
- 最终一致性:弱一致性的一种形式,数据更新成功后,系统不承诺立即可以返回最新写入的值,但是保证最终会返回上一次更新操作的值
4、分布式事务:处理关键是必须有一种方法可以知道事务在任何地方所做的所有动作,提交或回滚事务的决定必须产生统一的结果(全部提交或者全部回滚),由于存在事务机制,可以保证单节点上的数据操作可以满足ACID,但是相互独立的节点之间无法准确的知道其他节点中的事务执行情况,所以从理论上讲,两台机器理论上无法达到一致的状态,为了报纸所有机器中数据一致性,必须保证所有节点的数据写操作要不全执行,要么全不执行,但是一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果,所以它也就不知道本次事务到底是commit还是roolback,所以,常规解决方案就是引入一个“协调者”的组件来统一调度所有分布式节点的执行。
- 分布式事务:2PC(二段提交协议Two-phaseCommit),3PC(三段提交协议Three-phaseCommit),Paxos算法
- BASE理论
- 概念:分布式事务是指会涉及到操作多个分布式节点(服务器)上的多个数据库的事务,如果想让分布式部署的多台机器中的数据保持一致性,那么就要保证在所有节点的数据写操作,要么全部都执行,要么全部都不执行
- 分布式事务和分布式一致性的关系:为了满足分布式一致性,多节点上的数据库操作要保证分布式事务
- 分布式事务解决方案:补偿机制TCC,XA,消息队列MQ
事务补偿机制:在事务链中的任何一个正向事务操作,都必须存在一个完全符合回滚的可逆事务 - 幂等性:简单地说,业务操作支持重试,多次发起操作,不会长生不利影响,常见的实现方式:为消息额外增加唯一ID
X/Open组织,定义了分布式事务处理模型,X/Open DTP模型包括应用程序(AP),事务管理器(TM),资源管理器(RM),通信资源管理器(CRM)四部分,常见的事务管理器(TM)是交易中间件,常见的资源管理器(RM)是数据库,常见的通信资源管理器(CRM)是消息中间件,一般情况下,某一数据库无法知道其他数据库在做什么,因此在一个DTP环境中,交易中间件是必须的,由它通知和协调相关数据库的提交或者回滚,而一个数据库只将其自己所做的操作(可恢复)影射到全局事务中
XA规范就是X/Open DTP定义的交易中间件与数据库之间的接口规范(及接口函数),交易中间件用它来通知数据库事务的开始,结束以及提交,回滚等。XA接口函数由数据库厂商提供
2PC:二阶段提交的算法思路可以概况为:参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是终止操作
5、高并发高可用
- 海量数据的解决方案:
使用缓存;
页面静态化技术;
数据库优化;
分离数据库中活跃的数据;
批量读取和延迟修改;
读写分离;
使用NoSQL和Hadoop等技术;
分布式部署数据库;
应用服务和数据服务分离;
使用搜索引擎搜索数据库中的数据;
进行业务的拆分
- 高并发情况下的解决方案:
应用程序和静态资源文件进行分离;
页面缓存;
集群与分布式;
反向代理;
CDN; - 高并发场景下的限流策略:
信号量;
计数器(限制请求数量);
滑动窗口;
漏桶算法;
令牌桶算法;
分布式限流;
6、负载均衡
- 负载均衡:将流量或者请求均衡地分派到各个服务器,避免某个服务器压力过大
- 负载均衡分为硬件负载均衡和软件负载均衡
硬件负载均衡:主要通过在服务器节点之间安装专门用于负载均衡的设备,比如F5
软件负载均衡:在服务器上安装一些具有均衡负载功能或者模块的软件来完成请求分发工作 - 负载均衡策略:
7、Nginx
- 负载均衡
- 反向代理(FQ就是正向代理,VPN是正向代理,Nginx支持反向代理,反向代理是服务器不可见,正向代理就是客户端不可见)
正向代理就是代理服务器发起请求,反向代理就是代理服务器接受请求 - CDN,内容分发网络,基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节,使内容传输更可,更稳定,CDN可以加速
- 动静分离
- Nginx的缺陷是不支持HTTPS
8、分布式服务
- RPC:远程过程调用(用Socket比较麻烦)
对于大多数rpc框架通用,实现的几个技术点:
服务提供者发布服务:服务接口定义,数据结构,服务提供者信息等
客户端远程调用:通常是使用jdk的代码拦截
底层通信:多用netty,也有http
序列化:关注序列化反序列性能,xml,json,hession,pd,protostuff,kryo等 - 常用的RPC框架:dubbo,Thrift,Hadoop的Avro-RPC,Hession,gRPC
- SOA:面向服务的架构
9、分布式锁
- zookeeper可以进行分布式分布式服务协调,做为dubbo的服务注册中心,zookeeper还可以做分布式锁,也可以帮卡夫卡存储元数据(topic,partition信息等)更新
- 分布式系统的不同节点上需要分布式锁,特点如下:
a、互斥性:和本地锁一样互斥性是最基本的,但是分布式锁需要保证在不同节点的不同线程的互斥
b、可重入性:同一个节点上的同一个线程如果获取了锁之后那么也可以再次获取这个锁
c、锁超时:和本地锁一样支持锁超时,防止死锁
d、高效、高可用:加锁和解锁需要高效,同时也需要保证高可用防止分布式锁失效,可以增加降级
e、支持阻塞和非阻塞:和ReentrantLock一样支持lock和trylock以及tryLcok(long timeOut)
f、支持公平锁和非公平锁(可选):公平锁的意思是按照请求加锁的顺序获得锁,非公平锁就相反是无序的
常见的分布式锁是zookeeper
10、分布式消息队列
- 消息队列,属于生产者-消费者模式
消息队列作为中间件模式的优点:解耦、异步、削峰
a、解耦:将消息写入消息队列,需要消息的系统自己从消息队列中订阅,从而系统A不需要做任何修改
b、异步:将消息写入消息队列,非必要的业务逻辑以异步的方式运行,加快响应速度
c、削峰:系统A慢慢的按照数据库能处理的并发量,从消息队列中慢慢拉去信息,在生产中,这个短暂的高峰期积压是允许的
常用的MQ有ActiveMQ,RabbitMQ,RocketMQ,kafka - kafka,可以做消息队列,优点是分布式队列,吞吐量高
11、搜索引擎
elasticsearch是一个实时分布式搜索和分析引擎,可以应用在任何实时检索的场景中
12、分布式session
场景:第一次登陆,请求去了机器1,机器1上创建了一个session,但第二次访问,请求被路由到了机器2,但是机器2上面并没有我的session信息,所以要重新登陆,当然这种可以通过nginx的IP HASH负载策略来解决,对于同一个IP请求都会区同一个机器
但业务发展越来越大,拆分的越来越多,机器数不断增加,显然那种方案就不行了,这个时候就需要将session信息放在一个独立的机器上,所以分布式session要解决的问题其实就是分布式环境下的的session共享的问题
13、分布式数据库
- 假设有千万级/亿级的海量数据,如何设计数据库?
分库分表,主从架构,读写分离 - 分库分表,何时分?怎么分?
将库拆分,将表拆分,原来是放在同一个系统里面的,拆分后放到不同的系统或者不同的模块中
分库分表包括水平拆分,垂直拆分
水平分库/表:每一个库/表的结构和字段都一样,但是存储的数据不一样
垂直分库/表:每一个库/表的结构和字段都不一样,存储的数据不一样 - 数据库中间件,比如sharding-jdbc,mycat(有坑)
14、其他概念
- Web Service:可以将应用程序转换为网络应用程序
- 分布式系统怎么将任务分发到这些计算机节点呢,很简单的思想,分而治之,即分片(partition),对于计算,那么就是对计算任务进行切换,每个节点算一些,最终汇总就行了,这就是MapReduce的思想

参考资料:https://www.cnblods.com/expiator/p9581056.html

浙公网安备 33010602011771号