1

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

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

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

谢谢!

4

1 回答 1

1

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

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

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

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

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

这算不算“不稳定”?在我看来,没有。这是流水线的问题。

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

除了这个问题之外,对于异步(管道),您有很大的责任确保您不会过度过载连接器的输入。在很大程度上,JRedis 管道可以保护您免受这种情况的影响(因为调用者的线程用于进行网络写入,因此自然会抑制待处理响应队列上的输入负载)。

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

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

于 2010-08-29T04:02:31.087 回答