当今许多广泛使用的数据库系统是在一个公司在整个企业中采用单个数据库的时代开发的。这个单一的数据库系统将在一个地方存储和运行企业的所有功能。您可以想象一下：一个房间里摆满了冰箱大小的机器，许多房间都装有超大型的盘式磁带驱动器。
但是Redis的发展与许多其他流行的数据库系统不同。Redis建于NoSQL时代，是一个灵活而通用的数据库，专门设计用于不麻烦的存储大量数据，这些数据大部分是空闲的。微服务体系结构具有相关的目标：每种服务都旨在满足特定的用途，而不是运行业务中的所有内容。
Redis旨在存储经常更改和移动的活动数据，其不确定的结构没有关系的概念。Redis数据库占用空间小，即使使用最少的资源也可以提供巨大的吞吐量。同样，微服务体系结构中的单个服务仅与该服务专用的输入和输出以及数据有关，这意味着Redis数据库可以支持各种不同的微服务，每个微服务都具有自己的数据存储。这很重要，因为拥有许多服务的本质意味着每个服务必须尽快执行以弥补服务间通信带来的连接和延迟开销。
基于Redis的微服务架构描述
微服务体系结构的一个关键特征是每个单独的服务都独立存在-该服务没有与另一个服务紧密耦合。这意味着微服务必须维护自己的状态，并且要维持状态，您需要一个数据库。
微服务架构可以包含数百甚至数千个服务，而开销却是规模的敌人。仅消耗大量资源即可运行的基础架构将削弱微服务架构的优势。
理想情况下，服务数据应与其他数据层完全隔离，从而允许不耦合的扩展和跨服务争用，以节省资源。由于服务是专门为填补单个角色（就业务流程而言）而设计的，因此它们存储的状态本质上是非关系的，非常适合NoSQL数据模型。Redis可能不是微服务体系结构中所有数据存储的一揽子解决方案，但它确实可以满足许多要求。
构建服务后，需要与其他服务进行对话。在传统的微服务环境中，这是使用REST或类似约定在私有HTTP端点上发生的。收到请求后，服务将开始处理该请求。
尽管HTTP方法行之有效并被广泛使用，但还有一种替代的通信方法，即服务在类似日志的结构中进行读写操作。在这种情况下，这就是Redis Streams，它允许一种完全异步的模式，其中每个服务在其自己的流上宣布事件，并且仅侦听属于它感兴趣的服务的流。这时的双向通信是通过两个服务相互观察来实现的。流。
但是，即使在不使用Redis进行存储或通信的服务中，Redis仍然可以发挥至关重要的作用。为了提供低延迟的最终响应，每个服务都必须尽可能快地响应自己的请求，通常超出了传统数据库的性能极限。在这种情况下，Redis充当缓存的角色，其中服务的开发人员决定并非总是需要直接从主数据库检索数据的位置，而是可以更快地从Redis提取数据。
同样，需要通过API访问的外部数据服务也可能太慢了，可以在此处使用Redis来防止不必要且冗长的调用影响系统的整体性能。
