这篇文章就介绍了解决这个问题的方法：
http://www.zorched.net/2007/05/29/making-session-data-available-to-models-in-ruby-on-rails/

Ruby on Rails is implemented as the Model View Controller (MVC) pattern. This pattern separates the context of the Web Application (in the Controller and the View) from the core Model of the application. The Model contains the Domain objects which encapsulate business logic, data retrieval, etc. The View displays information to the user and allows them to provide input to the application. The Controller handles the interactions between the View and the Model.

This separation is a very good design principle that generally helps prevent spaghetti code. Sometimes though the separation might break down.

The following is really an alternative to using the ActionController::Caching::Sweeper which is a hybrid Model/Controller scoped Observer really. It seems to me, based on the name, that the intent is much more specific than giving Observers access to session data. Which do you prefer?

Rails provides the concept of a Model Observer. This Observer allows you to write code that will respond to the lifecycle events of the Model objects. For example you could log information every time a specific kind of Model object is saved. For example you could record some information every time an Account changed using the following Observer:

class AccountObserver < ActiveRecord::Observer
def after_update(record)
Audit.audit_change(record.account_id, record.new_balance)
end
end


You might have noticed a limitation with the previous API though. You didn’t notice? The only information passed to the Observer is the Object that is being changed. What if you want more context than this? For example, what if you want to audit not only the values that changed them, but the user who made the change?

class AccountObserver < ActiveRecord::Observer
def after_update(record)
Audit.audit_change(current_user, record.account_id, record.new_balance)
end
end


How do you get the current_user value? Well, you have to plan ahead a little bit. The User in this application is stored in the HTTP Session when the user is authenticated. The session isn’t directly available to the Model level (including the Observers) so you have to figure out a way around this. One way to accomplish this is by using a named Thread local variable. Using Mongrel as a web server, each HTTP request is served by its own thread. That means that a variable stored as thread local will be available for the entire processing of a request.

The UserInfo module encapsulates reading and writing the User object from/to the Thread local. This module can then be mixed in with other objects for easy access.

module UserInfo
def current_user
Thread.current[:user]
end
 
def self.current_user=(user)
Thread.current[:user] = user
end
end


A before_filter set in the ApplicationController will be called before any action is called in any controller. You can take advantage of this to copy a value out of the HTTP session and set it in the Thread local:


class ApplicationController < ActionController::Base
include UserInfo
# Pick a unique cookie name to distinguish our session data from others'
session :session_key => '_app_session_id'

before_filter :set_user

At any point in an Observer of a Model class that you need to have access to those values you can just mixin the helper module and then use its methods to access the data. In this final example we mixin the UserInfo module to our AccountObserver and it will now have access to the current_user method:

class AccountObserver < ActiveRecord::Observer
include UserInfo
 
def after_update(record)
Audit.audit_change(current_user, record.account_id, record.new_balance)
end
end


You generally shouldn’t need this kind of trick outside of an Observer. In most cases the Controller should pass all of the information needed by a Model object to it through its methods. That will allow the Model objects to interact and the Controller to do the orchestration needed. But in a few special cases, this trick might be handy.

10 steps to get Ruby on Rails running on Windows with IIS FastCGI

Since the original tech preview release of FastCGI last year, we've been seeing a lot of requests for getting Ruby on Rails running with our FastCGI.  Theoretically, since the FastCGI component uses a standard protocol to support FastCGI-enabled applications, this shouldnt be an issue - but, in practice, this is very far from reality.  After factoring in setup problems, configuration, and variations in runtime behavior / protocol deviations, every single FastCGI application we've looked at has required quite some effort to support properly. 

So, for FastCGI Tech Preview 2, I spent some time researching what it would take to enable Ruby on Rails, resulting in "experimental" RoR support in the TP2 release.  It is "experimental" because we did only limited testing, and given our lack of experience with Ruby its very hard to tell whether a real Ruby application will work as expected at this point.

