我正在使用JRedis的同步实现，但我打算切换到异步方式与redis服务器通信。
但在此之前，我想问一下社区是否对于@zero jredis的JRedisFuture实现是否足够稳定以供生产使用？
有没有人在使用它或有经验？
谢谢！
答案 0 :(得分：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也是如此。遗憾的是，在同一个核心上运行其中两个将导致在一个新的系统范围的高速缓存失效期间，它是原系统的HALF，因此TWICE会发生更多的高速缓存失效（平均）。所以这是自我挫败。但要测试您的负载条件，以及您预计的生产部署平台。