zblogredis的简单介绍

今天给各位分享zblogredis的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、风控系统实践之感: drools 和 redis
• 2、Redis“气急败坏”回击：13 年来，总有人想替 Redis 换套新架构
• 3、redis发布订阅模式

风控系统实践之感: drools 和 redis

需求:

开发一个风控系统，系统包括, 规则引擎和计算引擎, 主要的内容如下:

1. 规则的增删改和实时生效, 规则的分类执行

2. 按照一定的纬度计算累计值，比如按照 IP, 用户 id, 账户 等纬度。

3. 需要支持滑动窗口，滚动窗口，长度窗口等

遇到的问题主要有以下几点:

1. redis 做流计算太过勉强，一是根据业务上的需求，需要统计的key 至少有几亿个，最多也有几十亿个，另外redis 中需要存储少量的交易的信息。估算下来量也是非常可观

2. redis 中 hot key 特别明显，比如按照商户的纬度去统计，如果不对商户的key 进行拆封，像盒马那种流量的商户，对redis 的压力是非常大的。

我们采用的是redis 的cluster 模式，这样的话redis hot key 对redis 影响会更大。对其进行拆分是非常必要的，比如 按照小时拆分。 

3. 流式计算中，一个是乱序导致累加的计算不准确(有负值)，另外一个是消息延迟. 当时我们尝试使用flink 中的水印的概念去解决问题，发现并不适合。这个坑也是我们实践过后才发现的。

最痛苦的经历是乱序和延迟消息的解决，现在是采取纠正的方式解决。

规则引擎

规则引擎我们选用了drools，简单的探索了drools core, drools DRL, drools CEP 等，但是回头看看，针对drools的使用缺点还是很多, 而且很明显，暂时还没有替换的打算. 

1. 使用 drools CEP 如何做分布式? 我们发现drools CEP中的几种窗口都是内存计算的，应用到分布式中就没有很好的办法，几乎做不到，除非drools 也去集成redis等这种分布式缓存。

2. 使用drools 觉得很笨重，因为依赖比较多，二是我们只用到了 drools 中的 if else 等判断，许多其它的功能基本就用不到，因为 1 中解决不了分布式的问题。所以从这点来说drools 已经废了，根本不用在创建kiesession 这种 重量级的东西。

3. drools中支持的运算符不是特别充分，比如像 log 运算，sum, max, avg 这种的运算等都是不支持的. DRL 语言对业务人员来说不是非常的友好。

4. 另外drools 中的 连续，非连续的规则，没有看出来如何配置，至少flink cep 是有这样API的。

综上所描述，不得不吐槽下 drools真是无语，也许了解的很简单，还有别的方式，另外drools workbench 也是很无语，很复杂，估计drools 厂商想通过这种方式挣钱。

总体感觉，如果有别的选择，最好不要选用drools，分布式的问题没有解决，就等于废了，因为各种分布式窗口都需要我们自己去实现。怎么办呢? 

规则引擎最后还是采用了drools，根据具体的业务含义创建不同的kiesession,  drools 起到了if else 判断的作用，至于滚动窗口，长度窗口和滑动窗口都通过redis来做计算。遇到头疼的问题，是

1. 根据不同的统计纬度，大概计算了下，需要几十亿个key，在redis 中做计算

2. 滑动窗口暂时靠 redis的zsort 的数据结构，性能不是非常好

3. 热点key 的问题，特别对于大商户的热点key 的问题，需要做拆分，拆分起来是比较复杂的

4. 消息延迟和消息乱序问题。

所以计算引擎的需求一般是

1. 计算很快，大几百个规则，能够很快的计算出准确的结果来

2. 计算准确率，当面对乱序和延迟消息的时候，如何计算的更加准确

3. 计算的量的问题，正如前面提到的，几十亿个key，另外还需要存储一些信息，计算的中间状态等，如何在redis 中丢失，就会造成计算不准确。

基于以上的问题，关键是如何做的更好，优化的更好，说实话，我没有找到答案，可以做的就是不断的优化redis 计算(暂时不能上大数据，比如flink， spark 等)，减少redis 的操作带来的网络开销。

