redis 性能相关方面

一、存储延时

Cpu的运算速度发展迅速，最高峰平均每隔几个月，速度就翻一倍，目前Cpu的一个时钟周期已达到纳秒级
近几年cpu的发展趋势不再是提高速度，而是并行化，包括支持多cpu多核，超线程和numa结构
原因是存储设备的速度发展相对滞后，单纯提高cpu的运算速度已无法有效提高系统的性能
因此除少数计算密集型系统外，大部分系统的性能瓶颈往往在存储设备性能

Relative Latency

• CPU Register – 1x
• L2 Cache – 10x
• Memory – 100x
• Disk – 10,000,000x

内存的读写性能是磁盘的10W倍，因此基于内存操作的redis的性能会显著高于基于磁盘操作的数据库

二、内存管理

Linux默认内存分配函数ptmalloc性能不佳，并且存在内存碎片率过高的问题（部分长周期内存会影响其他内存回收）
Redis封装了zmalloc函数，如果linux安装了tcmalloc，则使用tcmalloc，否则使用默认的jemalloc

zmalloc.c

• 支持tcmalloc(google提供)，需要单独安装
• 默认使用jemalloc(freeBSD默认)，redis源码自带
• 快速分配和回收
• 解决内存碎片率问题
  tcmalloc: 1.01
  jemalloc: 1.02
  ptmalloc: 1.31

三、 IO multiplexing

Blocking io要求1条线程支持1条连接，连接仅消耗少量内存，并不稀缺，但线程为稀缺资源，一台机器一般最多支持1000条线程左右，因此blocking io严重制约系统吞吐量
Nonblocking io需要不断check连接状态，cpu消耗严重
Io multiplexing支持1条线程监听多条连接，不需要反复check，当有连接发送状态变更时，返回连接集合

单线程处理所有io事件，由于redis的请求都是内存操作，性能很高，因此所有事件都在同一条线程循环中完成

Io多路复用适合高吞吐量服务端使用，io开销小，释放紧缺的线程资源处理业务逻辑，nginx，jetty，tomcat，netty都在使用