最近遇到一个场景，服务寻址的时候，需要请求远程的服务，获取一批可用的ip和端口地址及其权重。根据权重和随机算法选择最合适的一个服务地址，进行请求。由于服务地址在短时间之内不会发生变化，因此为了避免无限制的进行寻址的请求，有必要将地址缓存至本地。

对于php而言，说到用户数据缓存本地，第一反应出来的就是APC。但是APC首先被创建出来是给php做内部缓存的，其次才是提供给用户态使用的。根据laruence在博客的说法，opcache出现了之后，对zend编译的opcode做了缓存，实际上解决了apc被创建出来想要解决的问题。因此现在APC已经处于不再更新维护的状态了。

对于想使用opcache，又要使用用户态的APC的同学，就需要额外的配置，同时性能上也会比原来的APC要差，差不多相当于本机的memcache。这显然就无法达到本机内存访问的效率了，因此需要寻求其他的解决方案。

php的共享内存API

随后我就想到了使用php的共享内存API，反正只是缓存非常少的路由信息，加在一起不超过1k，尽管是多读多写的场景，但是覆盖了也没关系，出于这种出发点，我就开始了对php的共享内存API的研究。

php中操作共享内存的方式一共有两组：

System V IPC

编译增加 --enable-sysvshm

Shared Memory

--enable-shmop

先来看一个shmop的例子：

// 从系统获取一个共享内存的id

$key = ftok(__FILE__, 'test');

$size = 1024;

// 打开1024字节的共享内存(如果不存在则申请)

$shm_h = @shmop_open($key, 'c', 0644, $size);

if($shm_h === false) {

echo "shmop open failed";

exit;

}

// 读取共享内存中的数据

$data = shmop_read($shm_h, 0, $size);

// 对读取的数据进行反序列化

$data = unserialize($data);

//如果没有数据则写入

if(empty($data)) {

echo "there is no data";

$data = "imdonkey";

//所有写入的数据，都必须提前序列化

$write_size = shmop_write($shm_h, serialize($data), 0);

if($write_size === false) echo "shmop write failed!";

}

//如果有，显示出来，之后删掉

else {

echo "shared memory data: ";

print_r($data);

shmop_delete($shm_h);

}

shmop_close($shm_h);

?>

使用shmop扩展，必须要注意数据的大小，以及读写时候的偏移量。同时，不管你写入的是什么数据类型，都必须进行序列化和反序列化。

再看一下SysV的例子：

// 从系统获取一个共享内存的id

$shm_key = ftok(__FILE__, 'test');

// 获取此共享内存资源的操作句柄

$memsize = 1024;

$shm_h = shm_attach($shm_key, $memsize, 0644);

if($shm_h === false) {

echo "shmop open failed";

exit;

}

// 获取共享内存中key=222时的内容

$var_key = 222;

$data = @shm_get_var($shm_h, $var_key);

if(empty($data)) {

$data = ['test'=>'here'];

echo "there is no data, insert $data.\n";

// 如果数据不存在，写入数据，可以是任意类型，无需初始化

shm_put_var($shm_h, $var_key, $data);

} else {

// 否则，输出数据，并清理相关内存

echo "find data: $data\n";

shm_remove_var($shm_h, $var_key);

}

// 断开资源的链接

shm_detach($shm_h);

?>

原理上来讲并无不同，只是SysV做了更多的封装，让你使用起来更加方便一些。不用自己控制偏移量，也不用进行序列化和反序列化。同时对于每个数据，都设置了对应的var_key, 这样在同一个区域可以保存多个数据，而无需再次申请另一片共享内存。

业务中的使用

在使用两者的时候，都要注意对数据大小的估算。否则很容易出现共享内存溢出的情况。而我在使用的时候，充分评估了要存储的数据结构的大小，我需要存储的内容是：

ip(15个字节以内)+port(8字节以内)+timestamp(15字节以内)+分隔符(3字节)=41字节

假设我调用100个后端服务。那么最高需要存储的路由信息就是4.1k大小。

出于这种考虑，我申请了1M的内存，觉得应该是够够的了。就这么悠哉哉的在线上跑了一个星期左右，有天没事到线上看了下php的错误日志，结果一脸懵逼：

屏幕快照 2016-12-25 下午2.51.26.png

