存档:2008年三月

php沉思录2

三月 20, 2008 | c/c++ | RSS 2.0

PME模型

在大规模的程序设计中,组件(component)已经成为一种非常流行的技术。常见的组件技术都基于PME模型,即属性(Property)、方法(Method)和事件(Event)。

基于PME的组件技术可以方便地实现IoC(Inversion of Control,控制反转),是从IDE的plugin到应用服务器的“热发布”等许多技术的基础。
PHP从版本5开始,大大完善了对OO的支持,以前不能被应用的许多pattern现在都可以在PHP5中实现。因此,是否能够实现基于PHP的组件技术,也就成了一个值得讨论的问题。
下面对PHP对于PME模型的支持,逐一进行讨论:

 属性(Property)
PHP并不支持类似Delphi或者C#的property语法,但这并不是问题。Java也不支持property语法,但是通过getXXX()和setXXX()的命名约定,同样可以支持属性。

PHP也可以通过这一方式来支持属性。但是,PHP提供了另一种也许更好的方法,那就是__set()和__get()方法。
在PHP中,每一个class都会自动继承__set()和__get()方法。它们的定义如下:

void __set ( string name, mixed value )
mixed __get ( string name )

这两个方法将在下列情况下被触发:当程序访问一个当前类没有显式定义的属性时。在这个时候,被访问的属性名称作为参数被传入相应的方法。任何类都可以重载__set()和__get()方法,以实现自己的功能。
如下例:

class PropertyTester {

public function __get($PropName) {
echo “Getting Property $PropNamen”;
}

public function __set($PropName, $Value) {
echo “Setting Property $PropName to ‘$Value’n”;
}
}

$Prop = new PropertyTester();
$Prop->Name;
$Prop->Name = “some string”;

类PropertyTester重载了__set()和__get()方法,为了测试,仅仅将参数打印输出,没有做更多的工作。测试代码创建了PropertyTester类的实例,并试图读写它并不存在的一个属性Name。此时,__set()和__get()相继被调用,并打印出相关参数。它的输出结果如下:

Getting Property Name
Setting Property Name to ’some string’

基于这种机制,我们可以将属性的值放在一个private的List中,在读写属性时,通过重载__set()和__get()方法,读写List中的属性值。
但是,__set()和__get()方法的有趣之处远不止及。通过这两个方法,可以实现动态属性,也就是不在程序中显式定义,而是在运行时动态生成的属性。只要想想这种技术在OR Mapping中的作用就能够明白它的重要性了。配合__call()方法(用于实现动态方法,在下一节中详述),它能够取代丑陋的代码生成器(code generator)的大部分功能。

 方法(Method)
PHP对方法的支持比较简单,没有太多可以讨论的。值得一提的是,PHP从版本5开始支持类的静态方法(static method),这使得程序员再也不用无谓地增加许多全局函数了。

 事件(Event)
事件也许是PHP遇到的最复杂的问题。PHP并没有在语法层面提供对事件的支持,我们只能考虑通过别的途径来实现。因此,我们需要先对事件的概念和其他语言对事件的实现方式进行讨论。

事件模型可以简述如下:充当事件触发者的代码本身并不处理事件,而仅仅是在事件发生时,把程序控制权转交给事件的处理者,在事件处理完成后,再收回控制权。事件触发者本身并不知道事件将会被如何处理,在大多数情况下,事件触发者的代码要先于事件处理者的代码被完成。

在传统的面向过程的语言(例如C或者PASCAL)中,事件可以通过函数指针来实现。具体来说,事件触发者定义一个函数指针,这个函数指针可以在以后被指向某个处理事件的函数。在事件发生时,调用该函数指针指向的处理函数,并将事件的上下文作为参数传入。处理完成后,控制权再回到事件触发者。

    

在面向对象的语言中,方法指针(指向某个类的方法的指针)取代了函数指针。以Delphi为例,事件处理的例子如下:

type
TNotifyEvent = procedure(Sender: TObject) of object;
TMainForm = class(TForm)
procedure ButtonClick(Sender: TObject);

