分类目录归档:PHP脚本

php学习中所积累的经验,技巧.编程,思想是关键…

使用PHP并发执行任务–curl_multi应用

注释:
1.关于curl_multi_exec函数的返回值:

返回CURLM_CALL_MULTI_PERFORM 说明curl_multi_exec需要马上被再调用一次。
返回CURLM_OK 说明已经有需要处理的数据。这时你需要进行相关处理,处理完后再次调用curl_multi_exec。
php中的curl_multi_exec是调用的curl库中的curl_multi_perform方法。代码在multi.c的230行左右。

2.此方式,虽然在获取数据和数据处理上是并行的,但是在数据处理时依然是串行的。即数据是一条条依次处理的。如果deal方法比较耗时的话,那整体会非常耗时。

php并发执行shell

最近在项目中做一个功能,是PHP调用shell来探测资源

在很快把,页面逻辑梳理好以后就开始动手,功能完成后开始测试使用,发现当多条命令发出以后,相应会非常慢,因为在PHP中循环调用,上一次执行完成后,才会调用下一步,这样就有问题了。会卡主,504等等

要不然限制用户输入的数据条数,不行,这样感觉体验太差了。于是经过和其他同事探讨,给进程加上一个超时时间,并用使用并发来解决此问题。下面上代码进化步骤

下面是主要代码

程序设计之状态机PHP版本

状态机

把复杂的控制逻辑分解成有限个稳定状态,在每个状态上判断事件,变连续处理为离散数字处理,符合计算机的工作特点。
同时,因为有限状态机具有有限个状态,所以可以在实际的工程上实现。但这并不意味着其只能进行有限次的处理,相反,有限状态机是闭环系统,有限无穷,可以用有限的状态,处理无穷的事务。

状态机可归纳为4个要素,即 现态条件动作次态。这样的归纳,主要是出于对状态机的内在因果关系的考虑。“现态”和“条件”是因,“动作”和“次态”是果。详解如下:

  1. 现态:是指当前所处的状态。
  2. 条件:又称为“事件”,当一个条件被满足,将会触发一个动作,或者执行一次状态的迁移。
  3. 动作:条件满足后执行的动作。动作执行完毕后,可以迁移到新的状态,也可以仍旧保持原状态。动作不是必需的,当条件满足后,也可以不执行任何动作,直接迁移到新状态。
  4. 次态:条件满足后要迁往的新状态。“次态”是相对于“现态”而言的,“次态”一旦被激活,就转变成新的“现态”了。

举个最简单的例子。
人有三个状态健康,感冒,康复中。
触发的条件有淋雨(t1),吃药(t2),打针(t3),休息(t4)。

所以状态机就是

  • 健康-(t4)->健康;
  • 健康-(t1)->感冒;
  • 感冒-(t3)->健康;
  • 感冒-(t2)->康复中;
  • 康复中-(t4)->健康,

就是这样状态在不同的条件下跳转到自己或不同状态的图。

举个例子:找出一个文本文件中所有符合条件的字符串(文本文件都是字母可能有回车,换行)

文本文件str.txt如下:

sdfasdfAAAsAAAdfasddllfadsBBBsBBBdfdfdfsdfdf dfadfsfaHHHsKKKsaddfkkslslAAAAhBBBddfFFhMMM

条件格式:
1. 左边三个大写字母
2. 中间一个小写字母
3. 右边三个大写字母

解决这个问题可能涉及栈结构
栈(stack)
后进先出

++++++++++++++++++++++++++++++解题思路++++++++++++++++++++++++++++++

定义状态:对栈的情况定义相关的状态

  • 栈空状态: stat0,
  • 栈中一个有效数据:stat1
  • 栈中两个有效数据:stat2
  • 栈中三个有效数据:stat3
  • 栈中四个有效数据:stat4
  • 栈中五个有效数据:stat5
  • 栈中六个有效数据:stat6
  • 栈中七个有效数据:stat7

