结构介绍

MemCache有几种内存概念：
slab_class、slab、chunk

slab_class：拥有同样chunk大小的slab被组织在一起，成为slab_class。

slab：MemCache将内存空间分为一组slab，slab下面是若干个chunk，默认大小为1M。

chunk：chunk是真正存储数据的地方，同一个slab里面chunk的大小是一样的。chunk的增长因子由-f指定，默认1.25，起始大小为48字节；

MemCache中的value过来存放的地方是由value的大小决定的，value总是会被存放到与chunk大小最接近的一个slab中，比如slabclass[1]的chunk大小为80字节、slabclass[2]的chunk大小为100字节、slabclass[3]的chunk大小为128字节（相邻slab_class内的chunk基本以1.25为比例进行增长，MemCache启动时可以用-f指定这个比例），那么过来一个88字节的value，这个value将被放到2号slab中。放slab的时候，首先slab要申请内存，申请内存是以slab为单位的，所以在放入第一个数据的时候，无论大小为多少，都会有1M大小的内存被分配给该slab。申请到后，slab会将内存按chunk的大小进行切分，这样就变成了一个chunk数组，最后从这个chunk数组中选择一个用于存储数据。

slab_class

这里是slab_class结构的定义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

typedef struct {
    unsigned int size;      /* sizes of items */ /* item的大小 */
    unsigned int perslab;   /* how many items per slab */ /* 每一个slab的item数量 */
    void *slots;           /* list of item ptrs */  /* 空闲item(被回收的item)链表的指针 */
    unsigned int sl_curr;   /* total free items in list */ /* 空闲item的总数量 */
    unsigned int slabs;     /* how many slabs were allocated for this class */ /* 在这个slabclass中已分配slab的数量 */
    void **slab_list;       /* array of slab pointers */  /* slab数组 */
    unsigned int list_size; /* size of prev array */      /* 前一个数组的大小 */
    unsigned int killing;  /* index+1 of dying slab, or zero if none */
    size_t requested; /* The number of requested bytes */  /* 被访问到的字节数 */
} slabclass_t;

item

在MemCache中，item是用于存储数据的结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

/**
 * Structure for storing items within memcached.
 */
typedef struct _stritem {
    struct _stritem *next;       /* 双向链表 */
    struct _stritem *prev;
    struct _stritem *h_next;    /* hash chain next */ /* 指向hash值相同的下一个元素 */
    rel_time_t      time;       /* least recent access */ /* 最近访问的时间 */
    rel_time_t      exptime;    /* expire time */  /* 过期时间 */
    int             nbytes;     /* size of data */ /* 数据大小 */
    unsigned short  refcount;   /* 被引用数 */
    uint8_t         nsuffix;    /* length of flags-and-length string */ /* 后缀长度 */
    uint8_t         it_flags;   /* ITEM_* above */
    uint8_t         slabs_clsid;/* which slab class we're in */   /* 此item所属哪个slabclass */
    uint8_t         nkey;       /* key length, w/terminating null and padding */ /* 键的长度　*/
    /* this odd type prevents type-punning issues when we do
     * the little shuffle to save space when not using CAS. */
    union {
        uint64_t cas;
        char end;
    } data[];//真实数据信息
    /* if it_flags & ITEM_CAS we have 8 bytes CAS */
    /* then null-terminated key */
    /* then " flags length\r\n" (no terminating null) */
    /* then data with terminating \r\n (no terminating null; it's binary!) */
} item;

杂谈

在一两年前就已经使用过websocket协议，但是当时也仅仅是停留在使用上，对于很多原理以及协议的实现没有过多的理解。
在很长一段时间里，我对websocket都还只是停留在“会用”的阶段。

最近总算有时间来捣鼓捣鼓一些底层原理性的东西，算是查缺补漏吧。

让我们进入我们的主题——websocket。

WebSocket 初探

首先，WebSocket是一个持久连接协议，WebSocket是HTML5出的东西（协议），也就是说HTTP协议没有变化，或者说没关系，但HTTP是不支持持久连接的（长连接，循环连接的不算）

