36 | 业务状态与存储中间件
许式伟
该思维导图由 AI 生成，仅供参考
你好，我是七牛云许式伟。
相比桌面程序而言，服务端程序依赖的基础软件不只是操作系统和编程语言，还多了两类：
负载均衡（Load Balance）；
数据库或其他形式的存储（DB/Storage）。
存储在服务端开发中是什么样的一个地位？今天我们就聊一下有关于存储中间件的那些事情。
业务状态
让我们从头开始。
首先我们思考一个问题：桌面程序和服务端程序的相似之处在哪里，不同之处又在哪里？对于这样一个开放性的问题，我们不同人可能有非常不同的答案。
今天让我们从数据的视角来看这个问题。
我们知道，一个桌面程序基本上是由一系列的 “用户交互事件” 所驱动。你可以把它理解为一个状态机：假设在 i 时刻，该桌面程序的状态为业务状态i ，它收到用户交互事件i 后，状态变化为业务状态i+1 。这个过程示意如下：
业务状态i+1 = F( 用户交互事件i ，业务状态i )
用状态转换图表示如下：
那么，服务端呢？
仔细考虑你会发现，其实服务端程序可以用一模一样的模型来看待。只不过它不是由 “用户交互事件” 来驱动，而是由 “网络 API 请求” 所驱动。
你同样可以把它理解为一个状态机：假设在 i 时刻，该服务端程序的状态为业务状态i ，它收到网络 API 请求i 后，状态变化为业务状态i+1 。这个过程示意如下：
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
服务端开发中的存储扮演着重要角色，与桌面程序相比，服务端程序依赖于负载均衡和数据库或其他形式的存储。服务端程序可以被视为一个状态机，由网络API请求驱动，但最大的区别在于业务状态的表示方式。桌面程序的业务状态通过内存中的数据结构表示，而服务端程序需要可靠的持久化存储来保证数据不丢失。存储中间件的出现极大地提升了服务端开发效率。随着互联网的普及，对存储中间件的容灾级别要求也越来越高，需要实现多机相互热备、规模可伸缩以及跨机房容灾的数据灾备方案。因此，存储在服务端开发中的地位是至关重要的，它不仅影响着数据的可靠性，还直接关系到服务端程序的性能和稳定性。数据库并不能解决所有服务端程序的业务状态持久化需求，因此存储中间件的种类是不可枚举的，但它们都是服务端开发的关键组成部分。存储中间件的出现解放了生产效率，也是服务端的性能瓶颈所在。存储中间件至关重要，它不仅极大地解放了生产效率，也是服务端的性能瓶颈所在。几乎所有服务端程序扛不住压力，往往都是因为存储没有扛住压力。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《许式伟的架构课》，新⼈⾸单¥68
《许式伟的架构课》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(28)
- 最新
- 精选
- 有铭补充一下：第一个数据库的头衔并不能戴在IBM System R上，它只是第一个广为人知的关系数据库模型。在关系模型之前，也会有其他的模型。1966年IBM就开启了一个数据库项目：IBM Information Management System，简称IMS。IMS用的是一个层次模型。和关系模型里面完全摊平的表结构不一样，层次模型里面的数据有层次的概念。某种程度上来说，你可以理解为比较像类似今天MongoDB这样的文档数据库，或者某种形态的图数据库。这个简称为IMS的系统1968年发行了第一个版本。大企业蜂拥而至。卖的不是一般的好。而且奇迹一般的，到今天还有很多的客户跑在IMS上，这个古董堪称生命力顽强。 然后此时要提到一个关键人物：Edgar Frank Codd，英格兰人，早年学习数学和化学。二战时候是飞行员。二战后来到美国给IBM服务。后来因为美国麦卡锡风潮辗转去了加拿大。之后又回美国IBM工作，顺便去密西根大学拿了一个PhD。Edgar Codd的PhD做的是冯诺依曼架构计算模型的扩展，非常的理论。1970年在加州圣何塞硅谷实验室里工作的他公开发表了一篇论文：A Relational Model of Data for Large Shared Data Banks。翻译成中文就是一个为大容量共享数据银行设计的数据的关系模型，提出了数据的关系模型，也就是著名的关系代数。 Edgar Codd最初提出关系模型的时候，他以为好日子很快就要到来了。但是IBM并不是很愿意去实现这个模型，IBM对Edgar Frank Codd的关系模型的态度很暧昧：不拒绝，不反对，但是也不给钱做系统。现在回头去看究其原因是怕影响了自己已经有的IMS这个层次模型数据库的钱。 但是，Codd也是一个非常顽强的人，他就去找IBM的大客户，给大客户们洗脑说关系数据库才是未来，层次是过去。大客户们被洗的都信了关系代数神教以后就回头找IBM，说赶紧给爸爸们做一个关系数据库出来。IBM不怕Codd，但是经不住客户金主爸爸们反复要求，就在自己的Future System里加了一个新的研究对象：System R。Future System项目是IBM1970年前后开展的一个大型研究项目，为的是开发出革命性的新软件和硬件——从名字就可以看出这东西本质是想做一个“系统”，而不是现在意义上的“数据库软件”。当时如日中天的IBM可谓浩浩荡荡的撒钱。System R团队成立于1973年。里面包括了后来很多在数据库圈里声名显赫的人，包括后来的图灵奖获得者Jim Gray。当然，也不知道IBM怎么想的，IBM把System R团队和Codd给隔离开来了。 可以看出直到现在IBM还是看关系模型不顺眼，但是很快的，加州伯克利大学的Ingres（这就是后来著名的PostgreSQL的前身），以及甲骨文在1978年开始入场。IBM这才发现大势所(不)趋(妙)，加快研发速度搞出了DB2，随后Ingres商业化，甲骨文发布oracle加入竞争。关系数据库至此广泛的出现在大众视野面前
作者回复: 多谢补充
2019-08-27333 
skye老师,为啥数据库叫中间件？数据最后才存数据库里的呀作者回复: 我自己是习惯把所有操作系统之上应用程序之下的都叫中间件。
2019-10-26221
诗泽老师今天讲的存储即数据结构可以这样理解：类比于桌面程序，服务端的系统状态也是存储于某些数据结构中，通过持久化这些数据结构来持久化服务的状态，这样服务重启或者扩容的时候可以利用这些数据来恢复服务状态，而存放持久化数据的存储系统即可被认为是内存外的数据结构。内存类型的数据结构有list map set 等，对应的内存外的数据结构类型有kv数据库，关系型数据库，对象储存，倒排索引等即“元数据结构”作者回复: 👍
2019-08-2720
williamcai老师，消息队列不是消息中间件里么，为啥属于存储中间件作者回复: 消息中间件是从功能来说的，存储中间件是从分类来说。
2019-08-296
靠人品去赢老师，这个把存储中间件看成一个元数据结构，举个例子：数据库是不是我可以看成是一个B+树结构的元数据结构，是不是这意思？作者回复: 不需要看实现，我们看使用界面（接口）。接口是什么数据结构，就认为是什么数据结构。
2019-08-276
逆流的鱼不明白服务端为什么比桌面程序实现kv更难，我理解桌面端能在内存那是因为服务端帮他实现了吧，区别不应该在一个是单用户的数据量级和全量数据的区别吗？作者回复: 是质量要求的差别
2019-09-053
humor文中说的分布式数据库是什么概念呢？我理解的数据库应该是有状态的，不能像业务服务器一样任意伸缩，如果数据库要伸缩的话，肯定是需要手工迁移数据的作者回复: 分布式数据库是自动迁移的
2019-08-2822
leslie老师今天的课回答了之前的之前上堂课问老师的问题：其实均衡是各个存储中间件的平衡；老师提到了持久化，可是目前业界大量的不落地或者为了数据的一致性定期落地。 存储中间件对于硬件所在的位置不同：MQ主要是基于PageCache、内存库主要其实访问的是内存、传统数据库其实不少时候还是在硬盘；几者之间的平衡性把握如何把握。 目前就是生产碰到困惑：关系型数据库无法满足现状，追加了内存库可是效果不是很好，目前在极客时间学习《消息队列高手课》，希望跟着老师学完后能找到一些思路；希望老师在下节课讲数据库时能把消息队列、内存库、关系型数据库同时结合分享一下老师的经验。作者回复: 多谢建议
2019-08-271
sam“存储中间件”从名字看来，我的理解是对数据库读写的公共层API封装，为何是 “元数据结构”不是很了解作者回复: 数据库只是一种存储中间件
2019-08-271
喆里几乎所有服务端程序扛不住压力，往往都是因为存储没有扛住压力。----这个怎么理解？ 实际中，有很多情况是cpu打满了，但是memory和io都正常；还有对于机器学习的模型训练来说，瓶颈也在cpu啊作者回复: 嗯，我是的是IT型业务，新兴的DT型业务不在此列
2020-04-25
收起评论
