Memcached源码分析之网络模型篇

memcached 采用多线程的工作方式, 主线程接收连接, 然后把连接平摊给

工作线程, 工作线程处理业务逻辑, memcached 使用 libevent 处理网络

事件, 主线程和工作线程都有一个 event base, 这是 libevent 的核心数据

结构, event base 能够监听多个 socket 的网络事件, 概括起来,

memcached 大体框架如 图1 所示.

 
  图1 memcached的多线程模型

 

 

 

主线程的初始化

主线程首先初始化 libevent 的核心数据结构 main base, 然后创建监听

socket, 把监听 socket 封装成一个连接, 加入 main base, 这样就能处理

网络事件.  

 

 

所有 socket 的网络事件处理都由两个函数完成:event_handler() 和

drive_machine(), 其中 event_handler() 调用 drive_machine(), 

所以真正的业务逻辑都在 drive_machine() 完成, 这个函数处理 socket

的读写事件, 还能为监听 socket 处理新的连接. 

 

Main Thread 初始化完成的状态:

 

工作线程的初始化

1 首先创建 n 个工作线程

 

2 然后为工作线程初始化 event base, 创建通知管道, 并加入 event base, 

通知管道的作用在于:　主线程把新来的连接转交给某个线程时，同时向该线程的通知管道发送一个

字符的数据，唤醒该线程去处理连接, 也就是调用 thread_libevent_process 来处理连接.

 

3 最后创建 CQ_ITEM 队列, 这个队列用于主线程和工作线程的上下文切换, 主线程把新来的连接

封装成 CQ_ITEM, 放到工作线程的 CQ_ITEM 队列, 并唤醒该线程去处理新来的连接.

 初始化完成后, 工作线程的状态如下:

 

下面这幅图是 memcached 整体的架构图:

连接的管理

网络服务器的开发少不了连接的管理, 所谓连接, 是指 connection, 它保存客户端

的 socket 描述符, 还有读和写的 buffer, 以及连接所在的线程 id. 

 

连接是一个结构体, 在 memcached 中定义为 conn, conn 占用一定的内存

空间, 如果服务器对新来的连接都分配 conn 结构体,  内存的分配和回收是一笔

不小的开销, 将影响服务器的性能. 

 

conn 结构体其实可以重复利用的, 连接用完的 conn 可以回收给其他连接用, 所以

服务器有必要维护一个连接池, 来统一管理 conn, 最大限度地重复利用 conn, 避免

不必要的分配. 

 

memcached 的连接管理做得相当简单, 就是维护一个 conn 数组. 如下图所示:

 freeconns 是 conn 的二维数组, freecurr指向当前的空闲槽

 

conn 的分配 -- conn_from_freelist()函数

分配策略很简单, 就是把 freeconns[freecurr -1] 分配出去, 然后 freecurr 指针下移一个单位.

如果 freeconns 没有空闲的 conn, 分配就失败, 函数 conn_from_freelist 返回 NULL, 这时

memcached 就会从操作系统分配内存空间. 事实上 memcached 不会预先给 freeconns

分配一些空闲 conn, conn 都是在系统运行期间按需分配的.

 

conn的回收

把用完的 conn 挂在 freecurr 所在的槽位.