数据是企业最重要的财产; 数据可靠性是企业的命根,一定要保证。 单机存储原理: 存储引擎:存储系统的发动机,它决定存储系统的功能和性能; 引擎类型:哈希存储引擎、B树存储引擎、LSM存储引擎 哈希存储引擎:基于哈希表结构 :数组+链表;支持Create\Update\Delete\随机Read B树存储引擎:基于B Tree实现,支持单条记录的CURD,支持顺序查找。RDBMS使用较多。 LSM树存储引擎:对数据的修改增量保存在内存,达到一定条件再批量更新到磁盘;优势在于批量写入;劣势在于读取需合并磁盘和内存; 避免内存数据丢失:修改操作写入到CommitLog日志。
数据模型: 文件:以目录树组织,如linux,mac,windows; 关系型:每个关系是一个表格,多行组成,每行多列; 键值(Key-Value):Memcached, Tokey, Redis; 列存储型:Casadra, Hbase; 图形数据库:Neo4J, InfoGrid, Infinite Graph 文档型: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备份;提供更好的高可用性; 异步热备份: 从主存储写入即返回给应用端,由存储系统异步写入其他副本; 同步热备份: 多份数据副本写入同步完成,无主从之分; 为提高性能,应用程序并发写入; 响应延迟是最慢的那台服务器; 数据存储层失效转移机制: 失效确认:是否宕机、心跳; 访问转移:访问路由到非宕机机器;存储数据完全一致; 数据恢复:主从、日志; (责任编辑:admin) |