End;
Var
MainForm: TMainForm;
OnClick: TNotifyEvent;

可以看出,TNotifyEvent被定义为所谓的过程类型(Procedural Type),事实上就是一个方法指针。TMainForm的ButtonClick方法是一个事件处理者,符合TNotifyEvent的签名。OnClick是一个事件触发者。在实际使用时,通过如下代码:

OnClick := MainForm.ButtonClick;

将MainForm.ButtonClick方法绑定到了OnClick事件。当OnClick事件触发时,MainForm.ButtonClick方法将被调用,并且将Sender(触发事件的组件对象)作为参数传入。
回到PHP,由于PHP不支持指针,因此无法使用函数指针这一技术。但是,PHP支持所谓的“函数变量”,可以把函数赋予某个变量,其作用类似于函数指针。如下例:

function EventHandler($Sender) {
echo “Calling EventHandler(), arv = $Sendern”;
}

$Func = ‘EventHandler’;
$Func(’Sender Name’);

在面向对象的语言中,方法指针(指向某个类的方法的指针)取代了函数指针。以Delphi为例,事件处理的例子如下:

type
TNotifyEvent = procedure(Sender: TObject) of object;
TMainForm = class(TForm)
procedure ButtonClick(Sender: TObject);

End;
Var
MainForm: TMainForm;
OnClick: TNotifyEvent;

可以看出,TNotifyEvent被定义为所谓的过程类型(Procedural Type),事实上就是一个方法指针。TMainForm的ButtonClick方法是一个事件处理者,符合TNotifyEvent的签名。OnClick是一个事件触发者。在实际使用时,通过如下代码:

OnClick := MainForm.ButtonClick;

将MainForm.ButtonClick方法绑定到了OnClick事件。当OnClick事件触发时,MainForm.ButtonClick方法将被调用,并且将Sender(触发事件的组件对象)作为参数传入。
回到PHP,由于PHP不支持指针,因此无法使用函数指针这一技术。但是,PHP支持所谓的“函数变量”,可以把函数赋予某个变量,其作用类似于函数指针。如下例:

function EventHandler($Sender) {
echo “Calling EventHandler(), arv = $Sendern”;
}

$Func = ‘EventHandler’;
$Func(’Sender Name’);

 

  由于PHP是一种动态语言,变量可以为任何类型,所以无须先定义函数指针的类型作为事件的签名。直接定义了一个函数EventHandler作为事件处理者,然后将它赋予变量$Func(注意直接使用了字符串形式的函数名),最后触发该事件,并将一个字符串“Sender Name”传给它作为参数。输出的结果是:

Calling EventHandler(), arv = Sender Name

同样地,PHP也提供了类似方法指针的机制。如下例:

Class EventHandler {

public function DoEvent($Sender) {
echo “Calling EventHandler.DoEvent(), arg = $Sendern”;
}
}

$EventHanler = new EventHandler();
$HandlerObject = $EventHanler;
$Method = ‘DoEvent’;
$HandlerObject->$Method(’Sender Name’);

由于PHP中没有能够直接引用对象方法的变量,因此需要使用两个变量来间接实现:$HandlerObject指向对象,$Method指向对象方法。通过$HandlerObject->$Method方式的调用,可以动态地指向任何对象方法。
为了使代码更加优雅和更适合复用,可以定义一个专门的类NotifyEvent,并使用一段新的调用代码:

final class NotifyEvent {

private $HandlerObject;
private $Method;

public function __construct($HandlerObject, $Method) {
$this->HandlerObject = $HandlerObject;
$this->Method = $Method;
}

public function Call($Sender) {
$Method = $this->Method;
$this->HandlerObject->$Method($Sender);
}
}

$EventHanler = new EventHandler();
$NotifyEvent = new NotifyEvent($EventHanler, ‘DoEvent’);
$NotifyEvent->Call(’Sender Name’);

NotifyEvent类定义了两个私有变量$HandlerObject和$Method,分别指向事件处理者对象和处理方法。在构造函数中对这两个变量赋值,再通过Call方法来调用。