单个字符扫描文件让符合条件的字符入栈,根据栈的状态做出相应动作
0.初始状态栈空,即$curState=0,遇到大写字母入栈,栈中一个有效字母,修改栈状态:$curState=1

  1. 当栈状态为1时,下一个字母必须为大写,才能入栈,否则置空栈,恢复栈状态:$curState=0
  2. 当栈状态为2时,下一个字母必须为大写,才能入栈,否则置空栈,恢复栈状态:$curState=0
  3. 当栈状态为3时,下一个字母必须为小写,才能入栈,否则置空栈,恢复栈状态:$curState=0
  4. 当栈状态为4时,下一个字母必须为大写,才能入栈,否则置空栈,恢复栈状态:$curState=0
  5. 当栈状态为5时,下一个字母必须为大写,才能入栈,否则置空栈,恢复栈状态:$curState=0
  6. 当栈状态为6时,下一个字母必须为大写,才能入栈,否则置空栈,恢复栈状态:$curState=0
  7. 当栈状态为7时,下一个字母必须为小写,此时栈中元素符合了有效条件格式,把栈中元素传给$box数组,然后置空栈,恢复栈状态:$curState=0;否则置空栈,恢复栈状态:$curState=0

必须考虑栈的当前状态与下一个状态成立间的关系,即现态与次态
$box数组中就是文本文件中所有符合条件格式的字符串

(PS:例子从别处抄来的,觉得很好理解,所以码在这里)

面向对象的S.O.L.I.D 原则

面向对象的S.O.L.I.D 原则

一般来说这是面向对象的五大设计原则,但是,我觉得这些原则可适用于所有的软件开发。

Single Responsibility Principle (SRP) – 职责单一原则

关于单一职责原则,其核心的思想是:一个类,只做一件事,并把这件事做好,其只有一个引起它变化的原因。单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申,将职责定义为引起变化的原因,以提高内聚性来减少引起变化的原因。职责过多,可能引起它变化的原因就越多,这将导致职责依赖,相互之间就产生影响,从而极大的损伤其内聚性和耦合度。单一职责,通常意味着单一的功能,因此不要为一个模块实现过多的功能点,以保证实体只有一个引起它变化的原因。

Unix/Linux是这一原则的完美体现者。各个程序都独立负责一个单一的事。
Windows是这一原则的反面示例。几乎所有的程序都交织耦合在一起。

Open/Closed Principle (OCP) – 开闭原则

关于开发封闭原则,其核心的思想是:模块是可扩展的,而不可修改的。也就是说,对扩展是开放的,而对修改是封闭的。

对扩展开放,意味着有新的需求或变化时,可以对现有代码进行扩展,以适应新的情况。
对修改封闭,意味着类一旦设计完成,就可以独立完成其工作,而不要对类进行任何修改。

对于面向对象来说,需要你依赖抽象,而不是实现,23个经典设计模式中的“策略模式”就是这个实现。对于非面向对象编程,一些API需要你传入一个你可以扩展的函数,比如我们的C 语言的qsort()允许你提供一个“比较器”,STL中的容器类的内存分配,ACE中的多线程的各种锁。对于软件方面,浏览器的各种插件属于这个原则的实践。

Liskov substitution principle (LSP) – 里氏代换原则

软件工程大师Robert C. Martin把里氏代换原则最终简化为一句话:“Subtypes must be substitutable for their base types”。也就是,子类必须能够替换成它们的基类。即:子类应该可以替换任何基类能够出现的地方,并且经过替换以后,代码还能正常工作。另外,不应该在代码中出现if/else之类对子类类型进行判断的条件。里氏替换原则LSP是使代码符合开闭原则的一个重要保证。正是由于子类型的可替换性才使得父类型的模块在无需修改的情况下就可以扩展。

这么说来,似乎有点教条化,我非常建议大家看看这个原则个两个最经典的案例——“正方形不是长方形”和“鸵鸟不是鸟”。通过这两个案例,你会明白《墨子 小取》中说的 ——“娣,美人也,爱娣,非爱美人也….盗,人也;恶盗,非恶人也。”——妹妹虽然是美人,但喜欢妹妹并不代表喜欢美人。盗贼是人,但讨厌盗贼也并不代表就讨厌人类。这个原则让你考虑的不是语义上对象的间的关系,而是实际需求的环境。

在很多情况下,在设计初期我们类之间的关系不是很明确,LSP则给了我们一个判断和设计类之间关系的基准:需不需要继承,以及怎样设计继承关系。

Interface Segregation Principle (ISP) – 接口隔离原则

