为了账号安全,请及时绑定邮箱和手机立即绑定

干货:分布式系统学习笔记

标签:
Java

一、分布式的两大场景

数据存储的分布式

服务的分布式

二、数据存储的分布式

比如海量数据,单机存储不下,需要多机,以集群的方式存储,即为数据的分布式存储,数据存储的分布式一般涉及如下几个方面

数据的分片策略

全局主键的实现机制

跨结点数据的聚合

分布式事务

数据容灾机制

2.1数据分片策略

2.1.1 基于数据范围来分

比如库1,存放id 1到1000w的数据,库2存放id 1000w到2000w的数据

优点 :

单库数据规模提前预估。超规模后,加机器,不需要迁移数据。

且相邻数据大都存放在一个库上,查询时,可以减少跨库聚合。

缺点

容易出现热点数据,比如项目初期,只有库1被高频率访问

待解决问题 :业务变更导致部分数据被删除后,如何做到数据容量的在平衡。一般也不用考虑这个问题。空间不值钱。

2.1.2 基于id hash来分

优点 :hash分配,数据分布均匀不会出现数据热点问题

缺点

数据的查询聚合可能需要频繁跨库。解决办法:hash算法和用于计算hash的key去保证,将业务关心的数据分片到同一库,甚至同一张表

集群扩容时,会导致重新hash。可能面临部分数据的迁移

2.1.3 怎么解决扩容时,数据重新hash的问题

方法来至于58沈剑。主要思想:分布式存储的每个库,出于数据可用性的考虑,设置一个主从库,这使得一份数据,有两份存储。扩容时,将每个从库,变成主库。于是容量就扩容了一倍,修改后的hash算法,依然能正确路由。同时由于新的主库包含了完整的数据,所以不需要做数据迁移,只需要做冗余数据的清理。图例如下:

扩容之前的状态

扩容,将从变主。%2=0的库,会变为%4=0与%4=2 。%2=1的部分,会变为%4=1与%4=3;

对扩容后的所有主数据库,新增从库,方便下次的翻倍扩容。删除冗余数据

2.2全局主键的实现机制

snowflake

2.3跨结点数据的聚合

对于跨节点聚合有两种思路,一是通过现有数据库,从查询算法上考虑。第二种,对于过于复杂的聚合统计查询,使用外置索引来实现,比如elasticsearch

第一种,几种跨库分页的方式

http://www.10tiao.com/html/249/201702/2651959942/1.html

第二种,索引外置,比如使用elasticsearch。参看elasticsearch 原理

三、服务的分布式

服务的分布式,一般涉及如下几个方面

服务注册

服务发现

负载均衡

分布式事务

服务的降级熔断

3.1服务的注册

3.2服务的发现

3.3负载均衡

以上三点的大概模式,可以参看之前的笔记微服务的注册与发现 https://chen-jun.me/wei-fu-wu-de-zhu-ce-yu-fa-xian/

3.4分布式事务

3.5服务的降级熔断

服务的降级熔断,可以在两方面做文章。比如A服务调用B服务。当B服务处理失败,导致A服务故障时。在A端,可以设置熔断,当故障率达到一定,A服务可以有一个默认值,不在调用B服务。B服务本身,也可以在A调用自己出故障时,不走计算流程,直接返回一个默认值。这方面的框架有Spring Cloud Hystrix

Spring Cloud Hystrix是基于Netflix的开源框架Hystrix实现,该框架实现了服务熔断、线程隔离等一系列服务保护功能。

对于熔断机制的实现,Hystrix设计了三种状态:

1.熔断关闭状态(Closed)

服务没有故障时,熔断器所处的状态,对调用方的调用不做任何限制。

2.熔断开启状态(Open)

在固定时间窗口内(Hystrix默认是10秒),接口调用出错比率达到一个阈值(Hystrix默认为50%),会进入熔断开启状态。进入熔断状态后,后续对该服务接口的调用不再经过网络,直接执行本地的fallback方法。

3.半熔断状态(Half-Open)