I am confident that the experience can be improved significantly with community testing, and any necessary fixes to both the FastCGI component and Ruby.  I am looking forward to any feedback/bug reports that can help us get there - please feel free to leave comments on the blog, or post to IIS FastCGI forums. 

Without further ado, these are the 10 steps get RoR working with FastCGI TP2:

Read this first - platform limitations

The steps below can be used to install Ruby on Rails on a Windows Server 2003 operating system, and configure it to work with the Microsoft IIS FastCGI technical preview 2 release.  Unfortunately Windows XP does not support the required configuration necessary for the FastCGI TP2 component to run RoR, and Windows Vista's version of FastCGI TP2 uses a different mechanism to run RoR (post on how to get that working in the near future).  The initial steps to install Ruby on Rails described here are similar for Windows XP, Windows Server 2003, and Windows Vista.

FastCGI TP2 Installation

1) Download and install FastCGI Technical Preview 2

Download the appropriate TP2 package for your OS, which in this case means either the IIS6 32bit FastCGI or IIS6 64bit FastCGI.  You can read more about this on my previous blog post.  Here is the synopsis of the install steps:

• Download the appropriate FastCGI TP2 package
• Unzip it to a local directory on your machine
• Use fcgisetup.js to install it:
  
  > cscript fcgisetup.js /install

This will install FastCGI on your machine, and enable us to configure it manually later.  We will not be using the automatic configuration support in the installer because we will need some customizations specific for RoR later.

Ruby Installation

2) Download and install Ruby (latest tested version was  1.8.5-22 Final)

3) Install Rails

Open a new command line window, and run the gem installer:

> gem install rails --include-dependencies

 

4) Download and install RoR IIS extensions

The RubyForIIS.exe package contains the FastCGI client library on which RoR is dependent in order to use its dispatch.fcgi script.  During the installation, the installer will ask for the location of the Ruby directory - be sure to point the installer to the directory where you installed Ruby, for example, f:\Ruby.



During the installation, you may get an error "Unable to write to file ...\msvcp7.dll"  - press ignore to continue.  If you want to double-check that everything went well, open a command prompt, and type in:
> irb <enter>
> require 'fcgi' <enter>
If you see "true", then its installed correctly.  If not, re-install and give the right path this time.

5) Fix the Ruby CGI script

This is a workaround for an IIS-specific behavior in Ruby that actually does not work with IIS.  Feel the irony.  Quick background - NPH, or No Parsed Headers, is a CGI mode of operation in which the CGI program produces a complete response including the http headers, instead of supplying the headers to the web server and letting the webserver manage them.  Most of today's webservers, including IIS, manage response headers on their own - for example, IIS enables a number of web server features that modify response headers in order to enable functionality like caching, compression, etc.  Ruby's CGI script assumes that IIS always requires NPH, and this of course completely breaks the FastCGI component because it does not even support NPH :)  The funnier thing is that even IIS CGI does not require NPH, and doesnt use it by default.  This is one of the things that totally makes sense to be fixed in a future Rails release to provide a more cohesive experience on IIS.

Open <f:\Ruby>\lib\ruby\1.8\cgi.rb, and edit line 559 of the script to remove:
                                       "OR /IIS/n.match(env_table([‘SERVER_SOFTWARE’])".

You can also download the already fixed script  if you dont want to do surgery yourself.

Creating a sample Ruby application

At this point, if you followed the instructions above, you should have Ruby on Rails installed and ready to go on your Windows machine.  Now, we will create a sample RoR application to use with the FastCGI component:

6) Create a sample Ruby app

Open a command line window, change to a base directory where you want to create your app, and type:

> rails myapp
> cd myapp
> ruby script\generate controller test

This creates the myapp RoR application, and then generates a sample "test" RoR controller.  Edit this controller to display some useful stuff by opening app\controller\test_controller.rb, and pasting the following into it:

class TestController < ApplicationController
  def index
    render :text=>"The index action"
  end
  def about
    render :text=>"Testing app v1.0"
  end
end

Configure the RoR application with IIS and FastCGI

We are almost there, so don't panic.  I promise to not exceed 10 steps :)

