资讯专栏INFORMATION COLUMN

Swoft 源码剖析 - 连接池

rozbo / 1527人阅读

摘要:基于扩展实现真正的数据库连接池这种方案中,项目占用的连接数仅仅为。一种是连接暂时不再使用,其占用状态解除,可以从使用者手中交回到空闲队列中这种我们称为连接的归队。源码剖析系列目录

作者:bromine
链接:https://www.jianshu.com/p/1a7...
來源:简书
著作权归作者所有,本文已获得作者授权转载,并对原文进行了重新的排版。
Swoft Github: https://github.com/swoft-clou...

为什么需要引入连接池?

对于基于php-fpm的传统php-web应用,包括且不限于Mysql,Redis,RabbitMq,每次请求到来都需要为其新建一套独享的的连接,这直接带来了一些典型问题:

连接开销:连接随着http请求到来而新建,随着请求返回而销毁,大量连接新建销毁是对系统资源的浪费。

连接数量过高:每一个请求都需要一套自己的连接,系统连接数和并发数会成一个近线性的关系。如果系统并发量达到了1w,那么就需要建立1w个对应的连接,这对于Mysql之类的后端服务而言,是一个大的负荷。

空闲连接:假设我们有一个接口使用了一个Mysql连接。该接口在一开始进行一次sql查询后,后面的操作都是sql无关的,那么该请求占据的空闲连接完全就是一种资源的浪费。

对于异步系统而言,这个问题变得更加的严峻。一个请求处理进程要对同一个服务进行并发的操作,意味着这个请求要持有1个以上同类的连接,这对于系统压力而言,无疑是雪上加霜了,所以连接池对于基于Swoole的Web框架而言已经是一个必需实现的机制了。

Swoft连接池的生命周期与进程模型

连接池作为一个SCOPESINGLETON的典型Bean,
其实例最早会在SwoftBeanBeanFactory::reload()阶段被初始化。

Worker/Task进程

对于RPC或者HTTP请求而言,关系最密切的进程肯定是Worker和Task进程了。
对于这两者而言 SwoftBeanBeanFactory::reload()会在swoole的onWorkerStart事件的回调阶段阶段被调用。

//SwoftBootstrapServerServerTrait(HttpServer和RpcServer都使用了该性状)
/**
 * OnWorkerStart event callback
 *
 * @param Server $server server
 * @param int $workerId workerId
 * @throws InvalidArgumentException
 */
public function onWorkerStart(Server $server, int $workerId)
{
    // Init Worker and TaskWorker
    $setting = $server->setting;
    $isWorker = false;

    if ($workerId >= $setting["worker_num"]) {
        // TaskWorker
        ApplicationContext::setContext(ApplicationContext::TASK);
        ProcessHelper::setProcessTitle($this->serverSetting["pname"] . " task process");
    } else {
        // Worker
        $isWorker = true;
        ApplicationContext::setContext(ApplicationContext::WORKER);
        ProcessHelper::setProcessTitle($this->serverSetting["pname"] . " worker process");
    }

    $this->fireServerEvent(SwooleEvent::ON_WORKER_START, [$server, $workerId, $isWorker]);
    //beforeWorkerStart()内部会调用BeanFactory::reload();
    $this->beforeWorkerStart($server, $workerId, $isWorker);
}

这意味着此时的连接池对象的生命周期是 进程全局期而不是程序全局期
将进程池设计为进程全局期,而不是共享程度最高的程序全局期原因,个人认为主要有3个

多个进程同时对一个连接进行读写会导致数据传输错乱,需要保证连接不会被同时访问。

Worker进程对程序全局期的对象进行写操作时会导致写时复制,产生一个进程全局期的副本,程序全局期较难维持。

使用进程全局期的话可以利用现有的Bean机制管理对象,减少的特殊编码。

Process中的连接池
//SwoftProcessProcessBuilder.php
/**
     * After process
     *
     * @param string $processName
     * @param bool   $boot 该参数即Process 注解的boot属性
     */
    private static function beforeProcess(string $processName, $boot)
    {
        if ($boot) {
            BeanFactory::reload();
            $initApplicationContext = new InitApplicationContext();
            $initApplicationContext->init();
        }

        App::trigger(ProcessEvent::BEFORE_PROCESS, null, $processName);
    }
}

