Skip to content

Latest commit

 

History

History
742 lines (710 loc) · 35 KB

2019-01-09_大型分布式存储系统.md

File metadata and controls

742 lines (710 loc) · 35 KB
Raw

大型分布式存储系统：原理解析与架构设计 （2012年时候的状态）

Chapter 1： 概述

  • 分布式系统
    • 分布式系统是大量普通 PC 服务器通过 Internet 互联，对外作为一个整体提供存储服务。
  • 分布式存储的系统的特点
    1. 可扩展
    2. 低成本
    3. 高性能
    4. 易用
  • 分布式存储系统涉及的技术主要来自：分布式系统以及数据库
    1. 数据分布
    2. 一致性
    3. 容错
    4. 负载均衡
    5. 事务并发控制
    6. 易用性
    7. 压缩/解压缩
  • 分布式存储分类
    • 存储的数据
      1. 非结构化数据：文本、图片、图像等
      2. 结构化数据：schema 和内容是分开的（hive）
      3. 半结构化数据
    • 分布式存储系统分类
      1. 分布式文件系统：存储Blob、定长块、大文件
        • GFS、TFS
      2. 分布式键值系统
        • Amazon Dynamo、Tabao Tair
      3. 分布式表格系统：支持某种程度的事务
      4. 分布式数据库
        • MySQL Sharding、Google Spanner、OceanBase

第一篇

Chapter 2：单机存储系统

  • 硬件基础
    • CPU 架构：对称多处理器（SMP）
    • IO 总线：南北桥结构
    • 网络拓扑：思科的三层模型 （核心层、汇聚层、接入层）
    • 性能参数（2013年）
类别 消耗时间
访问 L1 cache 0.5 ns
预测分支失败 5 ns
访问 L2 Cache 7 ns
Mutex 加锁/解锁 100 ns
内存访问 100 ns
千兆网络发送 1M 数据 10 ms
从内存顺序读取 1M 数据 0.25 ms
机房内网络来回 0.5 ms
异地机房之间的网络来回 30 ~ 100 ms
SATA 磁盘寻址 10 ms
从 SATA 磁盘顺序读取 1M 数据 20 ms
固态磁盘 SSD访问延时 0.1 ~ 0.2 ms
  • 存储层次架构：单机、同一机架、同一集群
  • 单机存储引擎
    1. Hash 存储引擎：以 Bitcask 为例
      • 仅支持追加操作（Append Only）
      • 数据结构：内存索引（key：<file_id,value_pos,value_size>） + 磁盘文件（控制大小，定期合并）
      • 快速恢复：索引落盘
    2. B 树存储引擎：以 MySQL InnoDB 使用的 B+ Tree 为例
      • 按照 Page 来组织数据，每个页面对应于一个 B+ 树的一个叶节点
      • 缓冲区管理：LRU + LIRS （两级的 LRU，解决全表扫描带来的问题）
    3. LSM 树（Log Structured Merge Tree）
      • 对数据的修改增量保存在内存中，达到指定的大小之后将这些修改操作批量写入磁盘，读取时需要合并磁盘中历史数据和内存中最近修改。
      • 数据合并。
  • 数据模型：文件模型、关系模型和键值模型
    • 文件模型
    • 关系模型：SQL
    • 键值模型：NoSQL
  • 事务与并发控制
    • ACID
    • 写时复制 COW（Copy on Write）
    • 多版本并发控制 MVCC （Multi-Version Concurrency Version Control）
    • 事务
      • ACID
      • 隔离级别：RU（Read Uncommitted）、RC（Read Committed）、RR（Repeatable Read）、S（Serializabe）
        • Dirty Reads、Non-Repeatable Reads 是因为 update
        • Phantom Reads 是因为 insert
    • 并发控制
      • 数据库锁
      • 写时复制（COW）
      • 多版本并发控制 （MVCC）
  • 故障恢复
    • 操作日志（UNDO/REDO)
    • REDO 日志
    • 优化手段
      • 成组提交
      • 检查点
  • 数据压缩
    • 压缩算法
      • 霍夫曼编码
      • LZ77 及其变种
      • BMDiff 与 Zippy （by google）
    • 列式存储

