JRedisFuture稳定性

Question

我使用的是JRedis的同步实现，但我计划切换到异步方式来与redis服务器通信。

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

有没有人正在使用它或有使用它的经验？

谢谢!

Answer 1

当JRedis获得对事务语义(Redis1.3.n，JRedis主分支)的支持时，当然，它应该足够“稳定”。

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

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

使用流水线，正在写入的命令和正在读取的响应之间不再存在顺序关联。(管道正在发送一个命令，该命令比导致Redis同时发出正在读取的响应的命令晚N个命令。如果有什么东西坏了，空气中有很多菜:)

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

这算不算“不稳定”？在我看来，不是。这是流水线的一个问题。

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

除了这个问题之外，对于异步(管道)，您有大量的责任来确保您不会过度地将输入过载到连接器。在很大程度上，JRedis管道可以避免这种情况(因为调用者的线程用于使网络写入，从而自然地减少了挂起响应队列上的输入负载)。

但是您仍然需要运行测试--您确实说的是“生产”，对吗？) --并调整框的大小，并在前端设置加载线程的数量上限。

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