Swoft中的Process有两种:一种是定义Process 注解的boot属性为true的 前置进程,这种进程随系统启动而启动的 ;另一种是定义Process 注解的boot属性为false的 用户自定义进程 ,该类进程需要用户在需要的时候手动调用ProcessBuilder::create()启动 。

但是无论是何者,最终都会在Process中调用beforeProcess()进行子进程的初始化。对于 boot为true的 前置进程 ,由于其启动时父进程还未初始化bean容器,所以会多带带进行bean容器初始化,而对于boot为false的其他 用户自定义进程,其会直接继承父进程的Ioc容器。

Swoft基本上遵守着一个进程拥有一个多带带连接池的规则,这样所有进程中的连接都是独立的,保证了连接
不会被同时读写。唯独在Process中有一个特例。如果对先使用依赖连接池的服务,如对Mysql进行CRUD,再调用ProcessBuilder::create()启动 用户自定义进程,由于用户自定义进程 会直接继承父进程的Bean容器而不重置,这时子进程会获得父进程中的连接池和连接。

Command
/**
 * The adapter of command
 * @Bean()
 */
class HandlerAdapter
{
    /**
     * before command
     *
     * @param string $class
     * @param string $command
     * @param bool   $server
     */
    private function beforeCommand(string $class, string $command, bool $server)
    {
        if ($server) {
            return;
        }
        $this->bootstrap();
        BeanFactory::reload();

        // 初始化
        $spanId = 0;
        $logId = uniqid();

        $uri = $class . "->" . $command;
        $contextData = [
            "logid"       => $logId,
            "spanid"      => $spanId,
            "uri"         => $uri,
            "requestTime" => microtime(true),
        ];

        RequestContext::setContextData($contextData);
    }
}

命令行脚本拥有自己多带带的Bean容器,其情况和Process相似且更简单,严格遵循一个进程一个连接池,这里不再累述。


假设Worker数目为j,Task数目为k,Process数为l,Command数为m,每个进程池内配置最大连接数为n,部署机器数为x,不难看出每个swoft项目占用的连接数为(j+k+l+m)*n*x

天峰本人曾经提过另一种基于Swoole的连接池模型。
Rango-<基于swoole扩展实现真正的PHP数据库连接池>


这种方案中,项目占用的连接数仅仅为k*x
除了Task进程各个进程并不直接持有连接池,而是通过向Task进程提交指令(task(),sendMessage())让其代为进行连接池相关服务的操作,至少需要额外的一次进程间通信(默认为Unix Socket)。
该方案虽然能够更好的复用连接和节省连接数,但机制实现并不方便。从另一个角度去看,Swoft的连接池方案是为了解决使用Swoole时,单进程并发执行的连接数要求问题;Range提出的连接池方案是为了解决超大流量系统下对Mysql等服务的压力控制问题。两者适合不同的场景,其目的和意义在一定程度下是重合的,但并不是完全一样的。

Swoft连接池的实现 池的容器

连接池根据当前是否协程环境选择一种合适的队列结构作为连接的容器。

SplQueue:SplQueue是PHP标准库的数据结构,底层是一个双向链表,在队列操作这种特化场景下,性能远高于底层使用链表+哈希表实现的array()数据结构。

SwooleCoroutineChannel是Swoole提供的协程相关的数据结构,不仅提供了常规的队列操作。在协程环境下,当其队列长度从0至1之间切换时,会自动让出协程控制权并唤醒对应的生产者或消费者。

连接的获取
SwoftPoolConnectionPool.php
abstract class ConnectionPool implements PoolInterface {
    /**
     * Get connection
     *
     * @throws ConnectionException;
     * @return ConnectionInterface
     */
    public function getConnection():ConnectionInterface
    {
        //根据执行环境选择容器
        if (App::isCoContext()) {
            $connection = $this->getConnectionByChannel();
        } else {
            $connection = $this->getConnectionByQueue();
        }

        //连接使用前的检查和重新连接
        if ($connection->check() == false) {
            $connection->reconnect();
        }
        //加入到全局上下文中,事务处理和资源相关的监听事件会用到
        $this->addContextConnection($connection);
        return $connection;
    }
}
SwoftPoolConnectionPool.php
/**
 * Get connection by queue
 *
 * @return ConnectionInterface
 * @throws ConnectionException
 */
