后台架构设计—数据存储层

                                  后台架构设计—数据存储层

来源：http://www.cnblogs.com/xiwang6428/p/6060138.html

数据存储重要性：

• 数据是企业最重要的财产；

• 数据可靠性是企业的命根，一定要保证。

单机存储原理：

• 存储引擎：存储系统的发动机，它决定存储系统的功能和性能；

• 引擎类型：哈希存储引擎、B树存储引擎、LSM存储引擎

  • 哈希存储引擎：基于哈希表结构 ：数组+链表；支持Create\Update\Delete\随机Read

  • B树存储引擎：基于B Tree实现，支持单条记录的CURD，支持顺序查找。RDBMS使用较多。

  • LSM树存储引擎：对数据的修改增量保存在内存，达到一定条件再批量更新到磁盘；优势在于批量写入；劣势在于读取需合并磁盘和内存；

    • 避免内存数据丢失：修改操作写入到CommitLog日志。

数据模型：

1. 文件：以目录树组织，如linux,mac,windows；

2. 关系型：每个关系是一个表格，多行组成，每行多列；

3. 键值(Key-Value)：Memcached, Tokey, Redis；

4. 列存储型：Casadra, Hbase;

5. 图形数据库：Neo4J, InfoGrid, Infinite Graph

6. 文档型：MongoDB, CouchDB

事务与并发控制：

• 事务4个基本属性：ACID 原子性、一致性、隔离性、持久性

• 并发控制：

  • 锁粒度：Process->DB->Table->Row

    • 提供Read并发，Read不加锁：写时复制、MVCC

•     数据恢复：通过操作日志
  

多机存储原理：

• 单机存储原理在多机存储仍然可用；多级存储基于单机存储；

• 数据分布：

  • 分布在多个节点，节点间负载均衡；

  • 分布方式：

    • 静态：取模、uid%32；

    • 动态：一致性hash，数据飘移问题（A节点更新前出现故障，更新迁移到B节点后A节点又恢复）；

  • 复制：

    • 分布式存储多个副本；保证高可靠和高可用；Commit Log。

  • 故障检测：

    • 心跳机制、数据迁移、故障恢复；

FLP定理与设计：

• FLP Impossiblity（FLP不可能性）:

  • 在异步消息通信场景，即使只有一个进程失败，没有任何方法能保证非失败进程达到一致性。

CAP定理与设计：

• CAP：一致性（Consistency）、可用性(Availabilty)、分区容忍性(Tolerance of network Partition)。

• 一致性和可用性需要折中权衡

• 分布式存储系统需要能够自动容错，也就是说分区容忍性需要保证。

2PC（Two Phase Commit）协议与设计：

• 用于分布式事务;

• 两类节点组成：

  • 协调者（1个）；

  • 事务参与者（多个）；

• 分两阶段：

  • 请求阶段：协调者通知参与者准备提交或取消事务，所有参与者都需要表决同意或者不同意。

  • 提交阶段：

    • 收到参与者所有决策后，协调者进行决策（提交或取消）；

    • 通知参与者执行操作，所有参与者都同意就提交，否则取消；

    • 参与者收到协调者的通知后执行操作。

    2PC协议是阻塞式：

• 事务参与者可能发生故障

        --设置超时时间；

• 协议者可能发生故障
  

      --日志记录、备用协调者

• 应用：交易订单 等；

Paxos协议与设计：

• 作用：

  • 解决节点间的一致性问题；

  • 主节点宕掉，则选择新节点；

  • 主节点常以操作日志的形式同步备节点。

• 分两种角色：提议者(Prpposer)、接受者(Acceptor)；

• 执行步骤：

  • 批准：Proposer发送accept消息给Accepter要求接受某个提议者；

  • 确认：超一半的Accepter接受，则提议值生效，Proposer发送acknowledge消息通知所有的Accepter提议生效。

• 与2PC比较：：

  • 2PC协议保证多个数据分片上操作的原子性；

  • Paxos协议保证一个数据分片多个副本之间的数据一致性；

• Paxos协议用法：

  • 实现全局的锁服务或者命名和配置服务；

    ---Apache Zookeeper

  • 将用户数据复制到多个数据中心；

    ---Google Megastore

数据存储层冗余：

• 多个副本，实现访问的高可用性。

• 如何实现： 

  • 数据复制：

    • 基于日志；

    • Master-Slave：mysql\MongoDB

    • Replic Set:MongoDB

  • 双写：

    • 存储层多主对等结构；比较灵活，但数据模块层成本较高；

• 数据备份：

  • 冷备份：

    • 定期将数据复制到某个存储介质，是传统的数据保护手段；

    • 优点：简单、廉价，技术难度低；

    • 缺点：定期存在数据不一致；恢复数据时间长；

  • 热备份：

    • online备份；提供更好的高可用性；

    • 异步热备份：

      • 从主存储写入即返回给应用端，由存储系统异步写入其他副本；

  • 同步热备份：

    • 多份数据副本写入同步完成，无主从之分；

    • 为提高性能，应用程序并发写入；

    • 响应延迟是最慢的那台服务器；

数据存储层失效转移机制：

• 失效确认：是否宕机、心跳；

• 访问转移：访问路由到非宕机机器；存储数据完全一致；

• 数据恢复：主从、日志；

版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢。

-END-