Chapter 3：分布式系统

  • 异常
    • 异常类型：服务器宕机、网络异常、磁盘故障
    • 超时：三态（成功、失败、超时）
    • 一致性
    • 衡量指标：性能、可用性、一致性、可扩展性
  • 性能分析
  • 数据分布
    • 哈希分布（一致性哈希 Distributed Hash Table，DHT）
    • 顺序分布：和 B+ 较为类似，每个节点只顺序存储一个 range 里面的数据
    • 负载均衡：总控节点 + 工作节点，数据迁移
  • 复制
    • 主从同步，commit log
    • 一致性与可用性：CAP
  • 容错
    • 常见故障 + 故障检测
  • 可扩展性
    • 总控节点 + 数据节点
    • 数据库扩容
    • 异构系统
  • 分布式协议
    • 两阶段提交
    • Paxos
  • 跨机房部署
    • 集群整体切换
    • 单个集群跨机房
    • Paxos 选主副本

第二篇：范型篇

Chapter 4：分布式文件系统

  • GFS
    • 系统架构：GFS Master（主控服务器）、GFS ChunkServer（数据块服务器）以及 GFS 客户端
    • 关键问题：租约机制、一致性模型（主要采用追加而不是改写）
    • 追加流程
    • 容错机制：Master 主备模式、ChunkServer 多副本
  • TFS：Tabao File System
    • 多个逻辑图片共享一个物理文件
    • 系统架构：NameServer （主备）、DataServer（主从）
    • 用 Tair 做图片去重
    • <BlockId, Block Offset>
    • 不支持磁盘回收
  • Facebook Haystack
    • 系统架构：Haystack 主要包括 目录（Directory）、存储（Storage）和缓存（Cache）
    • 延迟删除，支持磁盘回收
  • 淘宝 CDN （Content Delivery Network）
    • 架构：<全局调度系统> <==> < L1 Cache > <==> < L2 Cache > <==> < Application > <==> < Storage >
    • 单个 CDN 节点架构：< client > <==> < LVS > <==> < Haproxy > <==> <所有频道统一调度> <==> < squid > <==> <资源服务器>
    • 成本控制：分级存储 + 低功耗服务器定制

Chapter 5：分布式键值系统

  • Amazon Dynamo

    • 面临的问题以及解决方案
    问题 解决方案
    数据分布 改进的一致性哈希（虚拟节点）
    复制协议 复制写协议（Replicated-write Protocol， NWR参数可调）
    数据冲突处理 向量时钟
    临时故障处理 数据回传机制（Hinted handoff）
    永久故障后的恢复 Merkle 哈希树
    成员资格及错误检测 基于 Gossip
    • 特性
      • 采用了无中心节点的 P2P 设计，增加了系统的可扩展性
      • 一致性的问题
      • 可测试性困难

  • 淘宝 Tair

    • 系统架构
      • 中心控制节点 Config Server， 主备结构
      • 服务节点 Data Server
    • 关键问题
      • 数据分布：主键 hash，10240 个 bucket
      • 容错：每个 bucket 都是有备份存储的
      • 数据迁移，迁移过程中需要保证服务可用
      • Config Server。客户端会缓存路由表，Data Server 也有路由表的信息。
      • Data Server：负责数据存储，同时完成 Config Server 指派的数据复制和迁移工作。
    • 特点
      • 中心节点 Config Server，容易处理一致性
      • 数据复制技术，还是可能存在丢数据的可能性。

