简介
分布式系统是一组计算机系统一起工作,在终端用户看来,就像一台计算机在工作一样,分布式系统最大的好处就是能够让你横向的扩展系统。
分布式理论:CAP理论
-
定义:在理论计算机科学中,CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer's theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点
选项 | 具体意义 |
---|---|
一致性(Consistency) | 所有节点访问同一份最新的数据副本 |
可用性(Availability) | 每次请求都能获取到非错的响应,但是不保证获取的数据为最新数据 |
分区容错性(Partition tolerance) | 分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务,除非整个网络环境都发生了故障 |
一致性(Consistency)
在写操作完成后开始的任何读操作都必须返回该值,或者后续写操作的结果 也就是说,在一致性系统中,一旦客户端将值写入任何一台服务器并获得响应,那么之后client从其他任何服务器读取的都是刚写入的数据
可用性(Availability)
系统中非故障节点收到的每个请求都必须有响应 在可用系统中,如果我们的客户端向服务器发送请求,并且服务器未崩溃,则服务器必须最终响应客户端,不允许服务器忽略客户的请求
分区容错性(Partition tolerance)
一个分布式系统里面,节点组成的网络本来应该是连通的。然而可能因为一些故障,使得有些节点之间不连通了,整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。
当你一个数据项只在一个节点中保存,那么分区出现后,和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。
分布式系统优缺点
分布式系统的优点
-
分布式系统中的所有节点都是相互连接的。所以节点可以很容易地与其他节点共享数据
-
更多的节点可以很容易地添加到分布式系统中,即可以根据需要进行扩展
-
一个节点的故障不会导致整个分布式系统的失败,其他节点仍然可以相互通信
-
硬件资源可以与多个节点共享,而不是只限于一个节点
分布式系统的缺点
-
在分布式系统中很难提供足够的安全,因为节点以及连接都需要安全
-
一些消息和数据在从一个节点转移到另一个节点时,可能会在网络中丢失
-
与单用户系统相比,连接到分布式系统的数据库是相当复杂和难以处理的
-
如果分布式系统的所有节点都试图同时发送数据,网络中可能会出现过载现象
分布式系统常用策略
分布式系统是为了解决系统高性能、可用、可扩展的问题。
分布式服务框架
你如果要让不同的子系统或者服务之间互相通信,首先必须有一套分布式服务框架。
也就是各个服务可以互相感知到对方在哪里,可以发送请求过去,可以通过HTTP或者RPC的方式。
在这里,最常见的技术就是dubbo以及spring cloud,当然大厂一般都是自己有服务框架
分布式事务
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说,就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务器上,且属于不同的应用,分布式事务需要保证这些小操作要么全部成功,要么全部失败。本质上来说,分布式事务就是为了保证数据一致性。
分布式事务的产生的原因
-
数据库分库分表 当数据库单表一年产生的数据超过1000W,那么就要考虑分库分表,简单的说就是原来的一个数据库变成了多个数据库,这时候,如果一个操作既访问01库,又访问02库,而且要保证数据的一致性,那么就要用到分布式事务。
-
支付 最经典的场景就是支付了,一笔支付,是对买家账户进行扣款,同时对卖家账户进行加钱,这些操作必须在一个事务里执行,要么全部成功,要么全部失败。而对于买家账户属于买家中心,对应的是买家数据库,而卖家账户属于卖家中心,对应的是卖家数据库,对不同数据库的操作必然需要引入分布式事务。
-
在线下单 买家在电商平台下单,往往会涉及到两个动作,一个是扣库存,第二个是更新订单状态,库存和订单一般属于不同的数据库,需要使用分布式事务保证数据一致性。
事务的ACID特性
-
原子性(A) 所谓的原子性就是说,在整个事务中的所有操作,要么全部完成,要么全部不做,没有中间状态。对于事务在执行中发生错误,所有的操作都会被回滚,整个事务就像从没被执行过一样。
-
一致性(C) 事务的执行必须保证系统的一致性,就拿转账为例,A有500元,B有300元,如果在一个事务里A成功转给B50元,那么不管并发多少,不管发生什么,只要事务执行成功了,那么最后A账户一定是450元,B账户一定是350元。
-
隔离性(I) 所谓的隔离性就是说,事务与事务之间不会互相影响,一个事务的中间状态不会被其他事务感知。
-
持久性(D) 所谓的持久性,就是说一单事务完成了,那么事务对数据所做的变更就完全保存在了数据库中,即使发生停电,系统宕机也是如此。
分布式锁
分布式锁其实可以理解为:控制分布式系统有序的去对共享资源进行操作,通过互斥来保持一致性
分布式锁作用:
-
互斥性:基本功能,一个获取锁,另外一个就不能获取
-
可重入性能:一个线程获取到锁之后,可以再次获取(多次获取)
-
锁超时:持有锁的线程挂掉后,一定时间锁自动释放
-
高效:加锁/释放锁速度快
-
高可用:集群、容灾
-
支持阻塞和非阻塞
-
支持公平锁和非公平锁
常用的分布式锁中间件
-
mysql
-
zookeeper
-
redis
-
etcd
-
chubby
分布式缓存
分布式缓存技术有redis
和memcached
两种,缓存的目的是为了在高并发系统中有效降低DB
的压力,但是在使用的时候可能会因为缓存结构设计不当造成一些问题,这里会把可能遇到的坑整理出来,方便日后查找。
分布式消息系统
在单块系统内,就一个JVM进程内部,你可以用类似LinkedList之类的数据结构作为一个本地内存里的队列。
但是多个子系统之间要进行消息队列的传递呢?那是不是要引入类似RabbitMQ之类的分布式消息中间件?
分布式搜索系统
如果在单块系统内,你可以比如在本地就基于Lucene来开发一个全文检索模块,但是如果是分布式系统下的很多子系统,你还能直接基于Lucene吗?
明显不行,你需要在系统里引入一个外部的分布式搜索系统,比如Elasticsearch。
分布式配置中心
分布式日志中心
分布式监控告警中心
分布式会话
分布式系统常用组件
负载均衡
-
Nginx:高性能、高并发的web服务器;功能包括负载均衡、反向代理、静态内容缓存、访问控制;工作在应用层
-
LVS: Linux virtual server,基于集群技术和Linux操作系统实现一个高性能、高可用的服务器;工作在网络
webserver
-
Java:Tomcat,Apache,Jboss
-
Python:gunicorn、uwsgi、twisted、webpy、tornado
service
-
SOA、微服务、spring boot,django
容器
-
docker,kubernetes
cache
-
memcache、redis
协调中心
-
etcd
-
zookeeper使用了Paxos协议Paxos是强一致性,高可用的去中心化分布式。zookeeper的使用场景非常广泛,之后细讲。
rpc框架
-
grpc、brpc
-
dubbo是阿里开源的Java语言开发的高性能RPC框架,在阿里系的诸多架构中,都使用了dubbo + spring boot
消息队列
-
kafka、rabbitMQ、rocketMQ、QSP
-
消息队列的应用场景:异步处理、应用解耦、流量削锋和消息通讯
实时数据平台
-
storm
-
akka
离线数据平台
-
hadoop、spark
-
PS: apark、akka、kafka都是scala语言写的,看到这个语言还是很牛逼的
dbproxy
-
cobar也是阿里开源的,在阿里系中使用也非常广泛,是关系型数据库的sharding + replica 代理
db
-
mysql、oracle、MongoDB、HBase
搜索
-
elasticsearch、solr
日志
-
rsyslog、elk、fl