tag: Redis

Redis 是我遇到过的最强大、最通用的技术之一。遗憾的是，大多数人都只是将其作为一个优秀的缓存解决方案来使用。 为此，我们需要去改变这个现状。 我特别想通过本文告诉你，如何构建一个以 Redis 为核心的响应式架构。尤其是当你因为一些其它的需求（比如高性能的缓存）已经将 Redis 作为你整个应用基础设施的一部分时，这会是一个巨大的优势。 我在本文所描述的内容，你可以按照自己的想法采取各种手段来实现，说实话，在这一点上任何选择都是有效的。出于个人观点，我更倾向于使用 Node.js，但这也只是我自己的想法，你可以选择最适合你的方案。 构建一个响应式架构 首先要了解的问题是什么是响应式架构，以及为什么我们要构建一个响应式架构而不是采用其他更传统的方案？ 简单来说，一个响应式架构就是让每一个逻辑都在满足所有预设条件的情况下被执行 —— 我想我应该给 “简单” 这个词加一个引号。 换个其他的说法：为了让你的逻辑在某个特定事件发生后被触发，通常会有两种实现方案： 定期检查某种标志，直到它被打开，这意味着事件发生。 停下来等待，直到某个东西通知你的服务，事件被触发。 第二个是面向对象编程中观察者模式的关键。被观察的对象让所有订阅其内部状态的人知道它更新了。 我们在这里要做的是，将这种来源于面向对象（OOP）的设计模式推导到架构级的设计中。因此，这里我所谈及的不是程序内的一些逻辑，而是架构级别的，一旦触发响应条件，就运行某项服务。 这是分配和扩展平台最有效的方式，原因在于： 你不必浪费时间和流量去轮询一个特定数据源的标志（或任何你觉得应该轮询的东西）。此外，如果你使用的基础设施是按流量付费的，不必要的轮询可能会产生额外的费用，在目标服务上增加不需要的工作，如果在你的代码等待轮询的时间里发生了多个事件，你最终可能还需要聚合这些事件。 你可以通过增加新的服务，并行工作，并以尽可能快的速度捕捉事件，来增强服务的处理能力。 平台更加稳定。通过响应式工作，你可以确保你的服务以最佳速度运行，而不必担心由于客户的数据过载而崩溃。 响应式架构本质上是异步的，所以任何试图与之交流的客户端应用，也需要适应相同的响应范式。你可以通过 HTTP 得到一个来自外部的 REST API，但是你得到的响应结果可能并不是你想要的答案。例如，你可能会得到一个 ”200 OK“ 的响应，意味着你的请求已经收到。为了让你的应用程序得到实际的结果，它必须订阅包含这种响应的特定事件。 请记住这一点，否则，你可能会花很长时间来调试为什么没有得到你想要的响应结果。 接下来我们需要什么？ 既然如此，我们需要什么来使我们的平台/架构成为一个响应式的平台/架构呢？可以肯定的是，这不是 ReactJS。我们需要一个消息代理，一个能在多个服务之间集中分配消息的东西。 对于可以充当代理的东西，我们需要确保我们的代码知道它在哪里，以及他所需要的事件类型，以此来确保订阅到某些事件。 在此之后，一个通知将被发送到我们的服务，同时触发我们的业务逻辑。 听起来是不是很容易？那是因为它本就如此！ 那么 Redis 是如何发挥作用的呢？ Redis 不仅仅是一个存储在内存上的键值对存储引擎，事实上，它有三个我喜欢的特性，也正因如此，我才愿意使用 Redis 来搭建基于不同预期行为的响应式架构。 这三个特点分别是： 发布/订阅。Redis 内部维护着一个消息队列，它允许我们发送消息，并将它们分发到每个订阅的进程。这是一种“发后即忘”类型的约定，这意味着如果没有在线的监听器，那么消息就会丢失。所以在使用时要考虑到这一点。 键空间通知。这可能是 Redis 中我最喜欢的功能。他们是由 Redis 自己创建的事件，并分发给每个决定订阅它们的进程。这个功能和键空间的变化有关，也即存储在 Redis 里面的数据发生的任何变化。例如，当你删除或更新一个键时，或者当它的 TTL 计数器达到 0 自动删除时。这使你能够设定有时间限制的事件。比如说，你是否曾经需要在 “某事 “发生 3 天后触发一点逻辑？通过这种方法就可以实现。 Redis 流。这是 Redis 数据类型的混合物，混合了键空间通知和发布/订阅，所有这些都放在一起，工作得很好。Redis 流试图模仿 tail -f 命令在你的终端上的行为。如果你从来没有见过这个命令，说明这是一个*nix 命令，它向你显示一个文件的最后一行，并保持监听该文件的变化，每新增一行时，终端会立即显示。Redis 流也是同样的道理。如果使用得当，那么将会是一个强有力的工具。你可以阅读此处了解更多。 所有这些特性都使得你可以以各种方式与你的业务逻辑进行适配，根据你所期望的行为类型，解决其中的一个或全部。...