Basic Knowledge

CAP相关

  1. Paxos算法
  2. 分布式系统的事务处理

    关于事务机制部分写的很不错的一篇文章

关于元数据

分布式存储的元数据设计

常规的存储设计方法主要有以下几类。

  • 无中心的存储设计，如GlusterFS。
  • 有中心的存储设计，如Hadoop。
  • 基于数据库的存储设计，如GridFS和HBase。
  • 绕过元数据的存储设计，如FastDFS。

平安科技实战经验：分布式存储元数据设计方法

分析了有中心无中心两种元数据模式； 分析了swift和ceph的存储方式； 方式1-有中心的元数据设计 通常会有一个独立元数据控制器，它会管理整个集群文件的元数据信息，并能提供数据定位和集群策略智能管控等能力。此种设计方案能非常好的控制数据分布，避免因集群发生变化，导致过度数据迁移带来的内耗。但是要实现一个优秀的元数据控制器，真不是一件容易的事，其主要难点：如何能够在无限的海量小文件增长的前提下，还能够保证服务高效、稳定。Hadoop就是采取的有中心的元数据设计案例，其目标是存储大文件，主要进行离线分析。

方式2-无中心的元数据设计 文件的寻址定位完全通过算法搞定，不需要记录文件的索引信息。此种方式具备极高的寻址效率，也不需要担心海量元数据带来的其它问题（压根就没记录），是不是很巧妙的规避了很多问题？但是新的问题出现了，由于算法是无法动态变化的，那就要求任何时候数据分布都必须能够支撑算法（否则数据就找不到了），所以当集群发生变化时，数据就必须进行移动，而有些时候数据变动是我们不期望发生的，这样就会带来内耗。设计一个好的寻址算法是能够尽量降低内耗，但无法避免内耗。

swift的主要缺点：

    1. Ring无法在线动态变更和调整。 实际应用中，增减节点、盘坏是常态，必然会带来Ring的改变，它需要重新在线下构建Ring环，然后要替换重启服务才能生效，此种方式让人无法接受。

  • 2、不支持差异化配置。 存储会存在很多差异化需求，有的对延迟要求高，有的对延迟要求不高，所以就要差异化的物理配置来支持，而Swift的集群只能提供一种标准的服务。

  • 3、数据一旦重新分布，没有站岗机制。 在进行Ring调整时，有一定概率会发生“一个分区下对应的多份副本的Dev都发生变化”，这样就会导致数据在还没有迁移匹配之前，此分区下的部分数据就会查询不到。

分类

分布式文件系统

Schema:数据模式

Blob（Binary Large Object,二进制大对象）对象

定长块

大文件

  • 分布式文件系统用于存储Blob对象，典型的有Facebook Haystack；

  • 作为分布式表格及分布式数据库的底层存储：GFS，HDFS， Amazon EBS（Elastic Block Store）

GFS

  • 文件被划分为固定大小的数据块(chunk),由主服务器在创建时分配一个64位全局唯一的chunk句柄。

  • 主控服务器维护了系统的元数据

  • 租约机制：

  • 为了追加而不是改写而设计的；

  • 载均衡：当Master创建一个chunk，它会根据如下因素来选择chunk副本的初始位置：1) 新副本所在的ChunkServer的磁盘利用率低于平均水平；2） 限制每个chunkServer最近创建的数量；3） 每个chunk的所有副本不能再同一个机架上。

  • 垃圾回收：延迟删除的机制（默认为3天）

  • 两地三数据中心五副本：同城两个数据中心分别部署2个副本，异地数据中心部署1个副本

TFS

  • 针对大量小文件（图片）：将大量的小文件合并成一个大文件---Block

  • 多个逻辑文件共用一个物理文件；

  • 每个Block拥有集群唯一的编号（块ID），通过<块ID，块内便宜>可以唯一确定一个文件；

-

分布式键值系统

  • Amazon Dynamo

  • MemoryCache

分布式表格系统

  • Google Bigtable

    • 三种Compaction策略：

    • Minor Compaction：把内存中的MemTable转存到GFS中

    • Merging Compaction 和 Major Compaction 合并GFS中的多个SSTable文件，生成一个更大的SStable

  • Megastore

  • Amazon DynamoDB

分布式数据库

-Google Spanner

-Amaozon RDS

硬件

CPU的对称多处理结构（Symmetric Mult-Processing， SMP）

  • 每个CPU拥有多个核心，每个核心有各自的L1d Cache(L1数据缓存)和L1i Cache(L1指令缓存)

  • 同一个CPU的多个核心共享L2及L3缓存

  • 不同CPU共享ISO及存储资源

  • 不足，多个CPU竞争前端总线，扩展能力有限

NUMA

  • 现在主流服务器架构一般为NUMA（Non-Uniform Memory Access，非一致性存储访问）架构

  • 它具有多个NUMA节点，每个NUMA节点是一个SMP结构

IO

  • 北桥芯片通过前端总线与CPU挂连，PCIE设备挂载北桥

  • 北桥与南桥之间通过DMI连接（1GB/s）

  • 网卡、硬盘以及中低端固态硬盘挂接南桥上（300MB/s）

  • 跨机房传输延时比较大（30-100ms），北京与杭州大约40ms

  • 磁盘寻道时间 7.5ms~14ms, SSD 0.1ms数量级

缓冲区管理

  • LRU

  • LIRS： 两级缓冲池，根据在一级缓冲池的停留时间，来判断是否为热数据；

-

LSM树存储引擎

  • 数据修改增量写到内存，达到一定大小，批量写入硬盘；

  • Compaction操作：minor compaction， major compaction

数据模型

  • 文件、对象

  • 关系模型

  • 键值模型、表格模型

概念

  • OLAP 在线分析处理

  • OLTP 联机事务处理

跨机房部署

  • 数据同步

  • 服务切换

其他参考

  1. 大型互联网技术架构3－分布式存储-I
  2. 分布式原理
  3. 大型互联网技术架构分析之分布式存储(下)
  4. 从Google Spanner漫谈分布式存储与数据库技术

    介绍了google spanner的核心技术，尤其是true time api.

results matching ""

    No results matching ""