接口隔离原则意思是把功能实现在接口中,而不是类中,使用多个专门的接口比使用单一的总接口要好。

举个例子,我们对电脑有不同的使用方式,比如:写作,通讯,看电影,打游戏,上网,编程,计算,数据等,如果我们把这些功能都声明在电脑的抽类里面,那么,我们的上网本,PC机,服务器,笔记本的实现类都要实现所有的这些接口,这就显得太复杂了。所以,我们可以把其这些功能接口隔离开来,比如:工作学习接口,编程开发接口,上网娱乐接口,计算和数据服务接口,这样,我们的不同功能的电脑就可以有所选择地继承这些接口。

这个原则可以提升我们“搭积木式”的软件开发。对于设计来说,Java中的各种Event Listener和Adapter,对于软件开发来说,不同的用户权限有不同的功能,不同的版本有不同的功能,都是这个原则的应用。

Dependency Inversion Principle (DIP) – 依赖倒置原则

高层模块不应该依赖于低层模块的实现,而是依赖于高层抽象

举个例子,墙面的开关不应该依赖于电灯的开关实现,而是应该依赖于一个抽象的开关的标准接口,这样,当我们扩展程序的时候,我们的开关同样可以控制其它不同的灯,甚至不同的电器。也就是说,电灯和其它电器继承并实现我们的标准开关接口,而我们的开关产商就可不需要关于其要控制什么样的设备,只需要关心那个标准的开关标准。这就是依赖倒置原则。

这就好像浏览器并不依赖于后面的web服务器,其只依赖于HTTP协议。这个原则实在是太重要了,社会的分工化,标准化都是这个设计原则的体现。

参考:http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

PHP中闭包的使用

PHP中闭包的使用

例子一

例子二

Ubuntu下手动编译php-amqp扩展附PHP中RabbitMQ使用例子

Linux教程之ubuntu下手动编译php-amqp扩展

首先,神马是amqp?介绍在这里,简单的讲就是高级队列协议。而这个扩展就是为了让php可以支持amqp协议与相关的队列服务通讯。

优点:可以解决服务器处理的并发问题。
高级消息队列协议(AMQP)是一个异步消息传递所使用的应用层协议规范。作为线路层协议,而不是API(例如JMS),AMQP 客户端能够无视消息的来源任意发送和接受信息。现在,已经有相当一部分不同平台的服务器和客户端可以投入使用。

(一)基本概念

RabbitMQ 是流行的开源消息队列系统,用erlang语言开发。RabbitMQ是AMQP(高级消息队列协 议)的标准实现。如果不熟悉AMQP,直接看RabbitMQ的文档会比较困难。不过它也只有几个关键概念,这里简单介绍。

几个概念说明:

  • Broker:简单来说就是消息队列服务器实体。
  • Exchange:消息交换机,它指定消息按什么规则,路由到哪个队列。
  • Queue:消息队列载体,每个消息都会被投入到一个或多个队列。
  • Binding:绑定,它的作用就是把exchange和queue按照路由规则绑定起来。
  • Routing Key:路由关键字,exchange根据这个关键字进行消息投递。
  • vhost:虚拟主机,一个broker里可以开设多个vhost,用作不同用户的权限分离。
  • producer:消息生产者,就是投递消息的程序。
  • consumer:消息消费者,就是接受消息的程序。
  • channel:消息通道,在客户端的每个连接里,可建立多个channel,每个channel代表一个会话任务。

(二)使用流程

即 Client – AMQP server – Client
左边的Client向右边的Client发送消息,流程:

  • 获取Conection
  • 获取Channel
  • 定义Exchange,Queue
  • 使用一个RoutingKey将Queue Binding到一个Exchange上
  • 通过指定一个Exchange和一个RoutingKey来将消息发送到对应的Queue上,
  • 接收方在接收时也是获取connection,接着获取channel,然后指定一个Queue直接到它关心的Queue上取消息,它对Exchange,RoutingKey及如何binding都不关心,到对应的Queue上去取消息就OK了

由于ubuntu的默认源里面没有php5-amqp这个包,所以要用上amqp得考手动编译。

准备工作:

安装php编译工具

安装rabbitmq的库

如果你的Linux发行版没有现成的librabbitmq-dev包,那么可以通过下载源码编译安装

然后如果你没有安装git话请安装一下git,因为我们要从官方的版本库中获取源代码

