前言

服务端开发, 绕不过存储这个话题.那么存储在服务开发中是什么样的一个地位? 今天我们来聊一下关于存储中间件的那些事情

业务状态

服务端的业务状态, 可以理解为它收到网络API请求后, 状态由一个状态转变成了另一个状态, 如下图

服务端程序的业务状态如何表示?用内存中的数据结构可以吗? 答案当然是不能.如果业务状态存储在内存中, 服务端程序一挂, 数据就丢了

之前提到过 服务端的领域特征是大规模的用户请求, 以及24小时不间断的服务

这句话是理解服务端体系架构的核心, 至关重要. 从某种意义上来说更为重要的原则是: 坚决不能丢失用户的数据, 即他认为已经完成的业务状态

服务端对用户来说是个黑盒, 既然用户收到某个“网络API请求”成功的反馈, 那么他会认为这个成功是确认的. 所以服务端必须保证其业务状态的可靠性

在没有存储中间件的情况下, 服务端需要自己在响应完每一个网络API请求之后, 对业务状态进行持久化.这会很复杂.如果每一个做服务端程序的开发人员需要考虑如何持久化业务状态, 这个代码显然过高了.

于是, 存储中间件就应运而生了.

容灾级别, 随着互联网的普及, 我们对它的要求越来越高.

首先, 单机数据库是不够的, 需要多机相互热备. 这就是数据库主从结构的来由.

其次, 单机数据库是不够的, 单机存储量终归有上限, 这样我们服务的用户数就有上限. 在分布式数据库出现前, 人们的解决方案是手工的分库分表. 总之, 业务上我们需要做到规模可伸缩, 不必担心单机无力存储容量的限制

最后, 单机房的可靠性也是不够的, 机房可能会出现网络终端, 极端情况可还可能因为自然灾害, 如地震,导致整个机房的数据丢失. 于是出现了“两地三中心”, 跨机房容灾的数据灾备方案

那么问题来了, 数据库能够解决所有服务端程序的业务持久化需求吗?

答案是不能的.

存储中间件是”元数据结构“, 即数据结构的种类是非常有限的. 有了这些基本的数据结构, 所有的业务需求都可以高效地实现

我们今天接触的存储中间件有哪些? 不完整的列表如下:

坚决不能丢失用户的数据, 即他认为已经完成的业务状态

存储即数据结构. 存储中间件就是“元数据结构”

此文章为3月Day4学习笔记, 内容来源于极客时间《许式伟的架构课》, 强烈推荐该课