在进入熔断开启状态一段时间之后(Hystrix默认是5秒),熔断器会进入半熔断状态。所谓半熔断就是尝试恢复服务调用,允许有限的流量调用该服务,并监控调用成功率。如果成功率达到预期,则说明服务已恢复,进入熔断关闭状态;如果成功率仍旧很低,则重新进入熔断关闭状态。

关系转换图如下

四、 分布式事务

4.1 CAP理论

CAP理论是 Eric Brewer提出的一种分布式状况下,面临的三个无法同时兼顾的问题

Consistency所有分布式节点,对同一份数据,拥有相同的副本。不会出现数据不一致的情况

Availability对数据的更新和读写,具有高可用性。即服务不能无响应,或出错

Partition Tolerance分区的容忍性,这里的分区不是指数据分布式存储中的shard分区。而是指,由于诸如网络等原因,导致分布式节点之间,无法正常同性时,导致的结点隔离,成为分区。在分区时,整个系统还能允许多大程度的对外服务,成为分区容忍性。

假设一个分布式系统中,有两个节点,处于分区状态。若允许分区中节点可以更新数据,那么会丧失一致性 C 。如果要保证一致性 C ,那处于分区状态的节点将不允许提供服务,这又会丧失可用性 A 。如果一定要保证 CA ,必须保证节点之间能够互相通信,那分区就不能容忍,就无从谈起分区容忍性 P

Eric Brewer提出,在分布式环境下,一个系统只能同时满足以上两点特性,而无法同时满足所有特性。在大多数的分布式系统设计中,人们多会选择满足 AP 两点特性。而放弃强一致性,转而追求最终一致性。这种选择还有另外一个描述叫: B asically A vailable, S oft-state, E ventually consistent 简称 BASE

以上CAP理论的简洁抽象,容易让人们大概理解分布式系统中的难处,但也容易产生一些误导。那就是CAP中的3选2,并不是绝对的。所有Eric Brewer后来又做了一次澄清解释。为什么有误导?

1、很多时候,如果我们不能保证P,那CA也无从谈起

比如用户是通过html访问服务的,这个服务对应的节点,出现分区,导致html都无法访问时。那CA 就不用提了。只有在html能在客户端缓存,支持用户离线模式,才可以说系统保证了 P ,同时保证了 A

2、保证AP,并不是完全放弃C,当恢复分区时,我们依然要采取各种方式解决分区导致的不一致。

由于网络延迟,或网络断连,甚至一个写请求,同步至所有节点,由于节点跨机房,写完成的时间不同步,都可能导致分区。只是分区的时间长短不一而已。为了解决最终的一致性,这就涉及到分布式事务。对于分布式数据库中,某个值的写,保证其一致性,可以使用paxos,raft协议算法。对于业务类型的事务。可以使用TCC或者消息通知的模式来进行事务管理

4.2 最终一致性方案——paxos,raft

zookeeper就是使用的paxos协议

4.3最终一致性方案——TCC

分为 T ry , C onfirm, C ancel ,简称TCC。

Try:尝试锁定事务涉及的资源,进行资源预留

Confirm:对预留的资源做确认提交

Cancel:如果confirm失败,则进行补偿操作,回滚业务处理,解锁预留资源

可以看到这种,try , confrm/cancel。也是两阶段。那跟传统JAT支持的两阶段事务有什么区别?

JTA支持的传统两阶段事务,需要涉及的资源支持XA协议标准,但TCC则需要遵循什么工业标准,可以是完全的业务实现。传统的两阶段提交,任然要求满足事务的ACID,这导致资源的可用性很差。

传统两阶段提交的特点:

TCC事务的特点:

4.4 最终一致性方案——消息通知

这类事务的特点是,需要借助消息通知,来使得事务涉及的多个分布式服务能够协调,完成业务期望。这种方式,也有几种细分的设计。

4.4.1 使用本地事务

同一个共用的消息表,来协调服务双方的业务执行状况

4.4.2 使用MQ

4.4.3 另外一种使用MQ的方式


作者:伊竹凌
链接:https://www.jianshu.com/p/b244456677f2


点击查看更多内容
2人点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消