private function getConnectionByQueue(): ConnectionInterface
{
    if($this->queue == null){
        $this->queue = new SplQueue();
    }
    
    if (!$this->queue->isEmpty()) {
        //队列存在可用连接直接获取
        return $this->getEffectiveConnection($this->queue->count(), false);
    }
    //超出队列最大长度
    if ($this->currentCount >= $this->poolConfig->getMaxActive()) {
        throw new ConnectionException("Connection pool queue is full");
    }
    //向队列补充连接
    $connect = $this->createConnection();
    $this->currentCount++;

    return $connect;
}
SwoftPoolConnectionPool.php
/**
 * Get effective connection
 *
 * @param int  $queueNum
 * @param bool $isChannel
 *
 * @return ConnectionInterface
 */
private function getEffectiveConnection(int $queueNum, bool $isChannel = true): ConnectionInterface
{
    $minActive = $this->poolConfig->getMinActive();
    //连接池中连接少于数量下限时直接获取
    if ($queueNum <= $minActive) {
        return $this->getOriginalConnection($isChannel);
    }

    $time        = time();
    $moreActive  = $queueNum - $minActive;
    $maxWaitTime = $this->poolConfig->getMaxWaitTime();
    //检查多余的连接,如等待时间过长,表示当前所持连接数暂时大于需求值,且易失效,直接释放
    for ($i = 0; $i < $moreActive; $i++) {
        /* @var ConnectionInterface $connection */
        $connection = $this->getOriginalConnection($isChannel);;
        $lastTime = $connection->getLastTime();
        if ($time - $lastTime < $maxWaitTime) {
            return $connection;
        }
        $this->currentCount--;
    }

    return $this->getOriginalConnection($isChannel);
}

加点注释就非常清晰了,此处不再赘述。

连接的释放

连接的释放有两种不同的容易引起歧义的用法,为此我们做以下定义:
一种是连接已经不再使用了,可以关闭了,这种我们称为 连接的销毁
一种是连接暂时不再使用,其占用状态解除,可以从使用者手中交回到空闲队列中,这种我们称为 连接的归队

链接的销毁

一般通过unset变量,或者通过其他手段清除连接变量的所有引用,等待Zend引擎实现链接资源清理。
这一点在上文的getEffectiveConnection()中出现过。执行到$this->currentCount--;的时候 ,连接已经出队了,而$connection变量会在下个循环时作为循环变量被替换或者方法返回时作为局部变量被清除,连接资源的引用清0.引用降到0的资源会在下次gc执行时被回收,所以你没看到主动的连接释放代码也很正常。
如果你的代码在其他地方引用了这连接而没管理好,可能会导致资源泄露。

链接的归队
/**
 * Class AbstractConnect
 */
abstract class AbstractConnection implements ConnectionInterface
{
    //SwoftPoolAbstractConnection.php
    /**
     * @param bool $release
     */
    public function release($release = false)
    {
        if ($this->isAutoRelease() || $release) {
            $this->pool->release($this);
        }
    }
}
//SwoftPoolConnectionPool.php
/**
 * Class ConnectPool
 */
abstract class ConnectionPool implements PoolInterface
{
    /**
     * Release connection
     *
     * @param ConnectionInterface $connection
     */
    public function release(ConnectionInterface $connection)
    {
        $connectionId = $connection->getConnectionId();
        $connection->updateLastTime();
        $connection->setRecv(true);
        $connection->setAutoRelease(true);

        if (App::isCoContext()) {
            $this->releaseToChannel($connection);
        } else {
            $this->releaseToQueue($connection);
        }

        $this->removeContextConnection($connectionId);
    }
}

当用户使用完某个连接后,比如执行了完了一条sql后,应当调用连接的release()方法。
连接本身是持有连接池的反向连接,在用户调用ConnectionInterface->release()方法时,并不会马上销毁自身,而是清理自身的标记,调用PoolInterface->release()重新加入到连接池中。

//SwoftEventListenersResourceReleaseListener.php
/**
 * Resource release listener
 *
 * @Listener(AppEvent::RESOURCE_RELEASE)
 */
