你这样介绍整个设计。
当Redis启用了多线程之后，里面的主线程就要负责接收事件、创建连接、执行命令。Redis的IO线程就负责读写数据。
我用一个请求的处理过程来解释一下整个设计。当客户端发出请求的时候，主线程会收到一个可读的事件，于是它把对应的客户端丢掉可读的客户端列表。一个IO线程会被安排读写这个客户端发来的命令，并且解析好。紧接着主线程会执行 IO 线程解析好的命令，并且把响应放回到可写客户端列表里面。IO 线程负责写回响应。整个过程就结束了。 所以整个 Redis 在多线程模式下，可以看作是单线程 Reactor、单线程 Acceptor 和多线程 Handler 的 Reactor 模式。只不过 Redis 的主线程同时扮演了 Reactor 中分发事件的角色，也扮演了接收请求的角色。同时多线程 Handler 在 Redis 里面仅仅是读写数据，命令的执行还是依赖于主线程来进行的。
紧接着你要补充一个业界比较多人认同的观点，就是不到逼不得已不要启用 Redis 多线程模型。
虽然说现在 Redis 的 IO 改成多线程之后能够有效利用多核性能，但是大部分情况下都是不推荐使用多线程模式的。道理很简单，Redis 在单线程模式下的性能就足以满足绝大多数使用场景了，那么用不用多线程已经无所谓了。
接下来，你根据你们公司的实际情况来选择一个回答。第一个回答是介绍你们公司使用了多线程模型。
我司的 Redis 早期的时候就触及了单线程的性能瓶颈，后来在开启了多线程之后，能支撑的 QPS 大概提升了 50%，效果还是很不错的。
你最好在自己公司里面测试一下性能提升的幅度。有些时候面试官可能会问你用了几个线程，你回答公司的实际情况就行。另外一个回答是你们公司没有用多线程模型。
早期我们公司虽然遇到过 Redis 的性能瓶颈，但还是没有启用多线程模型，而是改成了使用 Redis Cluster（或者扩大了 Redis Cluster 规模）。我个人认为，Redis Cluster 一样能够解决性能瓶颈问题，而且相比多线程模式，Redis Cluster 的可用性更好，解决性能问题的效果也更好。
