大规模分布式存储系统笔记一

好玩的分布式笔记一

概述

目前分布式两个特点：一个特点是规模大（大量机器），另一个特点成本低（小型机）。
为什么要引入分布式的技术呢？企业要做大，流量要做大，逼着分布式技术在互联网应用，而且越来越压榨机器的性能。本篇只是引入一个分布式的话题，有兴趣的小伙伴可以跟着我探索下，博主立下flag，每周至少一篇更新。

分布式存储数据需求

非结构化数据(比如图像、音频、视频、图片、文档)
结构化数据（关系型数据）
半结构化数据(html，可以看出模式结构和内容混在一起)

常见分布式存储系统

A.分布式文件系统
B.分布式键值系统
C.分布式大表系统（Google Bigtable，Hadoop Hbase）
D.分布式数据库（Mysql sharding）
E.分布式文档系统 (mongodb)

番外：分布式理论

CAP理论

一致性C、可用性A、分区容错性P

大家应该都明白可用和一致是冲突的，你无法在保证各分区数据一致的情况下，又正常响应，因为同步数据总需要一定的时间。目前的分布式系统一般不能放弃P，也就是放弃扩展，违背系统设计原则。

所以这里常见的有CP系统和AP系统
CP：在数据一致性要求比较高的场合(譬如如:zookeeper,Hbase) 是比较常见的做法，一旦发生网络故障或者消息丢失，就会牺牲用户体验，等恢复之后用户才逐渐能访问。
AP：NoSQL中的Cassandra 就是这种架构。跟CP一样，放弃一致性不是说一致性就不保证了，而是逐渐的变得一致。后面的Base理论会介绍最终一致性。

Base理论

Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）

基本可用
响应时间上的损失：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。甚至采取限流（我们可以理解为只让一部分用户访问到，另一部分不响应直接给403，当然你也可以给404）使网站在高峰期不会崩溃。
功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。另外像熔断技术hytrix是在分布式服务中防止下游服务崩溃导致上游请求积累也跟着崩溃。要不然也不会有后来的链路追踪系统来查看整个服务链每个节点的健康状况，有点扯远了。

软状态
允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

最终一致性
上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。
Base理论的核心还是着重在最终一致性，这里有：因果一致性，读己之所写，会话一致性，单调读一致性，单调读一写性，这里我讲下会话一致性，我举个反例大家应该就明白了，你用Navicat Premium 连接了MongoDB 分片服务，我更改了某个值，然后我刷新一下还是原值，这会很奇怪的吧，这是bug吧？没有出现这种情形那就是会话一致性在起效果。其他的特性都是合乎正常思考逻辑的，不明白的可以再查阅更多资料。
Base解决多机协调工作问题，Java的volatile与内存模型及锁机制解决多CPU协调工作问题，这里只作个联系，只给个小建议，大家可以联系着学习。

一致性协议(2pc)

一致性算法(Paxos)

一致性算法(ZAB)

一致性算法(Hash)

番外：分布式服务框架

分布式服务框架理论

dubbo悄然出现

spring cloud 崭露头角

总结

本章只是作为开篇，下篇我们展开叙述各家之所长，谢谢！

大规模分布式存储系统笔记二