发表于
字数统计 2.8k 字 | 阅读时长 12 分钟

大部分的传统FPM项目性能瓶颈在于每次请求重新创建ZendVM的开销、IO阻塞导致的上下文频繁切换。Swoole解决的就是这类问题。

这篇文章教大家如何让Swoole的HTTP服务器性能达到最大。

压测脚本如下，机器的配置是单核、2G内存、50G硬盘：

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
<?php

use Swoole\Http\Request;
use Swoole\Http\Response;

$process = new Swoole\Process(function (Swoole\Process $process) {
    $server = new Swoole\Http\Server('127.0.0.1', 9501, SWOOLE_BASE);
    $server->set([
        'log_file' => '/dev/null',
        'log_level' => SWOOLE_LOG_INFO,
        'worker_num' => swoole_cpu_num() * 2,
        // 'hook_flags' => SWOOLE_HOOK_ALL,
    ]);
    $server->on('workerStart', function () use ($process, $server) {
        $process->write('1');
    });
    $server->on('request', function (Request $request, Response $response) use ($server) {
        try {
            $redis = new Redis;
            $redis->connect('127.0.0.1', 6379);
            $greeter = $redis->get('greeter');
            if (!$greeter) {
                throw new RedisException('get data failed');
            }
            $response->end("<h1>{$greeter}</h1>");
        } catch (\Throwable $th) {
            $response->status(500);
            $response->end();
        }
    });
    $server->start();
});

if ($process->start()) {
    register_shutdown_function(function () use ($process) {
        $process::kill($process->pid);
        $process::wait();
    });
    $process->read(1);
    System('ab -c 256 -n 10000 -k http://127.0.0.1:9501/ 2>&1');
}

首先，我们创建了一个Swoole\Process对象，这个对象会开启一个子进程，在子进程中，我创建了一个HTTP Server，这个服务器是BASE模式的。除了BASE模式之外，还有一种PROCESS模式。在PROCESS模式下，套接字连接是在Master进程维持的，Master进程和Worker进程会多一层IPC通信的开销，但是，当Worker进程奔溃的时候，因为连接是在Master进程维持的，所以连接不会被断开。所以，Process模式适用于维护大量长连接的场景。BASE模式是在每个工作进程维持自己的连接，所以性能会比Master更好。并且，在HTTP Server下，BASE模式会更加的适用。

这里，我们将worker_num，也就是进程的数量设置为当前机器CPU核数的两倍。但是，在实际的项目中，我们需要不断的压测，来调整这个参数。

在workerStart的时候，也就是工作进程启动的时候，我们让子进程向管道中随意写入一个数据给父进程，父进程此时会读到一点数据，读到数据后，父进程才开始压测。

此时，压测的请求会进入onRequest回调。在这个回调中，我们创建了一个Redis客户端，这个客户端会连接Redis服务器，并请求一条数据。得到数据后，我们调用end方法来响应压测的请求。当错误时，我们返回一个错误码为500的响应。

在开始压测前，我们需要安装Redis扩展：

1
pecl install redis

然后php.ini配置中开启redis扩展即可。

我们还需要在Redis服务器里面插入一条数据：

1
2
3
4
5
127.0.0.1:6379> SET greeter swoole
OK
127.0.0.1:6379> GET greeter
"swoole"
127.0.0.1:6379>

OK，我们现在进行压测：