熟悉C#的读者可以发现,NotifyEvent类与C#中的Delegate十分类似。Delegate超过NotifyEvent的地方在于支持多播(Multicast),也就是一个事件可以绑定多个事件处理者。只要事件触发者自己维护一个NotifyEvent对象数组,支持多播也不是一件难事。

至此,PHP对事件的支持已经得到了比较圆满的解决。但是,人的求知欲是无穷无尽的。还有没有可能通过其他的方式来实现事件呢?

除了方法指针,接口(interface)也可以用于实现事件。在Java中,这种技术被广泛应用。其核心思想是,将事件处理者的处理函数定义抽象为一个接口(相当于函数指针的签名),事件触发者针对这个接口编程,事件处理者则实现这个接口。

这种方式的好处在于,不需要语言支持函数指针或方法指针,让代码显得更加清晰和优雅,缺陷在于,实现同一种功能,要使用更多的代码。如下例:

interface IEventHandler {
public function DoEvent($Sender, $Arg);
}

class EventHanlerAdapter implements IEventHandler {

public function DoEvent($Sender, $Arg) {
echo “Calling EventHanlerAdapter.DoEvent(), Sender = $Sender, arg = $Argn”;
}
}

class EventRaiser {

private $EventHanlerVar;

public function __construct($EventHanlerAdapter) {
$this->EventHanlerVar = $EventHanlerAdapter;
}

public function RaiseEvent() {
if ($this->EventHanlerVar != null) {
$this->EventHanlerVar->DoEvent($this, ’some string’);
}
}

public function __tostring() {
return ‘Object EventRaier’;
}

}

$EventHanlerAdapter = new EventHanlerAdapter();
$EventRaiser = new EventRaiser($EventHanlerAdapter);
$EventRaiser->RaiseEvent();

首先定义了一个接口IEventHandler,它包含了方法的签名。EventHanlerAdapter类作为事件处理者,实现了这个接口,并提供了相应的处理方法。EventRaiser类作为事件触发者,针对$EventHanlerVar变量(它应该是IEventHandler接口类型,但是在PHP中不用显式定义)编码。

在实际应用中,将EventHanlerAdapter的实例作为参数赋予传给EventRaiser类的构造函数,当事件发生时,相应的处理方法将被调用。输出结果如下:

Calling EventHanlerAdapter.DoEvent(), Sender = Object EventRaier, arg = some string

最后,让我们回到现实世界中来。虽然我们用PHP完整地实现了PME模型,但是这到底有什么用呢?毕竟,我们不会用PHP去编写IDE,也不会用它编写应用服务器。回答是,基于PME模型的组件技术可以实现更加方便和更大规模的代码复用。

在基于PHP的应用系统中,虽然插件已经被广泛使用,但是通过组件技术可以实现功能更强大、更加规范和更容易维护的插件。此外,组件技术在实现一些大的Framework(例如,针对Web UI的Framework)时,也是不可或缺的。

没有评论 »

php沉思录

三月 20, 2008 | linux | RSS 2.0

工作模型

PHP的工作模型非常特殊。从某种程度上说,PHP和ASP、ASP.NET、JSP/Servlet等流行的Web技术,有着本质上的区别。

以Java为例,Java在Web应用领域,有两种技术:Java Servlet和JSP(Java Server Page)。Java Servlet是一种特殊类型的Java程序,它通过实现相关接口,处理Web服务器发送过来的请求,完成相应的工作。JSP在形式上是一种类似于PHP的脚本,但是事实上,它最后也被编译成Servlet。

也就是说,在Java解决方案中,JSP和Servlet是作为独立的Java应用程序执行的,它们在初始化之后就驻留内存,通过特定的接口和Web服务器通信,完成相应工作。除非被显式地重启,否则它们不会终止。因此,可以在JSP和Servlet中使用各种缓存技术,例如数据库连接池。

ASP.NET的机制与此类似。至于ASP,虽然也是一种解释型语言,但是仍然提供了Application对象来存放应用程序级的全局变量,它依托于ASP解释器在IIS中驻留的进程,在整个应用程序的生命期有效。

