许式伟的架构课
许式伟
七牛云CEO
立即订阅
20092 人已学习
课程目录
已更新 72 讲 / 共 77 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师?
免费
基础平台篇 (21讲)
01 | 架构设计的宏观视角
02 | 大厦基石:无生有,有生万物
03 | 汇编:编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读:如何实现可自我迭代的计算机?
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备:交互的演进
11 | 多任务:进程、线程与协程
12 | 进程内协同:同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络:连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理:数字世界的守护
17 | 架构:需求分析 (上)
18 | 架构:需求分析 (下) · 实战案例
19 | 基础平台篇:回顾与总结
加餐 | 我看Facebook发币(上):区块链、比特币与Libra币
加餐 | 我看Facebook发币(下):深入浅出理解 Libra 币
桌面开发篇 (16讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发:浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战(一):怎么设计一个“画图”程序?
27 | 实战(二):怎么设计一个“画图”程序?
28 | 实战(三):怎么设计一个“画图”程序?
29 | 实战(四):怎么设计一个“画图”程序?
30 | 实战(五):怎么设计一个“画图”程序?
31 | 辅助界面元素的架构设计
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师,我需要成为“全才”吗?
32 | 架构:系统的概要设计
33 | 桌面开发篇:回顾与总结
服务端开发篇 (14讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战(一):“画图”程序后端实战
42 | 实战(二):“画图”程序后端实战
43 | 实战(三):“画图”程序后端实战
44 | 实战(四):“画图”程序后端实战
45 | 架构:怎么做详细设计?
46 | 服务端开发篇:回顾与总结
加餐 | 如何做HTTP服务的测试?
服务治理篇 (11讲)
47 | 服务治理的宏观视角
48 | 事务与工程:什么是工程师思维?
49 | 发布、升级与版本管理
50 | 日志、监控与报警
加餐 | 怎么保障发布的效率与质量?
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇:回顾与总结
架构思维篇 (9讲)
57 | 心性:架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣?
59 | 少谈点框架,多谈点业务
60 | 架构分解:边界,不断重新审视边界
加餐 | 实战:“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
63 | 接口设计的准则
许式伟的架构课
登录|注册

38 | 文件系统与对象存储

许式伟 2019-09-03
你好,我是七牛云许式伟。
存储系统从其与生俱来的使命来说,就难以摆脱复杂系统的魔咒。无论是从单机时代的文件系统,还是后来 C/S 或 B/S 结构下数据库这样的存储中间件兴起,还是如今炙手可热的云存储服务来说,存储都很复杂,而且是越来越复杂。

异常处理才是存储的业务逻辑

存储为什么会复杂,要从什么是存储谈起。
让我们简单回顾一下 “36 | 业务状态与存储中间件” 的核心逻辑。
存储这个词非常平凡,存储 + 计算(操作)就构成了一个朴素的计算机模型。简单来说,存储就是负责维持计算系统的状态的单元。从维持状态的角度,我们会有最朴素的可靠性要求。
比如单机时代的文件系统,机器断电、程序故障、系统重启等常规的异常,文件系统必须可以正确地应对,甚至对于磁盘扇区损坏,文件系统也需要考虑尽量将损失降到最低。
到了互联网时代,有了 C/S 或 B/S 结构,存储系统又有了新指标:可用性。为了保证服务质量,那些用户看不见的服务器程序必须时时保持在线,最好做到逻辑上是不宕机的(可用性 100%)。
服务器程序怎么才能做到高可靠、高可用?
答案是存储中间件。没有存储中间件,意味着所有的业务程序,都必须考虑每做一步就对状态进行持久化,以便自己挂掉后另一台服务器(或者自己重启后),知道之前工作到哪里了,接下去应该做些什么。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(19)

  • Geek_88604f
    说到hdfs的文件块,首先看看为什么用块来管理而不用文件。因为块有如下优势:单文件的大小不会受到单节点容量的限制,文件的不同的部分可以存储到不同的节点上;容易对数据进行备份提高容错能力,可以按快来备份;可以按照块来并发处理提高吞吐量。从整体上来看简化了存储系统的设计,一是按照块来设计可以很容易地估算出一个节点可以存出多少文件块;二是方便元数据管理,元数据可以和文件块分开存储,我理解桌面存储系统下的树形结构是做不到的。
            那么块设置过小有什么不良影响呢?大概有以下几个影响:文件过小导致磁盘随机寻址操作变多,从而影响磁盘效率;网络开销也随之增大;元数据增多Namenode很快达到瓶颈;处理任务的task不断的启动、销毁,效率低下。
            但是也不能一味的往大里设置,过大也会带来不良影响:数据块越大数据加载时间越长,系统恢复过程也越长;监控方面的预设时间间隔和数据量有关;数据块越大对算法也是一个挑战。
            需要特别说明的是当文件大小小于块大小时,它占用的空间是小文件的实际大小,并非快的大小。hdfs对小文件是做了一些优化的,例如:hadoop archive、sequence file、combinefileinportformate。

    作者回复: 多谢补充

    2019-09-05
    6
  • Geek_88604f
    非结构化和结构化数据的键值存储,实现机制上往往有极大的差异。主要体现在哪些方面,许老师?

    作者回复: 主要还是因为值大小差异非常大,导致两者优化目标不同。对象存储的第一优化目标是低成本,结构化键值存储的优化目标是高iops,方向完全不同。

    2019-09-03
    2
  • 诗泽
    想到了Facebook 那篇关于小图片存储的论文🤣
    2019-09-03
    2
    2
  • Aaron Cheung
    存储这块是七牛的业务强项 从许老师这里学习了 38
    2019-09-03
    2
  • ch
    gfs和ec那部分对比计算出38%应该是ec(28+4)/gfs(28*3)=32/84。感觉这样表述直观点。
    2019-09-15
    1
  • 安排
    对象存储底层实现时还会经过操作系统自带的文件系统吗?还是说对象存储操作的直接是裸盘?相当于自己重新实现了文件系统功能?

    作者回复: 对象存储有一些是基于裸盘,有一些基于文件系统。推荐是前者。

    2019-09-06
    1
  • yga
    假设集群总的容量规模不变,但我们不是增加单台机器的磁盘数量,而是增加磁盘的密度。比如,我们把单盘容量增加一倍,那么我们集群的磁盘数也减少一半。这样我们的修复时长 T0 会变成 4T0(修复时间和要修复的数据量成正比,和集群可用的磁盘数成反比)——
    T0怎么变成4T0?修复时间和数据量成正比,和集群可用磁盘数成反比。为什么呢,希望老师能解答

    作者回复: 因为磁盘容量变大一倍,要修复的数据量变大一倍,而系统的总磁盘数减半,所以最终修复时间需要4倍。

    2019-09-06
    1
  • EidLeung
    “第一,HDFS 的 block 大小为 64M,如果文件不足 64M 也会占用 64M。”这句话有问题吧,HDFS的问题是文件的元数据存储在内存中,因此不适合小文件。不足64M(现在好像是128M了吧)的小文件在HDFS中存储只是在磁盘多了一些元数据信息而已,文件大小还是原来的大小啊。

    作者回复: 多谢补充,对hdfs的近况了解的确不多

    2019-09-03
    1
  • JACK
    36.5是怎么算出来的?麻烦再讲解一下,谢谢!

    作者回复: 32/28=1.14
    1.14/3=36.5%

    2019-09-03
    1
    1
  • 杜建平
    成本与持久性这块,还挺烧脑的!
    2019-11-27
  • zhuyc
    对象存储消除了结构化的关系和影响,那么对象间的关系,例如 原图与缩略图 的关系,是维护在另一个系统中吗?

    作者回复: 通过命名对应,或者在另外的关系型存储中记录

    2019-09-13
  • 醉雪飘痕
    许老师好,
    假设 RAID5 的数据修复时间是 1 天(实际上往往做不到,尤其是业务系统本身压力比较大的情况下,留给 RAID 修复用的磁盘读写带宽很有限),这种方案单机的可靠性大概是 100 年丢失一次数据(即可靠性是 2 个 9)。
    请问这个100年是怎么算出来的?
    2019-09-06
  • 歌在云端
    像老师请教一个问题,对象存储是怎么持久化到硬盘的?也是序列化之后存吗?请问一下跟文档型数据库类似MongoDB有什么区别
    2019-09-06
  • 安排
    结构化数据和非结构化数据啥区别啊?表结构就是结构化数据吗?

    作者回复: 主要是数据类型不一样。非结构化数据主要是图片、视频、应用日志等。表结构是结构化的。

    2019-09-06
  • williamcai
    mc冗余码,数据切成28片➕4份冗余,这4分冗余那些数据

    作者回复: 是算术结果。Yi = Fi(X1, X2, ..., X28), 其中 i = 1..4。

    2019-09-04
  • coyang
    在分布式系统中维护文件系统的目录树结构,会遭遇诸多难题。所以 HDFS 想把 Master 扩展为分布式的元数据集群并不容易。->GlusterFS就是分布式的元数据集群,没有master,active/standby的概念。实现也很复杂。许老师能不能说一下未来分布式存储的趋势?个人感觉分布式文件系统还会长期保留来适应老的application迁移到分布式系统不用做任何改变。

    作者回复: 是的,老 application 不消亡,文件系统在服务端就会一直存在。

    2019-09-04
  • 靠人品去赢
    对象存储学到了,但是文件系统,路径,文档这些概念已经习惯有时候转不过来,突然你说这是个对象可能理解不了,觉得这不就是一个IO流写入的文件吗。
    还有提高磁盘密度对持久化有影响,是不是我可以理解像机械硬盘叠瓦式(支持磁道可重叠,提高单盘容量),固态(一个单元储存的byte越来越多,QLC,PLC都要出来了)是不是都是,不仅修复难而且掉盘率搞,读写速度感人,这些硬件的影响。

    作者回复: 1、对象存储这个名字仅仅是名字,不要太想对象两个字代表什么。
    2、持久性的探讨只是定性分析,这块不是我们讨论的重点。

    2019-09-03
  • 有铭
    老师,你提到七牛云的对象存储是没有目录这个概念的;我记得阿里的oss是有的,也就是说,两者的实现原理并不一样?

    作者回复: 阿里也没有,目录是模拟出来的,这一点所有对象存储都一样。在七牛之间中也可以模拟出目录概念,但是它和真实的目录差别非常大。

    2019-09-03
    2
  • Geek_88604f
    假设集群总的容量规模不变,我们把单台机器的磁盘数量增加一倍,那么我们需要的机器数量减少一半。但由于磁盘数量不变,我们的修复时长 T0 也不变(假设网络和 CPU 计算力都不是瓶颈)。假设原本丢失数据的概率是 p,那么现在丢失数据的概率还是 p。——这个描述是不是有些小问题?前半段说磁盘数量增加一倍,后半段又说磁盘数量不变。

    作者回复: 后面描述过于含糊,应该是:但由于集群的磁盘数量不变

    2019-09-03
收起评论
19
返回
顶部