Chapter 6：分布式表格系统

  • Google Bigtable
    • Bigtable 是基于 GFS 和 Chubby 的分布式表格系统。
    • Bigtable 构建在 GFS 之上，为文件系统增加一层分布式索引层。
    • 架构
      • Bigtable 将达标划分为大小在 100M ~ 200M 的子表（tablet），每个子表对应于一个连续的数据范围。
      • 主要有三部分组成：
        1. 客户端程序（Client）：提供 Bigtable 到应用程序的接口，客户端通过 Chubby 获取控制信息，但是表格的数据内容都在客户端与子表服务器之间直接进行。
        2. 主控服务器（Master）：管理所有的子表服务器，包括子表分配、指导子表合并、接受子表服务器的分裂信息、监控子表服务器、负载均衡、故障恢复等。
        3. 子表服务器（Tablet Server）：实现子表的装载/卸载、表格内容的读写，子表的分裂和合并。
    • 三种类型的表格
      1. 用户表（User Table）： 存储用户实际数据
      2. 元数据表（Meta Table）：存储用户表的元数据。比如子表位置信息、SSTable及操作日志文件编号、日志回放点
      3. 根表（Root Table）：存储元数据表的元数据。根表的元数据（位置信息），又称为 Bigtable 引导信息，存放在 Chubby 系统中。
    • 一致性：Bigtable 系统保证了强一致性，同一个时刻同一个子表只能被一台服 Tablet Server 服务。
    • 存储引擎：采用 Merge-dump 存储引擎。
    • 垃圾回收：压缩，生成新的，删除旧的。
  • Google Megastore
    • Megastore 是在 Bigtable 系统上提供友好的数据库功能支持，增强易用性。
    • 抽象出实体组（Entity Group）概念。
    • 系统架构
      • 客户端库：提供应用程序接口，Megastore 系统大部分功能集中在客户端：包括映射 Megastore 操作到 Bigtable、事物及并发控制、基于 Paxos 的复制、将请求分送给复制服务器、通过协调者实现快速读取。
      • 复制服务器：接受客户端的用户请求并转发到所在机房的 Bigtable 实例，用于解决跨机房连接数过多的问题。
      • 协调者：存储每个机房本地的实体组是否处于最新状态的信息，用于快速读取。
    • 实体组
      • 单集群实体组内部：同一个实体组内部支持满足ACID特性的事务。
      • 单集群实体组之间：实体组之间一般采用分布式队列的方式提供最终一致性。
    • 并发控制
      • 读写事务
    • 复制：通过 Paxos 协议将数据复制到多个数据中心。
    • 索引：局部索引 + 全局索引
      • STRONG 子句 + 可重复索引
    • 协调者
      • 快速读取
      • 协调者的可用性
      • 竞争条件
    • Megastore 的主要创新
      • 提出实体组的数据模型
      • 通过 Paxos 协议同时保证高可靠性和高可用性
  • Windows Azure Storage
    • 整体架构
      • 定位服务（Location Service， LS）：管理所有的存储区，管理用户到存储区的映射关系，搜集存储区的负载信息，分配新用户到负载较轻的存储区。
      • 存储区（Storage Stamp）：每个存储区是一个集群，一般由 10 ~ 20 个机架组成，每个存储节点提供大约 2PB 存储容量。
        • 存储区分三层
          • 文件流层（Stream Layer）：与 GFS 类似，提供分布式文件存储
          • 分区层（Partition Layer）：与 Google Bigtable 类似，将对象划分到不同的分区服务器服务，分区服务器将对象持久化到文件流层。
          • 前端层（Front-end Layer）：前端层包括一系列的无状态 Web 服务器，这些 Web 服务器完成权限验证等功能并根据请求的分区名将请求转发到不同的分区服务器上
        • 两种复制方式
          • 存储区内复制：文件流层实现
          • 跨存储区复制：服务分区层实现
    • 文件流层
      • 架构
        • 流管理器（Stream Manager， SM）
        • extent 存储节点（Extent Node， EN）
        • 客户端程序（Partition Layer Client）
      • 复制一致性：至允许增加，不允许修改。
    • 分区层
      • 用于提供 Table、Blob、Queue 等数据服务。一个重要特性是提供强一致性并保证事务操作顺序。
      • 架构
        • 客户端层序：提供分区层到 WAS 前端的接口
        • 分区服务器（Partition Server， PS）：实现分区的装载/卸出、分区内容的读和写，分区的合并和分裂。
        • 分区管理器（Partition Manager， PM）管理所有的 PS，包括分配分区给 PS，指导 PS 实现分区的分裂和合并， 监控 PS，在 PS 之间进行负载均衡并实现 PS 的故障恢复等。
        • 锁服务（Lock Service）
    • 讨论：WAS 整体架构借鉴 GFS + Bigtable 并有所创新
      1. Chunk 大小的选择。GFS 中每个 Chunk 大小Wie 64MB，随着服务器西能的提升，WAS 每个 extent 大小提高到 1GB 从而减少元数据。
      2. 元数据层次。Bigtable 中元数据包括根表和元数据表两级。而 WAS 中只有一级元数据，实现更加简便。
      3. GFS 的多个 Chunk 副本之间是弱一致性的，不保证每个 Chunk 的不同副本之间每个字节都完全相同，而 WAS 能够保证这一点。
      4. Bigtable 么个 Tablet Server 的所有子表共享一个操作日志文件从而提高写入性能，而 WAS 将每个范围分区的操作写入到不同的操作日志文件。

