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

一、分布式的两大场景数据存储的分布式服务的分布式二、数据存储的分布式比如海量数据，单机存储不下，需要多机，以集群的方式存储，即为数据的分布式存储，数据存储的分布式一般涉及如下几个方面数据的分片策略全局主键的实现机制跨结点数据的聚合分布式事务数据容灾机制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全局主键的实现机制snowflake2.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 HystrixSpring 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 ，必须保证节点之间能够互相通信，那分区就不能容忍，就无从谈起分区容忍性 PEric 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 ,同时保证了 A2、保证AP,并不是完全放弃C，当恢复分区时，我们依然要采取各种方式解决分区导致的不一致。由于网络延迟，或网络断连，甚至一个写请求，同步至所有节点，由于节点跨机房，写完成的时间不同步，都可能导致分区。只是分区的时间长短不一而已。为了解决最终的一致性，这就涉及到分布式事务。对于分布式数据库中，某个值的写，保证其一致性，可以使用paxos,raft协议算法。对于业务类型的事务。可以使用TCC或者消息通知的模式来进行事务管理4.2 最终一致性方案——paxos,raftzookeeper就是使用的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的方式