PHP却完全不是这样。作为一种纯解释型语言,PHP脚本在每次被解释时进行初始化,在解释完毕后终止运行。这种运行是互相独立的,每一次请求都会创建一个单独的进程或线程,来解释相应的页面文件。页面创建的变量和其他对象,都只在当前的页面内部可见,无法跨越页面访问。

在终止运行后,页面中申请的、没有被代码显式释放的外部资源,包括内存、数据库连接、文件句柄、Socket连接等,都会被强行释放。
也就是说,PHP无法在语言级别直接访问跨越页面的变量,也无法创建驻留内存的对象。见下例:

<?php
class StaticVarTester {
public static $StaticVar = 0;
}

function TestStaticVar() {
StaticVarTester :: $StaticVar += 1;
echo “StaticVarTester :: StaticVar = ” . StaticVarTester :: $StaticVar;
}

TestStaticVar();
echo “<br/>”;
TestStaticVar();
?>

在这个例子中,定义了一个名为StaticVarTester的类,它仅有一个公共的静态成员$StaticVar,并被初始化为0。然后,在TestStaticVar()函数中,对StaticVarTester :: $StaticVar进行累加操作,并将它打印输出。

熟悉Java或C++的开发者对这个例子应该并不陌生。$StaticVar作为StaticVarTester类的一个静态成员,只在类被装载时进行初始化,无论StaticVarTester类被实例化多少次,$StaticVar都只存在一个实例,而且不会被多次初始化。因此,当第一次调用TestStaticVar()函数时,$StaticVar进行了累加操作,值为1,并被保存。第二次调用TestStaticVar()函数,$StaticVar的值为2。
打印出来的结果和我们预料的一样:

StaticVarTester :: StaticVar = 1
StaticVarTester :: StaticVar = 2

但是,当浏览器刷新页面,再次执行这段代码时,不同的情况出现了。在Java或C++里面,$StaticVar的值会被保存并一直累加下去,我们将会看到如下的结果:

StaticVarTester :: StaticVar = 3
StaticVarTester :: StaticVar = 4

但是在PHP中,由于上文叙及的机制,当前页面每次都解释时,都会执行一次程序初始化和终止的过程。也就是说,每次访问时,StaticVarTester都会被重新装载,而下列这行语句

public static $StaticVar = 0;

也会被重复执行。当页面执行完成后,所有的内存空间都会被回收,$StaticVar这个变量(连同整个StaticVarTester类)也就不复存在。因此,无论刷新页面多少次,$StaticVar变量都会回到起点:先被初始化为0,然后在TestStaticVar()函数调用中被累加。所以,我们看到的结果永远是这个:

StaticVarTester :: StaticVar = 1
StaticVarTester :: StaticVar = 2
PHP这种独特的工作模型的优势在于,基本上解决了令人头疼的资源泄漏问题。Web应用的特点是大量的、短时间的并发处理,对各种资源的申请和释放工作非常频繁,很容易导致泄漏。

同时,大量的动态html脚本的存在,使得追踪和调试的工作都非常困难。PHP的运行机制,以一种非常简单的方式避免了这个问题,同时也避免了将程序员带入到繁琐的缓冲池和同步等问题中去。在实践中,基于PHP的应用往往比基于Java或.NET的应用更加稳定,不会出现由于某个页面的BUG而导致整个站点崩溃的问题。

(相比之下,Java或.NET应用可能因为缓冲池崩溃或其他的非法操作,而导致整个站点崩溃。)后果是,即使PHP程序员水平不高,也无法写出使整个应用崩溃的代码。PHP脚本可以一次调用极多的资源,从而导致页面执行极为缓慢,但是执行完毕后所有的资源都会被释放,应用仍然不会崩溃。

甚至即使执行了一个死循环,也会在30秒(默认时间)后因为超时而中止。从理论上来说,基于PHP的应用是不太可能崩溃的,因为它的运行机制决定它不存在常规的崩溃这个问题。在实践中,很多开发者也认为PHP是最稳定的Web应用。

 