7) Create a website for your RoR app

Create a new website on port 81 pointing to the public directory of your rails app, which for me was f:\ruby\myapp\public:

8) Create the RoR FastCGI handler mapping

Because RoR uses SEF (search engine friendly) urls, it needs to use a wildcard mapping to forward all requests to FastCGI / RoR mapping - unlike PHP, which requires .PHP files to be mapped to the PHP / FastCGI mapping.  Because of reliance on wildcard mapping, FastCGI can only be used to run RoR on Windows Server 2003 (since Windows XP's version of IIS doesnt support wildcard mappings).  This is the sole reason why this walkthrough is limited to W2k3.

To create the mapping, click the "Configuration" button on the website, and "Insert" the handler mapping to "fcgiext.dll" FastCGI ISAPI handler (which you installed in step 1):

Be sure to clear the "Verify that file exists" checkbox.

9) Create the FastCGI application pool for your website

If you remember in step 1, when we installed the FastCGI TP2 package, we didnt use the installer's support for registering a FastCGI program.  This is because RoR requires some custom settings in the FastCGI config file that the installer doesnt surface. 

Because of this, we will manually create this configuration by editing the %windir%\system32\inetsrv\fcgiext.ini configuration file (NOTE that for 64bit installations, you will also need to make the same edits to %windir%\syswow64\inetsrv\fcgiext.ini):

[Types]
*:85358523=Ruby

[Ruby]
ExePath=F:\Ruby\bin\ruby.exe
Arguments=F:\Ruby\myapp\public\dispatch.fcgi
IgnoreDirectories=0
IgnoreExistingFiles=1
QueueLength=1000
MaxInstances=4
InstanceTimeout=30
InstanceMaxRequests=200

- Replace the ExePath with the path to your ruby.exe.
- Replace the Arguments with the path the dispatch.fcgi script inside your application.
- Replace the "85358523" number above with your site id.  You could omit this if you are not planning to run multiple Ruby applications on your machine. You can get it from the logging properties of your website: 

This configuration shows the several new configuration / behavior features we needed to add to TP2 in order to get Ruby working.  This includes support for specifying arguments to the FastCGI executable (per pool), the ability to scope FastCGI extension mappings to a particular site id (so that you can map the same extension to different pools for different sites), and the ability to execute as a wildcard mapping that only processes files that do not exist on disk.  More information on all of these later.

10) You are done!

At this point, you should be up and running.  Hit up http://localhost:81/test/about, and you should get the RoR response from our test controller.

Please try this out with your real RoR apps, and let me know how it went / what issues you hit.  Your feedback will be instrumental in getting to a production quality FastCGI support for RoR in a future release.  Feel free to leave comments on this blog, or hit us up at the FastCGI forums on www.iis.net.

Finally, I want to thank Brian Hogan, without whose invaluable help in explaining the workings of Ruby On Rails and how to get it installed on Windows, I wouldn't have been able to get even this far.  He has a book on Ruby on Rails coming out soon, and I hope that we can get IIS FastCGI and RoR to play well enough together to be mentioned in it :)

首先接收到HTTP请求的是HAProxy。HAProxy会把请求反向代理给其后的多个Mongrel实例。每个Mongrel实例同一时间只处理一个请求。只要Rails应用本身贯彻无共享架构，就可以直接通过增加服务器和改变HAProxy配置得到线性的性能提升。另外可以用Monit来管理Mongrel实例的开启和关闭，并且在异常状况发生时及时采取措施。这样一来，企业级超复杂所暗含的性能、伸缩性、可管理性等等要求都满足了。

“HAProxy is a free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP and HTTP-based applications.”
“Mongrel is a fast HTTP library and server for Ruby that is intended for hosting Ruby web applications of any kind using plain HTTP rather than FastCGI or SCGI.”
“monit is a utility for managing and monitoring, processes, files, directories and devices on a UNIX system.”

转自：http://gigix.thoughtworkers.org/articles/2007/04/24/deploy-rails-app-with-haproxy-and-mongrel