Chapter 7：分布式数据库

  • sharding 的位置：应用层，中间件（proxy），SQL Server层。
  • 数据库中间件
    • 架构：以 MySQL Sharding 为例
      1. MySQL 客户端
      2. 中间层 dbproxy：解析客户端 SQL 请求并转发到后端的数据库。
        • 解析 SQL 协议，执行 SQL 路由，SQL 过滤，读写分离，结果归并，排序以及分组，等等。
      3. 数据库组 dbgroup
        • 每个 dbgroup 由 N 台数据库机器组成。一主多从：主强一致性，并将操作以 binlog 的形式复制到从。
      4. 元数据服务器：主要负责维护 dbgroup 拆分规则并用于 dbgroup 选主。
        • 元数据服务器也需要 HA，可使用 Zookeeper 来实现
      5. 常驻进程 agents
        • 监控、单点切换、安装、卸载程序等
    • 扩容
      • 集群容量不够咋办？
        • 停服扩容 或者 双写
      • 单个用户的数据量太大怎么办？
        • 定期统计大用户，并拆分。开销大。
    • 中间层面临的问题
      • 数据库复制：MySQL 主从之间是异步复制。
      • 扩容问题：过程复杂，容易出错。
      • 动态数据迁移问题：难以自动化。
  • Microsoft SQL Azure
    • 数据模型
      1. 逻辑模型：有点类似 Entity Group 的概念
      2. 物理模型：每个有主键的表格组根据主键列有序地分成多个数据区（partition）。
        • 分区是云 SQL Server 复制、迁移、负载均衡的基本单位。
    • 架构：主要有四个部分
      • SQL Server 实例
      • 全局分区管理器（Global Partition Manager）：维护分区映射表信息，包括每个分区的主键范围，每个副本所在的服务器，以及每个副本的状态（是主还是备，正在被拷贝或是正在被追赶）。
      • 协议网关（Protocol Gateway）：负责将用户的数据库连接请求发到相应的主分区上。
      • 分布式基础部件（Distributed Fabric）：维护机器的上下线状态，检测服务器故障并未集群中的各种角色执行选主节点的操作。
    • 复制与一致性
      • 采用 Quorum Commit 的复制协议。
    • 容错
      • 全局分区管理器也采用 Quorum Commit 机制实现高可用，7个实例，一个时刻只有一个是主。
    • 负载均衡
      • 副本迁移、主副本切换
      • 影响因素：读写次数、磁盘/内存/CPU/IO 等的使用量。
    • 多租户
  • Google Spanner
    • 全球分布式数据库（Globally Distributed Database）。
      • 高可扩展性，支持跨数据中心事务。
    • 数据模型：与 Megastore 较为类似。
      • Entity Group
    • 架构：构建在分布式文件系统 Colossus 之上。
      • 新概念
        • Universe：一个 Spanner 实例称为一个 Universe。
        • Zones：每个 Zone 属于一个数据中心，一个数据中心有多个 Zone
      • 组件
        • Universe Master： 监控这个 Universe 里 Zone 级别的状态信息。
        • Placement Driver：提供跨 Zone 数据迁移能力。
        • Location Proxy：提供获取数据的位置信息服务。
        • Spanserver：提供存储能力。
    • 复制与一致性
      • Paxos 协议
    • TrueTime
      • GPS + 原子钟
    • 并发控制
    • 数据迁移
      • 目录是 Spanner 中对数据分区、复制和迁移的基本单位。

第三篇：实践篇