但是,这种机制的缺点也非常明显。最直接的后果是,PHP在语言级别无法实现跨页面的缓冲机制。这种缓冲机制缺失造成的影响,可以分成两个方面:

 一是对象的缓冲。

如我们所知,很多设计模式都依赖于对象的缓冲机制,对于需要频繁应付大量并发的服务端软件更是如此。因此,对象缓冲的缺失,理论上会极大地降低速度。但是,由于PHP本身的定位和工作机制等原因,它在实际工作中的速度非常快。就作者自己的经验来看,在小型的Web应用中,PHP至少不比Java慢。

在大型的应用中,为了榨干每一分硬件资源,即使PHP本身足够快,一个优秀的对象缓冲机制仍然是必要的。在这种情况下,可以使用第三方的内存缓冲软件,如Memcached。由于Memcached本身的优异特性(高性能,支持跨服务器的分布式存储,和PHP的无缝集成等),在大型的PHP应用中,Memcached几乎已经成为不可或缺的基础设施了。比起使用PHP语言自己实现对象缓冲来,这种第三方解决方案似乎更好一些。

二是数据库连接的缓冲。

对MySQL,PHP提供了一种内置的数据库缓冲机制,使用起来非常简单,程序员需要做的只是用mysql_pconnect()代替mysql_connect()来打开数据库而已。

PHP会自动回收被废弃的数据库连接,以供重复使用。具有讽刺意味的是,在实际应用中,这种持久性数据库连接往往会导致数据库连接的伪泄漏现象:在某个时间,并发的数据库连接过多,超过了MySQL的最大连接数,从而导致新的进程无法连接数据库。

但是过一段时间,当并发数减少时,PHP会释放掉一些连接,网站又会恢复正常。出现这种现象的原因是,当使用pconnect时,Apache的httpd进程会不释放connect,而当Apache的httpd进程数超过了mysql的最大连接数时,就会出现无法连接的情况。因此,需要小心地调整Apache和Mysql的配置,以使Apache的httpd进程数不会超出MySQL的最大连接数。在某些情况下,一些有经验的PHP程序员宁可继续使用mysql_connect(),而不是mysql_pconnect()。

就作者所知,在PHP未来的roadmap中,对于工作模型这一部分,没有根本性的变动。这是PHP的缺点,也是PHP的优势,从本质上说,这就是PHP的独特之处。因此,我们很难期待PHP在近期内会对这一问题做出重大的改变。但是,在对待这个问题带来的一系列后果时,我们必须谨慎应对。

数据库访问接口

长期以来,PHP都缺乏一个象ADO或JDBC那样的统一的数据库访问接口。PHP在访问不同的数据库时,使用不同的专门API。例如,使用mysql_connect函数连接MySQL,使用ora_logon函数连接Oracle。平心而论,这种方式并没有象我们想象的那样麻烦。
在真实项目中,把系统从一种数据库完全迁移到另一种数据库的要求是比较少见的,特别是对于LAMP这样的小型项目而言。而且,只要将访问数据库的代码进行了良好的封装,迁移的工作量也会较少。另外,使用专门API,在效率上多少会有一些优势。

虽然如此,PHP的开发人员仍然在努力构建PHP的统一的数据库访问接口。从PHP 5.1开始,PHP的发行包内置了PDO(PHP Data Objects,PHP数据对象)。PDO具有如下特性:
   
&#61548; 统一的数据库访问接口。PDO为访问不同的数据库提供了统一的接口,并且能够通过切换数据库驱动程序,方便地支持各种流行的数据库。
&#61548; 面向对象。PDO完全基于PHP 5的对象机制,因此区别于基于过程的专用API。
&#61548; 高性能。PDO的底层用C编写,比起用纯PHP开发的其他类似解决方案,有更高的性能。
   
一个典型的PDO应用如下例:

$pdo = new PDO(”mysql:host=localhost;dbname=justtest”, ” mysql_user “, ” mysql_password”);
   $query = “SELECT id, username FROM userinfo ORDER BY ID”;
   foreach ($pdo->query($query) as $row) {
   echo $row['id'].” | “.$row['username'].”<br/>”;
   }

