Swoole

任何你使用的现代框架，都可能严重依赖于依赖注入。但是你知道依赖注入代表的真正含义吗？或者换一个更好的角度 - 你知道依赖注入不是什么吗？ 依赖容器 虽然每个现代框架都附带依赖容器 — 一个用于构建对象的大盒子 — 但这并不能保证你会按照预期的方式使用依赖注入模式。 容器让依赖项更加容易注入到类中，但是它也可能被滥用。 服务定位器模式 一种滥用服务容器的方式是从容器中拉取对象，而不是注入到当前的上下文中。该模式称之为服务定位器模式，它与依赖注入相反。 class MyController { public function indexAction() { $service = app(Service::class); // … } } 　　 服务定位器模式向容器请求特定的对象。这将导致服务从一个难以测试的点拉取，并且，对于外部而言这就像一个黑匣子：除非你查看全部相关代码，否则你将无法了解 MyController 所依赖的外部类型。 一些框架提倡这种用法，因为在项目开始的时候它将变得简单快捷。一旦在容器中注册了成百上千个类，使用服务定位器模式将会导致混乱。而使用依赖注入将解决该问题。 更多信息，可查看我写的这篇博客： 为什么服务定位器模式是反模式. 依赖共享 接下来是一些更积极的方面：以一种更好的方式使用容器。 当依赖注入被正确使用时，外部上下文 (在许多情况下为容器)

简介 Opcache 的前生是 Optimizer+ ，它是 Zend 开发的 PHP 优化加速组件。Optimizer+ 将 PHP 代码预编译生成的脚本文件 Opcode 缓存在共享内存中供以后反复使用，从而避免了从磁盘读取代码再次编译的时间消耗。同时，它还应用了一些代码优化模式，使得代码执行更快。从而加速 PHP 的执行。 正常的执行流程如下： 开启 Opcache 后的执行流程如下： Yum 安装 php -v yum list *opcache* yum -y install rh-php71-php-opcache.x86_64 kill -USR2 cat `/usr/local/php/var/run/php-fpm.pid` nginx -s reload 配置 zend_extension=opcache.so [opcache] ;开启opcache功能 opcache.enable=1 ;CLI环境下，开启opcache功能 opcache.enable_cli=1 ;OPcache共享内存的大小，单位MB opcache.memory_consumption=128 ;字符串在进程间驻留科使用的内存大小，单位MB opcache.interned_strings_buffer=8 ;内存中可以缓存的文件量。200-1000000之间 ;可以使用“find

用于生产环境中的PHP需要对其进行优化，让PHP自身发挥更好的性能，除了写好PHP代码，还要配置好php-fpm以及php.ini调优。本文从内存、OPcache、上传、会话以及安全等方面讲解php.ini的配置调优。 内存优化 运行 PHP 时需要关心每个 PHP 进程要使用多少内存，php.ini 中的 memory_limit 设置用于设定单个 PHP 进程可以使用的系统内存最大值。 这个设置的默认值是 128M，这对于大多数中小型 PHP 应用来说或许合适，不过，如果运行的是微型 PHP 应用，可以降低这个值，以便节省系统资源，反之，如果运行的是内存集中型 PHP 应用，可以增加这个值。这个值的大小由可用的系统内存决定，确定给 PHP 分配多少值是一门艺术，决定给 PHP 分配多少内存，以及能负担起多少个 PHP-FPM 进程时，可以根据以下维度信息进行判断： 一共可以分配给 PHP 多少内存？以一个 2G 内存的 VPS 为例，这台设备中可能还运行了其他进程，如 MySQL、Nginx 等，那么留 512M 给 PHP 是合适的。 每个 PHP 进程平均耗费多少内存？这个要监控进程的内存使用量，可以使用命令行命令top，也可以在 PHP 脚本中调用 memory_get_peak_usage() 函数，不管使用哪种方式，都要多次运行同一个脚本，然后取内存消耗的平均值。

简介 首先说说, 这个是干啥的. 我见过很多的项目中, 用PHP文件做配置的, 一个config目录下可能有十几个甚至数十个.php配置文件, 里面都是各种各样的array, 还有甚者会把一些词典文件(比如中文/英文对照)也放到配置中去. 这就导致配置文件的解析耗费了很大的性能(诚然, 用了opcache能好点, 但是实际上还是有执行的过程). 除了PHP的, 还有用json的, yaml的, 一个共同的特点就是这些配置的可读性比较差. 另外, 他们也都要runtime解析. config目录往往和代码在一起, 首先会有安全隐患(配置中往往有敏感信息), 其次如果配置和代码属于一个项目, 这就会导致配置的修改也要走代码上线的流程. 一些资源配置文件, 比如mysql/memcache的配置信息, 这些内容本来是应该对开发透明的, 运维直接负责即可. 但是放到了代码中就会导致, 运维如果要发起一些变更, 也要开发配合修改配置文件上线. 所以, Yaconf就是为了解决这些问题而生的一个工具. 它使用单独的一个配置目录(在yaconf.directory指定), 不和代码在一起. 它在PHP启动的时候, 处理所有的要处理的配置, 然后这些配置就会常驻内存, 随着PHP的生命周期存亡. 避免了每次请求的时候解析配置文件. 所有的配置内容都是immutable的,

如果说数组是 PHP 的精髓，数组玩得不6的，根本不能算是会用PHP。那协程对于 Swoole 也是同理，不理解协程去用 Swoole，那就是在瞎用。 首先，Swoole 只能运行在命令行（Cli）模式下，所以我们开发调试都是使用命令行，而不是 php-fpm/apache 等。 在 Swoole 中，我们可以使用 `\Swoole\Coroutine::create()` 创建协程，或者你也可以使用简写`go()`。 初识 Swoole 协程 go(function(){ go(function(){ echo 0, PHP_EOL; }); echo 1, PHP_EOL; }); go(function(){ echo 2, PHP_EOL; }); go(function(){ echo 3, PHP_EOL; }); 执行结果： 0 1 2 3 Swoole 协程与同步模式比较 我们一直在说 Swoole 协程适合用于 I/O 密集场景，在同样的硬件配置环境下，它会比传统的同步模式承载更多的访问量。 我们熟悉的文件读写、网络通讯请求（MySQL、Redis、Http等）都是属于 I/O 密集型场景。 假设一次 SQL 查询为 100ms，在传统同步模式下，当前进程在这 100ms 的时间里，是不能做其它操作的。如果要执行十次这个 SQL，可能需要耗费 1s 以上。

swoole| swoole 协程初体验 date: 2018-5-30 14:31:38 title: swoole| swoole 协程初体验 description: 通过协程的执行初窥 swoole 中协程的调度; 理解协程为什么快; swoole 协程和 go 协程对比 折腾 swoole 协程有一段时间了, 总结一篇入门贴, 希望对新手有帮助. 内容概览: 协程的执行顺序: 初窥 swoole 中协程的调度 协程为什么快: 减少IO阻塞带来的性能损耗 swoole 协程和 go 协程对比: 单进程 vs 多线程 协程的执行顺序 先来看看基础的例子: go ( function ( ) { echo "hello go1 \n" ; } ) ; echo "hello main \n" ; go ( function ( ) { echo "hello go2 \n" ; } ) ; go() 是 \Co::create() 的缩写, 用来创建一个协程, 接受 callback 作为参数, callback 中的代码, 会在这个新建的协程中执行. 备注: \Swoole\Coroutine 可以简写为 \Co 上面的代码执行结果: root @b98940b00a9b /v /w /c /p /swoole # php co.php hello go1 hello

众所周知，Swoole 和我们传统的 PHP 开发差别是有的，需要理解的概念也是有的。使用目前一些基于 Swoole 的框架开发的话，从开发习惯上和传统的TP 框架相差不多。根据官方介绍它是一个底层通信框架,最大的优势在于： 常驻内存，避免重复加载带来的性能损耗，提升海量性能 协程异步，提高对 I/O 密集型场景并发处理能力（如：微信开发、支付、登录等） 方便地开发 Http、WebSocket、TCP、UDP 等应用，可以与硬件通信 PHP 高性能微服务架构成为现实 那么很多人学习swoole都遇到了很多困难，那么我将在这里分享一套PHP架构师路线路以及教程，主要针对1到5年及以上的PHP开发人员，里面的技术包涵了PHP高并发、分布式、微服务、框架内核、高性能等技术，这些也是目前中大型互联网企业比较常用的技术，那么来详细看看。 一：常见模式与框架 学习PHP技术体系，设计模式，流行的框架 常见的设计模式，编码必备 Laravel、ThinkPHP开发必不可少的最新框架 YII、Symfony4.1核心源码剖析 二：微服务架构与性能优化 业务体系越来越复杂，Swoole协程编程，PHP并发编程、MySQL底层优化是架构升级的必经之路，PHP性能优化和微服务相关的技术有哪些呢？ Tars分布式RPC框架 Swoft微服务框架 服务器性能优化 算法与数据结构 三：工程化与分布式架构

目录 需求分析 使用示例 模块设计 UML 类图 入口 事务 连接池 连接 查询器的组装 总结 需求分析 本篇我们将通过 Swoole 实现一个自带连接池的 MySQL 查询器： 支持通过链式调用构造并执行 SQL 语句； 支持连接池技术； 支持多协程事务并发执行（协程安全性）； 支持连接对象的健康检测； 支持连接对象断线重连； 程序需要可扩展，为未来的改造留好扩展点； 完整项目地址：[协程版 MySQL 查询器]（ https://github.com/linvanda/mysql） （注：该项目并非示例项目，而是生产可用的，已经在公司内部稳定使用。） 使用示例 查询： $query->select(['uid', 'name']) ->from('users u') ->join('auth_users au', "u.uid=au.uid") ->where(['uid' => $uid]) ->groupBy("u.phone") ->having("count(u.phone)>1") ->orderBy("u.uid desc") ->limit(10, 0) ->list(); 插入： $query->insert('users') ->values( [ [ 'name' => 'linvanda', 'phone' => '18687664562',

<? php # 注意：如果不开启兼容模式，会遇到这样的现象，用swoole协程的方法访问常规方法添加到redis中的数据，可能访问不到 （直接返回NULL）！ 这可能是两者采用了 不同的技术标准所致！ go(function (){ $redis = new Swoole\Coroutine\Redis(); $redis ->connect( ' 127.0.0.1 ' , 6379 ); $val = $redis-> set ( ' 陈培昌 ' ,json_encode([ ' age ' => 21 , ' expertin ' =>[ ' 泰拳 ' , ' 巴西柔术 ' ]])); #同样是hmset，常规方法第2个参数是混合类型 var_dump($val); }); go(function (){ $redis = new Swoole\Coroutine\Redis(); $redis ->connect( ' 127.0.0.1 ' , 6379 ); $val = $redis-> get ( ' 陈培昌 ' ); var_dump(json_decode($val)); }); 打印结果： object(stdClass)#8 (2) { ["age"]=> int(21) ["expertin"]=> array(2) { [0]=> string(6)

PHP作为一种解释型语言，不同于编译型语言编译结果即为当前CPU体系的指令，PHP源代码只有编译成opcode才能够被zend虚拟机直接执行。 下面就简单描述PHP7语言执行原理： 1. 源代码首先利用Re2c实现的词法分析器进行词法分析，将源代码切割为多个字符串单元，分割后的字符串称为Token； 2. 基于Bison实现的语法分析器将Token和符合BNF文法规则的代码生成抽象语法树； 3. 抽象语法树（AST）编译生成opcode； 我们常常讨论的解释型语言执行效率较低，原因在于PHP执行过程中要多了翻译为opcode的过程。 不仅如此，与常驻内存的Java等语言不同，PHP代码在执行过后，内存会马上释放，基本上所有数据都会在此时销毁（仅有极少数数据会缓存）。 这种执行机制的优点在于有效避免内存泄漏，内存回收机制更简单，缺点就是每个PHP请求都得重复执行请求-翻译-执行的过程。 备注：内存泄漏（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。 为了弥补不是常驻内存的缺憾，引入opcode缓存，zend虚拟机会将第一次执行的PHP代码编译结果缓存到内存或者硬盘中，当下次执行该部分代码时直接读取缓存，一定程度上可以提高PHP运行速度。 参考资料 1. 陈雷