1
2
3
4
5
6
7
8
9
10
11
12
~/codeDir/phpCode/swoole/server # php server.php
Concurrency Level:      256
Time taken for tests:   2.293 seconds
Complete requests:      10000
Failed requests:        0
Keep-Alive requests:    10000
Total transferred:      1680000 bytes
HTML transferred:       150000 bytes
Requests per second:    4361.00 [#/sec] (mean)
Time per request:       58.702 [ms] (mean)
Time per request:       0.229 [ms] (mean, across all concurrent requests)
Transfer rate:          715.48 [Kbytes/sec] received

我们发现，现在的QPS比较低，只有4361.00。

因为，我们目前使用的Redis扩展是PHP官方的同步阻塞客户端，没有利用到协程（或者说异步的特性）。当进程去连接Redis服务器的时候，可能会阻塞整个进程，导致进程无法处理其他的连接，这样，这个HTTP Server处理请求的速度就不可能快。但是，这个压测结果会比FPM下好，因为Swoole是常驻进程的。

现在，我们来开启Swoole提供的RuntimeHook机制，也就是在运行时动态的将PHP同步阻塞的方法全部替换为异步非阻塞的协程调度的方法。我们只需要在server->set配置中加入一行即可：

1
'hook_flags' => SWOOLE_HOOK_ALL

此时，我们再来运行这个脚本：

1
2
3
4
5
6
7
8
9
10
11
Concurrency Level:      256
Time taken for tests:   1.643 seconds
Complete requests:      10000
Failed requests:        0
Keep-Alive requests:    10000
Total transferred:      1680000 bytes
HTML transferred:       150000 bytes
Requests per second:    6086.22 [#/sec] (mean)
Time per request:       42.062 [ms] (mean)
Time per request:       0.164 [ms] (mean, across all concurrent requests)
Transfer rate:          998.52 [Kbytes/sec] received

我们发现，此时的QPS还是有一定的提升的。（这里，视频中压测的时候，会夯住请求，导致QPS非常的低，但是我实际测试的时候没有发生这个情况，估计是和Redis服务器本身对连接个数的的配置有关）

但是，为了避免请求数量过多，导致创建连接个数过多的问题，我们可以使用一个Redis连接池来解决。（同步阻塞是没有Redis连接过多的问题的，因为一旦worker进程阻塞住了，那么后面的请求就不会继续执行了，也就不会创建新的Redis连接了。因此，在同步阻塞的模式下，Redis的连接数量最大是worker进程的个数）

现在，我们来实现一下Redis连接池：

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
class RedisQueue
{
    protected $pool;

    public function __construct()
    {
        $this->pool = new SplQueue;
    }

    public function get(): Redis
    {
        if ($this->pool->isEmpty()) {
            $redis = new \Redis();
            $redis->connect('127.0.0.1', 6379);
            return $redis;
        }
        return $this->pool->dequeue();
    }

    public function put(Redis $redis)
    {
        $this->pool->enqueue($redis);
    }

    public function close()
    {
        $this->pool = null;
    }
}

这里通过spl的队列实现的连接池。如果连接池中没有连接的时候，我们就新建一个连接，并且把创建的这个连接返回；如果连接池里面有连接，那么我们获取队列中前面的一个连接。当我们用完连接的时候，，就可以调用put方法归还连接。这样，我们就可以在一定程度上复用Redis的连接，缓解Redis服务器的压力，以及频繁创建Redis连接的开销也会降低。

我们现在使用这个连接池队列：

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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
<?php

use Swoole\Http\Request;
use Swoole\Http\Response;

$process = new Swoole\Process(function (Swoole\Process $process) {
    $server = new Swoole\Http\Server('127.0.0.1', 9501, SWOOLE_BASE);
    $server->set([
        'log_file' => '/dev/null',
        'log_level' => SWOOLE_LOG_INFO,
        'worker_num' => swoole_cpu_num() * 2,
        'hook_flags' => SWOOLE_HOOK_ALL,
    ]);
    $server->on('workerStart', function () use ($process, $server) {
        $server->pool = new RedisQueue;
        $process->write('1');
    });
    $server->on('request', function (Request $request, Response $response) use ($server) {
        try {
            $redis = $server->pool->get();
            // $redis = new Redis;
            // $redis->connect('127.0.0.1', 6379);
            $greeter = $redis->get('greeter');
            if (!$greeter) {
                throw new RedisException('get data failed');
            }
            $server->pool->put($redis);
            $response->end("<h1>{$greeter}</h1>");
        } catch (\Throwable $th) {
            $response->status(500);
            $response->end();
        }
    });
    $server->start();
});

if ($process->start()) {
    register_shutdown_function(function () use ($process) {
        $process::kill($process->pid);
        $process::wait();
    });
    $process->read(1);
    System('ab -c 256 -n 10000 -k http://127.0.0.1:9501/ 2>&1');
}

class RedisQueue
{
    protected $pool;

    public function __construct()
    {
        $this->pool = new SplQueue;
    }

    public function get(): Redis
    {
        if ($this->pool->isEmpty()) {
            $redis = new \Redis();
            $redis->connect('127.0.0.1', 6379);
            return $redis;
        }
        return $this->pool->dequeue();
    }

    public function put(Redis $redis)
    {
        $this->pool->enqueue($redis);
    }

    public function close()
    {
        $this->pool = null;
    }
}

我们在worker进程初始化的时候，创建了这个RedisQueue。然后在onRequest的阶段，从这个RedisQueue里面获取一个Redis连接。

现在，我们来进行压测：

1
2
3
4
5
6
7
8
9
10
11
Concurrency Level:      256
Time taken for tests:   1.188 seconds
Complete requests:      10000
Failed requests:        0
Keep-Alive requests:    10000
Total transferred:      1680000 bytes
HTML transferred:       150000 bytes
Requests per second:    8416.18 [#/sec] (mean)
Time per request:       30.418 [ms] (mean)
Time per request:       0.119 [ms] (mean, across all concurrent requests)
Transfer rate:          1380.78 [Kbytes/sec] received

QPS提升到了8416.18。

但是，通过splqueue实现的连接池是有缺陷的，因为这个队列是可以无限长的。这样，当并发量特别大的时候，还是会有可能创建非常多的连接，因为连接池里面可能始终都是空的。

这个时候，我们可以使用Channel来实现连接池。代码如下：

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
class RedisPool
{
    protected $pool;

    public function __construct(int $size = 100)
    {
        $this->pool = new \Swoole\Coroutine\Channel($size);
        for ($i = 0; $i < $size; $i++)
        {
            while (true) {
                try {
                    $redis = new \Redis();
                    $redis->connect('127.0.0.1', 6379);
                    $this->put($redis);
                    break;
                } catch (\Throwable $th) {
                    usleep(1 * 1000);
                    continue;
                }
            }
        }
    }

    public function get(): \Redis
    {
        return $this->pool->pop();
    }

    public function put(\Redis $redis)
    {
        $this->pool->push($redis);
    }

    public function close()
    {
        $this->pool->close();
        $this->pool = null;
    }
}

可以看到，我们在这个构造方法中，将这个Channel的size设置为这个传入的参数。并且，创建size个连接。这些连接会在初始化连接池的时候就被创建，处于就就绪状态。这个有好处也有坏处，坏处就是在每个进程初始化的时候，就会占用一些连接，但是此时的进程并不会接收连接。好处就是提前创建好了Redis连接，这样服务器响应的延迟就会降低。

虽然，其他地方的代码其实和RedisQueue的实现一样。但是，底层是和RedisQueue大有不同的。因为当Channel里面没有Redis连接的时候，会让当前的协程挂起，让其他的协程继续被执行。等有协程把Redis连接还回到连接池里面的时候，这个被挂起的协程才会继续执行。这就是协程协作的原理。

现在，我们修改服务器的代码：

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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
<?php

use Swoole\Http\Request;
use Swoole\Http\Response;

$process = new Swoole\Process(function (Swoole\Process $process) {
    $server = new Swoole\Http\Server('127.0.0.1', 9501, SWOOLE_BASE);
    $server->set([
        'log_file' => '/dev/null',
        'log_level' => SWOOLE_LOG_INFO,
        'worker_num' => swoole_cpu_num() * 2,
        'hook_flags' => SWOOLE_HOOK_ALL,
    ]);
    $server->on('workerStart', function () use ($process, $server) {
        $server->pool = new RedisPool(64);
        $process->write('1');
    });
    $server->on('request', function (Request $request, Response $response) use ($server) {
        try {
            $redis = $server->pool->get();
            // $redis = new Redis;
            // $redis->connect('127.0.0.1', 6379);
            $greeter = $redis->get('greeter');
            if (!$greeter) {
                throw new RedisException('get data failed');
            }
            $server->pool->put($redis);
            $response->end("<h1>{$greeter}</h1>");
        } catch (\Throwable $th) {
            $response->status(500);
            $response->end();
        }
    });
    $server->start();
});

if ($process->start()) {
    register_shutdown_function(function () use ($process) {
        $process::kill($process->pid);
        $process::wait();
    });
    $process->read(1);
    System('ab -c 256 -n 10000 -k http://127.0.0.1:9501/ 2>&1');
}

class RedisPool
{
    protected $pool;

    public function __construct(int $size = 100)
    {
        $this->pool = new \Swoole\Coroutine\Channel($size);
        for ($i = 0; $i < $size; $i++)
        {
            while (true) {
                try {
                    $redis = new \Redis();
                    $redis->connect('127.0.0.1', 6379);
                    $this->put($redis);
                    break;
                } catch (\Throwable $th) {
                    usleep(1 * 1000);
                    continue;
                }
            }
        }
    }

    public function get(): \Redis
    {
        return $this->pool->pop();
    }

    public function put(\Redis $redis)
    {
        $this->pool->push($redis);
    }

    public function close()
    {
        $this->pool->close();
        $this->pool = null;
    }
}

只需要修改workerStart里面的部分即可，其他地方不需要做修改。这样，每个进程最多只能创建64个Redis连接。

我们继续压测：

1
2
3
4
5
6
7
8
9
10
11
Concurrency Level:      256
Time taken for tests:   0.817 seconds
Complete requests:      10000
Failed requests:        0
Keep-Alive requests:    10000
Total transferred:      1680000 bytes
HTML transferred:       150000 bytes
Requests per second:    12234.30 [#/sec] (mean)
Time per request:       20.925 [ms] (mean)
Time per request:       0.082 [ms] (mean, across all concurrent requests)
Transfer rate:          2007.19 [Kbytes/sec] received

我们发现QPS还是有所提升的，为什么我的QPS没有视频里面的提升明显呢？这个和测试环境有关。我自己的机器已经无法再提升了。就好像学霸最高只可以考100分一样的道理。（实际上，经过我的测试，如果我调整连接池的最大连接数，QPS会有所提升）

发表于
字数统计 1.2k 字 | 阅读时长 5 分钟

感谢twosee大佬的点拨。

这篇文章，我们来讲一下PHP扩展开发的常见问题，引用计数管理。因为现有的书籍有些老旧，跟不上PHP的发展，所以很有必要学习一下。

PHP版本是7.3.5。

我们来写一个测试扩展函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
ZEND_BEGIN_ARG_INFO_EX(arginfo_study_test, 0, 0, 1)
    ZEND_ARG_ARRAY_INFO(0, arr, 0)
ZEND_END_ARG_INFO()

PHP_FUNCTION(test)
{
    zval *arr;

    if(zend_parse_parameters(ZEND_NUM_ARGS(), "a", &arr) == FAILURE){
        RETURN_FALSE;
    }
    RETURN_ARR(Z_ARR_P(arr));
}

这个函数做的事情很简单，接收一个数组，然后直接返回回去。

(小伙伴们自己记得注册一下创建的这个测试函数)

OK。我们编译、安装扩展：

1
2
3
4
5
6
7
8
9
~/codeDir/cppCode/study # make clean ; make ; make install
----------------------------------------------------------------------

Build complete.
Don't forget to run 'make test'.

Installing shared extensions:     /usr/local/lib/php/extensions/no-debug-non-zts-20180731/
Installing header files:          /usr/local/include/php/
~/codeDir/cppCode/study #

然后编写测试脚本：

1
2
3
4
5
6
7
8
9
10
11
<?php

$a = array("time" => time());
xdebug_debug_zval("a");
$b = test($a);
xdebug_debug_zval("a");
xdebug_debug_zval("b");

unset($a);

var_dump($b);

执行：

1
2
3
4
5
6
7
~/codeDir/cppCode/study # php test.php
a: (refcount=1, is_ref=0)=array ('time' => (refcount=0, is_ref=0)=1569290383)
a: (refcount=1, is_ref=0)=array ('time' => (refcount=0, is_ref=0)=1569290383)
b: (refcount=1, is_ref=0)=array ('time' => (refcount=0, is_ref=0)=1569290383)
/root/codeDir/cppCode/study/test.php:11:
&array
~/codeDir/cppCode/study #

我们发现，没有打印出$b这个数组。出现了bug，我们分析一下。

因为PHP对于复杂类型，例如字符串、数组、对象都是通过引用计数来管理的，不会拷贝出一个副本。所以，当我们在PHP脚本传递一个数组进入PHP扩展的时候，实际上只是增加了这个数组的引用计数。我们可以用gdb来调试一下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 34│ PHP_FUNCTION(test)
 35│ {
 36│     zval *arr;
 37│
 38│     if(zend_parse_parameters(ZEND_NUM_ARGS(), "a", &arr) == FAILURE){
 39│         RETURN_FALSE;
 40│     }
 41├───> RETURN_ARR(Z_ARR_P(arr));
 42│ }

(gdb) p *arr.value.arr
$3 = {gc = {refcount = 2, u = {type_info = 23}}, u = {v = {flags = 24 '\030', _unused = 0 '\000', nIteratorsCount = 0 '\000', _unused2 = 0 '\000'}, flags = 24}, nTableMask = 4294967280, arData = 0x7ffff76
66680, nNumUsed = 1, nNumOfElements = 1, nTableSize = 8, nInternalPointer = 0, nNextFreeElement = 0, pDestructor = 0x555555a46860 <zval_ptr_dtor>}
(gdb)

我们发现，在调用了zend_parse_parameters解析出PHP脚本传递过来的数组之后，这个数组的引用计数变成了2。这一步增加引用计数的操作是PHP底层自动帮我们做的。

然后，通过xdebug打印发现，从扩展里面返回数组到PHP脚本后，它的引用计数又变回了1。这一步也是PHP帮我们做的。

接下来，我们unset了$a，使得这个数组的引用计数变成了0。又因为$b和$a指向的是一个数组，所以，此时我们再使用$b，就会报错了。

以上bug会在动态生成数组时出现。如果我们初始的数组是一个不可变数组，那么，同样的代码是不会出现bug的。因为不可变数组的初始引用计数是2，而不是1。我们可以测试一下：

1
2
3
4
5
6
7
8
9
10
11
<?php

$a = array("time" => 1111);
xdebug_debug_zval("a");
$b = test($a);
xdebug_debug_zval("a");
xdebug_debug_zval("b");

unset($a);

var_dump($b);

我们把time对应的value写死为1111。然后执行脚本：

1
2
3
4
5
6
7
8
9
10
~/codeDir/cppCode/study # php test.php
a: (refcount=2, is_ref=0)=array ('time' => (refcount=0, is_ref=0)=1111)
a: (refcount=2, is_ref=0)=array ('time' => (refcount=0, is_ref=0)=1111)
b: (refcount=2, is_ref=0)=array ('time' => (refcount=0, is_ref=0)=1111)
/root/codeDir/cppCode/study/test.php:11:
array(1) {
  'time' =>
  int(1111)
}
~/codeDir/cppCode/study #

我们发现，因为不可变数组初始的引用计数是2，当我们对unset($a)之后，它的引用计数变成了1。此时，这个数组还是可以用的，所以后面使用$b不会报错。

正是因为从PHP脚本传入到扩展，以及从扩展传出到PHP脚本的那个数组是同一个，所以，$a和$b都是指向同一个数组的，因此，我们需要在扩展层面手动为这个数组的引用计数+1。所以，扩展代码应该改为：

1
2
3
4
5
6
7
8
9
10
PHP_FUNCTION(test)
{
    zval *arr;

    if(zend_parse_parameters(ZEND_NUM_ARGS(), "a", &arr) == FAILURE){
        RETURN_FALSE;
    }
    Z_TRY_ADDREF_P(arr);
    RETURN_ARR(Z_ARR_P(arr));
}

重新编译、安装扩展：

1
2
3
4
5
6
7
8
9
~/codeDir/cppCode/study # make clean ; make ; make install
----------------------------------------------------------------------

Build complete.
Don't forget to run 'make test'.

Installing shared extensions:     /usr/local/lib/php/extensions/no-debug-non-zts-20180731/
Installing header files:          /usr/local/include/php/
~/codeDir/cppCode/study #

测试脚本为：

1
2
3
4
5
6
7
8
9
10
11
<?php

$a = array("time" => time());
xdebug_debug_zval("a");
$b = test($a);
xdebug_debug_zval("a");
xdebug_debug_zval("b");

unset($a);

var_dump($b);

指向脚本：

1
2
3
4
5
6
7
8
9
10
~/codeDir/cppCode/study # php test.php
a: (refcount=1, is_ref=0)=array ('time' => (refcount=0, is_ref=0)=1569291353)
a: (refcount=2, is_ref=0)=array ('time' => (refcount=0, is_ref=0)=1569291353)
b: (refcount=2, is_ref=0)=array ('time' => (refcount=0, is_ref=0)=1569291353)
/root/codeDir/cppCode/study/test.php:11:
array(1) {
  'time' =>
  int(1569291353)
}
~/codeDir/cppCode/study #

我们发现，从扩展传回到PHP的时候，这个数组的引用计数变成了2。因此，当我们unset($a)之后，这个数组的引用计数变成了1。此时，我们再次使用$b就不会出错了。

发表于
字数统计 1.1k 字 | 阅读时长 5 分钟

这篇文章，我们来实战操作一下扩展的内存管理，感受一下内存泄漏，加深对PHP内存管理的理解。

首先，创建扩展目录：

1
~/codeDir/cCode/php-7.1.0/ext # ./ext_skel --extname=memory

然后进入目录：

1
~/codeDir/cCode/php-7.1.0/ext # cd memory/

替换文件config.m4为如下内容：

1
2
3
4
5
6
7
PHP_ARG_ENABLE(memory, whether to enable memory support,
Make sure that the comment is aligned:
[  --enable-memory           Enable memory support])

if test "$PHP_MEMORY" != "no"; then
  PHP_NEW_EXTENSION(memory, memory.c, $ext_shared,, -DZEND_ENABLE_STATIC_TSRMLS_CACHE=1)
fi

然后编辑文件memory.c里面的PHP_FUNCTION(confirm_memory_compiled)方法：

1
2
3
4
PHP_FUNCTION(confirm_memory_compiled)
{
  void *foo = malloc(2 * 1024 * 1024);
}

这里，我们定义了一个PHP函数confirm_memory_compiled。它做的事情很简单，就是从堆中申请一块2M的内存，并且没有主动释放。

接着，编译、安装扩展：

1
2
~/codeDir/cCode/php-7.1.0/ext/memory # phpize ; ./configure
~/codeDir/cCode/php-7.1.0/ext/memory # make ; make install

然后把扩展加入配置文件里面：

1
extension=memory.so

然后确认是否安装扩展成功：

1
2
3
4
5
6
~/codeDir/cCode/php-7.1.0/ext/memory # php --ri memory

memory

memory support => enabled
~/codeDir/cCode/php-7.1.0/ext/memory #

然后编写测试脚本：

1
2
<?php
confirm_memory_compiled();

执行脚本：

1
2
~/codeDir/cCode/php-7.1.0/ext/memory # php memory.php
~/codeDir/cCode/php-7.1.0/ext/memory #

没有报错，说明我们的脚本正常执行了。

接着，我们启动一个PHP自带的服务器：

1
2
3
4
5
~/codeDir/cCode/php-7.1.0/ext/memory # php -S 127.0.0.1:80 -t ./
PHP 7.3.5 Development Server started at Mon Sep 23 13:08:13 2019
Listening on http://127.0.0.1:80
Document root is /root/codeDir/cCode/php-7.1.0/ext/memory
Press Ctrl-C to quit.

然后，另起一个终端，执行top命令，用来观察PHP进程的内存使用情况：

1
35247 root      20   0   27.8m  14.7m   0.0   0.7   0:00.02 S  `- php -S 127.0.0.1:80 -t ./

可以看到，在启动服务器的时候，PHP占用了27.8M的内存。

我们请求一次我们的服务器：

1
~/codeDir/cppCode/study # curl 127.0.0.1/memory.php

然后查看PHP占的内存：

1
13713 root      20   0   29.8m  14.9m   0.0   0.7   0:00.01 S  `- php -S 127.0.0.1:80 -t ./

我们发现PHP多占了2M的内存。

我们再请求一次：

1
~/codeDir/cppCode/study # curl 127.0.0.1/memory.php

然后再次查看PHP占的内存：

1
13713 root      20   0   31.8m  15.0m   0.0   0.8   0:00.03 S  `- php -S 127.0.0.1:80 -t ./

我们发现PHP又多占了2M的内存。

所以说，如果我们在一次请求的生命周期通过malloc分配了内存，但是没有释放，那么就会造成PHP整个生命周期的内存泄漏。

我们修改扩展函数：

1
2
3
4
PHP_FUNCTION(confirm_memory_compiled)
{
  void *foo = emalloc(2 * 1024 * 1024);
}

然后，重新编译、安装扩展：

1
~/codeDir/cCode/php-7.1.0/ext/memory # make clean ; make ; make install

重新启动服务器：

1
2
3
4
5
~/codeDir/cCode/php-7.1.0/ext/memory # php -S 127.0.0.1:80 -t ./
PHP 7.3.5 Development Server started at Mon Sep 23 14:27:22 2019
Listening on http://127.0.0.1:80
Document root is /root/codeDir/cCode/php-7.1.0/ext/memory
Press Ctrl-C to quit.

此时，PHP进程占用的内存：

1
14470 root      20   0   27.8m  14.6m   0.0   0.7   0:00.01 S  `- php -S 127.0.0.1:80 -t ./

然后，我们请求一次服务器：

1
~/codeDir/cppCode/study # curl 127.0.0.1/memory.php

查看PHP内存占用情况：

1
14470 root      20   0   27.8m  15.2m   0.0   0.8   0:00.02 S  `- php -S 127.0.0.1:80 -t ./

发现，没有增长。

再次请求服务器：

1
~/codeDir/cppCode/study # curl 127.0.0.1/memory.php

再次查看PHP内存占用情况：

1
14470 root      20   0   27.8m  15.2m   0.7   0.8   0:00.03 S  `- php -S 127.0.0.1:80 -t ./

发现还是没有增长。

所以说，如果我们在一次请求的生命周期中通过emalloc分配了内存，但是没有释放，那么在PHP整个生命周期是不会造成内存泄漏的。因为在请求结束的时候，PHP会自动帮我们释放掉这些内存。但是，在一次请求中，如果一直不自己释放内存，那么这次请求很可能会内存不够，导致PHP进程挂掉。

以上对malloc和emalloc的分析适用于FPM模式。但是对于Swoole这类扩展，接管了PHP的请求生命周期，所有对Swoole的请求都是在同一个请求生命周期里面，并且，这个请求生命周期一直不会结束。所以，就算我们使用了emalloc这类内存管理器，如果没有主动释放，也是会造成内存泄漏的，因为此时PHP的请求生命周期不会结束，因此PHP不会自己帮我们去释放这些内存。

发表于
字数统计 851 字 | 阅读时长 3 分钟

为了给我们的扩展实现Channel做准备，这里，很有必要简单分析一下Swoole协程的Channel实现原理。核心点如下：

1
2
3
4
5
6
1、什么情况下可以pop
2、当channel不可以pop的时候，应该如何处理消费者协程
3、什么情况下可以push
4、当channel不可以push的时候，应该如何处理生产者协程
5、当channel可以pop的时候，应该如何通知消费者协程
6、当channel可以push的时候，应该如何通知生产者协程

如果解决了这些问题，就可以去实现Channel了。

什么情况下可以pop

这个问题很简单，当channel里面有数据的时候。我们来看看Swoole对应的源码，在方法Channel::pop(double timeout)里面：

1
2
void *data = data_queue.front();
data_queue.pop();

消费者协程和生产者协程

我们定义一个协程是消费者协程还是生产者协程，取决于这个协程正在执行哪种操作。如果这个协程此时正在执行pop操作，那么这个协程此时就是消费者协程；如果这个协程此时正在执行push操作，那么这个协程此时就是生产者协程。也就是说，协程是生产者还是消费者不是死的，是会随着协程的操作动态变化的。

当channel不可以pop的时候，应该如何处理消费者协程

当channel不可以pop的时候，我们应该挂起这个消费者协程。我们来看看Swoole对应的代码：

1
2
3
4
5
6
if (is_empty() || !consumer_queue.empty())
{
    // 省略其他代码
    yield(CONSUMER);
    // 省略其他代码
}

我们可以看到，当Channel为空的时候，消费者协程是不可以进行pop操作的，此时被yield出去了。

什么情况下可以push

这个问题很简单，当channel容器没有满的时候。我们来看看Swoole对应的源码，在方法Channel::push(void *data, double timeout)里面：

1
2
data_queue.push(data);
swTraceLog(SW_TRACE_CHANNEL, "push data to channel, count=%ld", length());

当channel不可以push的时候，应该如何处理生产者协程

当channel不可以push的时候，我们应该挂起这个生产者协程。我们来看看Swoole对应的代码：

1
2
3
4
5
6
if (is_full() || !producer_queue.empty())
{
    // 省略其他的代码
    yield(PRODUCER);
    // 省略其他的代码
}

我们可以看到，当Channel满了的时候，生产者协程是不可以进行push操作的，此时被yield出去了。

当channel可以pop的时候，应该如何通知消费者协程

首先，我们这里需要明白，是谁在通知消费者协程。是Swoole的那套事件循环吗？不是的。

通知消费这协程的是生产者协程。我们来看看pop的逆操作push的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
/**
 * push data
 */
data_queue.push(data);
swTraceLog(SW_TRACE_CHANNEL, "push data to channel, count=%ld", length());
/**
 * notify consumer
 */
if (!consumer_queue.empty())
{
    Coroutine *co = pop_coroutine(CONSUMER);
    co->resume();
}

可以看到，当生产者协程push完数据的时候，此时channel必定是有数据的。然后，如果有消费者协程在等待channel的话，那么就唤醒第一个等待的那个消费者协程。（所以规则是：谁先等待channel，谁就先被唤醒）

当channel可以push的时候，应该如何通知生产者协程

这个的原理和上一个问题的答案类似，不重复说了。一句话：消费者通知的生产者协程。

发表于
字数统计 1.4k 字 | 阅读时长 6 分钟

我们先来看一段代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/wait.h>

int main()
{
    pid_t id;

    id = fork();
    if (id == 0)
    {
        printf("Hello from Child!, pid: %d\n", getpid());
    }
    else
    {
        printf("Hello from Parent!, pid: %d\n", getpid());
    }

    return 0;
}

执行结果如下：

1
2
3
4
~/codeDir/cCode/test # ./a.out
Hello from Parent!, pid: 2290
Hello from Child!, pid: 2291
~/codeDir/cCode/test #

我们看看进程状态：

1
2
3
4
~/codeDir # ps -a
  PID TTY          TIME CMD
 2292 pts/2    00:00:00 ps
~/codeDir #

我们发现，进程直接退出了。

然后，我们再来看一段代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/wait.h>

int main()
{
    pid_t id;

    id = fork();
    if (id == 0)
    {
        printf("Hello from Child!, pid: %d\n", getpid());
        sleep(-1);
    }
    else
    {
        printf("Hello from Parent!, pid: %d\n", getpid());
    }

    return 0;
}

我们让子进程无限阻塞住，然后父进程先退出。执行结果如下：

1
2
3
4
~/codeDir/cCode/test # ./a.out
Hello from Parent!, pid: 2314
Hello from Child!, pid: 2315
~/codeDir/cCode/test #

我们发现，终端不会卡住，而是直接退出了。说明，终端是否会卡住，是由父进程是否退出决定的。然后，我们看看进程状态：

1
2
3
4
5
~/codeDir # ps -a
  PID TTY          TIME CMD
 2315 pts/4    00:00:00 a.out
 2316 pts/2    00:00:00 ps
~/codeDir #

我们发现，此时子进程（PID是2315）还存在。因为进程2315的父进程2314不在了，所以进程2315会变成孤儿进程，此时，它的父进程会变成init进程。

此时，我们可以通过wait函数来等待子进程的结束：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/wait.h>

int main()
{
    pid_t id;

    id = fork();
    if (id == 0)
    {
        printf("Hello from Child!, pid: %d\n", getpid());
        sleep(-1);
    }
    else
    {
        wait(NULL);
        printf("Hello from Parent!, pid: %d\n", getpid());
    }

    return 0;
}

其中，wait可以等待子进程结束。代码执行结果如下：

1
2
~/codeDir/cCode/test # ./a.out
Hello from Child!, pid: 2327

我们发现，此时的终端没有直接退出。我们查看一下进程状态：

1
2
3
4
5
6
~/codeDir # ps -a
  PID TTY          TIME CMD
 2326 pts/4    00:00:00 a.out
 2327 pts/4    00:00:00 a.out
 2329 pts/2    00:00:00 ps
~/codeDir #

我们发现，父进程和子进程都没挂掉。正是因为我们子进程一直没有退出，所以父进程阻塞在了wait这个地方。

我们再来看一段代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/wait.h>

int main()
{
    pid_t id;

    id = fork();
    if (id == 0)
    {
        printf("Hello from Child!, pid: %d\n", getpid());
    }
    else
    {
        printf("Hello from Parent!, pid: %d\n", getpid());
        sleep(-1);
    }

    return 0;
}

目的是，子进程退出后，父进程一直阻塞住不退出。

执行结果如下：

1
2
3
~/codeDir/cCode/test # ./a.out
Hello from Parent!, pid: 2337
Hello from Child!, pid: 2338

因为父进程没有退出，所以终端会被卡住。此时，我们看看进程状态。

1
2
3
4
5
6
~/codeDir # ps -a
  PID TTY          TIME CMD
 2337 pts/4    00:00:00 a.out
 2338 pts/4    00:00:00 a.out <defunct>
 2339 pts/2    00:00:00 ps
~/codeDir #

我们发现，这里依然会看到子进程2338的信息，为什么呢？因为这个子进程目前是一个僵尸进程。我们发现这个进程旁边有一个标识defunct，代表这个进程执行完了它的任务，已经挂了，但是，这个进程的一些基本信息依然保存着。这个僵尸进程的信息依旧被内核保存在进程表里面。

我们现在用kill命令给僵尸进程发送信号看看：

1
2
3
4
5
6
7
~/codeDir # kill 2338
~/codeDir # ps -a
  PID TTY          TIME CMD
 2337 pts/4    00:00:00 a.out
 2338 pts/4    00:00:00 a.out <defunct>
 2342 pts/2    00:00:00 ps
~/codeDir #

我们发现，这个僵尸进程还是会被查找到？为什么呢？因为这个僵尸进程本来就是死的，当然kill会失效。那么，我们如何去避免这个问题呢？

可以用wait函数。wait函数除了可以等待子进程的结束，其实还可以获取到子进程的信息。这也是为什么一个子进程挂了之后，它的基本信息不会立马被内核清除的原因，因为，操作系统认为父进程会在某个时候要用到子进程的一些信息，例如子进程的退出状态。只有当父进程获取完子进程的信息之后，操作系统才会清理子进程残留的信息。而操作系统如何知道父进程读取过子进程的信息呢？那就是wait函数。实际上，wait函数可以传入一个获取子进程信息的结构体，只不过我们的代码没有去获取而已，说明此时我们是不关心子进程的状态的。

分析完之后，我们来看下一段代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/wait.h>

int main()
{
    pid_t id;

    id = fork();
    if (id == 0)
    {
        printf("Hello from Child!, pid: %d\n", getpid());
        sleep(1);
    }
    else
    {
        wait(NULL);
        printf("Hello from Parent!, pid: %d\n", getpid());
        sleep(-1);
    }

    return 0;
}

这里，我们的父进程会去调用wait函数，等待子进程结束。等子进程执行完毕之后，父进程才回去执行。一旦父进程调用了wait函数，操作系统就知道父进程获取过子进程的信息，因此，操作系统就可以放心的去清理僵尸进程的残留信息了。

我们执行代码：

1
2
3
~/codeDir/cCode/test # ./a.out
Hello from Child!, pid: 2350
Hello from Parent!, pid: 2349

我们看看进程的状态：

1
2
3
4
5
~/codeDir # ps -a
  PID TTY          TIME CMD
 2349 pts/4    00:00:00 a.out
 2351 pts/2    00:00:00 ps
~/codeDir #

我们发现，子进程2350不再出现在进程状态列表里面了，说明子进程已经被清理完毕了。

发表于
字数统计 331 字 | 阅读时长 1 分钟

有一个需求，是把表里面所有的数据都查询出来，并且生成json文件。因为一张表里面的数据很多，所以不可能一次性全部查询出来，所以需要用到chunk。之前用的gorm，但是发现gorm没有chunk方式的查询。如果要自己去实现这种操作，就需要去管理偏移量，而且还容易出现bug，所以就找了一个库，叫做gorose。用起来挺舒服的。

代码如下：

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
package main

import (
    "fmt"

    "github.com/gohouse/gorose"
)

// User struct
// type User struct {
//  ID       int
//  UserName string
// }

const (
    dbHost     = "tcp(host.docker.internal:3306)"
    dbName     = "test"
    dbUser     = "root"
    dbPassword = "123456"
)

func main() {
    dsn := dbUser + ":" + dbPassword + "@" + dbHost + "/" + dbName + "?charset=utf8"
    var dbConfig = gorose.DbConfigSingle{
        Driver: "mysql",
        Dsn:    dsn,
    }

    connection, err := gorose.Open(&dbConfig)
    if err != nil {
        fmt.Println(err)
        return
    }

    session := connection.NewSession()

    user := session.Table("users")
    user.Fields("id", "username", "number").Chunk(2, func(data []map[string]interface{}) {
    fmt.Println(data)
    })
}

执行结果如下：

1
2
3
4
5
~/codeDir/golangCode/test # go run main.go
[map[id:1 username:a number:1] map[id:2 username:b number:2]]
[map[number:3 id:3 username:c] map[id:4 username:d number:4]]
[map[id:5 username:e number:5]]
~/codeDir/golangCode/test #

可以看出，每次都会查询出2条记录。

这个框架一个缺点就是文档不是很清楚，报错也有点不习惯。但是先用这个库解决一下chunk查询的问题吧。

发表于
字数统计 317 字 | 阅读时长 1 分钟

为了让我创作出来的PHP协程扩展教程更加的好，所以我把扩展里src的代码抽离了出来，并且可以编译出一个动态链接库，仓库地址。

这里简单的演示一下，同学们可以下载下来玩一玩。

首先，我们需要把fsw编译为动态链接库：

1
2
3
~/codeDir/cppCode/fsw # cmake .
~/codeDir/cppCode/fsw # make
~/codeDir/cppCode/fsw # make install

然后，我们先写一个创建协程的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#include <iostream>
#include "fsw/coroutine.h"

using namespace Fsw;
using namespace std;

int main(int argc, char const *argv[])
{
    Coroutine::create([](void *arg)
    {
        cout << "co1" << endl;
    });

    Coroutine::create([](void *arg)
    {
        cout << "co2" << endl;
    });

    return 0;
}

然后进行编译、运行：

1
2
3
4
5
~/codeDir/cppCode/fsw/examples # g++ create.cc -lfsw
~/codeDir/cppCode/fsw/examples # ./a.out 
co1
co2
~/codeDir/cppCode/fsw/examples #

然后，我们再写一段协程sleep的代码：

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
#include <iostream>
#include "fsw/coroutine.h"

using namespace Fsw;
using namespace std;

int main(int argc, char const *argv[])
{
    Coroutine::create([](void *arg)
    {
        cout << "co1" << endl;
        Coroutine::sleep(0.3);
        cout << "co1" << endl;
    });

    Coroutine::create([](void *arg)
    {
        cout << "co2" << endl;
        Coroutine::sleep(1);
        cout << "co2" << endl;
    });

    Coroutine::scheduler();
    
    return 0;
}

然后进行编译、运行：

1
2
3
4
5
6
7
~/codeDir/cppCode/fsw/examples # g++ sleep.cc -lfsw
~/codeDir/cppCode/fsw/examples # ./a.out 
co1
co2
co1
co2
~/codeDir/cppCode/fsw/examples #

发表于
字数统计 598 字 | 阅读时长 2 分钟

今天，在看Swoole的commit的时候，看到了一个commitf413593。

代码如下：

1
2
3
4
5
inline size_t count()
{
    unique_lock<mutex> lock(_mutex);
    return _queue.size();
}

也就是使用了unique_lock，之前没见过。并且，这里我只看到了加锁的过程，没看到解锁的过程，所以比较好奇。于是搜了一下，得到如下答案：

1
2
3
When you want to lock a mutex, you create a local variable of type std::unique_lock passing the mutex as parameter. When the unique_lock is constructed it will lock the mutex, and it gets destructed it will unlock the mutex. More importantly: If a exceptions is thrown, the std::unique_lock destructer will be called and so the mutex will be unlocked.

当需要锁定mutex时，可以创建一个 std::unique_lock 类型的局部变量，将 mutex 作为参数传递。当这个 unique_lock 被构造出来时，它会锁定 mutex，当 unique_lock 被析构的时候，它会解锁 mutex。 更重要的是: 如果抛出异常，将调用     std::unique_lock destructer，从而解锁 mutex。

这里写一个完整的例子：

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
#include <mutex>
#include <thread>
#include <iostream>
#include <vector>

using namespace std;
 
int some_shared_var = 0;

void func()
{
    int a = 1;

    some_shared_var += a;
}

int main()
{
    size_t count = 10000;
    vector<thread> threads;

    for (size_t i = 0; i < count; i++)
    {
        threads.push_back(thread(func));
    }

    for (size_t i = 0; i < count; i++)
    {
        threads[i].join();
    }

    cout << some_shared_var << endl;
}

这里，我们创建了10000个线程来执行func函数里面的代码。但是，在写入线程间共享的变量some_shared_var的时候我们没有去保护它，而是任由线程间去竞争执行。

我们来编译运行下代码：

1
2
3
4
5
~/codeDir/cppCode/test # g++ mutex.cpp ; ./a.out ; ./a.out ; ./a.out 
9998
9999
9999
~/codeDir/cppCode/test #

我们发现，这个共享的变量累加出错了，我们期待的值应该是10000。

然后，我们使用下unique_lock：

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
#include <mutex>
#include <thread>
#include <iostream>
#include <vector>

using namespace std;
 
int some_shared_var = 0;
mutex my_mutex;

void func()
{
    int a = 1;

    unique_lock<mutex> lock(my_mutex);
    some_shared_var += a;
}

int main()
{
    size_t count = 10000;
    vector<thread> threads;

    for (size_t i = 0; i < count; i++)
    {
        threads.push_back(thread(func));
    }

    for (size_t i = 0; i < count; i++)
    {
        threads[i].join();
    }

    cout << some_shared_var << endl;
}

在函数func中，

1
unique_lock<mutex> lock(my_mutex);

后面的代码都是安全的。所以：

1
some_shared_var += a;

这一行代码就是线程安全的。

我们编译运行下：

1
2
3
4
5
~/codeDir/cppCode/test # g++ mutex.cpp ; ./a.out ; ./a.out ; ./a.out 
10000
10000
10000
~/codeDir/cppCode/test #

最后，c++有点好用鸭，有些喜欢了，慢慢学习中。

发表于
字数统计 1.7k 字 | 阅读时长 7 分钟

昨天，我们在使用gqlgen的时候，发现它默认没有int64类型的标量，只有int类型的标量。所以需要自定义一个int64标量。

先说一下自定义标量的原理吧，这个在文档里面没有去解释，只是给出了一段代码，其他的就要自己去理解了。

自定义标量的原理就是，前端传递一个字符串，然后gqlgen会自动调用我们实现的解析函数，去解析这个字符串，得到我们想要的类型。

现在，我们来实战一下。我们初始化项目：

1
2
3
~/codeDir/golangCode # mkdir scalars ; cd scalars ; go mod init scalars
go: creating new go.mod: module scalars
~/codeDir/golangCode/scalars #

这里，我们是通过go module这个包依赖管理工具来管理的。

因为gqlgen是先定义schema的然后再生成代码的，所以，我们需要先定义好我们的schema。我们先创建文件：

1
~/codeDir/golangCode/scalars # touch schema.graphql

内容如下：

1
2
3
4
5
6
7
type Article {
  id: ID!
  text: String!
}
type Query {
  article: Article!
}

这里，我们简单的定义了一个类型Article和一个查询article。

OK，现在我们来生成一下我们的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
~/codeDir/golangCode/scalars # gqlgen init
Exec "go run ./server/server.go" to start GraphQL server
~/codeDir/golangCode/scalars # tree
.
├── generated.go
├── go.mod
├── go.sum
├── gqlgen.yml
├── models_gen.go
├── resolver.go
├── schema.graphql
└── server
    └── server.go

1 directory, 8 files
~/codeDir/golangCode/scalars #

我们可以在resolver.go的Article函数里面写我们的查询，这里，我们简单的返回一条记录即可：

1
2
3
4
5
6
func (r *queryResolver) Article(ctx context.Context) (*Article, error) {
	return &Article{
		ID:   "1",
		Text: "I am codinghuang",
	}, nil
}

然后，我们启动服务器：

1
2
~/codeDir/golangCode/scalars # go run server/server.go 
2019/08/30 02:04:46 connect to http://localhost:8080/ for GraphQL playground

然后，我们在浏览器里面做如下请求：

1
2
3
4
5
6
7
# Write your query or mutation here
query {
  article {
    id
    text
  }
}

我们将会得到如下结果：

1
2
3
4
5
6
7
8
{
  "data": {
    "article": {
      "id": "1",
      "text": "I am codinghuang"
    }
  }
}

现在，我们来给article增加一个查询参数，比如说时间，我们这里假定是int64这个标量。我们修改schema：

1
2
3
4
5
6
7
8
9
10
11
scalar Int64

type Article {
  id: ID!
  text: String!
  time: Int64!
}

type Query {
  article (time: Int64): Article!
}

然后，我们需要去实现这个Int64标量。我们创建一个新的文件，叫做int64.go：

1
~/codeDir/golangCode/scalars # touch int64.go

内容如下：

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

import (
	"io"
)

// Int64 is int64
type Int64 int64

// UnmarshalGQL implements the graphql.UnMarshaler interface
func (i *Int64) UnmarshalGQL(v interface{}) error {
	return nil
}

// MarshalGQL implements the graphql.Marshaler interface
func (i Int64) MarshalGQL(w io.Writer) {
	return
}

我们需要去实现这里的UnmarshalGQL函数和MarshalGQL函数。这里，我们先简单的做个小测试，实现如下：

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

import (
	"io"
)

// Int64 is int64
type Int64 int64

// UnmarshalGQL implements the graphql.UnMarshaler interface
func (i *Int64) UnmarshalGQL(v interface{}) error {
	*i = 10
	return nil
}

// MarshalGQL implements the graphql.Marshaler interface
func (i Int64) MarshalGQL(w io.Writer) {
	w.Write([]byte("5"))
	return
}

然后，我们需要去修改gqlgen.yml文件，指明我们的这个自定义的标量：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# .gqlgen.yml example
#
# Refer to https://gqlgen.com/config/
# for detailed .gqlgen.yml documentation.

schema:
- schema.graphql
exec:
  filename: generated.go
model:
  filename: models_gen.go
resolver:
  filename: resolver.go
  type: Resolver
models:
  Int64:
    model: scalars.Int64

然后，我们需要把resolver.go文件删除：

1
~/codeDir/golangCode/scalars # rm resolver.go

然后重新生成：

1
~/codeDir/golangCode/scalars # gqlgen

我们会发现，此时Article这个queryResolver多了一个参数time *Int64，注意，这里的Int64是我们scalars包下自定义的那个Int64，而不是golang自带的那个int64。

OK，我们重新写一下这个Article函数：

1
2
3
4
5
6
7
8
func (r *queryResolver) Article(ctx context.Context, time *Int64) (*Article, error) {
	fmt.Println(*time)
	return &Article{
		ID:   "1",
		Text: "I am codinghuang",
		Time: *time,
	}, nil
}

然后，我们重新启动服务器：

1
2
~/codeDir/golangCode/scalars # go run server/server.go 
2019/08/30 02:23:25 connect to http://localhost:8080/ for GraphQL playground

我们发起如下请求，我们传递了一个时间参数"1"：

1
2
3
4
5
6
7
8
# Write your query or mutation here
query {
  article (time: "1") {
    id
    text
    time
  }
}

会得到如下的结果：

1
2
3
4
5
6
7
8
9
{
  "data": {
    "article": {
      "id": "1",
      "text": "I am codinghuang",
      "time": 5
    }
  }
}

我们发现，返回的这个时间5实际上就是我们在int64.go文件里面实现的：

1
2
3
4
func (i Int64) MarshalGQL(w io.Writer) {
	w.Write([]byte("5"))
	return
}

也就是说，我们w io.Writer里面写了什么内容，就会返回给前端。

我们再看看终端的输出：

1
2
3
~/codeDir/golangCode/scalars # go run server/server.go 
2019/08/30 02:28:40 connect to http://localhost:8080/ for GraphQL playground
10

打印出了10，而不是客户端传递给服务器的1。这个10其实就是我们再int64.go文件里面实现的：

1
2
3
4
5
// UnmarshalGQL implements the graphql.UnMarshaler interface
func (i *Int64) UnmarshalGQL(v interface{}) error {
	*i = 10
	return nil
}

也就是说，我们在*i里面填写的值，可以被Article queryResolver的time *Int64获取到。

OK，那我们如何获取到前端传递过来的time呢？

我们对int.go里面的UnmarshalGQL函数做如下修改：

1
2
3
4
5
6
7
8
9
10
11
// UnmarshalGQL implements the graphql.UnMarshaler interface
func (i *Int64) UnmarshalGQL(v interface{}) error {
	str, ok := v.(string)
	if !ok {
		return errors.New("time must be string")
	}
	n, err := strconv.ParseInt(str, 10, 64)

	*i = Int64(n)
	return err
}

也就是说，前端传递给服务器的参数，我们可以在v interface{}里面获取到。

然后重新启动服务器：

1
2
~/codeDir/golangCode/scalars # go run server/server.go 
2019/08/30 02:36:26 connect to http://localhost:8080/ for GraphQL playground

然后做如下请求：

1
2
3
4
5
6
7
8
# Write your query or mutation here
query {
  article (time: 1) {
    id
    text
    time
  }
}

结果：

1
2
3
4
5
6
7
8
9
10
11
{
  "errors": [
    {
      "message": "time must be string",
      "path": [
        "article"
      ]
    }
  ],
  "data": null
}

因为我们在UnmarshalGQL里面限定了time必须为string。

我们修改请求如下：

1
2
3
4
5
6
7
8
# Write your query or mutation here
query {
  article (time: "100") {
    id
    text
    time
  }
}

结果：

1
2
3
4
5
6
7
8
9
{
  "data": {
    "article": {
      "id": "1",
      "text": "I am codinghuang",
      "time": 5
    }
  }
}

我来看看终端的输出：

1
2
3
~/codeDir/golangCode/scalars # go run server/server.go 
2019/08/30 02:36:26 connect to http://localhost:8080/ for GraphQL playground
100

说明我们在reoslver里面获取到了客户端传递的这个时间字符串100，并且成功的转换为了我们自定义的Int64类型。

所以，对于自定义标量，总结下了实际上就是：

1
2
3
4
5
1、先定义好我们的两个解析函数
2、客户端传递一个自定义标量的参数，那么就会调用我们的UnmarshalGQL解析函数，把前端传递过来的值转化为我们自定义的标量类型（至于这里我们需不需要去限定客户端传递过来的是字符串还是整数，看个人情况吧，在我的例子里面，其实不可以不对传递的参数做字符串的要求，完全可以传递一个整数过来）
	然后，resolver就可以通过参数获取到我们在UnmarshalGQL解析函数里面设置的那个值
3、服务器返回给客户端的值，首先会经过MarshalGQL解析函数处理，然后再通过io.Writer写入我们需要返回给前端的值。
4、这一切，gqlgen都会帮我们自动的调用

最后，GraphQL好用。

发表于
字数统计 1.2k 字 | 阅读时长 5 分钟

今天，同事问到我一个问题，就是Dockerfile中的WORKDIR怎么工作的？说实话，刚开始我还真没思考过。我只是想当然的认为Dockerfile里面设置了WORKDIR，然后启动容器的时候当然就会进入这个目录了。

但是，我们知道docker-compose也有一个类似的配置：

1
working_dir

那么，当我们在Dockerfile里面设置了WORKDIR，又在docker-compose里面设置了working_dir，那么，为什么我们创建一个容器的时候，进入的就是working_dir里面配置的那个目录呢？

我们实战分析一下，我们有如下Dockerfile：

1
2
3
FROM alpine:3.8

WORKDIR /root

很简单，就是以alpine:3.8为基础镜像，然后配置WORKDIR为/root。然后，我们编写对应的docker-compose.yml文件：

1
2
3
4
5
6
7
8
9
10
version: '3'

services:
  test:
    build: .
    image: test
    container_name: test
    working_dir: /tmp
    restart: always
    command: /sbin/init

我们配置working_dir为/tmp，而不是Dockerfile中的/root。

现在，我们来编译一下进行：

1
2
3
4
5
6
7
8
9
10
11
hantaohuang@~/tmp/test docker-compose build
Building test
Step 1/2 : FROM alpine:3.8
 ---> dac705114996
Step 2/2 : WORKDIR /root
 ---> Running in 463b6fa13304
Removing intermediate container 463b6fa13304
 ---> f5ae5eef35b3
Successfully built f5ae5eef35b3
Successfully tagged test:latest
hantaohuang@~/tmp/test

首先，我理解build的过程实际上是起一个临时容器，然后在容器里面跑对应的指令，然后再把这个容器的aufs merged层commit成一个镜像，不断的重复这个过程，直到commit出最后一个镜像，即我最终需要的镜像test。

我思考到了这一步，发现我就产生了一个问题：

1
在之前的临时容器里面执行的指令WORKDIR为什么会作用到我最终的镜像？

我在内网里面提了这个问题，有大佬解答说镜像里面除了基本的文件系统之外，还有一些元数据，我们可以通过inspect命令来查看。我们来看看镜像的这些数据：

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
hantaohuang@~/tmp/test docker inspect f5ae5eef35b3
[
    {
        "Id": "sha256:f5ae5eef35b36914df42d3170a800f6461b06b2f6fa600a539806fb9216b6b0f",
        "RepoTags": [
            "test:latest"
        ],
        "RepoDigests": [],
        "Parent": "sha256:dac7051149965716b0acdcab16380b5f4ab6f2a1565c86ed5f651e954d1e615c",
        "Comment": "",
        "Created": "2019-08-29T09:02:15.96601Z",
        "Container": "463b6fa1330400120536ffb408b3ec5797077cdcaa7249ffc353c4e6fe8bcbb0",
        "ContainerConfig": {
            "Hostname": "463b6fa13304",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "/bin/sh",
                "-c",
                "#(nop) WORKDIR /root"
            ],
            "ArgsEscaped": true,
            "Image": "sha256:dac7051149965716b0acdcab16380b5f4ab6f2a1565c86ed5f651e954d1e615c",
            "Volumes": null,
            "WorkingDir": "/root",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": {}
        },
    }
]

我们发现，在ContainerConfig中有一项WorkingDir就记录了我们在Dockerfile里面设置的工作目录。所以，当我们通过这个镜像创建容器的时候，我们会进入WorkingDir指定的路径，也就是/root。我们来测试一下：

1
2
3
4
hantaohuang@~/tmp/test docker run --rm -it f5ae5eef35b3 sh
~ # pwd
/root
~ #

符合预期。

然后，如果我们通过docker-compose起一个容器：

1
2
3
4
5
6
~ # exit
hantaohuang@~/tmp/test docker-compose up -d
Creating network "test_default" with the default driver
Creating test ... 
Creating test ... done
hantaohuang@~/tmp/test

我们查看一下容器的id：

1
2
3
4
5
6
7
hantaohuang@~/tmp/test docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                    NAMES
078a7370c21d        test                "/sbin/init"             17 seconds ago      Up 16 seconds                                test
e53716f972ec        php_alpine          "docker-php-entrypoi…"   31 hours ago        Up 31 hours         0.0.0.0:8000->8000/tcp   php
564c95acc209        gdb_swoole_alpine   "docker-php-entrypoi…"   2 weeks ago         Up 8 days           0.0.0.0:9501->9501/tcp   gdb_swoole_alpine
8be291961531        golang:alpine       "/sbin/init"             3 weeks ago         Up 8 days           0.0.0.0:8080->8080/tcp   go
hantaohuang@~/tmp/test

然后进入容器：

1
2
hantaohuang@~/tmp/test docker exec -it test sh
/tmp #

我们发现，进入的是/tmp目录而不是/root目录。为什么呢？因为我们的容器也是有一份和镜像类似的数据，我们可以查看一下test容器的信息：

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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
hantaohuang@~/tmp/test docker inspect 078a7370c21d
[
    {
        "Id": "078a7370c21d453a4e59dab57c4a3ec4752d0535616a9200350c56ef91bc73e8",
        "Created": "2019-08-29T09:10:41.5564366Z",
        "Path": "/sbin/init",
        "Args": [],
        "State": {
            "Status": "running",
            "Running": true,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": false,
            "Pid": 14784,
            "ExitCode": 0,
            "Error": "",
            "StartedAt": "2019-08-29T09:10:42.1561139Z",
            "FinishedAt": "0001-01-01T00:00:00Z"
        },
        "Image": "sha256:f5ae5eef35b36914df42d3170a800f6461b06b2f6fa600a539806fb9216b6b0f",
        "ResolvConfPath": "/var/lib/docker/containers/078a7370c21d453a4e59dab57c4a3ec4752d0535616a9200350c56ef91bc73e8/resolv.conf",
        "HostnamePath": "/var/lib/docker/containers/078a7370c21d453a4e59dab57c4a3ec4752d0535616a9200350c56ef91bc73e8/hostname",
        "HostsPath": "/var/lib/docker/containers/078a7370c21d453a4e59dab57c4a3ec4752d0535616a9200350c56ef91bc73e8/hosts",
        "LogPath": "/var/lib/docker/containers/078a7370c21d453a4e59dab57c4a3ec4752d0535616a9200350c56ef91bc73e8/078a7370c21d453a4e59dab57c4a3ec4752d0535616a9200350c56ef91bc73e8-json.log",
        "Name": "/test",
        "RestartCount": 0,
        "Driver": "overlay2",
        "Platform": "linux",
        "MountLabel": "",
        "ProcessLabel": "",
        "AppArmorProfile": "",
        "ExecIDs": null,
        "Mounts": [],
        "Config": {
            "Hostname": "078a7370c21d",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "/sbin/init"
            ],
            "Image": "test",
            "Volumes": null,
            "WorkingDir": "/tmp",
            "Entrypoint": null,
            "OnBuild": null,
        },
    }
]

记录的信息比镜像多得多（我还省略了其他很多信息）。我们会发现，容器也是有一个Config.WorkingDir来进入进入容器的时候，应该到什么目录里面。

所以，我们可以得出结论，通过命令：

1
docker run

起一个容器的话（如果不指定工作目录），那么容器inspect出来的信息里面的workdir是和镜像inspect出来的信息里面的workdir一致。

如果我们在容器启动的时候指定了workdir，那么容器inspect出来的信息里面的workdir就和镜像inspect出来的不一致。

然后，当我们进入一个处于运行状态的容器里面的时候，也就是执行命令docker exec的时候，就会去读取容器的那个workdir。因此，我们通过docker-compose管理的workdir实际上是容器的那个workdir而不是镜像的那个wordir。