关于php的共享内存的使用和研究之由起

最近遇到一个场景,服务寻址的时候,需要请求远程的服务,获取一批可用的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的例子:

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
<?php
// 从系统获取一个共享内存的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的例子:

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
<?php
// 从系统获取一个共享内存的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的错误日志,结果一脸懵逼:

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

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

shm_remove_var($shareKey)

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

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

Alt text

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

Alt text

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

踩坑与解决

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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,发现有问题:

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
// 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版本
  • 另辟蹊径,使用别的本地内存存储方案

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

热评文章