Chapter 8：OceanBase（2012 版本） 架构初探

  • 支持数百 TB 或 PB 级别的数据量，以及千万级别 QPS
  • 基线数据（分布式） + 增量数据（单点，主备）
  • 系统架构
    • 客户端：兼容 MySQL 协议
      • 流程
        1. 请求 RootServer 获取集群中 MergeServer 的地址列表
          • 客户端会定期从 RootServer 同步 MergeServer 地址列表。
        2. 按照一定的策略选择某台 MergeServer 发送读写请求。
          • 随机
          • 一致性哈希：可以利用缓存
        3. 如果请求 MergeServer 失败，换一台。
    • RootServer：管理集群中的所有服务器，子表（tablet）数据分布以及副本管理
      • 一般为一主一备，主备之间数据强同步。
      • 通过租约机制（lease）同一时刻只允许一个 UpdateServer 写。
      • 与 MergeServer 和 ChunkServer 之间保持 heartbeat。
      • 基线数据按照主键排序，顺序分布。采用一级索引。
    • UpdateServer：存储 OceanBase 系统的增量更新数据。
      • 一般是一主一备，可以配置不同的同步模式。
      • 更新操作首先是写入内存表，当内存表的数据量达到一定值时，可以生成快找文件并转储到 SSD 磁盘。快照与 SSTable 类似，稀疏性 SSTable。
    • ChunkServer：存储 OceanBase 系统的基线数据。
      • 基线数据一般是两三个备份。
      • 存储多个子表，提供读取服务，执行定期合并以及数据分发。
    • MergeServer：接收并解析用户的 SQL 请求，经过词法分析、语法分析、查询优化等一些列操作之后转发给相应的 ChunkServer 或者 UpdateServer。
    • 定期合并 & 数据分发
      • 流程
        1. UpdateServer 冻结当前的活跃内存表（Active MemTable），生成冻结内存表，并开启新的活跃内存表，后续的更新操作都写入新的活跃内存表。
        2. UpdateServer 通知 RootServer 数据版本发生了变化，之后 RootServer 通过心跳通知 ChunkServer。
        3. 每台 ChunkServer 启动定期合并或者数据分发操作，从 UpdateServer 定期获取每个子表对应的增量更新数据。
      • 不同
        • 数据分发：过程中 ChunkServer 只是将 UpdateServer 中冻结内存表中的增量更新缓存到本地。
        • 定期合并：ChunkServer 需要将本地 SSTable 中的基线数据和冻结内存中的增量数据进行多路归并。融合和生成新的基线数据并存放到新的 SSTable 中。
      • 新子表 = 旧子表 + 冻结内存表
      • 查询结果 = 旧子表 + 冻结内存表 + 新的活跃内存表 = 新子表 + 新的活跃内存表
  • 架构剖析
    • 一致性选择：强一致性，UpdateServer 同步完成主备。
      • 可以配置成异步同步，这个模式一般用来支持异地容灾。
    • 数据结构
      • 基线数据结构
        • 每个表格按照主键组成一棵分布式 B+ 树，主键由若干列组成
        • 每个叶子节点包含表格一个前开后闭的主键范围（rk1，rk2] 内的数据
        • 每个叶子节点称为一个子表（tablet），包含一个或多个 SSTable
        • 每个 SSTable 内部按主键范围有序划分为多个块（block）并内建索引块（block inde）
        • 每个块的大小通常在 4~64KB 之间并内建块内的行索引
        • 数据压缩以块为单位，压缩算法由用户指定并可随时变更
        • 叶子节点可能合并或者分裂
        • 所有叶子节点基本上是均匀的，随机地分布在多台 ChunkServer 上
        • 通常情况下，每个叶子节点有 2~3 个副本
        • 叶子节点是负载均衡和任务调度的基本单元
        • 支持布隆过滤器的过滤
      • 增量数据的数据结构
        • 增量数据按照时间从旧到旧划分为多个版本
        • 最新版本的数据为一棵内存中的 B+ 树，称为活跃的 MemTable
        • 用户的修改操作写入活跃 MemTable，达到一定大小之后，原有的活跃 MemTable 将被冻结，并开启新的活跃 MemTable 接受修改操作
        • 冻结的 MemTable 将以 SSTable 的形式转储到 SSD 中持久化
        • 每个 SSTable 内部按主键范围有序划分为多个块并内建索引，每个块的大小通常为 4~8 KB 并内建块内行索引，一般不压缩
        • UpdateServer 支持主备，增量数据通常为两个副本，每个副本支持 RAID1 存储
    • 可靠性 & 可用性
      • 冗余。
      • ChunkServer 保存基线数据的多个副本
      • UpdateServer 保存增量数据的多个副本
      • ChunkServer 的多个副本可以同时提供服务。
      • UpdateServer 主备之间为热备。
    • 读写事务
      • 只读事务
        1. MergeServer 解析 SQL 语句，生成逻辑执行计划和物理执行计划
        2. 如果 SQL 请求只涉及单张表格，MergeServer 将请求拆分后同时发给多台 ChunkServer 并发执行
        3. 如果 SQL 请求涉及多张表格， MergeServer 还需要执行联表、嵌套查询等操作
        4. MergeServer 将最终结果返回给客户端
      • 读写事务
        1. 与只读事务相同，MergeServer 首先解析 SQL 请求，得到物理执行计划
        2. MergeServer 请求 ChunkServer 获取需要读取的基线数据，并将物理执行计划和基线数据一起传给 UpdateServer
        3. UpdateServer 根据物理执行计划执行读写事务，执行过程中需要使用 MergeServer 传入的基线数据
        4. UpdateServer 返回 MergeServer 操作成功或者失败，MergeServer接着讲结果返回给客户端
    • 单点性能
      • UpdateServer 单点
      • 内存：更新量小，20GB 内存
      • 网络：需要的带宽小
      • 磁盘：UpdateServer 带有缓存的 RAID 卡；成组提交。
    • SSD 支持
    • 数据正确性
      • 数据存储校验：每个存储记录同时保存 64 位 CRC 校验码
      • 数据传输校验
      • 数据镜像校验：UpdateServer 为 MemTable 生成校验码
      • 数据副本校验
    • 分层结构
      • 逻辑上可分为两层：分布式存储引擎 和 数据库功能层

