最近遇到一个场景，服务寻址的时候，需要请求远程的服务，获取一批可用的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版本
另辟蹊径，使用别的本地内存存储方案
权衡之下，准备采取第二种做法，预知后事如何，且看下回分解~