其实最后还要提一下，如果能采用内存计算，不用分布式计算，会不会速度更快点，比如根据业务来做分片，这样在各个实例统计的中间值就不用汇总，那么每个实例只需要内存计算就好，不需要访问redis而带来的网络开销。但是这样做也会带来架构层面的调整，比如 如何做 fault tolerance， 如何做 状态持久化, 等一系列的问题。 

从使用redis结果来看，效果也不是那么差，不考虑非常热点key 的情况下，最高tps 也达到6000多(2 台机器，16core，32G 内存), 一般公司的业务其实是可以满足的，对于非常热点的key，后续的优化是继续拆分.

一个好的风控系统是非常难的，做以笔记，以希望不断成长

Redis“气急败坏”回击：13 年来，总有人想替 Redis 换套新架构

今年年中，一位前谷歌、前亚马逊的工程师推出了他创作的开源内存数据缓存系统 Dragonfly，用 C/C++ 编写，基于 BSL 许可（Business Source License）分发。

根据过往的基准测试结果来看， Dragonfly 可能是世界上最快的内存存储系统，它提供了对 Memcached 和 Redis 协议的支持，但能够以更高的性能进行查询，运行时内存消耗也更少。与 Redis 相比，Dragonfly 在典型工作负载下实现了 25 倍的性能提升；单个 Dragonfly 服务器每秒可以处理数百万个请求；在 5GB 存储测试中，Dragonfly 所需的内存比 Redis 少 30%。

作为一个开源软件，Dragonfly 在短短两个月获得了 9.2K GitHub 星，177 个 fork 分支。虽然这些年，涌现了不少类似的 Redis 兼容型内存数据存储系统，例如 KeyDB、Skytable，但是都没能像这次这么“轰动”。毕竟 Redis 诞生了十多年，这时从头开始设计一个缓存系统，可以抛弃 历史 包袱，更好地利用资源。

为回击新冒头的 Dragonfly，Redis 的联合创始人兼 CTO Yiftach Shoolman 和 Redis Labs 的首席架构师 Yossi Gottlieb、Redis Labs 的性能工程师 Filipe Oliveira 联合发布了一篇名为《13 年后，Redis 是否需要新的架构》的文章。

在文章中，他们特地给出了自认更加公平的 Redis 7.0 vs. Dragonfly 基准测试结果：Redis 的吞吐量比 Dragonfly 高 18% - 40%，以及一些有关 Redis 架构的观点和思考，以证明 “为什么 Redis 的架构仍然是内存实时数据存储（缓存、数据库，以及介于两者之间的所有内容）的最佳架构”。

虽然他们强调 Redis 架构仍然是同类最佳，但也没法忽视 Dragonfly 这些新软件提供的一些新鲜、有趣的想法和技术，Redis 表示其中的一些甚至有可能在未来进入 Redis（比如已经开始研究的 io_uring 、更现代的 dictionaries、更有策略地使用线程等）。

另外，Redis 指出 Dragonfly 基准测试的比较方法 “不能代表 Redis 在现实世界中的运行方式” 。对此，Reddit 上有网友反驳称：

还有人表示，这篇文章是 Redis 团队在有礼貌地否认“Dragonfly 是最快的缓存系统”，但更多网友表示，Redis 发文章进行“回击”，就已经代表他们的营销部门输了：

我们当然一直在寻求为 Redis 提升性能、扩充功能的创新方向，但这里我们想聊聊自己的观点和思考，阐释 Redis 时至今日为何仍是最出色的实时内存数据存储（包括缓存、数据库以及介于二者之间的一切）方案之一。

接下来，我们将重点介绍 Redis 对于速度和架构差异的观点，再以此为基础做出比较。在文章的最后，我们还会提供基准测试结果、与 Dragonfly 项目的详尽性能比较信息，欢迎大家自行对比参考。

Dragonfly 基准测试其实是将独立单进程 Redis 实例（只能使用单一核心）与多线程 Dragonfly 实例（可以使用虚拟机 / 服务器上的全部可用核心）进行比较。很明显，这样的粗暴比较并不能代表 Redis 在现实场景下的运行状态。作为技术构建者，我们希望更确切地把握自有技术同其他方案间的差异，所以这里我们做了一点公平性调整：将具有 40 个分片的 Redis 7.0 集群（可使用其中的大部分实例核心）与 Dragonfly 团队在基准测试中使用的最大实例类型（AWS c4gn.16xlarge）进行性能比较。