Chapter 9：分布式存储引擎

  • 公共模块
    • 公用的网络框架、内存池、队列、锁、RPC 框架、压缩/解压缩等
      • 内存管理：全局订场内存池
    • 基础数据结构
      • 哈希表
      • B 树
    • 锁：共享锁、互斥锁
    • 任务队列
    • 网络框架
    • 压缩与解压缩
  • RootServer 实现机制
    • 数据结构：RootTable 存储了子表数据分布的的有序表格，读多写少，写时复制。
    • 子表复制与负载均衡
    • 子表分裂与合并
    • RootServer 主备：VIP
  • UpdateServer 实现机制
    • 内存存储引擎
      • 操作日志：Direct IO，成组提交
      • MemTable：B 树
    • 任务模型
      • Tbnet：上下文切换大
      • Libeasy：多线程收发包，减少了上下文切换
    • 主备同步
      • 强一致性
  • ChunkServer 实现机制
    • 子表管理：主动实现子表分裂，配合 RootServer 实现子表迁移、删除、合并
    • SSTable：根据主键有序存储每个子表的基线数据
    • 基于 LRU 实现块缓存已经行缓存
      • 缓存的增删是以 memblock 为单位；没有维护 LRU 链表，而是对每个 memblock维护了方位次数和最近频繁访问时间；每个 memblock 有引用计数
      • 惊群效应：多个线程发现未命中，而去取内容并更新缓存。
        • 缓存 fake 标记，其他线程发现后等待
      • 缓存预热
    • 实现 Direct IO：磁盘 IO 与 CPU 计算并行化
      • ChunkServer 采用 Linux 的 Libaio 实现异步 IO，并通过双缓冲区机制实现磁盘预读与 CPU 并行化处理，步骤如下：
        1. 分配当前（current）以及预读（ahead）两个缓冲区
        2. 使用当前缓冲区读取数据，当前缓冲区通过 Libaio 发起异步读取请求，
        3. 异步读取完成后，将当前缓冲区返回上层执行 CPU 计算，同时，原来的预读区变为新的当前缓冲区，发送异步读取请求将数据读取到新的当前缓冲区。CPU 计算完成后，原来的当前缓冲区变为空闲，成为新的预读缓冲区，用于下一次读取。
        4. 重复步骤3，知道所有数据全部读完。
    • 定期合并 & 数据分发
    • 定期合并限速
      • ChunkServer：考虑机器负载
      • UpdateServer：将任务分优先级，高优先级（用户正常请求）和低优先级（定期合并任务）
      • 主备集群：可以采用错峰合并。
  • 消除更新瓶颈
    • 网络框架优化
      • libeasy 框架
      • 多网卡负载均衡
    • 高性能内存数据结构
      • UpdateServer 底层是一颗高性能内存 B 树，大部分情况做到了无锁。
    • 写操作日志优化
      • 成组提交
      • 降低日志缓冲区的锁冲突
      • 日志文件并发写入
    • 内存容量优化
      • 精心设计内存数据结构，节约内存使用
      • 将 UpdateServer 内存中的数据很快地分发出去
    • 数据旁路导入
      • 应用场景：将大量数据一次性导入。用于 OLAP 分析
      • 步骤：
        1. 离线排序数据，划分范围，生成对应的 SSTable
        2. 将 SSTable 并行拷贝到 ChunkServer
        3. 通知 RootServer 要求每个 ChunkServer 并行加载

Chapter 10：数据库功能

  • 整体结构
    • CS-SQL：实现对单个子表的 SQL 查询
    • UPS-SQL：实现写事务，支持的功能包括多版本并发控制、操作日志多线程并发回放等
    • MS-SQL：SQL 语句解析
  • 只读事务
  • 写事务
    • UPDATE、INSERT、DELETE、REPLACE
  • OLAP 业务支持
    • 并发查询
    • 列式存储
  • 特色功能
    • 大表左连接
      • 一般的方式：join VS. 信息冗余
      • OceanBase 的实现方式：冗余 + 查询时 merge + 定期 merge
    • 数据过期与批量删除

