Nginx的默认配置是不支持的pathinfo的,要支持path_info也很简单。
原配置如下

      location ~ \.php$ {
            root           /data0/wwwroot/default;
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /data0/wwwroot/default$fastcgi_script_name;
            include        fastcgi_params;
      }

修改为:

        location ~ \.php(.*)$ {
            root           /data0/wwwroot/default;
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_split_path_info ^(.+\.php)(.*)$;
            fastcgi_param PATH_INFO $fastcgi_path_info;
            fastcgi_param  SCRIPT_FILENAME  /data0/wwwroot/default$fastcgi_script_name;
            include        fastcgi_params;
        }

修改的地方:
1、将location ~ \.php$ 修改为 location ~ \.php(.*)$
2、添加如下两行

    fastcgi_split_path_info ^(.+\.php)(.*)$;
    fastcgi_param PATH_INFO $fastcgi_path_info;

这个pathinfo的问题碰到好几次了,每一次都是thinkPHP框架所致,远离thinkPHP,幸福一生。

,

在mac os x系统编译php时,在configure阶段就报如下错误:

error: Don’t know how to define struct flock on this system, set –enable-opcache=no

解决方法:

sudo cp /opt/mysql/lib/libmysqlclient.* /usr/local/lib/libmysqlclient.*

,

几乎每一个 PHP 程序员都发布过代码,可能是通过 ftp 或者 rsync 同步的,也可能是通过 svn 或者 git 更新的。一个活跃的项目可能每天都要发布若干次代码,但是现实却是很少有人注意其中的细节,实际上这里面有好多坑,很可能你就在坑中却浑然不知。

一个正确实现的发布系统至少应该支持原子发布。如果说每一个版本都表示一个独立的状态的话,那么在发布期间,任何一次请求只能在单一状态下被执行。如此称之为支持原子发布;反之如果在发布期间,一次请求跨越不同的状态,那么就不能称之为原子发布。我们不妨举个例子来说明一下:假设一次请求需要 include 两个 PHP 文件,分别是 a.php 和 b.php,当 include a.php 完成后,发布代码,接着 include b.php,如果处理不当的话,那么就可能会导致旧版本的 a.php 和新版本的 b.php 同时存在于同一个请求之中,换句话说就是没有实现原子发布。

开源世界里有很多不错的发布代码工具,比如 ruby 社区的 capistrano,其流程大致就是发布代码到一个全新的目录,然后再软链接到真正的发布目录。

.
├── current -> releases/v1
└── releases
    ├── v1
    │   ├── foo.php
    │   └── bar.php
    └── v2
        ├── foo.php
        └── bar.php

不过鉴于 PHP 本身的特殊性,如果只是简单套用上面的流程,那么将很难实现真正的原子发布。要理清个中缘由,还需要了解一下 PHP 中的两个 Cache 的概念:

  • opcode cache
  • realpath cache

先聊聊 opcode cache,早先大家一直用 apc,现在多半选择 zend opcode,关于它的作用,大家都已经很熟悉,不必多言,唯一需要注意的是 apc 和 zend opcode 对缓存键的选择有所差异:apc 选择的是文件的 inode,zend opcode 选择的是文件的 path。

再聊聊 realpath cache,它的作用是缓冲获取文件信息的 IO 操作,大多数时候它对我们而言是透明的,以至于很多人都不知道它的存在,需要注意的是 realpath cache 是进程级别的,也就是说,每一个 php-fpm 进程都有自己独立的 realpath cache。

相关的技术细节特别琐碎,建议大家仔细阅读如下资料:

在采用软链接发布代码的时候,通常遇到的第一个问题多半是新代码不生效!不管是开启了 apc.stat 或者 opcache.validate_timestamps 配置,还是调用了 apc_clear_cache 或者 opcache_reset 方法,均无效,重启 php-fpm 自然是能够解决问题,不过对脚本语言来说重启太重了!难道除了重启就没有别的办法了么?

事实上之所以会出现这样的问题,主要是因为 opcode cache 是通过 realpath cache 获取文件信息,即便软链接已经指向了新位置,但是如果 realpath cache 里还保存着旧数据的话,opcode cache 依然无法知道新代码的存在,缺省情况下,realpath_cache_ttl 缓存有效期是两分钟,这意味着发布代码后,可能要两分钟才能生效。为了让发布尽快生效,需要以进程为单位清除 realpath cache:

<?php

$key = 'php.pid_' . getmypid();

if (($rev = apc_fetch($key)) != DEPLOY_VERSION) {
    if($rev < DEPLOY_VERSION) {
        apc_store($key, DEPLOY_VERSION);
    }
    
    clearstatcache(true);
}

?>

如此在 apc 环境下基本就能工作了,但是在 zend opcode 环境下还可能有问题。因为在缺省情况下 opcache.revalidate_path 是关闭的,此时会缓存符号链接的值,这会导致即便软链接指向修改了,也永远无法生效,所以在使用 zend opcode 的时候,如果使用了软链接,视情况最好把 opcache.revalidate_path 激活。

分析到这里,我们不妨反思一下:在 PHP 中原子发布之所以是一个棘手的问题,归根结底是因为软链接和缓存之间的的矛盾。不管是 opcode cache 还是 realpath cache,都是 PHP 固有的缓存特性,基于客观需要无法绕开,如此说来是否有办法绕开软链接,使其成为马奇诺防线呢?答案是 nginx 的 $realpath_root

fastcgi_param SCRIPT_FILENAME $realpath_root $fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;

有了 $realpath_root,即便 DOCUMENT_ROOT 目录中含有软链接,nginx 也会把软链接指向的真正的路径发给 PHP,也就是说,对 PHP 而言,软链接已经不存在了!不过作为代价,每一次请求,nginx 都要通过相对昂贵的 IO 操作获取 $realpath_root 的值,通过 strace 命令我们能监控这一过程,下图从 current 到 foo 的过程:

realpath

在本例中,压测发现使用 $realpath_root 后,性能下降了大约 5% 左右,不过明眼人一下就能发现,虽然 $realpath_root 导致了 lstat 和 readlink 操作,但是 lstat 操作的次数是和目录深度成正比的,也就是说目录越深,执行的 lstat 次数越多,性能下降也就越大。如果能够降低发布目录的深度,那么可以预计性能下降能够控制在 1% 左右。

结尾介绍一下 Deployer,它是 PHP 中做得比较好的工具,有很多特色,比如支持并行发布,具体演示如下图,左边是串行,右边是并行,使用「vvv」能得到更详细信息:

deploy

不过 Deployer 在原子发布上有一点瑕疵,具体见 deploy:release 代码:

<?php

run("cd {{deploy_path}} && if [ -h release ]; then rm release; fi");
run("ln -s $releasePath {{deploy_path}}/release");

?>

也就是说,在切换软链接的时候,它是先删除再创建,是一个两步操作,理论上如果有请求在这两步中间进入的话,那么将会出现找不到文件的错误。

问题到这里,大部分人会觉得使用「ln -sfn」就好了,实际上也是错误的:

shell> strace ln -sfn releases/foo current
symlink("releases/foo", "current")      = -1 EEXIST (File exists)
unlink("current")                       = 0
symlink("releases/foo", "current")      = 0

通过 strace 我们能清晰的看到,虽然表面上使用「ln -sfn」是一步操作,但是内部依然是按照先删除再创建的逻辑执行的,实际上这里应该搭配使用「ln & mv」:

shell> ln -sfn releases/foo current.tmp
shell> mv -fT current.tmp current

先通过 ln 创建一个临时的软链接,再通过 mv 实现原子操作,此时如果使用 strace 监控,会发现 mv 的「T」选项实际上仅仅执行了一个 rename 操作,所以是原子的。

link: http://huoding.com/2016/05/27/515

I’m trying to compile PHP 5.6.10 from the source, and I encountered the following problem:

Undefined symbols for architecture x86_64:
  "_PKCS5_PBKDF2_HMAC", referenced from:
      _zif_openssl_pbkdf2 in openssl.o
  "_TLSv1_1_client_method", referenced from:
      _php_openssl_setup_crypto in xp_ssl.o
  "_TLSv1_1_server_method", referenced from:
      _php_openssl_setup_crypto in xp_ssl.o
  "_TLSv1_2_client_method", referenced from:
      _php_openssl_setup_crypto in xp_ssl.o
  "_TLSv1_2_server_method", referenced from:
      _php_openssl_setup_crypto in xp_ssl.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [libs/libphp5.bundle] Error 1

