gpt4 book ai didi

java - JRedis future 稳定

转载 作者:IT王子 更新时间:2023-10-29 06:16:14 27 4
gpt4 key购买 nike

我正在使用 JRedis 的同步实现,但我打算切换到异步方式与 Redis 服务器通信。

但在此之前我想问一下社区 JRedisFuture 是否实现了 alphazero 的 jredis对于生产使用是否足够稳定?

有没有人在使用它或有使用它的经验?

谢谢!

最佳答案

当 JRedis 获得对事务语义的支持(Redis 1.3.n,JRedis master 分支)时,当然,它应该足够“稳定”。

用于非事务性命令的 Redis 协议(protocol)本身是原子的,允许在发送破坏性命令时出现不可恢复的故障窗口,并且在读取阶段出现连接故障。客户端无法知道 Redis 是否确实处理了最后一个请求,但由于网络故障(例如)导致响应被丢弃。即使是基本的请求/回复客户端也容易受到此影响(我认为这不限于 Java 本身。)

由于 Redis 的协议(protocol)不需要任何元数据(根本)与 DML 和 DDL 类型的命令(例如,没有命令序列号),这个失败窗口被打开。

有了流水线,正在写入的命令和正在读取的响应之间不再有顺序关联。 (管道正在发送一个命令,该命令落后于导致 Redis 发出正在同时读取的响应的命令。如果有任何问题,空气中有很多盘子:)

也就是说,管道中的每个 future 对象都将被标记为故障,您将准确地知道故障发生在哪个响应

这是否符合“不稳定”的条件?在我看来,没有。这是流水线的问题。

同样,具有事务语义的 Redis 1.3.n 完全解决了这个问题。

除此之外,对于异步(管道),您有很大的责任确保您不会过度重载连接器的输入。在很大程度上,JRedis 管道可以保护您免受此影响(因为调用者的线程用于使网络写入,从而自然地抑制挂起响应队列上的输入负载)。

但是您仍然需要运行测试——您说的是“生产”,对吗? )) -- 调整你的盒子大小,并限制前端加载线程的数量。

我还可能建议不要在多核机器上运行多个 JRedis 管道。在现有的实现(不分 block 写入缓冲区)中,通过运行多个流水线到同一台服务器,可以提高效率(在充分利用带宽和最大化吞吐量的情况下)。当一个管道忙于创建要写入的缓冲区时,另一个正在写入等。但是,这两个管道将由于它们(不可避免——记住它们是队列并且必须发生某种形式的同步)和周期性缓存失效而相互干扰(在最坏的情况下,在每次出队/入队时——但我们相信 Doug Lea。)因此,如果管道 A 的平均延迟达到 d1(隔离),那么管道 B 也是如此。遗憾的是,在相同的内核上运行它们中的两个将导致在一个新的系统范围内的缓存失效周期是原始系统的一半,因此随着更多缓存失效的发生(平均),两倍。所以这是弄巧成拙。但是测试你的负载条件,并在你预计的生产部署平台上。

关于java - JRedis future 稳定,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3092578/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com