Chapter 11：质量保证、运维及实践

  • 质量保证
    • 新版的开发流程
      • 开发 => 单元测试 & 快速测试 => RD 压力测试 => 系统提测 => QA 接口、功能、容灾、压力测试 => 兼容性测试 => Benchmark 测试
    • RD 开发
      • 编码规范（c、c++语言）
        1. 函数单入口单出口
        2. 禁止在函数中抛异常，谨慎使用 STL、boost
        3. 资源管理做到可控：内存使用，线程使用
        4. 每个可能失败的函数都必须返回错误码
        5. 所有的指针使用前都必须判空，不允许使用 assert 语句代替错误检查
        6. 不允许使用 strcpy/strcat/sprintf 等，而改用对应的限制字符串长度的函数
        7. 严格要求自己，编译时开启 GCC 所有报警开关，代码提交前要解决所有的报警。
      • 代码审核
        • 编码风格审核 + 逻辑审核
      • 单元测试
      • 快速测试（quicktest）
      • RD 压力测试
        • 分布式存储殷勤压力测试：syscheckr + mixedtest
        • 数据库功能压力测试：sqltest + bigquery
    • QA 测试
      • 接口、功能、容灾测试
      • 压力测试
      • Benchmark 测试
      • 兼容性测试
    • 试运行
      • 业务压力测试
      • 线上流量回放
      • 灰度上线
  • 使用与运维
    • 使用
    • 运维
      • 数据字典
      • 服务器列表
      • 配置信息
      • 内部状态
  • 应用
    • 无需手动分库分表
    • 易于使用
    • 更低的成本
  • 最佳实践
    • 系统发展路径
      • 通用分布式存储平台主要有两种成长方式：
        1. 公司高层制定战略大理发展通用平台
          • 前期比较顺利，但是往往会因为离业务太远而在中期暴露大量平台本身的问题。
        2. 来源于具体业务并将业务需求通用化
          • 面临更大的技术挑战，但是团队成员反而而能够在这个过程中得到更多的锻炼。
          • 大致经历一下几个阶段
            1. 起步：解决待解决的问题
            2. 求生存：应用为王
            3. 平台化：提升易用性、可云卫星
            4. 成熟期：持续不断地优化
    • 人员成长
      • 师兄带师弟
        • 提供文档，解惑文档中的问题
        • 与技术负责人协商安排师弟的工作
        • 与师弟沟通代码编写（功能实现、bug 修复等）的思路
        • 审核师弟的代码并对代码质量负责，确保代码符合部门编码规范
        • 保持代码修改与技术文档更新的同步并审核师弟文档的正确性及质量
          • 文档：技术规范文档，模块接口文档，数据结构文档，编码规范
      • 架构理论学习
        • 主动挖掘整体架构背后的设计思想和关键实现细节
        • 将自己想象成设计者，对每个设计点提出质疑，直到找到合理的及时。
    • 系统设计
      1. 架构师的职责
        • 权衡架构，从多种设计方案中选择一种与当前团队能力匹配的方案
        • 模块划分、接口设计、代码规范制定。
        • 思考清楚关键实现细节并写入设计文档。
        • 提前预支团队成员的问题并给予指导。
      2. 设计原则
        • 容错。
        • 自动化。
        • 保持兼容。
    • 系统实现
      1. 重视服务器代码资源管理
      2. 做好代码审核
      3. 重视测试
    • 使用与运维
      1. 吃自己的狗粮：开发人员轮流运维自己的系统
      2. 标准客户端
      3. 线上版本管理：保证版本之间的兼容。
      4. 自动化运维
    • 工程现象
      1. 错误必然出现：不要有侥幸心理
      2. 错误必然复现：增加调试日志，加大数据规模，错误必然复现。
      3. 两倍数据规模：压力测试。
      4. 怪异现象的背后总有一个预存的初级 bug
      5. 线上问题第一次出现后，第二次将会很快重现
    • 经验法则
      1. 简单性原则： 一两句话吧事情说清楚。
      2. 精力投入原则：将主要精力放在最大产出的地方。
      3. 先稳定再优化：系统的整体性能关键在于架构，架构上的问题需要在设计阶段解决，实现细节的问题可以留到优化阶段。
      4. 想清楚，再动手：伪代码。

第四篇：专题篇