WebSocket和HTTP之前会有一些小小的共同点，比如：
1、他们都是基于TCP。因为WebSocket是基于TCP的，所以连接可靠性得到了保障。
2、他们都有“Header”，像 Cookie=xxxx;Content-Type=xxxx; 这样的键值对

他们之间的关系就像是这样的：

WebSocket 之深入

握手阶段

一起来看看WebSocket建立连接的过程。

这里是浏览器发起的请求：

1
2
3
4
5
6
7
8

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

可以看到，比起传统的HTTP协议，多了几个头：Upgrade Sec-WebSocket-Key Sec-WebSocket-Protocol Sec-WebSocket-Version
这些头部是用于给WebSocket握手建立连接用的，指定的是websocket协议
Sec-WebSocket-Key 是浏览器随机生成的base64 encode的值，用来询问服务器是否是支持WebSocket。

再看看服务端返回的Response：

1
2
3
4
5

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

Sec-WebSocket-Accept是将请求包Sec-WebSocket-Key的值，与”258EAFA5-E914-47DA-95CA-C5AB0DC85B11″这个字符串进行拼接，然后对拼接后的字符串进行sha-1运算，再进行base64编码得到的。用来说明自己是WebSocket助理服务器。

Data Frame（数据帧）

WebSocket数据帧结构如下图所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

在使用PHP-X开发PHP拓展的过程中，发现一个非常奇怪的bug

在频繁地调用zend_wrong_paramers_count_error这个Zend API方法后，会导致发生core dump。这个方法的作用是抛出一个入参参数数量不正确的Warning级别异常

先看看我们的源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

ZEND_RESULT_CODE _check_args_num(zend_execute_data *data, int num_args)
{
    uint32_t min_num_args = data->func->common.required_num_args;
    uint32_t max_num_args = data->func->common.num_args;
    if (num_args < min_num_args || (num_args > max_num_args && max_num_args > 0)) 
    {
        #if PHP_MAJOR_VERSION >= 7 && PHP_MINOR_VERSION == 0
        zend_wrong_paramers_count_error(num_args, min_num_args, max_num_args);
        #else
        zend_wrong_parameters_count_error(num_args, min_num_args, max_num_args);  //出错所在
        #endif
        return FAILURE;
	}
    return SUCCESS;
}

使用gdb对core进行分析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

