千里之行，始于足下

为了让大家对 Redis 服务有个比较直观的认知，在 底层结构 的分享前 我们会先从 服务器(redis-server) 和 客户端(redis-cli) 两个方面的概况进行简单展示，至于流程中的一些细节可能不甚了了，放心，后续我们基本都会针对性的进行详解。

这篇主要对 服务器(redis-server) 端进行讲解…

工欲善其事，必先利其器

Redis 作为单进程网络编程的巅峰， 除却 大家都已经熟知的 持久化高效缓存、丰富的存储结构、高可用集群、原子性操作、publish/subscribe、通知 等特性，另外还有很多值得借鉴的优秀设计，比如 hyperloglog（基量统计算法）、zmalloc内存分配优化（jemalloc 和 tcmalloc）、multi事务、链地址 hash、zskiplist 跳跃表、ziplist 压缩表 等。

再加上 微博拥有国内最大的 Redis 集群资源（~手动狗头~） 和 平时的一些工作需求，不可避免对 Redis 产生极大的兴趣，更更更为优秀的是，redis 源码极其精简，整个核心源码只有 7~8w 行 ~~~

在之前的线程机制中我们提到辅助线程，其中 LRU 和 ASSOC扩容 就是其中比较典型的辅助功能，分别 负责 缓存回收、存储扩容

什么是 LRU

LRU，Least Recently Used 最近最少使用的一种页面置换算法。算法根据数据的历史访问记录的时间来进行淘汰数据，其核心思想是 如果最近没有被访问过，那么将来被访问的概率也比较低，所以被删除的几率就更大

另外，除了 LRU 还有另外两种常用的缓存 页面置换算法：FIFO（先进先出，先来先服务）、LFU（最近最少使用算法，跟 LRU 的区别为 LFU是按照访问次数进行处理 而 LRU是访问时间）

LRU的实现原理比较简单：维护一个链表，INPUT操作的时候如果对应元素在链表已经存在，则把UPDATE后将该元素放到链表顶端，如果不存在则INSERT后将元素放到链表顶端；SELECT操作的后将查询到的元素移动到链表顶端；这样就能确保不常用的数据在链表底端。

但是如果你觉得 MEMCACHED的LRU机制 也是这么单纯的话，就 too young, too simple...

世界上有许多种遇见

最美好的

莫过于

在我最美的年华里与你相遇

作为 缓存，永远都脱离不了 增删改查 这一基本的 API，而这点儿也正是好多人刚开始看源码最感兴趣的部分，此次我们就 消息解析、增删改查、消息响应 等方面进行分析

本章承接 状态机 conn_read 逻辑（不熟悉的可以先查看 http://www.web-lovers.com/memcached-source-threads.html 状态机 部分），功能型的代码逻辑比较清晰，我们此次跟随着代码逻辑进行解析

从某个意义上讲，资源总是有限的，衡量一个计算机处理能力的指标有很多， 根据不同的应用需要也会有不同的指标，比如3D游戏对显卡的性能有要求，Web服务器对吞吐量及响应时间有要求，而缓存服务器对存取效率着重要求， 通常CPU、内存及硬盘的读取和计算速度具有决定性的作用，在同一时刻这些资源是有限的， 正是因为有限我们才需要合理的利用他们。

我们此次就 memcached的 存储模型、hashtable、slabs 三个方面进行解析，分析其存储机制的精妙设计

memcached 多线程网络编程的巅峰，其线程机制的设计十分之精妙。线程池部分主要包含 主线程、工作线程 以及 辅助线程，另外再辅以 状态机、通信管道，就大致组成了整个线程机制

memcached 网络线程模型事件完全基于 libevent 处理机制，利用 基础的 多路复用IO模型 进行事件监控，以下我们就 网络模型 以及 源码解析 两部分进行解读

千里之行，始于足下

作为模块化比较明显的开源软件，根据初始化过程可以很清晰的区别其结构。