使用多个python线程可以提供帮助,但是当阻塞命令发送到服务器时,每个线程仍然会空闲.除非你有很多线程,否则它们会经常同步并且所有块都在等待响应.因为每个线程都连接到所有三个服务器,所以减少了发生这种情况的可能性,除非所有线程都被阻塞等待同一个服务器.

假设您在服务器上有统一的随机分布式访问来为您的请求提供服务(通过对密钥名称进行散列来实现分片或分区),那么三个随机请求将散列到同一个redis服务器的几率与服务器数量成反比.对于1台服务器,100％的时间你将散列到同一台服务器,2％是50％的时间,3％是33％的时间.可能发生的是1/3的时间,所有线程都被阻塞,等待同一台服务器. Redis是处理数据操作的单线程,因此它必须一个接一个地处理每个请求.您的cpu仅达到60％利用率的观察结果与您的请求全部被阻止同一服务器的网络延迟的概率一致.

继续假设您通过对密钥名称进行散列来实现客户端分片,您可以通过为每个线程分配单个服务器连接来消除线程之间的争用,并在将请求传递给工作线程之前评估分区哈希.这将确保所有线程都在等待不同的网络延迟.但是使用流水线可能会有更好的改进.

如果您不需要服务器的即时结果,则可以使用the redis-py module的管道功能来减少网络延迟的影响.这对您来说可能是可行的,因为您将数据处理的结果存储到redis中.要使用redis-py实现此功能,请使用.pipeline()方法定期获取现有redis连接对象的管道句柄,并针对该新句柄调用多个存储命令,与主redis.Redis连接对象相同.然后调用.execute()来阻止回复.通过使用流水线技术将数十或数百个命令一起批量处理,您可以获得数量级的改进.在管道句柄上发出最终的.execute()方法之前,您的客户端线程不会阻塞.

如果同时应用这两个更改,并且每个工作线程只与一个服务器通信,将多个命令组合在一起(至少5-10个以查看显着结果),则可能会在客户端中看到更大的cpu使用率(接近100％). cpython GIL仍然会将客户端限制为一个核心,但听起来您已经使用其他核心通过使用多处理模块进行XML解析.

redis.io网站上有一个good writeup about pipelining.