以前一直有一个误区，以为：高性能服务器一定是多线程来实现的, 原因很简单因为误区二导致的：多线程一定比单线程效率高。其实不然。
redis核心就是如果我的数据全都在内存里，我单线程的去操作，就是效率最高的，为什么呢？因为多线程的本质就是cpu模拟出来多个线程的情况，这种模拟出来的情况就是一个代价，就是上下文的切换，对于一个内存系统来说，它没有上下文的切换就是效率最高的，redis用单个cpu绑定一块内存的数据，然后针对这块内存的数据进行多次读写的时候，是在一个cpu上完成的，所以它是但线程处理这个事情。在内存的情况下，这个方案就是最佳方案。
因为一次cpu上下文切换大概在1500ns(纳秒)左右，从内存中读取1MB的连续数据，耗时大约为250us(微妙)(1us=1000ns)，假设1MB的数据有多个线程读取1000次，那么就由1000次时间上的上下文切换。那么就由1500ns * 1000 = 1500us，而我单线程读完1MB数据才250us，你光时间上下文切换就用了1500us了，我还没有算你每次读一点数据的时间呢。
那么什么时候用多线程的方案呢？
答案是：下层的存储等慢速的情况，比如磁盘，内存是一个IOPS(每秒进行IO操作的次数)非常高的系统，因为我想申请一块内存就申请一块内存，销毁一块内存我就销毁一块内存，内存的申请和销毁是很容易的。而且内存是可以动态申请大小的。
磁盘的特点是：IOPS很低，但是吞吐量很高，这就意味着，大量的读和写操作必须攒到一起，在提交到磁盘的时候，性能最高。为什么呢？
如果我有一个事务组的操作(就是几个已经分开了的事务请求，比如写读写读写，这五个操作在一起)， 在内存中，因为IOPS非常高，我可以一个一个的完成，但是如果在磁盘中也有这种请求方式的话，我第一个写操作是这样完成的，我先从磁盘中寻址，大搞花费10ms(毫秒)，然后我读取一个数据可能花费1ms，然后我在计算(忽略不计)，在写会磁盘又是10ms，总共21ms
第二个请求去读花了10ms，第三个又是写花费了21ms，然后我在读写，五个请求一共花费了21+10+21+10+21=83ms，这还是理想的情况下，这如果在内存中，大概1ms不到。
所以对于磁盘来说，他吞吐量这么大，那最好的方案就是我将N个请求一起放在一个buffer里，然后一起去提交。
方法就是用异步：将请求和处理的线程不绑定，请求的线程将请求放在一个buffer里，然后等buffer快慢了，处理的线程不再去处理这个buffer，然后有这个buffer统一的去写如磁盘，或者读磁盘。这样效率就是最高的。
对于慢速设备，这种处理方式是最佳的，慢速设备有磁盘，网络，ssd等。
多线程，异步的方式处理问题是非常常见的，大名鼎鼎的netty就是这样操作的。
为和单核cpu绑定一块内存效率最高
我们不能任由操作系统负载均衡，因为我们自己更加了解自己的程序，所有我们可以手动的为其分配cpu核，而不会过多的占用cpu，默认情况下单线程在进行系统调用的时候会随机使用cpu内核，为了优化redis，我们可以使用工具为单线程绑定固定的cpu内核，减少不必要的性能损耗！redis作为单进程模型的程序，为了充分利用多核cpu，常常在一台server上启动多个实例，而为了减少切换的开销，我们有必要为每个实例指定其所运行的cpu。
linux上taskset可以将某个进程绑定到一个特定的cpu。你比操作系统更了解自己的程序，为了避免调度器愚蠢的调度你的程序，或是为了在多线程程序中避免失效造成的开销，
redis的瓶颈在网络上。
