java JRedisFuture稳定性

Question

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

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

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

谢谢

Answer 1

当JRedis获得对事务语义的支持（Redis 1.3.n，JRedis主分支）时，它当然应该足够“稳定”

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

由于Redis的协议不需要DML和DDL类型命令的任何元数据（例如，没有命令序列号），因此会打开此失败窗口

通过管道，正在写入的命令和正在读取的响应之间不再存在顺序关联。（管道正在发送一个命令，该命令位于导致Redis发出同时读取的响应的命令后面的N个命令。如果出现任何问题，空气中会有很多盘子：）

也就是说，管道中未来的每一个对象都将被标记为故障，您将准确地知道故障发生的位置

这算不算“不稳定”？在我看来，不是。这是管道的问题

再次，Redis 1.3。n和事务语义完全解决了这个问题

除此之外，对于异步（管道），您有很大责任确保连接器的输入不会过度过载。JRedis管道在很大程度上保护了您不受此影响（因为调用方的线程被用来进行网络写入，因此自然地减少了挂起响应队列上的输入负载）

但你仍然需要运行测试（你说的是“生产”，对吧？）调整盒子的尺寸，并在前端的加载线数量上盖上盖子

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