在这轮测试中，我们看到 Redis 的吞吐量比 Dragonfly 要高出 18% 至 40%，而这还仅仅只用到全部 64 个 vCore 中的 40 个。

在我们看来，每一位多线程项目的开发者在立项之前，都会根据以往工作中经历过的痛点来指导架构决策。我们也承认，在多核设备上运行单一 Redis 进程（这类设备往往提供几十个核心和数百 GB 内存）确实存在资源无法充分利用的问题。但 Redis 在设计之初也确实没有考虑到这一点，而且众多 Redis 服务商已经拿出了相应的解决方案，借此在市场上占得一席之地。

Redis 通过运行多个进程（使用 Redis 集群）实现横向扩展，包括在单一云实例背景下也是如此。在 Redis 公司，我们进一步拓展这个概念并建立起 Redis Enterprise。Redis Enterprise 提供管理层，允许用户大规模运行 Redis，并默认启用高可用性、即时故障转移、数据持久与备份等功能。

下面，我们打算分享幕后使用的一些原则，向大家介绍我们如何为 Redis 的生产应用设计良好的工程实践。

通过在每个虚拟机上运行多个 Redis 实例，我们可以：

我们不允许单一 Redis 进程的大小超过 25 GB（运行 Redis on Flash 时上限为 50 GB）。如此一来，我们就能：

以横向扩展的方式灵活运行内存数据存储，是 Redis 获得成功的关键。下面来看具体原因：

我们仍然欣赏由社区提出的种种有趣思路和技术方案。其中一部分有望在未来进入 Redis（我们已经开始研究 io_uring、更现代的字典、更丰富的线程使用策略等）。但在可预见的未来，我们不会放弃 Redis 所坚守的无共享、多进程等基本架构原则。这种设计不仅具备最佳性能、可扩展性和弹性，同时也能够支持内存内实时数据平台所需要的各类部署架构。

附录：Redis 7.0 对 Draonfly 基准测试细节

版本：

目标：

客户端配置：

资源利用与配置优化：

最后，我们还发现 Redis 和 Dragonfly 都不受网络每秒数据包或传输带宽的限制。我们已经确认在 2 个虚拟机间（分别作为客户端和服务器，且均使用 c6gn.16xlarge 实例）使用 TCP 传递约 300 B 大小的数据包负载时，可以让每秒数据包传输量达到 1000 万以上、传输带宽超过 30 Gbps。

单 GET 通道延迟低于 1 毫秒：

30 条 GET 通道：

单 SET 通道延迟低于 1 毫秒：

30 条 SET 通道:

用于各变体的 memtier_benchmark 命令：

单 GET 通道延迟低于 1 毫秒

30 条 GET 通道

单 SET 通道延迟低于 1 毫秒

30 条 SET 通道

在本次比较测试中，我们在客户端（用于运行 memtier_benchmark）和服务器（用于运行 Redis 和 Dragonfly）使用了相同的虚拟机类型，具体规格为：

参考链接：

原文链接：

redis发布订阅模式

最近项目中，有个功能点是利用redis的发布订阅机制，进行服务器本地缓存数据同步。

由于redis发布订阅功能的可靠性较差，在项目中出现了有服务器没有订阅成功问题，以及服务器订阅消息不及时，导致部分业务受到影响。所以将redis通知本地缓存的机制改为了使用redis做二级缓存。

虽然Redis能够实现发布/订阅的功能,但是有如下缺点,所以选用前需谨慎考虑

和常规的MQ不同,redis实现的发布/订阅模型消息无法持久化,一经发布,即使没有任何订阅方处理,该条消息就会丢失

即发布方不会确保订阅方成功接收

广播机制无法通过添加多个消费方增强消费能力,因为这和发布/订阅模型本身的目的是不符的.广播机制的目的是一个一个发布者被多个订阅进行不同的处理

由于Redis发布/订阅模型存在的缺陷,所以使用前需要考虑如下几点

1.对于消息处理可靠性要求不强

2.消费能力无需通过增加消费方进行增强

————————————————

原文链接：

zblogredis的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、zblogredis的信息别忘了在本站进行查找喔。