$ gdb php -c /corefile/core.11
[New LWP 2852]
Core was generated by `php ../tests/main.php'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000085c681 in incomplete_class_message (object=0x7effd7a6b140, error_type=32511) at /usr/local/php-7.2.0/ext/standard/incomplete_class.c:47
47			php_error_docref(NULL, error_type, INCOMPLETE_CLASS_MSG, "unknown")
$ (gdb) bt
#0  0x000000000085c681 in zend_mm_alloc_small (bin_num=8, size=79, heap=0x7f1cf8800040) at /usr/local/php-7.0.26/Zend/zend_alloc.c:1318
#1  zend_mm_alloc_heap (size=79, heap=0x7f1cf8800040) at /usr/local/php-7.0.26/Zend/zend_alloc.c:1389
#2  zend_mm_realloc_heap (heap=0x7f1cf8800040, ptr=0x0, size=79, copy_size=79) at /usr/local/php-7.0.26/Zend/zend_alloc.c:1485
#3  0x000000000086409e in _erealloc (ptr=0x0, size=79) at /usr/local/php-7.0.26/Zend/zend_alloc.c:2506
#4  0x00000000007f999c in xbuf_format_converter (xbuf=0x7ffeddbfe950, is_char=1 '\001', fmt=0xe356e5 "PHP %s:  %s in %s on line %d", ap=0x7ffeddbfe9a8) at /usr/local/php-7.0.26/main/spprintf.c:246
#5  0x00000000007fc799 in vspprintf (pbuf=0x7ffeddbfeb40, max_len=0, format=0xe356e5 "PHP %s:  %s in %s on line %d", ap=0x7ffeddbfe9a8) at /usr/local/php-7.0.26/main/spprintf.c:847
#6  0x00000000007fc8af in spprintf (pbuf=0x7ffeddbfeb40, max_len=0, format=0xe356e5 "PHP %s:  %s in %s on line %d") at /usr/local/php-7.0.26/main/spprintf.c:871
#7  0x00000000007f2fd3 in php_error_cb (type=2, error_filename=0x7f1cf886a068 "/share/docker/c/www/PHP-X-demo/args/tests/main.php", error_lineno=10, format=0xe4b424 "%s", args=0x7ffeddbfed40) at /usr/local/php-7.0.26/main/main.c:1122
#8  0x00000000008a398d in zend_error (type=2, format=0xe4b424 "%s") at /usr/local/php-7.0.26/Zend/zend.c:1172
#9  0x00000000008a468b in zend_internal_type_error (throw_exception=0 '\000', format=0xe4b520 "%s%s%s() expects %s %d parameter%s, %d given") at /usr/local/php-7.0.26/Zend/zend.c:1366
#10 0x00000000008a5476 in zend_wrong_paramers_count_error (num_args=2, min_num_args=1, max_num_args=1) at /usr/local/php-7.0.26/Zend/zend_API.c:205
#11 0x00007f1cf83ba69f in php::_check_args_num (data=0x7f1cf8813170, num_args=2) at /share/docker/c/www/PHP-X/src/base.cc:216
#12 0x00007f1cf83ba54e in php::_exec_method (data=0x7f1cf8813170, return_value=0x7f1cf8813110) at /share/docker/c/www/PHP-X/src/base.cc:194
#13 0x0000000000938799 in ZEND_DO_FCALL_SPEC_HANDLER () at /usr/local/php-7.0.26/Zend/zend_vm_execute.h:842
#14 0x0000000000934566 in execute_ex (ex=0x7f1cf8813030) at /usr/local/php-7.0.26/Zend/zend_vm_execute.h:414
#15 0x0000000000934efa in zend_execute (op_array=0x7f1cf887f000, return_value=0x0) at /usr/local/php-7.0.26/Zend/zend_vm_execute.h:458
#16 0x00000000008a4a6d in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/php-7.0.26/Zend/zend.c:1445
#17 0x00000000007f619f in php_execute_script (primary_file=0x7ffeddc01ac0) at /usr/local/php-7.0.26/main/main.c:2518
#18 0x0000000000a103f7 in do_cli (argc=2, argv=0x2144a20) at /usr/local/php-7.0.26/sapi/cli/php_cli.c:977
#19 0x0000000000a117bd in main (argc=2, argv=0x2144a20) at /usr/local/php-7.0.26/sapi/cli/php_cli.c:1347

worker模型

nginx架构

每个请求会占用一个线程，一个worker进程可以处理成千上万的请求。

nginx采用多worker的方式来处理请求，每个worker里面只有一个主线程，那能够处理的并发数很有限啊，多少个worker就能处理多少个并发，何来高并发呢？非也，这就是nginx的高明之处，nginx采用了异步非阻塞的方式来处理请求，也就是说，nginx是可以同时处理成千上万个请求的。

异步非阻塞的事件处理机制，具体到系统调用就是像select/poll/epoll/kqueue这样的系统调用。它们提供了一种机制，让你可以同时监控多个事件，调用他们是阻塞的，但可以设置超时时间，在超时时间之内，如果有事件准备好了，就返回。这种机制正好解决了我们上面的两个问题，拿epoll为例，当事件没准备好时，放到epoll里面，事件准备好了，我们就去读写，当读写返回EAGAIN时，我们将它再次加入到epoll里面。

nginx事件处理模型：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

while (true) {
    for t in run_tasks:
        t.handler();
    update_time(&now);
    timeout = ETERNITY;
    for t in wait_tasks: /* sorted already */
        if (t.time <= now) {
            t.timeout_handler();
        } else {
            timeout = t.time - now;
            break;
        }
    nevents = poll_function(events, timeout);
    for i in nevents:
        task t;
        if (events[i].type == READ) {
            t.handler = read_handler;
        } else { /* events[i].type == WRITE */
            t.handler = write_handler;
        }
        run_tasks_add(t);
}

connection

在这里，很多人会误解worker_connections这个参数的意思，认为这个值就是nginx所能建立连接的最大值。其实不然，这个值是表示每个worker进程所能建立连接的最大值，所以，一个nginx能建立的最大连接数，应该是worker_connections * worker_processes。当然，这里说的是最大连接数，对于HTTP请求本地资源来说，能够支持的最大并发数量是worker_connections * worker_processes，而如果是HTTP作为反向代理来说，最大并发数量应该是worker_connections * worker_processes/2。因为作为反向代理服务器，每个并发会建立与客户端的连接和与后端服务的连接，会占用两个连接。

1. location正则写法

一个示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

location  = / {
  # 精确匹配 / ，主机名后面不能带任何字符串
  [ configuration A ]
}
location  / {
  # 因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求
  # 但是正则和最长字符串会优先匹配
  [ configuration B ]
}
location /documents/ {
  # 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索
  # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条
  [ configuration C ]
}
location ~ /documents/Abc {
  # 匹配任何以 /documents/Abc 开头的地址，匹配符合以后，还要继续往下搜索
  # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条
  [ configuration CC ]
}
location ^~ /images/ {
  # 匹配任何以 /images/ 开头的地址，匹配符合以后，停止往下搜索正则，采用这一条。
  [ configuration D ]
}
location ~* \.(gif|jpg|jpeg)$ {
  # 匹配所有以 gif,jpg或jpeg 结尾的请求
  # 然而，所有请求 /images/ 下的图片会被 config D 处理，因为 ^~ 到达不了这一条正则
  [ configuration E ]
}
location /images/ {
  # 字符匹配到 /images/，继续往下，会发现 ^~ 存在
  [ configuration F ]
}
location /images/abc {
  # 最长字符匹配到 /images/abc，继续往下，会发现 ^~ 存在
  # F与G的放置顺序是没有关系的
  [ configuration G ]
}
location ~ /images/abc/ {
  # 只有去掉 config D 才有效：先最长匹配 config G 开头的地址，继续往下搜索，匹配到这一条正则，采用
    [ configuration H ]
}
location ~* /js/.*/\.js

以=开头表示精确匹配
如 A 中只匹配根目录结尾的请求，后面不能带任何字符串。
^~ 开头表示uri以某个常规字符串开头，不是正则匹配
~ 开头表示区分大小写的正则匹配;
~* 开头表示不区分大小写的正则匹配
/ 通用匹配, 如果没有其它匹配,任何请求都会匹配到
顺序 no优先级：
(location =) > (location 完整路径) > (location ^~ 路径) > (location ~,~* 正则顺序) > (location 部分起始路径) > (/)

上面的匹配结果
按照上面的location写法，以下的匹配示例成立：

/ -> config A
精确完全匹配，即使/index.html也匹配不了
/downloads/download.html -> config B
匹配B以后，往下没有任何匹配，采用B
/images/1.gif -> configuration D
匹配到F，往下匹配到D，停止往下
/images/abc/def -> config D
最长匹配到G，往下匹配D，停止往下
你可以看到 任何以/images/开头的都会匹配到D并停止，FG写在这里是没有任何意义的，H是永远轮不到的，这里只是为了说明匹配顺序
/documents/document.html -> config C
匹配到C，往下没有任何匹配，采用C
/documents/1.jpg -> configuration E
匹配到C，往下正则匹配到E
/documents/Abc.jpg -> config CC
最长匹配到C，往下正则顺序匹配到CC，不会往下到E

遇到了php-fpm register_shutdown_function()的一个bug：

1
2
3
4
5

echo "Expected:" . getcwd() . "<br>";
register_shutdown_function(function () {
    echo "In shutdown function:" . getcwd() . "<br>";
});

php-fpm输出如下

1
2

Expected:/var/www/html/test
In shutdown function:/

在cli模式下输出正常

1

Expected:/var/www/html/test<br>In shutdown function:/var/www/html/test<br>

去翻翻源码，找到getcwd的定义
函数定义的位置在：ext/standard/dir.c的364行

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

PHP_FUNCTION(getcwd)
{
    char path[MAXPATHLEN];
    char *ret=NULL;
    if (zend_parse_parameters_none() == FAILURE) {
        return;
    }
#if HAVE_GETCWD
    ret = VCWD_GETCWD(path, MAXPATHLEN);  //这里调用ZEND的方法，获取当前工作目录
#elif HAVE_GETWD
    ret = VCWD_GETWD(path);
#endif
    if (ret) {
        RETURN_STRING(path);
    } else {
        RETURN_FALSE;
    }
}

能愿动词

• 必须 (MUST) ：绝对，严格遵循，请照做，无条件遵守；
• 一定不可 (MUST NOT) ：禁令，严令禁止；
• 应该 (SHOULD) ：强烈建议这样做，但是不强求；
• 不该 (SHOULD NOT) ：强烈不建议这样做，但是不强求；
• 可以 (MAY) 和 可选 (OPTIONAL) ：选择性高一点，在这个文档内，此词语使用较少；

PSR-1（基础编码规范）

• PHP代码文件 必须 以 <?php 或 <?= 标签开始；

• PHP代码文件 必须 以 不带 BOM 的 UTF-8 编码；

• PHP代码中 应该 只定义类、函数、常量等声明，或其他会产生 副作用 的操作（如：生成文件输出以及修改 .ini 配置文件等），二者只能选其一；

• 命名空间以及类 必须 符合 PSR 的自动加载规范：PSR-4 中的一个；

• 类的命名 必须 遵循 StudlyCaps 大写开头的驼峰命名规范；

• 类中的常量所有字母都 必须 大写，单词间用下划线分隔；

• 方法名称 必须 符合 camelCase 式的小写开头驼峰命名规范。（这个类似于Java的命名方式）

工厂模式Factory（创建型）

工厂（Factory）负责组装生产产品，客户只需要告知工厂需要生产的产品即可获得产品。

建造者模式（创建型）

建造者模式是在工厂模式之上建立更加复杂的对象，在各个工厂生产出产品后再将每个产品进行组合

单例模式Singleton（创建型）

单例模式比较简单，保证对象是单例即可，在类中添加一个类似于get_instance()的方法获取对象

由于Ubuntu14.04源自带的Docker版本很旧，并且由于国内环境特殊原因在DockerHub上Pull镜像十分之慢，故作此文

下面看看实现的方法，先说升级：

升级

apt-get的安装方式

比较方便的方法就是通过包管理的方式安装了

首先添加docker仓库秘钥到本地：

1

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9

再将docker仓库添加到本地的软件源中：

1

sudo sh -c "echo deb https://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list"

最后执行更新一下软件源

1

sudo apt-get update

最后安装docker即可：

1

sudo apt-get install lxc-docker

设置加速器

由于国内网络原因，连接docker hub速度特别慢，特别是在不稳定的网络环境下
在使用加速器后下载镜像时长由原来的几个小时到现在的几十分钟，大大的提升了下载速度！
这里我们使用的是国内良心厂家DaoCloud免费提供的加速器

翻了下PHP内核的定义，大概心中也有了答案了

count()和strlen()都是O(1)的时间复杂度

试想一下如果strlen()需要O(N)的复杂度那未免也太慢了，字符串长度起来的话服务器不是要直接挂掉吗

这两个函数都是典型的空间换时间的做法

我们可以先看看zvalue的结构：

1
2
3
4
5
6
7
8
9
10
11

typedef union _zvalue_value {
   long lval;             /* long value */
   double dval;            /* double value */
   struct {
      char *val;
      int len;
   } str;
   HashTable *ht;          /* hash table value */
   zend_object_value obj;
   zend_ast *ast;
} zvalue_value;