• 快来参加7月17日在成都举行的SOA中国技术论坛
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 搜狐网站诚聘Java、PHP和C++工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

数据库Recipe

没有数据库的rails

问题描述

就像所有“偏执的软件”一样，Rails一开始就假定你在做一个数据库应用程序的开发。出现这个假定是因为--通常情况都是这样的。但是，当你开发一个基于文件做后台的程序时，或者是为一个外部API提供前台展现时，Rails都显得不那么友好，特别是在做测试时。

解决方案

默认的情况下，Rails假定你运行任何测试的时候都要连接并初始化一个数据库。这就意味着如果你没有数据库的话，测试就变得难以进行。当然，你可以仅仅创建一个没有任何内容的空库，但这也意味着你有了一堆没有意义的基础架构。对于已经生成的Rails程序，有一些小技巧（hacking）可以使它们变成可测试的样子。

为了保持事情简单和可重复，我们将从一个新的程序开始。这样你就能容易的把我们在这里做的东西放到你的程序里边。让我们现在就开始创建这个程序，你可以叫它任意你喜欢的名字，我给它的命名是“DatabaselessApplicatio”。

然后我们在lib中创建个简单的class来写一些测试。让我们创建这个叫Adder的类，它可以使两个数加起来（真的非常容易）。

DatabaselessApplication/lib/adder.rb

class Adder

def initialize(first,second)

@first=first

@second=second

end

def sum

@first+@second

end

end

现在我们来为它创建一个测试用例，也就是test/unit/adder_test.rb:

DatabaselessApplication/test/unit/adder_test.rb

require File.join(File.dirname(__FILE__), "..", "test_helper")

require ' adder'

class AdderTest<Test::Unit::TestCase

def test_simple_addition

assert_equal(4,Adder.new(3,1).sum)

end

end

让我们运行这个测试：

chad> raketest_units

(in/Users/chad/src/FR_RR/Book/code/DatabaselessApplication)

Rake aborted!

#42000Unknown database 'databaselessapplication_development'

看上去Rails的test_units()这个RakeTask做了些数据初始化的工作。事实上，用rake-P 可以证明这一点：

chad> rake-P|tail

prepare_test_database

rakestats

raketest_functional

prepare_test_database

raketest_plugins

environment

raketest_units

prepare_test_database

rakeunfreeze_rails

rakeupdate_javascripts

足够确定test_units()是依赖于prepare_test_database() 这个task的。那我们不通过RakeTest直接运行这个测试会怎么样呢？

chad> rubytest/unit/adder_test.rb

Loaded suite test/unit/adder_test

Started

EE

Finished in 0.052262 seconds.

1)Error:

test_simple_addition(AdderTest):

Mysql::Error:

#42000Unknowndatabase ' databaselessapplication_test'

(abbreviated)

这些输出的结果说明了，因为在运行链路的某个地方引入了test_helper.rb，使得我们继承了数据库为中心的setup()和teardown()方法。我们可以在测试中仅仅手工指定是否需要”test/unit”，但是这样在我们创建的每一个测试里都会有重复这个指定。而且我们还会发现这样将不能初始化Rails环境。所以，我们采用修改test_helper.rb的方法来替代。

• 快来参加7月17日在成都举行的SOA中国技术论坛
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 快来参加7月17日在成都举行的SOA中国技术论坛
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 快来参加7月17日在成都举行的SOA中国技术论坛
• 搜狐网站诚聘Java、PHP和C++工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

• 快来参加7月17日在成都举行的SOA中国技术论坛
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 搜狐网站诚聘Java、PHP和C++工程师

本文目的

本文的主要目的是讨论企业应用实现高可用性的方案。即如何在保证性能的同时，使得应用保持 24 小时的可用性。 为实现此目的，灾难恢复和性能问题的解决是必不可少的。本文仅就程序和应用服务器两方面进行讨论，不讨论数据库等相关的问题。

1.    灾难恢复

所谓灾难恢复（仅对 Web 应用而言），是指在某个应用失去响应能力后（比如重启），客户端能立即透明的切换到冗余应用。这一切换对客户端来讲应该是感觉不到的。从技术上来讲，就是客户端在与服务器端进行交互的过程中，客户端在服务器端保存的状态能立即切换到新的服务器上。在 web 应用中，这些状态一般保存在 http session 里。所以所谓状态复制，一般来讲就是 http session 复制。

目前能提供灾难的方案之一是集群。对于 Weblogic ，集群的实现方式为 Paired servers replication ：

（图片引自 http://www.theserverside.com/articles/article.tss?l=J2EEClustering ）

在这种实现方式里， session 只在相邻的或者指定的两个 server 之间进行复制，当某一个 server down 掉后，需要 servers 前端的 load balancer 知道哪一台 server 是这个 Server1 的 paired backup server ，并将原来指向 Server1 的请求转发给这台 paired backup server 。应该说这种复制策略是相当高效的，但是对集群前端的路由要求比较高。

2.    性能

企业应用一般会跑在多台服务器上。就性能而言，我们的期望自然是：总体性能 = 单台服务器性能 X 服务器台数。不过从上边的说明就能看出，集群中的每一台 server 都会有一部分性能耗费在 session 复制上。耗费的性能取决于 session 的大小。如果应用中 session 保留了大量的数据，或者用户数量很多，损耗的性能也将相当可观。

（有一种提升性能的方案是使用分布式的对象，例如 EJB ，根据对象耗费性能的不同对其所在服务器进行调整。不过这种方案早已充满了极大的争论。流行的观点认为，对于业务逻辑不是很复杂的应用，使用分布式对象只会让性能下降。因此下边将不再讨论。）

3.    维护

从维护的角度上看，如果我们能不重启应用就能给应用添加新的功能，或者修改已有的 bug ，那显然相当 8 错。

分析

根据上边的说明，我们可以初步得出几个结论：

1、  要使用Weblogic集群所带来的灾难恢复的好处，就必须忍受同时带来的性能损失。

2、  在使用weblogic集群的同时，我们必须拥有高性能的 Server 路由设备。

3、  使用weblogic集群，在重新部署应用时，由于不能重新部署 (redeploy) 集群下单台 server 的应用，导致几台 server 需要同时停掉应用。当所有的 server 全都陷入灾难中，灾难恢复也就失去了意义。

那么，如何在实现灾难恢复和高性能的同时，又能避免或者减少上边列举的损失呢？

初步的思路可以有：

1、  如果我们能忍受某一台 server down 机后客户状态丢失的后果，那么最简单的方案就是停用集群，前端 load balancer 把相同 IP 的请求转到相同的服务器。在重新部署应用时，分批重起不同 server 上的应用。

2、  全部采用无 session 策略。将客户状态保留在客户端。这样没有Weblogic集群也就无所谓了。我们只需要一个普通的（分发器+失败检测）将请求均匀的分发到可用的服务器上。

• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 搜狐网站诚聘Java、PHP和C++工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 北京: 千橡集团暨校内网诚聘软件研发工程师