分布式系统学习笔记

一、分布式的两大场景

  • 数据存储的分布式
  • 服务的分布式

二、数据存储的分布式

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

  • 数据的分片策略
  • 全局主键的实现机制
  • 跨结点数据的聚合
  • 分布式事务
  • 数据容灾机制

2.1数据分片策略

2.1.1 基于数据范围来分

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

  • 优点
    1. 单库数据规模提前预估。超规模后,加机器,不需要迁移数据。
    2. 且相邻数据大都存放在一个库上,查询时,可以减少跨库聚合。
  • 缺点
    1. 容易出现热点数据,比如项目初期,只有库1被高频率访问
  • 待解决问题:业务变更导致部分数据被删除后,如何做到数据容量的在平衡。一般也不用考虑这个问题。空间不值钱。

2.1.2 基于id hash来分

  • 优点:hash分配,数据分布均匀不会出现数据热点问题
  • 缺点
    1. 数据的查询聚合可能需要频繁跨库。解决办法:hash算法和用于计算hash的key去保证,将业务关心的数据分片到同一库,甚至同一张表
    2. 集群扩容时,会导致重新hash。可能面临部分数据的迁移

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

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

扩容之前的状态
1520645560750

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

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

2.2全局主键的实现机制

snowflake

2.3跨结点数据的聚合

对于跨节点聚合有两种思路,一是通过现有数据库,从查询算法上考虑。第二种,对于过于复杂的聚合统计查询,使用外置索引来实现,比如elasticsearch
第一种,几种跨库分页的方式
来至58沈剑: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秒),熔断器会进入半熔断状态。所谓半熔断就是尝试恢复服务调用,允许有限的流量调用该服务,并监控调用成功率。如果成功率达到预期,则说明服务已恢复,进入熔断关闭状态;如果成功率仍旧很低,则重新进入熔断关闭状态。

关系转换图如下
1520651424017

四、 分布式事务

4.1 CAP理论

CAP理论是 Eric Brewer提出的一种分布式状况下,面临的三个无法同时兼顾的问题
Consistency 所有分布式节点,对同一份数据,拥有相同的副本。不会出现数据不一致的情况
Availability 对数据的更新和读写,具有高可用性。即服务不能无响应,或出错
Partition Tolerance 分区的容忍性,这里的分区不是指数据分布式存储中的shard分区。而是指,由于诸如网络等原因,导致分布式节点之间,无法正常同性时,导致的结点隔离,成为分区。在分区时,整个系统还能允许多大程度的对外服务,成为分区容忍性。

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

Eric Brewer提出,在分布式环境下,一个系统只能同时满足以上两点特性,而无法同时满足所有特性。在大多数的分布式系统设计中,人们多会选择满足AP两点特性。而放弃强一致性,转而追求最终一致性。这种选择还有另外一个描述叫:Basically Available, Soft-state, Eventually 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

分为Try , Confirm,Cancel ,简称TCC。
Try:尝试锁定事务涉及的资源,进行资源预留
Confirm:对预留的资源做确认提交
Cancel:如果confirm失败,则进行补偿操作,回滚业务处理,解锁预留资源

可以看到这种,try , confrm/cancel。也是两阶段。那跟传统JAT支持的两阶段事务有什么区别?
JTA支持的传统两阶段事务,需要涉及的资源支持XA协议标准,但TCC则需要遵循什么工业标准,可以是完全的业务实现。传统的两阶段提交,任然要求满足事务的ACID,这导致资源的可用性很差。

传统两阶段提交的特点:
1520847782600
1520847789208

TCC事务的特点:
1520847819266

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

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

4.4.1 使用本地事务

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

4.4.2 使用MQ

1520848367455

4.4.3 另外一种使用MQ的方式

1520848383974-1

参考链接

https://mp.weixin.qq.com/s/scl8aGEdUagToeJ1I2wN2A
http://www.infoq.com/cn/articles/cap-twelve-years-later-how-the-rules-have-changed
https://en.wikipedia.org/wiki/CAP_theorem
https://kaimingwan.com/post/fen-bu-shi/fen-bu-shi-shi-wu-de-dian-xing-chu-li-fang-shi-2pc-tcc-yi-bu-que-bao-he-zui-da-nu-li-xing
https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html