什么情况，调用的后端服务一共才5个，共享内存这么快就写满了？？经过一个初步的判断之后，我得出的结论是：sysV的接口能力太差，对于shareKey没有做去重处理，而是每次都写入了新的key，这样就导致了共享内存的写入指针尽管是相同的shareKey，但是却不断的后移，最终导致共享内存被写爆，而寻址的请求全部都打到了寻址服务，还好它比较健壮，也有短时的缓存，才没有产生运营事故。

在得出了这么个结论之后，我修改了我的代码，在每次完成对shareKey内容的获取之后，增加了一行

shm_remove_var($shareKey)

同时写了一个脚本，把原有的共享内存id对应的内容清空，经过手工处理十台机器之后，再全量替换一把代码，打卡下班，感觉自己棒棒哒。

没想到，这才是悲剧的开始。就在当周的周六，吃着火锅，突然就有一台线上机器罢工了。机器服务狂core不止，打开系统配置的core文件输出之后，迅速占满磁盘，无奈之下，先让运维把机器摘掉，再进一步的分析。其他机器也出现了不同程度的core，线上失败率直线上升。

屏幕快照 2016-12-25 下午3.08.52.png

再把机器摘下来之后，看了一眼core文件，就发现，哎呀，闯祸了。

屏幕快照 2016-12-25 下午3.18.50.png

赶快恢复到没有remove的版本，至少还能撑一个星期，不至于程序core掉。

踩坑与解决

接下来开始仔细分析源码，发现sysV的扩展中，remove_var实现如下：

PHP_FUNCTION(shm_remove_var)

{

zval *shm_id;

long shm_key, shm_varpos;

sysvshm_shm *shm_list_ptr;

// 读取输入参数

if (SUCCESS != zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rl", &shm_id, &shm_key)) {

return;

}

SHM_FETCH_RESOURCE(shm_list_ptr, shm_id);

// 检查sharekey在共享内存中是否存在

shm_varpos = php_check_shm_data((shm_list_ptr->ptr), shm_key);

// 如果不存在，返回错误

if (shm_varpos < 0) {

php_error_docref(NULL TSRMLS_CC, E_WARNING, "variable key %ld doesn't exist", shm_key);

RETURN_FALSE;

}

// 如果存在，删除共享内存

php_remove_shm_data((shm_list_ptr->ptr), shm_varpos);

RETURN_TRUE;

}

咋一看没啥问题，但是深入看一下php_check_shm_data，发现有问题：

// ptr为整个共享内存区块的头指针

static long php_check_shm_data(sysvshm_chunk_head *ptr, long key)

{

long pos;

sysvshm_chunk *shm_var;

// 从头开始寻找

pos = ptr->start;

for (;;) {

// 找到最后了返回

if (pos >= ptr->end) {

return -1;

}

// 向前进一个内存区块，由当前区块的next指针决定

shm_var = (sysvshm_chunk*) ((char *) ptr + pos);

if (shm_var->key == key) {

return pos;

}

pos += shm_var->next;

if (shm_var->next <= 0 || pos < ptr->start) {

return -1;

}

}

return -1;

}

这个根本就是线程不安全的版本额，在高并发的场景下，非常有可能出现，对一个shareKey内是否存在数据的错误判断，根据swoole的多进程模型，进程A进行寻址，查看共享内存，发现shareKey对应的区块无数据，所以他准备进行写入，同时进程B之前已经检查了shareKey数据，发现shareKey数据已经过期，执行了remove操作。这时候进程A再想去写入的时候，就会发生不可避免的segmentation fault。

发现了这个问题之后，反过来去想当时为什么共享内存会被写满，也是一样的问题，都怪php_check_shm_data对key的判断线程不安全，所以不可避免的，高并发下一直会用重复的key不停的向前写入。当时申请了 12M的内存, 每秒500请求，swoole开了24个进程，假设碰撞概率是1/(24*500)=1/12000。每次写入的大小是4k*3(四个服务寻址)，程序设计的是五分钟进行一次put。

那么12M共享内存被写满的时间应该是12M/12k/(60min/5min)/24h = 3.6天左右。基本上只能撑个这么久。

所以呢，解决方向有两个：

实现一个有锁的共享内存API版本

另辟蹊径，使用别的本地内存存储方案

权衡之下，准备采取第二种做法，预知后事如何，且看下回分解~