Redis 原理

       在CPU的世界里，我就把这个CPU执行一个指令的时间 成为单元时间， 假设这个单元时间 对应的我们现实世界的 一秒钟，我们看看CPU的世界是如果在计算机中度过的。

       一级缓存的读取速度是：0.5ns，对应的人类时间是 1.3s，这个速度还是挺快的，一般一级缓存的大小是 32K；

分支预测错误需要耗时 5ns 对应的人类时间是 13s 是不是有点久了？什么是分支预测

       二级缓存的读取速度是：7ns,对应的人类时间是 18.2s, 如果一级缓存没有命中的话，再去二级缓存中找，二级缓存通常大小是 256K ， 速度就慢了18倍了，所以redis里没有命中，如果要去DB种找的话，那个性能会差得更多。。不信接着下面的时间看...

       每次内存寻址的速度是：100ns,对应的人类时间是 260S ， 已经是四分多钟了，这还只是寻址，从内存中读取数据属于IO操作，IO操作更费时间，这就是 内存 跟 CPU 的速度不在一个量级的地方了。

       因为一次CPU上下文的切换大概在 1500ns 左右。

       从内存中读取 1MB 的连续数据，耗时大约为 250us，假设1MB的数据由多个线程读取了1000次，那么就有1000次时间上下文的切换，那么就有1500ns * 1000 = 1500us ，我单线程的读完1MB数据才250us ,你光时间上下文的切换就用了1500us了，我还不算你每次读一点数据 的时间，那什么时候用多线程的方案呢？

       答案是：下层的存储等慢速的情况。比如磁盘。

       内存是一个 IOPS 非常高的系统，因为我想申请一块内存就申请一块内存，销毁一块内存我就销毁一块内存，内存的申请和销毁是很容易的。而且内存是可以动态的申请大小的。

       磁盘的特性是：IPOS很低很低，但吞吐量很高。这就意味着，大量的读写操作都必须攒到一起，再提交到磁盘的时候，性能最高。为什么呢？

       如果我有一个事务组的操作（就是几个已经分开了的事务请求，比如写读写读写，这么五个操作在一起），在内存中，因为IOPS非常高，我可以一个一个的完成，但是如果在磁盘中也有这种请求方式的话，我第一个写操作是这样完成的：我先在硬盘中寻址，大概花费10ms，然后我读一个数据可能花费1ms然后我再运算（忽略不计），再写回硬盘又是10ms ，总共21ms；第二个操作去读花了10ms, 第三个又是写花费了21ms ,然后我再读10ms, 写21ms ，五个请求总共花费83ms，这还是最理想的情况下，这如果在内存中，大概1ms不到。

       所以对于磁盘来说，它吞吐量这么大，那最好的方案肯定是我将N个请求一起放在一个buff里，然后一起去提交。

 

       方法就是用异步：将请求和处理的线程不绑定，请求的线程将请求放在一个buff里，然后等buff快满了，处理的线程再去处理这个buff。然后由这个buff 统一的去写入磁盘，或者读磁盘，这样效率就是最高。 java里的 IO不就是这么干的么~

       对于慢速设备，这种处理方式就是最佳的，慢速设备有磁盘，网络 ，SSD 等等，多线程 ，异步的方式处理这些问题非常常见，大名鼎鼎的netty 就是这么干的。

       终于把 redis 为什么是单线程说清楚了，把什么时候用单线程跟多线程也说清楚了，其实也是些很简单的东西，只是基础不好的时候，就真的尴尬。。。。

       补一发大师语录：来说说，为何单核cpu绑定一块内存效率最高

       “我们不能任由操作系统负载均衡，因为我们自己更了解自己的程序，所以我们可以手动地为其分配CPU核，而不会过多地占用CPU”，默认情况下单线程在进行系统调用的时候会随机使用CPU内核，为了优化Redis，我们可以使用工具为单线程绑定固定的CPU内核，减少不必要的性能损耗！

       redis作为单进程模型的程序，为了充分利用多核CPU，常常在一台server上会启动多个实例。而为了减少切换的开销，有必要为每个实例指定其所运行的CPU。

       Linux 上 taskset 可以将某个进程绑定到一个特定的CPU。你比操作系统更了解自己的程序，为了避免调度器愚蠢的调度你的程序，或是为了在多线程程序中避免缓存失效造成的开销。