克隆源码并编译

编译库

然后我们需要去下载php扩展的源代码,地址在此:

http://pecl.php.net/package/amqp

当前最新版本为1.4.0

创建配置文件

然后重启你的web服务器或者php-fpm并打印phpinfo,如果见到以下的内容就说明扩展安装好了

@RabbitMQ使用例子

生产方

消费方

PHP版本Socket学习

PHP版本Socket学习

Socket是在应用层和传输层之间的一个抽象层,它把TCP/IP层复杂的操作抽象为几个简单的接口供应用层调用已实现进程在网络中通信。

Socket起源于UNIX,在Unix一切皆文件哲学的思想下,Socket是一种 打开—读/写—关闭 模式的实现,服务器和客户端各自维护一个”文件”,在建立连接打开后,可以向自己文件写入内容供对方读取或者读取对方内容,通讯结束时关闭文件。服务器根据地址类型(ipv4,ipv6)、socket类型、协议创建socket

Socket通信流程

  • 服务器为socket绑定ip地址和端口号
  • 服务器socket监听端口号请求,随时准备接收客户端发来的连接,这时候服务器的socket并没有被打开
  • 客户端创建socket
  • 客户端打开socket,根据服务器ip地址和端口号试图连接服务器socket
  • 服务器socket接收到客户端socket请求,被动打开,开始接收客户端请求,直到客户端返回连接信息。这时候socket进入 阻塞 状态,所谓阻塞即accept()方法一直到客户端返回连接信息后才返回,开始接收下一个客户端谅解请求
  • 客户端连接成功,向服务器发送连接状态信息
  • 服务器accept方法返回,连接成功
  • 客户端向socket写入信息
  • 服务器读取信息
  • 客户端关闭
  • 服务器端关闭

服务端代码,运行在cli模式

客户端代码

RESTful API 设计指南

网络应用程序,分为前端和后端两个部分。当前的发展趋势,就是前端设备层出不穷(手机、平板、桌面电脑、其他专用设备……)。

因此,必须有一种统一的机制,方便不同的前端设备与后端进行通信。这导致API构架的流行,甚至出现“API First”的设计思想。RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。我以前写过一篇《理解RESTful架构》,探讨如何理解这个概念。

今天,我将介绍RESTful API的设计细节,探讨如何设计一套合理、好用的API。我的主要参考资料是这篇《Principles of good RESTful API Design》

一、协议

API与用户的通信协议,总是使用HTTPs协议

二、域名

应该尽量将API部署在专用域名之下。

如果确定API很简单,不会有进一步扩展,可以考虑放在主域名下。

 

三、版本(Versioning)

应该将API的版本号放入URL。

另一种做法是,将版本号放在HTTP头信息中,但不如放入URL方便和直观。

四、路径(Endpoint)

路径又称”终点”(endpoint),表示API的具体网址。

在RESTful架构中,每个网址代表一种资源(resource),所以网址中不能有动词,只能有名词,而且所用的名词往往与数据库的表格名对应。一般来说,数据库中的表都是同种记录的”集合”(collection),所以API中的名词也应该使用复数。

举例来说,有一个API提供动物园(zoo)的信息,还包括各种动物和雇员的信息,则它的路径应该设计成下面这样。

  • https://api.example.com/v1/zoos
  • https://api.example.com/v1/animals
  • https://api.example.com/v1/employees

五、HTTP动词

对于资源的具体操作类型,由HTTP动词表示。

常用的HTTP动词有下面五个(括号里是对应的SQL命令)。

  • GET(SELECT):从服务器取出资源(一项或多项)。
  • POST(CREATE):在服务器新建一个资源。
  • PUT(UPDATE):在服务器更新资源(客户端提供改变后的完整资源)。
  • PATCH(UPDATE):在服务器更新资源(客户端提供改变的属性)。
  • DELETE(DELETE):从服务器删除资源。

还有两个不常用的HTTP动词。

  • HEAD:获取资源的元数据。
  • OPTIONS:获取信息,关于资源的哪些属性是客户端可以改变的。