没有评论 »

牺牲一致性来换取分布式架构的可伸缩性

三月 18, 2008 | c/c++ | RSS 2.0

牺牲一致性来换取分布式架构的可伸缩性

作者 Floyd Marinescu & Charles Humble译者 王丽娟 发布于 2008年3月11日 下午7时30分

社区

Architecture

主题

性能和扩展性

系 统架构师角色关键的一方面就是衡量相互冲突的需求、决定解决方案,常常要牺牲一个方面来换取另一个方面。随着系统变得越来越大、越来越复杂,越来越多关于 如何构建应用的传统智慧正在受到挑战。比如说,去年3月在伦敦召开的QCon会议上,Dan Pritchard谈论了eBay的架构。他的介绍随后得到了很多的报道,其中一个主要的结论就是eBay不使用事务,用数据一致性上的损失来换取系统整 体伸缩性和性能上相当大的改进。

InfoQ接着Dan Pritchard在QCon会议上的谈话与他继续讨论,以获得更多信息:

为什么eBay不使用事务,或者为什么可以决定不采取应用级事务?

我们并非一概不使用事务。我们只是不使用跨物理资源的事务,因为它会造成多个组件之间出现依赖。组件可以是应用服务器和数据库。(例如在客户端控制 的事务中,)一个客户端的失败会长久地阻塞数据库资源、超出我们的忍受程度。我们也不使用分布式事务,因为让应用依赖于多个数据库会降低客户端实际的可用性。相反,我们选择缺少事务的设计,并加入失效模式,失效模式可以使客户端甚至在发生数据库可用性问题的时候也能继续进行。

应用级事务总是有些问题。只要让开发人员管理资源的生命周期,就少不了因管理出错而引起的Bug。事务管理和内存管理比起来没有多大的不同,而且我们看到由于生命周期问题,语言的总体趋势是不再让开发人员负责内存管理。假设Bean后面的每个数据库操作都是同等重要的,那么声明性事务(就像EJB中 的那些)就是一个简化事务管理的强有力的方法。

是否采用事务真正取决于你的伸缩性和可用性目标。如果你的应用需要达到每秒数百笔事务,你会发现分布式事务达不到这一目标。如果你想使可用性超过 99.9%,那么你根本不能想当然地假设所有的数据库提交都能在Web页面的上下文中完成。遗憾的是,对于何时应当放弃应用级事务并没有简单的规则。相反,做为一名架构师,你必须决定什么时候应当为了满足系统的一个制约因素的要求而放松对另一个制约因素的要求。

你是怎样为像“出价竞拍”这样的操作实现原子性的?

出价竞拍本身就是一个很有意思的问题,原子性并不是重点,更多的是关系到在拍卖关键的最后几秒钟里不要阻塞任何出价人。如果改成在显示时刻而不是在 出价时刻计算最高出价人和最高出价,就会变得非常简单。所有出价都被插入到一个单独的子表,插入操作不太会引起资源争用的情况。每次显示产品的时候,再重新取回所有的出价,并且在这个时候应用业务逻辑来决定最高的出价人。

你的问题背后隐藏的真正问题是我们如何实现一致性?要在大型系统中实现一致性,你必须放弃ACID,转而使用BASE:

基本可用(Basically Available)

软状态(Soft state)

最终一致(Eventually consistent)

如果你能够在每个客户端请求快结束的时候放松对数据一致的要求,就有可能消除分布式事务,并使用其它机制来达成一致的状态。举例来说,在上面的出价 案例中,我们也更新视图数据表,视图数据表是按照出价人来组织数据的,目的是加速“我的eBay”页面的显示。这里用两个异步事件来完成。一个是依靠内存 中的队列,因为我们希望尽量缩短从出价到在显示在“我的eBay”页面上之间的响应时间。但是,内存中的队列不可靠,所以在发生出价操作的时候,我们同时用一个服务器端事务来捕获出价事件。即使内存中队列的操作失败了,这个出价事件也能根据还原机制被处理。出价人视图数据表因此而解耦,但不总是与出价表的 状态保持一致。不过这是我们可以接受的让步,它让出价表和出价视图表之间不必服从ACID要求。

