分布式缓存 - 分布式系统理论（下）

一. 分布式系统设计策略

 
分布式系统的本质是通过低廉的硬件攒在一起已获得更好的吞吐量、性能及可用性等，在分布式环境下，有几个问题是普遍关心的，称为设计策略：
 

• 如何检测你还活着
• 如何保障高可用
• 容错处理
• 重试机制
• 负载均衡

 

1.1 心跳检测

 

如图所示，当 Server 没有收到节点 Node3 发送的心跳时，Server 认为Node3 失联，失联代表不确定是否是 Node3 故障，有可能是 Node3 处于繁忙状态，导致调用检测超时，也可能是 Server 与节点3之间链路出现故障或闪断。所以心跳不是万能的，收到心跳可以确定节点正常，但是收不到心跳却不能认为节点已经宣告“死亡”

 
没有心跳不代表节点宕机，有一些具体的做法来帮我们决定是否宕机，一般分为两类：周期检测心跳机制、累计失效检测机制

 
周期检测心跳机制：Server每隔 t 秒向 Node 集群发起监测请求，设定超时时间，如果超过超时时间，则判断死亡。也可加上超时重传的机制，即若对方没在规定时间内重传，则可重试一定次数

 

1.2 高可用设计

系统高可用性的常用设计模式包括三种：主备、互备、集群

 

1.2.1 主备

当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，按使用者的设定以 自动（热备）或手动（冷备） 方式将服务切换到主机上运行。

 
在数据库部分，习惯称之为MS模式。MS模式即 Master/Slave 模式，在数据库高可用性方案中比较常用，如下图所示

 

1.2.2 互备

互备模式是指两台主机同时运行各自的服务工作且相互监测情况。在数据库高可用部分，常见的互备是 MM 模式。MM 模式即 Multi-Master 模式，指一个系统存在多个 master，每个 master 都有 read-write 能力，需要根据时间戳或业务逻辑合并版本，如分布式版本管理系统 git，具备最终一致性

 
如下，机房H、K同时具有全套服务能力（读能力+写能力），而数据库之间需要通过同步来保障一致性。对于 K 机房的备库则在机房 H 不可用的时候发挥作用

 

1.2.3 集群

 
集群模式是指有多个节点在运行，同时可以通过主控节点分担服务请求，如zookeeper。集群模式要特别解决主控节点本身的高可用问题

 

1.3 容错性

IT系统对于错误包容的能力，这里容错确切的说是容故障（Fault），而并非容错误（Error）

 
容错的处理是保障分布式环境下相应系统的高可用或者健壮性。典型处理就是对于缓存失效雪崩问题的解决方案

1.4 负载均衡

负载均衡集群： 其关键是在于使用多台集群服务器分担计算任务，把网络请求及计算分配到集群可用服务器上去，从而达到更好的用户体验

 

2. 分布式系统设计实践

 

2.1 全局 ID 生成

如果用数据库的自增，则每次Insert都要用到 id 生成器作 DB 层面的查询，应该避免

 

2.1.1 UUID

组成：时间+时钟+全局唯一IEEE识别器
优势：API简单易用
不足：占用空间大、字符串本身无法加工，可读性不强

 

2.1.2 ID 生成表模式

2.1.3 SnowFlake

2.1.4 结合缓存方案

提前将ID生成器生成的如1k个ID放入缓存，提高性能

 

2.2 哈希取模

缺点是如果id分布不均匀可能出现计算、存储倾斜的问题。还有如果调整数据存储，如增加两个库，比较麻烦。一个可解决的方法是先预设足够大的逻辑库，如100个库，随着物理负载的增加，把对应的逻辑库迁移到新增的物理库上即可，对于应用透明，相当于在应用和物理数据库之间增加了一层映射关系

2.3 一致性哈希

一致性Hash
一致性Hash，通俗易懂版

一致性哈希的有点事可以任意动态添加、删除节点，每次添加、删除一个节点仅影响一致性哈希环上相邻的节点。为了尽可能均匀地分布节点和数据，一种常见的算法是增加虚拟节点（虚拟节点链接自定义物理节点，避免某一段内数据过多）

 

2.4 路由表

暂时看不懂，P58

 

2.5 数据拆分

 
Cobar：阿里开源分布式数据库中间件

用户可以将表放在不同的datanode，也可将不同的datasource放置在同意MySQL实例上

 
sharding-jdbc：当当开源