1学习来源
《大规模分布式存储系统原理解析与架构实战》--杨传辉
2学习目标
- 数据分布：如何使数据均匀分布到多台服务器上？分布到多台服务器后如何实现跨服务器读写操作？
- 一致性：如何将数据的多个副本复制到多台服务器？即使在异常情况下，也能保证不同副本间数据的一致性
- 容错：如何检测到服务器故障？故障后如何将数据和服务迁移到集群中的其他服务器上？
- 负载均衡：新增服务器/集群正常运行过程中如何实现自动负载均衡？数据迁移过程中如何不影响已有服务？
- 事务与并发控制：如何实现分布式事务？如何实现并发控制？
- 易用性：如何设计对外接口使系统变得易用？如何设计监控系统并将系统的内部状态方便的暴露给运维人员？
- 压缩/解压缩：如何根据数据的特点设计压缩/解压缩算法？如何平衡压缩算法节省的存储空间和消耗的CPU计算资源？
3分布式存储分类
分布式文件系统：常作为分布式表格系统和分布式数据库系统的底层存储。
分布式键值系统：只提供基于主键的CRUD功能，即根据主键创建、读取、更新、删除一条键值记录
分布式表格系统：用于存储较为复杂的半结构化数据。
分布式数据库：存储结构化数据，典型的包括：Mysql数据库分片集群、Amazon RDS、Microsoft SQL Azure。
4Tips
- 存储系统性能主要包含2个维度：吞吐量以及访问延时。设计系统时要求在保证访问延时的基础上，通过最低成本尽可能实现更高的吞吐。磁盘和SSD的访问延时差别很大、但带宽差别不大，因此磁盘适合大块顺序访问的存储系统，SSD适合随机访问较多或者延时敏感的关键系统。
- 事务的ACID特性：
A（原子性）：事务对数据库的修改，要么全都执行，要么全都不执行；
C（一致性）：例如数据的类型必须正确或者银行账户余额不能是负数；
I（隔离性）：数据库在并发执行多个事务时，每个事务可能需要对多个表项进行修改和查询。数据库需要保证每个事务在它的修改全部完成前，对其他的事物上不可见的。也就是，不能让其他事务看到该事务的中间状态；
D（持久性）：事务提交后对数据库的影响是永久性的，即使系统出现异常也是如此
- 如何解决死锁？一是为每个事务设置一个超时时间，超时后自动回滚；二是死锁检测，如果发现事务之间相互依赖构成一个环路，就回滚某些事物来解除循环依赖
- 存储系统在选择压缩算法时，需要考虑压缩比和效率
5存储引擎
哈希存储引擎
bitcask是一个基于哈希表结构的键值存储引擎。她仅支持追加操作，即所有的写只追加而不修改老的数据。在bitcask系统中，每个文件有大小限制，文件增加到相应大小时会产生一个新文件，老文件只读不写，这样在任意时刻，只有一个文件是可写的，用于数据追加，称为活跃数据文件。而其他已经达到大小限制的文件成为老数据文件。
数据结构
哈希存储引擎：基于哈希表结构，在内存中存储了主键和value的索引信息，磁盘文件中存储了主键和value的实际内容。内存中存储file_id、value_pos、value_size.通过读取file_id对应的value_pos开始的value_size个字节，这样就得到了最终的value值。
定期合并
bitcask的记录删除或更新后，原来的数据为垃圾数据。为了解决这些数据，它会定期做合并（compaction）来实现垃圾回收。所谓合并，就是把老数据文件中的数据重新扫描一遍生成新的数据文件，把同一个key的记录只保留最新的，这样新数据文件里就没有冗余数据了。
快速恢复
bitcask的索引信息存储在内存中，服务器断电重启后需要重建索引表：需要重新扫描磁盘上的数据文件来重建索引表，这个过程很耗时，为了提高效率，bitcask通过索引文件来提高速度，也就是把内存中的索引表转储的磁盘中，这样只需一行行读取索引文件中的数据重建即可，大大减少了重启后的恢复时间
6B树存储引擎
Mysql InnoDB按照页面（Page）来组织数据，每个页面对应B+树的一个节点。其中，叶子结点保存每行的完整数据，非叶子节点保存索引信息。
LSM树存储引擎
将对数据的修改增量保存在内存中，达到指定的大小限制后将这些修改操作批量写入磁盘，读取时需要合并磁盘中的历史数据和内存中最近的修改操作。LSM树的优势是有效规避磁盘随机写入问题，但读取时可能需要访问更多的磁盘文件。
6问题
- ESSD的三副本是否在同一个机架上？
- ESSD的增删改读流程
- 对ESSD来说什么是垃圾数据，或者说什么样的数据需要GC？