OpenSSL is installed via Brew. In PHP included like --with-openssl=/usr/local/Cellar/openssl/1.0.2c

P.S. Before tried to use just /usr for OpenSSL but got the same error.

 

The Makefile has a line with EXTRA_LIBS, something like:

EXTRA_LIBS = -lresolv -lmcrypt -lltdl -liconv-lm -lxml2 -lcurl -lssl -lcrypto

Remove all occurrences of -lssl and -lcrypto and add the full path to libssl.dylib and libcrypto.dylib (brew links openssl to /usr/local/opt/openssl/lib/)

EXTRA_LIBS = -lresolv -lexslt -ltidy -lmysqlclient -lmcrypt -lltdl /usr/local/lib/libiconv.dylib /usr/local/Cellar/openssl/1.0.2d_1/lib/libssl.dylib /usr/local/Cellar/openssl/1.0.2d_1/lib/libcrypto.dylib -lpng -lz -ljpeg -lcurl -lbz2 -lz  -lm -lxml2 -lz -licucore -lm -lcurl -lldap -lz -lxml2 -lz -licucore -lm -lfreetype -lmysqlclient -lxml2 -lz -licucore -lm -lxml2 -lz -licucore -lm -lxml2 -lz -licucore -lm -lxml2 -lz -licucore -lm -lxml2 -lz -licucore -lm -lxslt -lxml2 -lz -licucore -lm
,

首先让我们踏着欢快的脚步去Github创建一个新库,这里取名 composer-car,又欢快的将它克隆到本地:

git clone https://github.com/GeHou/composer-car.git

cd composer-car

这个composer-car文件夹就是你的包的root目录了,你只需要记住composer.json在包的哪个目录下面,一般那就是包的root目录了。什么?做包子的工作台?这么理解呢也是可以的,不过同学能先收收你的口水么。

现在我们还没有composer.json文件,你可以根据composer文档生成并编辑它,当然composer贴心的为我们准备了命令行,look:

-> composer init

Welcome to the Composer config generator

This command will guide you through creating your composer.json config.

Package name (<vendor>/<name>) [hou/composer-car]: 这里填写<包提供者>/<包名>的信息
Description []: 包的描述
Author [GeHou <***@gmail.com>]: 作者信息
Minimum Stability []: 最低稳定版本
License []: 授权协议

Define your dependencies.

Would you like to define your dependencies (require) interactively [yes]? no
Would you like to define your dev dependencies (require-dev) interactively [yes]? no

{
    "name": "hou/composer-car",
    "description": "In order to study composer",
    "license": "MIT",
    "authors": [
        {
            "name": "GeHou",
            "email": "***@gmail.com"
        }
    ],
    "minimum-stability": "dev",
    "require": {

    }
}

Do you confirm generation [yes]? yes
Would you like the vendor directory added to your .gitignore [yes]? yes

虽然经过以上的一番挣扎生成了composer.json文件,不过我们还得往里面加点东西。使用你熟悉的编辑器打开composer.json文件修改至如下:

{
    "name": "hou/composer-car",
    "description": "In order to study composer",
    "license": "MIT",
    "authors": [
        {
            "name": "GeHou",
            "email": "***@gmail.com"
        }
    ],
    "minimum-stability": "dev",
    "require": {
        "php": ">=5.3.0"
    },
    "autoload": {
        "psr-4": {
            "Ford\\Escape\\": "src/Ford/Escape",
            "Ford\\Fusion\\": "src/Ford/Fusion",
            "Ford\\Focus\\": "src/Ford/Focus",
            "Ford\\Fiesta\\": "src/Ford/Fiesta"
        }
    }   
}

细心的小伙伴可能已经认出了福特的商标(Ford),这说明我们都是同道中人,你一定也很喜欢汽车,对吧对吧? 🙂