class ResourceReleaseListener implements EventHandlerInterface
{
    /**
     * @param SwoftEventEventInterface $event
     * @throws InvalidArgumentException
     */
    public function handle(EventInterface $event)
    {
        // Release system resources
        App::trigger(AppEvent::RESOURCE_RELEASE_BEFORE);

        $connectionKey = PoolHelper::getContextCntKey();
        $connections   = RequestContext::getContextDataByKey($connectionKey, []);
        if (empty($connections)) {
            return;
        }

        /* @var SwoftPoolConnectionInterface $connection */
        foreach ($connections as $connectionId => $connection) {
            if (!$connection->isRecv()) {
                Log::error(sprintf("%s connection is not received ,forget to getResult()", get_class($connection)));
                $connection->receive();
            }

            Log::error(sprintf("%s connection is not released ,forget to getResult()", get_class($connection)));
            $connection->release(true);
        }
    }
}

考虑到用户可能会在使用完后没有释放连接造成连接泄露,Swoft会在Rpc/Http请求或者Task结束后触发一个Swoft.resourceRelease事件(注:Swoft是笔者添加的前缀,方便读者区分Swoole相关事件和Swoft相关事件),将连接强制收包并归队。

Swoft源码剖析系列目录:https://segmentfault.com/a/11...

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/28976.html

相关文章

  • Swoft 源码剖析 - 目录

    摘要:作者链接來源简书著作权归作者所有,本文已获得作者授权转载,并对原文进行了重新的排版。同时顺手整理个人对源码的相关理解,希望能够稍微填补学习领域的空白。系列文章只会节选关键代码辅以思路讲解,请自行配合源码阅读。 作者:bromine链接:https://www.jianshu.com/p/2f6...來源:简书著作权归作者所有,本文已获得作者授权转载,并对原文进行了重新的排版。Swoft...

    qpwoeiru96 评论0 收藏0
  • Swoft 源码剖析 - Swoole和Swoft的那些事 (Http/Rpc服务篇)

    摘要:和服务关系最密切的进程是中的进程组,绝大部分业务处理都在该进程中进行。随后触发一个事件各组件通过该事件进行配置文件加载路由注册。事件每个请求到来时仅仅会触发事件。服务器生命周期和服务基本一致,详情参考源码剖析功能实现 作者:bromine链接:https://www.jianshu.com/p/4c0...來源:简书著作权归作者所有,本文已获得作者授权转载,并对原文进行了重新的排版。S...

    张汉庆 评论0 收藏0
  • Swoole 在 Swoft 中的应用

    摘要:在中的应用官网源码解读号外号外欢迎大家我们开发组定了一个就线下聚一次的小目标上一篇源码解读反响还不错不少同学推荐再加一篇讲解一下中使用到的功能帮助大家开启的实战之旅服务器开发涉及到的相关技术领域的知识非常多不日积月累打好基础是很难真正 date: 2017-12-14 21:34:51title: swoole 在 swoft 中的应用 swoft 官网: https://www.sw...

    EscapedDog 评论0 收藏0
  • Swoft 源码剖析 - Swoft 中 AOP 的实现原理

    摘要:官方在文档没有提供完整的但我们还是可以在单元测试中找得到的用法。解决的问题是分散在引用各处的横切关注点。横切关注点指的是分布于应用中多处的功能,譬如日志,事务和安全。通过将真正执行操作的对象委托给实现了能提供许多功能。源码剖析系列目录 作者:bromine链接:https://www.jianshu.com/p/e13...來源:简书著作权归作者所有,本文已获得作者授权转载,并对原文进...

    chenjiang3 评论0 收藏0
  • Swoft 源码剖析 - Swoft 中 IOC 容器的实现原理

    摘要:作者链接來源简书著作权归作者所有,本文已获得作者授权转载,并对原文进行了重新的排版。前言为应用提供一个完整的容器作为依赖管理方案,是功能,模块等功能的实现基础。的依赖注入管理方案基于服务定位器。源码剖析系列目录 作者:bromine链接:https://www.jianshu.com/p/a23...來源:简书著作权归作者所有,本文已获得作者授权转载,并对原文进行了重新的排版。Swof...

    Astrian 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<