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

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

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

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

千里之行，始于足下

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

工欲善其事，必先利其器

守护进程daemon，一般是指 不受终端控制，不能直接和用户交互，自动运行在系统后台的进程。

一般对于 UNIX / LINUX 来说，守护进程往往都是托管在 init 的孤儿进程。命名上 普遍是以 d 结尾，比如 httpd、mysqld、memcached、crond、sshd 等。进程属性分辨上一般通过 TPGID、TTY 等：

作为 电子邮件、图片 等场景最常用的编码算法，Base64 的地位无可撼动。究其原因呢？我们很多协议要求数据传输只能由ASCII文本传输，而 ASCII 中 128 ~ 255 之间的值是不可见的，而在网络传输中经过的不同设备对于数据的处理方式不一，容易导致不可见字符出现一些不愿意见到的错误处理，这样就很不利于传输，所以通过 一种编码进行转化为可见字符，统一按照普通字符进行处理，so…经过发展，就有了今天的 Base64。

作为 UNIX/LINUX 背景下的开发人员或者运维人员，当然对 configure -> make -> make install 系列操作非常熟悉，但是可能对其实现方式不是那么熟悉，实际上，这叫 GNU构建系统，利用脚本和 make 程序在特定平台上构建软件。此次我们以开发者的视角来分析构建细节。

环境说明：

• CentOS release 6.9 (Final)
• autoconf 2.69 (包含 autoscan autoconf autoheader )
• automake 1.11.1 (包含 aclocal automake)
• make 3.81

上次我们利用一个 websocket client 的实现对 ws协议 进行了详细的解析（websocket client & ws协议解析），作为一个深度强迫症犯者，那么 websocket server 就必不可少了。

为了保证示例的简洁性，我们仅仅建立了支持单个客户端的 websocket 服务端的模型。而一般的网络编程模型，都是主进程一个事件监听连接，接收连接之后把连接对象抛给IO线程池（一般线程数量等于CPU核数），这个IO线程池每个人都有自己的epoll，来监听连接对象的可读事件，IO线程读取完数据，进行TCP粘包、半包处理，然后封装成task，最后丢给一个工作线程池来处理task，最后处理完task由一个专门的发送线程进行统一发送数据。

环境说明：

• 完整代码: websocket_server.c
• RFC6455协议
• gcc version 4.4.7 x86_64-redhat-linux
• websocket客户端 采用 Javascript 的 new WebSocket("ws://127.0.0.1:2346/") 系列方法