关于redis的异步api, 为什么很少有人用异步方式？没必要吗？

dive_

如题。redis的官方client lib. hiredis默认是同步方式操作的。 异步方式的API支持算不上完善。
我粗略的了解下来，hiredis的异步方式的支持也是不完全的。就是我可以在一个连接上异步地发送多个请求过去。redis处理完成后会按顺利给我响应。这个异步仅仅是在socket的层面上。
如果我有多个工作线程都要通过统一的socket层向redis发送请求，就会发现，没有地方用来安放trans_id. 当socket层收到响应后根本不知道这个响应对应到哪一个请求上去。
究其原因，应该是redis的协议本身是完全基于字符的，面向单个连接的。天生就不提供完全意义上的异步API支持。

不知道我以上的理解是否正确。有没有和我一样碰到这个问题的朋友？
我的疑问是，redis是不是真的像我想的那样不提供完全意义的异步支持？或者是我理解错误了？
如果我理解的是正确的，那么redis为什么设计成这样？各位在实际应用中，有没有因为同步访问redis而导致服务性能下降的问题？

dive_

没人理我？难道是要发到其他版块？

Fixend

这个正常啊，比如mysql，基本都是同步的，要用异步，上层根据需要自己设计。

csumck

异步接口不能携带序列号之类的数据，异步返回后都不知道是前面哪个请求返回的，只能完全依赖“顺序返回”的特性来查，非常不好用。

starwing83

额，是这样的，使用redis的时候通常会把它当作一个服务来使用，具体的方法是这样的：

首先，有一个中心的Proxy负责收集外界的请求，并记录请求的callback。
然后，这个中心采用同步（开线程）或者异步（epoll）的方式，对redis进行请求。
然后，当redis返回的时候，这个Proxy负责用回复的结果调用callback。

这样，对这个proxy而言，就是完全异步的了，并且通过callback来标识异步执行结果。

这样的设计以及redis的设计决定的原因是：redis本身是作为一个单独的服务提供的，这意味着，它有一个固定的输入/输出的接口（类比客户端：客户端的数量是不确定的、连接是不确定的、连接持续时间也是不确定的）。因此，他不需要提供很复杂的接口控制，如果需要这些功能，可以自己进行包装，这是基于两个想法：
- 首先，socket本身就是定义良好的接口了，并且支持非常多种类的同步/异步操作
- 其次，很遗憾的是，这些操作通常都是跟平台有关的。

其实习惯就好了~你用第三方的包装库（比如node-redis）基本上感觉不到不方便的，嗯~

dive_

TO: starwing83
非常感谢你的回复. 你的回复印证了我对redis接口的想法。
你提到的redis proxy也是一个很好的建议。至于node.js是库。 由于我是用c/c++开发。没有接触过，所以不是很了解。按照我们的理解，node.js应该就是用你提到的proxy这样的方法来提供异步接口的吧。