zblog使用redis（zblog app）

本篇文章给大家谈谈zblog使用redis，以及zblog app对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、风控系统实践之感: drools 和 redis
• 2、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怎么使用

应用Redis实现数据的读写，同时利用队列处理器定时将数据写入mysql。

同时要注意避免冲突，在redis启动时去mysql读取所有表键值存入redis中，往redis写数据时，对redis主键自增并进行读取，若mysql更新失败，则需要及时清除缓存及同步redis主键。

这样处理，主要是实时读写redis，而mysql数据则通过队列异步处理，缓解mysql压力，不过这种方法应用场景主要基于高并发，而且redis的高可用集群架构相对更复杂，一般不是很推荐。

Redis集群操作

有 slots

无 slots 时直接删除

（5）学习redis-trib命令使用：

添加两个节点

docker-compose.yaml 添加

1 create ：创建一个集群环境host1:port1 ... hostN:portN（集群中的主从节点比例）

2 call ：可以执行redis命令

3 add-node ：将一个节点添加到集群里，第一个参数为新节点的ip:port，第二个参数为集群中任意一个已经存在的节点的ip:port

4 del-node [host:port node_id] ：移除一个节点

5 reshard ：重新分片

6 check [hosts:port]：检查集群状态

步骤一：使用add-node命令：绿色为新增节点，红色为已知存在节点

输出如下：

步骤二：查看集群状态：

注意： 当添加节点成功以后，新增的节点不会有任何数据，因为它没有分配任何的slot（hash槽）。我们需要为新节点手工分配slot。

步骤一：使用redis-trib命令，找到集群中的任意一个主节点（红色位置表现集群中的任意一个主节点），对其进行重新分片工作。

输出如下：

1提示一：是希望你需要多少个槽移动到新的节点上，可以自己设置，比如200个槽。

2提示二：是你需要把这200个slot槽移动到那个节点上去（需要指定节点id），并且下个 提示是输入all为从所有主节点（7001 7002 7003）中分别抽取响应的槽数（一共为200个槽到指定的新节点中！，并且会打印执行分片的计划。）

3提示三：输入yes确认开始执行分片任务。在最后我们再次看一下集群状态：

如上图所示，现在我们的7007已经有slot槽了，也就是说可以在7007上进行读写数据啦！到此为止我们的7007已经加入到集群中啦，并且是主节点（Master）

步骤一：还是需要执行add-node命令：

提示添加成功后我们继续看一下集群的状态：

如图所示，还是一个master节点，没有被分配任何的slot槽。

步骤二：我们需要执行replicate命令来指定当前节点（从节点）的主节点id为哪个。

首先需要登录新加的7008节点的客户端，然后使用集群命令进行操作，把当前的7008（slave）节点指定到一个主节点下（这里使用之前创建的7007主节点，红色表示节点id）

我们继续看一下当前集群的状态，如下图：我们已经成功的把7008放到7007这个主节点下面了，到此为止我们已经成功的添加完一个从节点了。

（9）我们可以对集群进行操作，来验证下是否可以进行读写（当然可以）。

（10）我们现在尝试删除一个节点（7008 slave）

步骤一：删除从节点7008，输入del-node命令，指定删除节点ip和端口，以及节点id（红色为7008节点id）

输出如下：

步骤二：再次查看一下集群状态，如下图所示，我们已经成功的移除了7008 slave节点，另外我们发现移除一个节点以后，当前节点的服务进程也会随之销毁。可以使用ps命令查看当前的服务（ps -el | grep redis），发现少了一个运行的server，也就是刚移除的7008从节点。

（11）最后，我们尝试删除之前加入的主节点7007，这个步骤会相对比较麻烦一些，因为主节点的里面是有分配了slot槽的，所以我们这里必须先把7007里的slot槽放入到其他的可用主节点中去，然后再进行移除节点操作才行，不然会出现数据丢失问题。

步骤一：删除7007（master）节点之前，我们需要先把其全部的数据（slot槽）移动到其他节点上去（目前只能把master的数据迁移到一个节点上，暂时做不了平均分配功能）。

输出如下：

到此为止我们已经成功的把7007主节点的数据迁移到7001上去了，我们可以看一下现在的集群状态如下图，你会发现7007下面已经没有任何数据（slot）槽了，证明迁移成功！

输出如下：

最后：我们查看集群状态，一切还原为最初始状态啦！OK 结束！

关于zblog使用redis和zblog app的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。