我们登陆一下福特的网站看看都有哪些热销车型,嗯嗯分别有ESCAPE、FUSION、FOCUS、FIESTA,中文名称分别是翼虎、蒙迪欧、福克斯、嘉年华,嘉年华ST我的梦想啊~~~ 好了好了,那位看官放下你手里的板砖,我承认一说到汽车就会滔滔不绝,下面我们把水分挤出去继续讲解。

根据上面的命名空间和目录的映射关系,包的结构现在应该是下面这个样子:

composer-car
- src
- - Ford
- - - Escape
- - - - Escape2013.php
- - - Fiesta
- - - - Fiesta2013.php
- - - Focus
- - - - Focus2013.php
- - - Fusion
- - - - Fusion2013.php
- .gitignore
- composer.json
- README.md

Escape2013.php:

<?php

namespace Ford\Escape;

class Escape2013
{
    public static function info()
    {
        echo "This is Ford Escape2013!<br />";
    }
}

Fiesta2013.php:

<?php

namespace Ford\Fiesta;

class Fiesta2013
{
    public static function info()
    {
        echo "This is Ford Fiesta2013!<br />";
    }
}

Focus2013.php:

<?php

namespace Ford\Focus;

class Focus2013
{
    public static function info()
    {
        echo "This is Ford Focus2013!<br />";
    }
}

Fusion2013.php:

<?php

namespace Ford\Fusion;

class Fusion2013
{
    public static function info()
    {
        echo "This is Ford Fusion2013!<br />";
    }
}

以上都梳理完毕后,需要安装composer来测试我们的包是否可以正常工作,安装它很简单在包的root目录下install即可:

composer install

闪过几行神秘的提示之后即安装完毕,此时会在vendor/composer/autoload_psr4.php中生成命名空间和目录的映射关系,被包在一个数组中:

<?php

// autoload_psr4.php @generated by Composer

$vendorDir = dirname(dirname(__FILE__));
$baseDir = dirname($vendorDir);

return array(
    'Ford\\Fusion\\' => array($baseDir . '/src/Ford/Fusion'),
    'Ford\\Focus\\' => array($baseDir . '/src/Ford/Focus'),
    'Ford\\Fiesta\\' => array($baseDir . '/src/Ford/Fiesta'),
    'Ford\\Escape\\' => array($baseDir . '/src/Ford/Escape'),
);

如果发布成packagist包然后进行安装的话,到时候这里就不是$baseDir了而是$vendorDir。

然后我们新建一个测试文件show.php,用以下内容填充它:

<?php

require 'vendor/autoload.php';

use Ford\Escape as Escape;
use Ford\Fiesta as Fiesta;
use Ford\Focus as Focus;
use Ford\Fusion as Fusion;

echo Escape\Escape2013::info();
echo Fiesta\Fiesta2013::info();
echo Focus\Focus2013::info();
echo Fusion\Fusion2013::info();

打开浏览器敲入 http://foo.com/composer-car/show.php (foo.com是我的本地测试域名,请替换成小伙伴自己的)。

浏览器上依次输出了:

This is Ford Escape2013!
This is Ford Fiesta2013!
This is Ford Focus2013!
This is Ford Fusion2013!

是不是有点小激动呢?别急,别一副作鸟兽散的样子,还有发布的流程呢?不过你要是真的急着wc或者觉得教程too simple,侯哥是不会让你捡肥皂的。

首先作为调试代码的部分我们是不需要push到github上的,所以将show.php打入冷宫,编辑.gitignore文件,在末尾加入show.php。这个时候有些小伙伴可能会疑惑了,为什么上面还有个/vendor/,记得我们init包的时候回答过一个问题么?

Would you like the vendor directory added to your .gitignore [yes]? yes

嗯嗯,你懂了吧?

废话少说,经过职业玩家的一番噼里啪啦的敲击之后,代码被push到github上了,噼里啪啦的内容如下:

$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   .gitignore
#   composer.json
#   src/
nothing added to commit but untracked files present (use "git add" to track)

$ git add .
$ git commit -m "gogogo"
$ git push

接下来需要将github上的代码同步到https://packagist.org/上,去[Packagist的网站](https://packagist.org/](https://packagist.org/)注册一个账号(Login with github是个不错的选择)。登录,然后点击的大大的绿色背景按钮 Submit a Package,在 Repository URL (Git/Svn/Hg) 处输入包在github上的地址,这里就是:

https://github.com/GeHou/composer-car 

now,点击 Check,如果一切顺利,会返回项目的名称,确认后点击 Submit 完成抓取操作。

默认情况下Packagist是不会自动更新你在github上commit的代码的,在刚才导入的项目页面中点击 Force Update,Packagist会抓取github上对应库的内容进行更新,但这还不是自动化的,幸运的是我们可以在Github库的设置中进行配置来消除手动更新的麻烦。

进入Github库的 Settings 页面,找到 Webhooks & Services 选项,点击 Configure services 按钮,在出现的列表中找到 Packagist,猛击它!这里需要填写一些信息,在Packagist网站的profile页面可以找到它们:

  • User : Packagist上的用户名
  • Token : Packagist的授权令牌
  • Domain : http://packagist.org

补全后点击 Update settings,如果列表中显示绿剪头就表示OK了。

真的OK了吗?还是有点担心?大不了我们再测试下嘛!

先跳出root目录,在测试环境下新建一个文件夹:

mkdir test-auto-update
cd test-auto-update
vim composer.json

这次我们不使用init命令,只往composer.json里填充一些简单内容:

{
    "require": {
        "php": ">=5.3.0",
        "hou/composer-car": "dev-master"
    },
    "minimum-stability": "dev"
}

然后:

composer install

安装完后扫一眼test-auto-update/src/Ford/Fiesta目录看下是否只有2013款的Fiesta,然后暂时就不需要理会此目录下的内容了,让我们回到composer-car目录。

注:这时test-auto-update/vendor下面的hou/composer-car对应建立项目时的( / ) [hou/composer-car]。

听说2014款的嘉年华出了,赶紧追加新的车款吧:

composer-car/src/Ford/Fiesta 目录下新建文件Fiesta2014.php,填充它:

<?php

namespace Ford\Fiesta;

class Fiesta2014
{
    public static function info()
    {
        echo "This is Ford Fiesta2014!<br />";
    }
}

修改show.php,在最后追加:

echo Fiesta\Fiesta2014::info();

访问测试页,看看是否出现了:

This is Ford Fiesta2014!

ok,再次提交代码:

git add .
git commit -m "test auto update"
git push

接着回到 test-auto-update 目录,这次要换一个命令耍耍,因为install命令之后root目录下会生成一个composer.lock文件,已经安装过的依赖是不能通过install命令进行更新的,所以这次需要使用composer update命令,试试这个命令,看看会发生什么:

$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
       - Updating hou/composer-car dev-master (91bceb0 => 01550b4)
    Checking out 01550b4eeaa85513573ce7406ca7d46ee30c6978

Writing lock file
Generating autoload files

类似这样的神秘信息又在屏幕上一闪而过,实际上因为网络的缘故,有时候得闪好久~

不管怎么闪,更新成功后你就应该在 test-auto-update/vendor/hou/composer-car/src/Ford/Fiesta/ 文件夹下中找到新的 Fiesta2014.php 文件了。不过这里需要注意一点,有时候Packagist与Github之间的同步可能会出现延迟,这时不妨喝杯咖啡、找妹子聊会、扣扣鼻孔之类的噼里啪啦一会再回来试试更新操作。

好吧我们在 test-auto-update 根目录下新建一个 index.php 文件看看是否能跑起来,文件内容其实跟前面的show.php差不了多少:

<?php

require 'vendor/autoload.php';

use Ford\Fiesta as Fiesta;

echo Fiesta\Fiesta2014::info();

不错的话,运行index.php文件后浏览器会输出:

This is Ford Fiesta2014!

至此更新操作也被证实是OK了,同志赶紧自己动手试试吧。

参考资料

中文文档 http://composer.golaravel.com/

PSR-4规范 https://github.com/php-fig/fig-standards/blob/master/proposed/psr-4-autoloader/psr-4-autoloader.md

本文示例

https://github.com/GeHou/composer-car

https://packagist.org/packages/hou/composer-car

link: http://my.oschina.net/houlive/blog/206832