对其它大型系统的架构,你有什么建议吗?

最简单的建议就是,给一个为小规模应用而设计的架构增加资源并不能让它变成大规模的架构。你必须打破常规模式,比如ACID和分布式事务。乐于寻找机会放松一些约束,即使传统上认为是不能放松的。

还有两条简单的原则:把每样东西都设计成分离的;考虑BASE、而不是ACID。

亚马逊CTO Werner Vogels也在QCon发了言,他通过引用Eric Brewer的CAP定理提供了一些权衡取舍更深层的背景。这个定理曾在2000年PODC会议上(.pdf 文件)进行过介绍,介绍中也包括ACID vs. BASE的内容。它陈述了对于数据共享系统的三项属性——数据一致性、系统可用性、对网络分区的耐受性——在同一时间只能达成其中的两项。换句话说,一个 不能容忍网络分区的系统可以利用像事务这样普通的技术来实现一致性和可用性。然而,像亚马逊和eBay这样的大型分布式系统,网络分区是既定的。它的后果 就是,大型分布式系统的架构必须决定时放松对一致性的要求,还是放松对可用性的要求。两种选择都会给开发人员造成一些负担,他们需要了解他们处理的架构的特点。比如说,如果你选择放松一致性要求,那么开发人员就要决定怎样处理这种情形——对系统的写入不会立即反映到对应的读出中。就像Windows Live项目经理Dare Obasanjo在他的博客中写的一样。

我们在Windows Live平台的某些方面也采用了类似的做法。我也听到了开发人员抱怨一件事情,就是原先能通过事务轻松获得的错误恢复,现在要留给应用开发人员来处理。最大的苦恼往往是关于回滚复杂的批处理操作。

许多大型网站似乎都殊途同归,得到了同样的结论。观察到这一点是很有意思的。虽然只有几个节点的小型系统尚不需要关注这些形形色色的权衡取舍,但是eBay和亚马逊正在处理的各种问题可能已经开始在企业系统中出现了,因为这些企业系统的用户规模也正变得越来越大。

没有评论 »

zendframework 权限验证登陆

三月 17, 2008 | 网站架构 | RSS 2.0

讲述Zend 的权限和身份验证的综合应用

2008-03-07 13:47:16 / 个人分类:Zend Framework

讲述Zend 的权限和身份验证的综合应用.

 

思路如下:

                                                                                 —àsetModule()

浏览器地址—àZend_Controller_Front—àregisterPlugin—àsetController()

                                                                                    –àsetAction()

registerPlugin载入的插件处理程序将完成权限判断后定义程序的流程.

 

代码详解:

主文件(index.php)

$dbconfig = array(

       ‘type’ => ‘PDO_MYSQL’,

       ‘db’  => array(

       ‘host’ => ‘localhost’,

       ‘username’ => ‘root’,

       ‘password’ => ‘123456’,

       ‘dbname’  => ‘zend’

)

);

//创建一个数据库连接先

$db = Zend_Db::Factory($dbconfig[‘type’], $dbconfig[‘db’]);

$acl = new MyAcl();            //创建了一个MyAcl对象. MyAcl内完成分配权限功能.

$auth = Zend_Auth::getInstance();

$frontController = new Zend_Controller_Front();

$frontController->throwException(true);

$frontController->setDefaultDirectory(‘./application/controllers’)

                      ->registerPlugin(new MyAuth($auth, $acl)); //注册一个权限处理和身份验证插件,这个插件将对当前用户进行验证,并判断是否具备权限.并分别对程序的module, controller, action进行定义。

$frontController->dispatch();

 

这是MyAcl类所有的文件(MyAcl.php)

解释这个文件代码前,先交代一下代码中用到的ini文件.内容如下:

 

[index]

Index = index:index

Add = index:add

Edit = index:edit

Del = index:del

Login = index:login