Chapter 12：云存储

  • 云存储的概念
    • 概念：是通过网络将大量普通存储设备构成的存储资源池中的存储和数据服务以统一的接口按需提供给授权用户
    • 特点：
      • 超大规模
      • 高可扩展性
      • 高可靠性和可用性
      • 安全
      • 按需服务
      • 透明服务
      • 自动容错
      • 低成本
    • 优势：
      • 可扩展性
      • 利用率
      • 成本服务能力
      • 便携性
  • 云存储的产品形态
    • Amazon S3
    • Google Cloud Storage
    • 阿里云开放存储服务（Open Storage Service）
  • 云存储技术：云端 + 终端
    • 摩尔定律
    • 宽带网络
    • Web 技术
    • 移动设备
    • 分布式存储、CDN、P2P 技术
    • 数据加密、云安全
  • 云存储的核心优势
    • 硬件开销、能耗以及管理成本
  • 云平台整体架构（2012年）
    • 云计算按照服务类型分为三类
      • 基础设施及服务（Infrastructure as a Service， IaaS）
        • Amazon EC2
      • 平台即服务（Platform as a Service，PaaS）
        • Google App Engine
        • Microsoft Azure Platform
      • 软件即服务（Softwar as a Service， SaaS）
        • Salesforce online CRM
        • Google Apps
    • Amazon 云平台：AWS
      • 计算类：EC2（Elastic Computing） 虚拟机
      • 存储类：S3
      • 工具支持：各种语言
    • Google 云平台
      • 前端服务器
      • 应用服务器
      • 应用管理节点
      • 存储区
      • 服务区
    • Microsoft 云平台
      • 计算服务
      • 存储服务
      • 连接服务
      • 工具支持
    • 云平台架构
      • 云平台核心组件：云存储组件和运行平台组件。
        • 云存储组件：分布式存储层 + 存储访问层
          • 存储层管理存储服务器集群，实现各个存储设备之间的协同工作，保证数据可靠性。屏蔽数据位置、数据迁移、数据复制、机器增减等变化，使得整个分布式系统看起来向一台机器。
          • 存储访问层：主要将分布式存储层的客户端接口封装成 WebService（基于 RESTful， SOAP 等协议）
        • 应用运行平台组件：计算实例 => 计算组
        • 公共服务：
          • 消息服务
          • 缓存服务
          • 用户管理
          • 权限管理
          • 安全服务
          • 计费管理
          • 资源管理
          • 监控系统
  • 云存储技术体系：硬件层、单机存储层、分布式存储层、存储访问层
    • 硬件层
      • 存储：SSD/SAS/SATA/PCI-E
      • 网络：交换机/万兆网卡
      • CPU：Nehelam/Atom
      • 定制服务器：低功耗/低成本
      • 数据中心：电源、冷却、PUE（Pow Usage Efficient，能源使用率）
    • 单机存储层
      • NoSQL 存储引擎：hash、LSM tree
      • 关系数据库：SQL
      • 压缩/解压缩：lzo/zippy/bmdiff
      • 文件系统：ext3/ext4/btrfs
      • 网络协议：tcp/udp
      • CPU 与内存：内存管理、CPU 优化
    • 分布式存储层
      • 分布式文件系统：GFS/TFS
      • 分布式彪哥系统：Bigtable
      • 分布式数据库：SQL Azure
      • 访问加速：CDN/P2P
      • 分布式缓存：Tair/Redis
      • 服务总线：消息中间件
      • 集群资源管理：Borg
      • 分布式锁服务：Chubby，Zk
      • 数据分布
      • 负载均衡
      • 数据复制
      • 一致性
      • 故障检测和恢复
    • 存储访问层
      • Web 服务器：Apache/Nginx
      • 负载均衡：LVS/HaProxy
      • 安全及计费服务
      • 身份验证
      • 访问授权
      • 综合防护
      • 安全审计
      • DDos/防火墙
    • 相关技术
      • 弹性计算平台：EC2等
      • 分布式计算：MapReduce/MPI等
      • 云引擎：AppEngine
      • 虚拟化：Xen/Kvm 等
      • 自动伸缩
      • 应用容器：沙箱
      • 连接：VPN
  • 云存储安全
    • 安全问题的方面
      • 在信任边界方面有了巨大变化
      • 更多的利益相关方
      • 云存储服务暴露在互联网上
      • 多租户共享的引入
      • 数据存储
    • 技术层面
      • 用户安全
      • 网络安全
      • 多租户隔离
      • 存储安全

Chapter 13：大数据

  • 大数据概念
    • 特点
      • Volume
      • Variety
      • Velocity
      • Value
    • 大数据的管理、理解、应用
  • MapReduce
    • 任务优化：
      • 本地化：计算靠近数据
      • 备份任务：较少“拖后腿”任务
  • MapReduce 扩展
    • Google Tenzing： 基于 MR 构建的 SQL 执行引擎
    • Microsoft Dryad：将 MR 模型从一个简单的两步工作流扩展为任何函数的集合，并通过一个有向无环图来表示函数之间的工作流
    • Google Pregel：用于图模型迭代计算
  • 流失计算
    • 原理：
    • Yahoo S4
    • Twitter Storm
    • Spout/Bolt
  • 事实分析（OLAP）
    • MPP（Massive Parallel Processing，大规模并行处理） 架构
    • EMC Greenplum
    • HP Vertica
    • Google Dremel