下面是一些例子。

  • GET /zoos:列出所有动物园
  • POST /zoos:新建一个动物园
  • GET /zoos/ID:获取某个指定动物园的信息
  • PUT /zoos/ID:更新某个指定动物园的信息(提供该动物园的全部信息)
  • PATCH /zoos/ID:更新某个指定动物园的信息(提供该动物园的部分信息)
  • DELETE /zoos/ID:删除某个动物园
  • GET /zoos/ID/animals:列出某个指定动物园的所有动物
  • DELETE /zoos/ID/animals/ID:删除某个指定动物园的指定动物

六、过滤信息(Filtering)

如果记录数量很多,服务器不可能都将它们返回给用户。API应该提供参数,过滤返回结果。

下面是一些常见的参数。

  • ?limit=10:指定返回记录的数量
  • ?offset=10:指定返回记录的开始位置。
  • ?sortby=name&order=asc:指定返回结果按照哪个属性排序,以及排序顺序。
  • ?animal_type_id=1:指定筛选条件

参数的设计允许存在冗余,即允许API路径和URL参数偶尔有重复。比如,GET /zoo/ID/animals 与 GET /animals?zoo_id=ID 的含义是相同的。

七、状态码(Status Codes)

服务器向用户返回的状态码和提示信息,常见的有以下一些(方括号中是该状态码对应的HTTP动词)。

  • 200 OK – [GET]:服务器成功返回用户请求的数据,该操作是幂等的(Idempotent)。
  • 201 CREATED – [POST/PUT/PATCH]:用户新建或修改数据成功。
  • 204 NO CONTENT – [DELETE]:用户删除数据成功。
  • 400 INVALID REQUEST – [POST/PUT/PATCH]:用户发出的请求有错误,服务器没有进行新建或修改数据的操作,该操作是幂等的。。
  • 404 NOT FOUND – [*]:用户发出的请求针对的是不存在的记录,服务器没有进行操作,该操作是幂等的。
  • 500 INTERNAL SERVER ERROR – [*]:服务器发生错误,用户将无法判断发出的请求是否成功。

状态码的完全列表参见这里

八、错误处理(Error handling)

如果状态码是4xx,就应该向用户返回出错信息。一般来说,返回的信息中将error作为键名,出错信息作为键值即可。

 

九、返回结果

针对不同操作,服务器向用户返回的结果应该符合以下规范。

  • GET /collection:返回资源对象的列表(数组)
  • GET /collection/resource:返回单个资源对象
  • POST /collection:返回新生成的资源对象
  • PUT /collection/resource:返回完整的资源对象
  • PATCH /collection/resource:返回完整的资源对象
  • DELETE /collection/resource:返回一个空文档

十、Hypermedia API

RESTful API最好做到Hypermedia,即返回结果中提供链接,连向其他API方法,使得用户不查文档,也知道下一步应该做什么。

比如,当用户向api.example.com的根目录发出请求,会得到这样一个文档。

上面代码表示,文档中有一个link属性,用户读取这个属性就知道下一步该调用什么API了。rel表示这个API与当前网址的关系(collection关系,并给出该collection的网址),href表示API的路径,title表示API的标题,type表示返回类型。

Hypermedia API的设计被称为HATEOAS。Github的API就是这种设计,访问api.github.com会得到一个所有可用API的网址列表。

 

从上面可以看到,如果想获取当前用户的信息,应该去访问api.github.com/user,然后就得到了下面结果。

 

上面代码表示,服务器给出了提示信息,以及文档的网址。

十一、其他

(1)API的身份认证应该使用OAuth 2.0框架。

(2)服务器返回的数据格式,应该尽量使用JSON,避免使用XML。

(完)

PHP设计模式之代理模式

代理模式:在客户端和实体之间建立一个代理对象(Proxy),客户端对实体的操作全部委派给代理对象,隐藏实体的具体实现细节
Proxy还可以与业务代码分离,部署到另外的服务器。业务代码通过RPC来委派任务

代理模式proxy.php

当要执行一个读操作时,在从库执行,当要执行写操作时连接主库,这样就实现了读写分离,连接数据库的操作交给代理类来执行。

PHP设计模式之装饰器模式

装饰器模式可以动态的添加修改类的功能
一个类提供了一项功能,如果要在修改并添加额外的功能,传统编程,需要写一个字类继承它,并重新实现类的方法
使用装饰器模式,只需在运行时添加一个装饰器对象,可以实现最大的灵活性