Logout = index:logout

 

对这种格式很熟悉吧, Zend_Config_Ini 载入后,等号左边将为数组的指针, 右边为数组的值.

Class MyAcl extents Zend_Acl {

Function __Construct() {

/*载入ini文件后,将得到一个数组

$config = array(

‘index’ = > ‘index:index’,

‘add’  => ‘index:add’,

‘edit’  => ‘index:edit’,

‘del’  => ‘index:del’,

‘login’ => ‘index:login’,

‘logout’ => ‘index:logout’

)

*/

$config = new Zend_Config_Ini(‘resource.ini’, ‘index’);

      Foreach($config as $key => $value) {

             $this->add(new Zend_Acl_Resource($value));         //将配置文件中的值添加至资源中.完成了的Acl中的资源设置.

            }

            $this->addRole(new Zend_Acl_Role(‘guest’));             //分三个权限等级,完成对角色的设置.

            $this->addRole(new Zend_Acl_Role(‘editor’), ‘guest’);  

            $this->addRole(new Zend_Acl_Role(‘admin’));

 

            //分配权限, Zend_Acl 提供allow和deny方法.

            $this->deny(‘guest’, null);       //初级用户将不具备任何权限.

            $this->allow(‘editor’, array(‘index:index’, ‘index:add’, ‘index:edit’, ‘index:del’, array(‘index’,’add’,’edit’,’del’);

            $this->allow(‘admin’);

}

}

 

 

MyAuth.php

 

Class MyAuth extents Zend_Controller_Plugins_Abstractor {

       Private $_acl;

       Private $_auth;

       Private $noauth = array(

              ‘module’ => ‘index’,

              ‘controller’ => ‘index’

              ‘action’   => ‘login’

       );

       Private $nopur = array(

              ‘module’ => ‘index’,

              ‘controller’ => ‘index’,

              ‘action’  => ‘login’

       );

       /*

       获取从主文件index.php 中传递过来的对象参数$auth, $acl

       */

       Public function __construct($auth, $acl) {

              $this->_auth = $auth;

              $this->_acl  = $acl;

       }

       Public function preDispatch(Zend_Controller_Request_Abstractor $request) {

              If(!$this->_auth->hasIdentity()) {

                     $role = $this->_auth->getIdentity()->role;

              } else {

                     $role = ‘guest’;

              }

              $module = $request->module();

              $controller = $request->controller();

              $action   = $request->action();

              $resource = “$controller:$action”;

              If(!$this->_acl->has($resource)) {

                     $resource = null;

              }

             

              $if(!$this->_acl->isallowed($role, $resource, $action)) {

                     /*

                            没有权限或者没有验证时,分别定义Module Controller Action

                     */

                     If(!$this->_auth->hasIdentity()) {

                            $module = $noauth[‘module’];

                            $controller = $noauth[‘controller’];

                            $action  = $noauth[‘action’];

                     } else {

                            $module = $nopur[‘module’];

                            $controller = $nopur[‘controller’];

                                   $action = $nopur[‘action’];

                     }

                     $request->setModuleName($module);

                     $request->setControllerName($controller);

                     $request->setActionName($action);

              }

       }

}

 

 

 

身份验证文件代码(login.php)

 

Function loginAction() {

       If($this->_request->isPost()) {

              $filter = new Zend_Filter_Striptags();

              $username = trim($filter->filter($this->_request->getPost(‘username’));

              $password = trim($filter->filter($this->_request->getPost(‘password’));

 

              $db = Zend_Registry::get(‘db’);

              $authAdapter = new Zend_Auth_Adapter_DbTable($db, ‘users’, ‘username’, ‘password’);

              $authAdapter->setIdentity($username)

                               ->setCredential(md5($password));

              $auth = Zend_Auth::getInstance();

              $result = $auth->authenticate($authAdapter);

              If($result->isValid()) {

       $data = $authAdapter->getResultRowObject(null, ‘password’);

       $auth->getStorage()->write($data);

       $this->_redirct(‘/’);

       Return;

}

       }

}

没有评论 »