代码之家  ›  专栏  ›  技术社区  ›  user213154

如何使用MySQL DB连接设计后台程序[关闭]

  •  7
  • user213154  · 技术社区  · 15 年前

    假设您正在编写一个为作业队列提供服务的守护进程。其他各种软件将守护进程的作业写入队列。守护进程每隔几秒钟轮询队列以查找挂起的作业。假设队列是作为MySQL数据库中的表实现的,并且守护进程是一个简单的循环:

    1. 从队列中获取所有到期作业
    2. 做这些工作
    3. 睡眠N秒
    4. 转到1

    守护进程必须在MySQL数据库服务器中断的服务和数据库连接中断后生存。

    是否将守护进程设计为每个周期连接一次数据库服务器?i、 e.在1之前连接。在2和3之间断开?

    或者让daemon保持连接打开?在这种情况下,它还需要a)检测服务器或连接何时不工作,b)断开连接并重新连接,c)在不累积数据库连接、dud连接描述符或其他死机资源的情况下执行此操作。

    如果你有偏好,为什么?

    利与弊?

    进入设计的因素?

    还有别的办法吗?

    答案如下: mysql connection from daemon written in php 不说为什么最好保持连接畅通。我在其他地方读到MySQL中的每连接开销非常小。因此,不清楚为什么永久使用一个服务器连接比每隔几秒钟连接/断开连接要好。

    在我的例子中,守护进程是用PHP编写的。

    3 回复  |  直到 9 年前
        1
  •  7
  •   Community Mohan Dere    9 年前

    我真的在努力 something 非常接近您所描述的,但是在我的例子中,守护进程不会通过XMPP异步地轮询事件(但这不是重点)。

    去掉中间人

    我认为,与其将事件存储在数据库中并使用MySQL对其进行轮询,还不如使用 Gearman 从客户端异步发送( example ).

    垃圾收集

    PHP并不是作为守护进程运行的,直到PHP 5.3 circular reference garbage collection 这成为一个可行的选择。它是 非常 重要的是,如果你想在没有内存泄漏的情况下长期运行,可以使用PHP 5.3。

    GC的另一个需要记住的是,内存只有在不再被引用时才是空闲的。因此,如果将变量分配给全局作用域,它将一直存在,直到守护进程退出。重要的是,您创建或使用的任何代码都不能在某个地方构建变量(例如,静态日志,不删除旧数据等)。

    状态缓存

    另一件事是跑步很重要 clearstatcache 经常。由于PHP进程没有重新启动,所以手动执行此调用很重要,以防止获取旧的stat数据(这可能会影响您,也可能不会影响您)。根据 documentation 这些函数被缓存。

    受影响的函数包括Stf()、ListStand()、IsAuthReabable()、IsAccess()、ISAXECUTABLE()、ISHiFiele()、IsIr()、IsLink()、FieldMeMe()、FielaTime()、FieldTime()、FielIONE()、FielGROUP()、FielHOVER()、FielSeIe()、FielyPee()和FielePyMs()。

    资源管理

    如果你打算在进程的生命周期中使用类似MySQL的东西,我建议在启动时建立一个连接并保持它的活力。尽管MySQL端可能会使用更多的ram,但不必每1秒连接一次,就可以减少一些延迟和CPU开销。

    没有URL请求

    这看起来很明显,但是对于CLI PHP,没有URL请求信息。有些库没有考虑到这一点,这可能会导致一些问题。

    活套

    我将在这里弹出一个无耻的插件,用于我编写的帮助管理PHP守护进程的框架。 LooPHP 是一个运行循环框架,允许您安排事件发生或创建侦听抽象源(套接字、流等)。在我的例子中,我让守护进程做了不止一件事,因此让系统为我跟踪所有计时器非常有帮助,这样我可以有效地轮询 stream_select 用于XMPP连接。

        2
  •  1
  •   Sean Reifschneider    15 年前

    如果您想创建一个可靠的守护进程,则需要捕获数据库错误/断开连接并在任何情况下重新连接(断开连接或保持连接)。既然您无论如何都需要这样做,那么您最好重新使用一个连接。

    换句话说,仅仅因为您有一个新打开的连接,并不意味着查询不会失败,连接需要重新打开并重试。

    所以,我相信最干净的方法就是保持连接。但只是勉强。

        3
  •  0
  •   Klaus Byskov Pedersen    15 年前

    我认为最好的方法是测量连接/断开与数据库的连接所需的时间。然后尝试找出数据库服务器不可用的某种可能性。确定永久服务器连接的成本。最后,尝试确定添加处理数据库连接问题的代码的成本(以小时、烦恼或其他形式表示)。如果你能成功地确定这些数字,并进行比较,你就有了答案。对我(我想任何人)来说,很难对这些价值做出正确的猜测,但结论可能是,这是一个在性能和可行性之间的选择(就较低的成本而言)。

    推荐文章