簡介

Ruby On Rails 框架自它提出之日起就受到廣泛關注，在“不要重復自己”，“約定優于配置”等思想的指導下，Rails 帶給 Web 開發者的是極高的開發效率。 ActiveRecord 的靈活讓你再也不用配置繁瑣的 Hibernate 即可實現非常易用的持久化，Github 和 Rubygems 上豐富多樣的 Rails 插件是 Rails 開發高效率的又一有力保障。Rails 是一個真正徹底的 MVC（Model-View-Controller) 框架，Rails 清楚地將你的模型的代碼與你的控制器的應用邏輯從 View 代碼中分離出來。Rails 開發人員很少或者可能從未遇到過某些代碼該放于哪一層的困擾，在 Rails 的世界中，你的代碼的職責很清楚的被定位，你可以輕松的決定出它們應該位于哪一層。Rails1.2 之后的版本開始支持 Rest Service，通過這些內嵌的特別，你在開發你 Web 應用，展現給用戶 HTML 的頁面的同時，幾乎不費吹灰之力，就可又提供基于 Rest API 的 Web Service，另外，你也可以方便的像使用基本數據的 Model 一樣的去消費第三方提供的基于 Rest API 的 Web Service。

通過搜索引擎，你可以找到很多類似于用 Ruby On Rails 十五分鐘創建 Blog 系統等類似的使用 Rails 進行快速開發的文章。 Ruby On Rails 對于敏捷開發過程的也是非常友好，在 Rails 框架中集成了 Unit Test, Function Test 對你的 Model 和應用邏輯進行測試。通過這些，你不需要再安裝任何插件或者程序庫便可方便的進行測試驅動開發，通過 Watir 的支持，你可以輕松的用 Ruby 代碼實現基于瀏覽器的自動測試。 另外，在 Rspec 等插件的支持下，你甚至可以進行行為驅動開發（Behaviour Driven Development），讓你的測試代碼變得更加有意義，也更加容易被客戶所接受。

雖然 Rails 的優點你可以一下子列出很多，你也可能會拿出用 Java/Hibernate/Spring/Struts 和 Ruby On Rails 開發同樣功能 Web 應用程序的代碼行比較來舉例，或者提供進行 Java/Hibernate/Spring/Struts 和 Ruby On Rails 開發所需要接受的培訓資料的書籍的對比照片來舉例，但我們都不可避免的會面對可伸縮性（Scalability）的問題。很多 Web 應用會面對大量的用戶群，這樣的應用會遇到很大的并發帶來的性能的考驗。 Rails 在這一點上，并沒有讓所有人信服，依然有很多的系統架構師和工程師對 Rails 是否適用于開發高負載高并發的 Web 應用持懷疑的態度。但不可否認，隨著 twitter, friends for sale,basecamp 這類大負載量的應用的出現，Rails 也越來越被認識是可擴展的，這些成熟的應用也告訴我們，開發出同時處理數百萬用戶請求的 Rails 應用是可能的。Ruby On Rails 框架在可伸縮性上為人詬病無非集中于以下幾點，Ruby 語言本身性能問題，Ruby On Rails 缺少成熟的高性能的應用服務器，對數據庫擴展的支持，互聯網上缺乏可熟可靠的網絡提供商等等。 本文將從這些點出發，介紹具可伸縮性的 Rails 應用程序的部署架構，以及開發高性能的 Rails 應用程序的一些比較好的具體實踐。

通常的 Web2.0 應用，特別是高負載的應用，除了 Web 和應用服務器選擇 , 負載均衡這類部署需要面對的問題之外，通常還必須得面對后臺任務，高性能全文搜索這些開發上的問題，這些在 Java 或者 PHP 這些比較成熟的開發環境里面都有比較成熟的方案，開發和架構人員通常都會有多種選擇，結合具體應用做出架構設計。在新興的 Rails 社區，這些還并不完善和成熟，本文將介紹一些高性能可伸縮的 Rails 應用程序的開發和部署的具體實踐，針對通常 Web 2.0 網站所遇到的具體問題做出分析和解決方案，旨在給 Rails 開發者提供具體的參考。本文將介紹的內容可以用下圖來綜合表示：
圖 1. 本文總體結構

使用 Nginx+Passenger 來替代 Apache+Mongrel 來部署 Rails 應用

事實上，進行 Rails 部署可以描述得非常簡單，我們需要一些機器配置我們的環境，為了性能和成本，我們理所當然選用 Linux 系列的服務器，可選的有 CentOS，Debian, Ubuntu Server 等。本文的所有程序，命令以及代碼如非特別說明，都默認是以 Linux 為基本環境的。 然后我們需要數據庫存儲我們的數據，我們可以選用免費的 Mysql，然后我們便開始開發我們的 Web 應用的 Rails 代碼，部署時，我們需要支持 Ruby On Rails 的應用服務器讓我們的 Rails 代碼跑起來，這可能是 Rails 自帶的 Webrick，當然這個可能性極小，也可能是 FastCGI, 或者是 Mongrel，Thin, Passenger 等等，然后我們通過 Apache，Nginx，Lighttpd，HAProxy 之類的 Web 服務器訪問我們的應用服務器，這個訪問可以直接通過 HTTP 協議，也可以是 FastCGI，或者是自定義的其它協議，如此這般，我們便可以通過瀏覽器訪問我們的應用程序了。如下圖所示，這便是通常的 Rails 應用程序部署結構。
圖 2. Rails 應用程序部署結構

對于前端的 Web Server，Apache 是事實上的工業標準，在 Web 服務器市場，是占有率最高的，全球大量的網站采用 Apache 來部署他們的應用，Apache 是一款成熟穩定的 Web 服務器，功能非常強大，提供對幾乎所有 Web 開發語言和框架的擴展支持，在對 Rails 框架的支持上，我們可以采用 mod_fcgid 模塊，通過 FastCGI 協議與 Rails 進程通訊?；蛘呃?mod_proxy_balancer 對后端的獨立的 Rails 服務器如 Thin Cluster，Mongrel Cluster 或者 Apach/Nginx+Passenger 進行 HTTP 分發。但 Apache 作為一個通用的服務器，在性能上和一些輕量型的 Web 服務器相差甚遠。Apache 的 mod_proxy_balancer 模塊的分發性能不高，比 Nginx 或者 HAproxy 都相差很多，另外，Apache 目前并不支持 Event（事件）模型，它僅支持 Prefork（進程）模式和 Worker（線程）模式，每處理一個鏈接，就需要創建一個進程或線程，而一些輕量級 Web 服務器如 Nginx 和 Lighttpd，則都很好地利用內核的事件機制提高性能，極大減少線程或進程數量，降低系統負載。

Nginx 是一個輕量級的高效快速的 Web 服務器，它作為 HTTP 服務器和反向代理服務器時都具有很高的性能。Nginx 可以在大多數 Unix like OS 上編譯運行，并有 Windows 移植版。 Nginx 選擇了 Epoll 和 Kqueue 作為開發模型，它能夠支持高達 50,000 個并發連接數的響應，可以在內部直接支持 Rails 和 PHP 程序對外進行服務。另外，Nginx 作為負載均衡服務器，也可以支持作為 HTTP 代理服務器對外進行服務 , Nginx 不論是系統資源開銷還是 CPU 使用效率都比 Apache 要好很多。當你打開 Nginx 官方網站，你會發現一個如此知名的 Web 服務器產品的官方主頁竟然如此簡單，其實，Nginx 本身就是一個安裝非常簡單，配置文件非常簡潔，甚至可以在配置文件中使用 Perl 語法。

在處理靜態文件上， Apache 和 Nginx 都可以勝任。但對于應用服務器或者是前端的負載均衡服務器，我們推薦 Nginx 而不是相對 Nginx 較為重量級的 Apache。

對于應用服務器，Mongrel 一度是最流行的部署方式，它的 HTTP 協議的解析部分是用 C 語言編寫的，效率上有所保證。Mongrel 使用了 Ruby 的用戶線程機制來實現多線程并發 , 但是 Ruby 并不是本地線程 ,Rails 也不是線程安全的，因此 Mongrel 在執行 Rails 代碼的過程中，完全是加鎖的狀態，那和單進程其實也沒有太大差別。所有我們在使用 Mongrel 來部署 Rails 應用程序時，一般是在后臺啟動一個 mongrel_cluster 來啟動多個 Mongrel 進程，如我們在 mongrel_cluster.yml 中進行如下配置可以在 8000~8009 端口啟動 10 個 Mongrel 進程。
清單 1. Mongrel_cluster.yml 配置

 --- 
 cwd: /var/www/test_app 
 log_file: log/Mongrel.log 
 port: "8000"
 environment: production 
 debug: false 
 pid_file: log/mongrel.pid 
 servers: 10

這樣的部署方式實際上也限制了 Mongrel 處理大并發應用的能力，在處理大數據量請求的時候，Mongrel 進程經常被掛過，但并發數一多，就會出現所有的 Mongrel 進都會被掛過的情況，這樣前端的服務器便得不到返回，整個 Web 應用就陷入癱瘓。所以，Mongrel 并沒有被廣泛采用，很多網站寧愿堅持使用最古老的 FastCGI 的部署方式也不使用 Mongrel 來部署應用，而且 Mongrel 也停止更新很久，Mongrel 的開發者已完全不再進行 Mongrel 的開發了。所以，Mongrel 并不是現在最推薦的 Rails 應用服務器。

Passenger 是類似于 mod_php 的 Rails 運行環境，而不是 Mongrel 那樣是獨立的 Http 服務器。Passenger 對目前主流的 apache 和 Nginx 兩大 Web 服務器都有支持。Passenger 使用起來極其方便，而且它具有較高的性能，從 Passenger 官方網站公布的測試結果來看，Passenger 的性能要優于 Mongrel 服務器，目前來說，Passenger 無疑是最好的選擇。Passenger 繼承了 Rails"不重復自己"的慣例，通過 Passenger 部署應用程序，你僅僅需要將 Rails 項目程序文件上傳到目標服務器，甚至都不需要重啟服務器，非常簡單。

要在 Nginx 環境下安裝運行 Passenger, 你僅僅需要如下操作：
清單 2. 安裝 Passenger

 gem install passenger 
 Passenger-install-nginx-module

下面的代碼展示了在 Nginx 上配置 Passenger:
清單 3. 在 Nginx 上配置 Passenger

 http { 
  ... 
  server { 
    listen 80; 
    server_name www.test.com; 
    root /var/www/test/public; 
    passenger_enabled on; 
  } 
  ... 
 }

通過 Nginx+Passenger 構建 Ruby On Rails 的應用服務器可以得到顯著的性能提升，同時，還可以采用 Ruby Enterprise Edition 來提升 Ruby 本身的性能。這個版本也是由 Phusion 開發的，采用 copy-on-write 的垃圾回收策略，并使用 tcmalloc 來改善內存分配，他們的網站公布的數據，使用 Ruby Enterprise Edition 能比普通的 Ruby 版本減少 33% 的內存消耗。

Nginx+Passenger 就部署在一臺機器上的應用服務器，但并發過大時，一臺機器并不足以來提供這樣的處理能力，這個時候，一般會做負載均衡，這和通常的負載均衡策略并無二異，Nginx 在使用反向代理來實現負載均衡的能力上要強于 Apache 的反向代理模塊，我們可以在多臺 Nginx+Passenger 的前端可以再增加一臺 Nginx 的 Web 服務器。甚至為了更強的處理能力，我們也可以采用 LVS 來進行負載均衡。

使用 Starling 和 Workling 去異步執行 Rails 后臺任務

在進行 Web 應用開發時，每個 Web 請求都需要迅速的得到返回，這時候有些計算量比較大的操作可以放在后臺去異步執行，比如大量的數據更新操作，只需要在 Web 應用中進行觸發，然后在后臺進行執行。而有些操作則需要定期去執行，比如數據的備份，一些數據的統計分析，圖片的處理，郵件的發送等等。這些操作如果放在 Web 應用中即時返回顯然是不合適的，而且也會帶來機器的負載很嚴重，對于 Rails 應用程序來說，除了影響用戶體驗，這樣的操作還會阻塞 Rails 服務器實例，從而帶來整體性能的下降。對于這類操作，我們可以使用一個任務隊列，將需要執行的操作依次入隊，然后在后臺再啟動進程進隊列中取出這些任務，并執行，隊列可以使用數據庫，Memcached, ActiveMQ 或者 Amazon SQS 來實現，而后端進程則可以使用 Rails 里面的 cronjob+script/runner 或者 BackgrounDRb 等等來操作。這里要介紹的解決方案則是采用 twitter 開發人員貢獻出來的采用 Memcache 協議的 Starling 消息隊列和 Workling 插件來進行實現。

Starling 是 twitter 開發團隊從 twitter 項目抽象出來開源的 Rails 插件，雖然說 Starling 并不完全就是 twitter 的線上版本所用的插件，但我們也可以足以相信 Starling 的性能和應對高并發的處理能力。類似的插件還有 backgroundrb，background job, background_fu。backgroundrb 是使用 drb 實現隊列的消息傳遞，但它還有一個問題，更新隊列的時候，backgroundrb 使用的是悲觀鎖，在大訪問量的情況下，這種情況是不容允許的。 background job 和 background_fu 則是基于數據庫的消息隊列，在大負載量的情況下數據庫的性能也不容易得到保證。而 Starling 是基于 Memcached 協議的消息隊列，效率更高，也更容易伸縮，通常你可以在每臺應用服務器上都運行一個 Starling 服務器，并在同一臺機器或者其它機器上去運行后臺程序與之交互。

我們通過如下命令來安裝 Starling：
清單 4. 安裝 Starling

 gem sources -a http://gems.github.com/ 
 sudo gem install starling-starling 
 mkdir /var/spool/starling

在讀取 Starling Server 時，我們需要 memcache-client，這個 gem 的 1.5.0 版本有一些問題，在 fiveruns-memcache-client 得到修正，這個 fiveruns-memcache-client gem 在 starling-starling gem 中是作為依賴項自動安裝的。

安裝完 Starling 之后，使用 sudo Starling -d -p 15151 這個命令來啟動它，啟動時用 -p 參數來指定所要使用的端口，一般加 -d 參數使它以 daemon 方式在后臺運行：

為了明白 Starling 的機制和 Starling 究竟做了哪些工作，在啟動了 Starling 之后，我們可以使用我們打開 irb 下面的程序來進行簡單的測試：

進行簡單的測試
清單 5. 測試 Starling

 >> require 'starling'
 => true 
 >> Starling = Starling.new('127.0.0.1:15151) 
 => MemCache: 1 servers, ns: nil, ro: false 
 >> Starling.set('test_queue', 123) 
 => nil 
 >> loop { puts Starling.get('test_queue'); sleep 1 } 
 123 
 nil 
 nil 
 ...

這里我們可以看到確實啟動了 Server，然后我們向這里插入數據，我們用一個循環去訪問這個隊列，最后的輸出便是我們想要的結果。

接下來我們安裝 workling：
清單 6. 安裝 workling

 script/plugin install git://github.com/purzelrakete/workling.git

Workling 支持多種方式來進行后臺任務操作，其中就包括上面已經安裝的 Starling，安裝好 Starling 后，我們需要在 Rails 應用程序中的 environment.rb 加上以下代碼來配置 Workling 使用 Starling：
清單 7. 使用 workling

 Workling::Remote.dispatcher = Workling::Remote::Runners::StarlingRunner.new

Workling 的配置文件在 workling.yml， 和其它 Rails 的配置文件類似，workling.yml 也可以針對不同產品模式進行不同的模式，這里僅列出 production 的配置。
清單 8. Workling 配置

 production: 
   listens_on:localhost:15151, localhost:15152, localhost:15153 
   sleep_time: 2 
   reset_time: 30 
   memcache_options: 
    namespace: myapp

listens_on 參數即為 workling_client 去訪問的 Starling 啟動的地址和端口，這里可以允許多個 Starling 地址，這就意味著你啟動多個 Starling 服務器，而用一個 workling_client 去調用。sleep_time 即為 workling_client 去隊列中取數據的等待時間，reset_time 則定義了如果出現 memcache 錯誤時，workling_client 等待去重建和服務器連接的時間。 在 memcache_options 的 namespace 參數則定義了所使用的命名空間，這在同一臺服務器如果為不同的 Rails 應用啟動同一個 Starling 服務器時是非常有用的。

用 script/workling_client start 腳本便可以啟動 workling_client 進程，有時候我們覺得一個 workling_client 不夠用，我們可以修改 script/workling_client start 來支持多個 workling_client 實例，這樣每運行 script/workling_client start 一次都會新啟動一個 workling_client 實例。
清單 9. 多 client 的 Workling 配置

 options = { 
 :app_name  => "workling", 
 :ARGV    => ARGV, 
 :dir_mode  => :normal, 
 :dir    => File.join(File.dirname(__FILE__), '..', 'log'), 
 :log_output => true, 
 :multiple  => true, 
 :backtrace => true, 
 :monitor  => true 
 }

使用 Memcached 和 cache-money 來緩存數據

Rails 自身提供四種緩存方式，即 Page Cache, Action Cache，Fragment Cache 和 ActiveRecord Cache 這三種緩存。Page Cache 是最高效的緩存機制，他把整個頁面以靜態頁面 HTML 的形式進行緩存，這對于不會經常發生變化的頁面是非常有效的。Action Cache 是對某個 action 進行緩存，與 Page Cache 的區別在于：HTTP 請求會經過 Rails 應用服務器，直到所有的 before filters 都被處理，這種緩存就能處理 Page Cache 無法處理的如需要登錄驗證的頁面，可以所驗證的步驟加入 before filter 中，Fragment Cache 則為了緩存頁面中的某一部分，同一個頁面中的不同部分還可以采用不同的過期策略。對于 Rails 本身的緩存機制，我們可以寫 sweeper 進行過期和清除的處理。ActiveRecord Cache 則是較新版本 Rails 中新推出的對 ActiveRecord 的緩存機制，使用 SQL 查詢緩存，對于同一 action 里面同一 SQL 語句的數據庫操作會使用緩存。

Rails 的緩存機制能非常有效的提升網站性能，Rails 默認是將緩存存在于文件系統中，這并不是適合生產環境下的存儲方式，文件 IO 的效率有限，Rails 還支持在同一進程的內存中保存 Cache，但如果有多個 Rails application，它們之間不能共享緩存。我們這里推薦的是以 MemCached 的方式進行存儲，這也是目前是流行的緩存存儲方式。

Memcached 是由 Danga Interactive 開發，用于提升 LiveJournal.com 訪問速度的。LiveJournal.com 每秒有幾千次動態頁面訪問量，用戶 700 萬。Memcached 是一個具有極高性能的分布式內存對象緩存系統 , 基于一個存儲鍵 / 值對的哈希表。其守護進程（daemon）是用 C 寫的 , Memcached 將數據庫負載大幅度降低，更好的分配資源，更快速訪問?？梢杂酶鞣N其它語言去實現客戶端。上文的介紹中已經安裝了 Rails 的 Memcached 客戶端，因為我們只需要在 Rails 應用程序中做如下配置：
清單 10. Memcached 配置

 config.cache_store = :mem_cache_store, 'localhost:11211'

便可以進行使用 MemCached 進行緩存數據。除了 Rails 本身的緩存機制，我們還直接用 Rails.cache 操作 Memcached 進行數據緩存，如，我們讀取所有 blog 的數量，可以如下使用緩存：
清單 11. 使用 Rails.cache

 blogs_count = Rails.cache.fetch("blogs_count") do 
  Blog.count 
 end

Rails 自身的 ActiveRecord 作用有限，只適用同一個 action 中的 SQL 查詢語句進行緩存，我們需要一個更強大的 ActiveRecord 緩存，而 cache-money 更是為了解決如此問題而推出的。當 twitter 網站變得越來越穩定，逐漸擺脫被人拿來作為"Rails 無法擴展的"典型例子的陰影時，人們便期待 twitter 開發團隊能向 Rails 社區有更多的貢獻，cache-money 便是在 Starling 之后 twitter 團隊貢獻出來的另一個插件。cache-money 和 Hibernate 的二級緩存類似，是一個讀寫式（write-through）緩存。在 ActiveRecord 對象更新的時候不是將緩存中的數據清除，而是直接將更新的內容寫入到緩存中去。

cache-money 有許多很棒的特性，如：緩存自動清除機制 ( 利用 after_save/after_destroy) ；支持事務，由于 Rails 的 Active Record 沒有提供 after_commit 機制，目前常見的緩存插件在高并發下會出現緩存更新競爭沖突，而這個特性對于解決這個問題會很有幫助，可以通過 gem 來安裝 cache-money：
清單 12. 安裝 cache-money

 gem sources -a http://gems.github.com 
 sudo gem install nkallen-cache-money 
 require 'cache_money'

清單 13. 配置 config/memcached.yml

 production: 
 ttl: 604800 
 namespace: ... 
 sessions: false 
 debug: false 
 servers: localhost:11211 

 development: 
  ....

清單 14. 使用 config/initializers/cache_money.rb 來初始化

 config = YAML.load(IO.read(File.join(Rails_ROOT, "config", "Memcached.yml")))[Rails_ENV] 
 $memcache = MemCache.new(config) 
 $memcache.servers = config['servers'] 
 $local = Cash::Local.new($memcache) 
 $lock = Cash::Lock.new($memcache) 
 $cache = Cash::Transactional.new($local, $lock) 
 class ActiveRecord::Base 
 is_cached :repository => $cache 
 end

使用 cache-money 非常方便，不需要額外的操作，只需要在你的 Model 里面進行簡單的配置，如：
清單 15. 配置 Model 來使用 cache_money

 class User  ActiveRecord::Base 
 index :name 
 end 
 class Post  ActiveRecord::Base 
 index [:title, :author] 
 end 
 class Article  ActiveRecord::Base 
 version 7 
 index ... 
 end

然后便可以跟以前一樣使用 Rails ActiveRecord 各種方法以及事務操作。如果你改變了數據庫的表結構，你可以改變 Model 的版本號來使以前的緩存失效，而不需要重啟 Memcached 服務器。

使用 Sphinx+LibMMSeg+Ultrasphinx 進行全文搜索

很多應用會有全文搜索的需求，當然你可以直接集成 google 或者其它搜索引擎提供的搜索服務，但如果你要更好的控制你的搜索結果，或者對你的搜索結果進行再次利用，你恐怕必須得自己實現全文搜索了。在進行中文全文搜索時，一般要考慮兩個方面的問題，即所使用搜索工具的性能問題，以及中文分詞的準備度。在 Java 的世界里，Lucene 是做全文搜索絕對的權威和首選，雖然它本身沒有對中文分詞很好的支持，但有很多第三方插件可以利用來提高中文分詞的準備率和性能。Ferret 一度是最流行的 Rails 全文搜索插件，但本文推薦是效率更高的 Sphinx。Sphinx 是俄羅斯人 Andrew Aksyonoff 開發的，這個詞的意思“獅身人面”，它能在一兩分鐘的時間內完成數百萬條記錄的索引，并在毫秒級的時間類返回搜索結果。 Sphinx 和數據庫集成良好，可以通過配置文件，直接用來對數據庫的數據進行索引，另外，Sphinx 開發了一個 SphinxSE 數據庫引擎，可以在編譯 Mysql 的時候直接編譯到 Mysql 里面去來實現數據庫級別的高效能索引。在 Rails 中使用 Sphinx 可以通過 Ultrasphinx 插件，Rails 開發人員可以使用它來很方便地調用 Sphinx 的功能。

可以從這里 http://www.sphinxsearch.com/downloads.html 下載 Sphinx

在安裝好 Sphinx 后可以直接從 Rubyforge 上安裝 Ultrasphinx:
清單 16. 安裝 ultrasphinx

 Ruby script/plugin install svn://Rubyforge.org/var/svn/fauna/ultrasphinx/trunk

LibMMSeg 就是一個中文分詞程序，當前最新版本是 0.7.3，采用 C++ 開發，分詞算法采用的是“復雜最大匹配 (Complex maximum matching)”，同時支持 Linux 平臺和 Windows 平臺，切分速度大約在 300K/s（PM-1.2G），LibMMSeg 從 0.7.2 版本開始，作者提供了 Ruby 調用的接口，所以我們可以直接在 Ruby 中用 LibMMSeg 進行分詞，相當方便。LibMMSeg 可以通過 http://www.coreseek.cn/opensource/mmseg/ 來下載安裝。

用戶可以通過修改詞典文件增加自己的自定義詞，以提高分詞法在某一具體領域的切分精度，系統默認的詞典文件在 data/unigram.txt中。 然后通過 mmseg -u unigram.txt這個命令來產生一個名為 unigram.txt.uni的文件，將該文件改名為 uni.lib，完成詞典的構造。需要注意的是，unigram.txt必須為 UTF-8 編碼。

LibMMSeg 的開發者為了更好的讓 Sphinx 使用 LibMMSeg 進行中文分詞，為 Sphinx 開發了相關的補丁，從這里 http://www.coreseek.cn/opensource/Sphinx/ 下載兩個補丁文件：

http://www.coreseek.com/uploads/sources/sphinx-0.98rc2.zhcn-support.patch

http://www.coreseek.com/uploads/sources/fix-crash-in-excerpts.patch

然后打上補丁：
清單 17. 安裝 Sphinx 補丁

 cd sphinx-0.9.8-rc2 
 patch -p1  ../sphinx-0.98rc2.zhcn-support.patch 
 patch -p1  ../fix-crash-in-excerpts.patch

安裝完這幾個插件和補丁之后，我們便可以進行配置來讓 Rails 應用程序來支持全文搜索了，

首先我們將 ultrasphinx 插件目錄下的 vendor/plugins/ultrasphinx/examples/default.base復制到：config/ultrasphinx/default.base，打開這個文件，將其中的：

charset_type = utf-8改為：charset_type = zh_cn.utf-8來支持中文字符的全文檢索， 并且在 charset_type 設置的下面加入一行：

charset_dictpath = /home/test/Search/lib，這個就是上文講到的 uni.lib 字典所在的路徑，然后刪除所有 charset_table 相關的設置。

在 Rails 應用程序中的 Model 代碼，加入全文檢索支持：

如有一個 Model 為 Article，其中有兩個屬性叫做 title,body，我希望對這兩個屬性做全文檢索，便可以在 article.rb 中加入一行：
清單 18. 使用 ultrasphinx

 is_indexed :fields => ['created_at','title', 'body']

進行完這個配置后，我們可以使用 rake ultrasphinx:configure 這個命令來生成Sphinx 的配置文件，這條命令在 config/ultrasphinx 下創建了一個 development.conf，這個文件就是 Sphinx 的配置文件。并用rake ultrasphinx:index 這個命令來創建索引。rake ultrasphinx:daemon:start 和 rake ultrasphinx:daemon:stop 則對應著Sphinx 的searchd服務的啟動和停止。searchd 會在 3313 端口啟動一個 searchd，搜索請求將會全部發送到這個端口來執行。我們在控制臺中進行簡單的測試：
清單 19. 測試全文索引

 search = Ultrasphinx::Search.new(:class_names => 'Article') 
 search.run 
 Search.results 

一切運行正常后，我們便可以在 action 的代碼中進行全文搜索了。

使用 Capistrano 進行快速部署

在進行 Rails 部署的時候你可以直接從 svn 或者 git 下面更新代碼，運行 db:migrate 來進行數據庫的更新，然后進行這樣那樣的操作后，再啟動服務器，便可進行部署，即便你只有一臺機器，你也會覺得太麻煩，如果你需要多臺機器來運行，那你可能就會覺得每次手工部署都是一場惡夢，你可以使用 shell 腳本來簡化部署的程序。在用 Rails 開發應用時，你可以使用 Capistrano 插件來進行更簡單的部署工作。簡單來說，Capistrano 是一個通過 SSH 并行的在多臺機器上執行相同命令的工具，使用用來安裝一整批機器。 它通過一個個已有的和用戶自定制的任務讓部署過程簡單化。
清單 20. 安裝 Capistrano

 gem sources -a http://gems.github.com/ 
 gem install Capistrano

然后在 config/deploy.rb 中配置要部署的服務器的地址，各種服務器的角色以及每個服務器統一的用戶名和密碼，如下面的樣例配置：
清單 21. 配置 Capistrano

 set :application, "test_app" # 應用的名稱
 set :scm_username, "test"  # 資源庫的用戶名
 set :scm_password, 'test'  # 資源庫的密碼
 set :repository, Proc.new {"--username #{scm_username} 
 --password #{scm_password} svn://localhost/test_app/trunk"}  
 # 資源庫
 set :user, "test"  # 服務器 SSH 用戶名
 set :password, 'test' # 服務器 SSH 密碼
 set :deploy_to,    "/var/www/#{application} " 
 # 在服務器上的部署路徑，默認的部署路徑是 /u/apps/#{application} 
 role :Web, 'Web.test_app.com' # 前端 Web 服務器
 role :app, 'app1.test_app.com', 'app2.test_app.com', 'app3.test_app.com' #Rails 應用服務器
 role :db, 'app1.test_app.com', :primary => true 
 # 運行 migrate 腳本的機器，通常為其中一臺應用服務器。

在使用 Capistrano 進行部署的時候，通常是這樣使用 cap sometask來運行任務。你可以先用 cap -h查看所有的選項，并用 cap -T查看現有的所有任務。如 cap migrate則在 role 為 db 的機器上執行 rake db:migrate命令。使用 Capistrano 的更多資料可以參考 http://wiki.capify.org 這個網站。另外，Capistrano 還可以使用在非 Rails 環境下進行自動部署，在配置好 ruby 環境和 Capistrano 插件后，再安裝下面的插件即可：
清單 22. 非 Rails 環境使用 Capistrano

 gem sources -a http://gems.github.com/ 
 gem install leehambley-railsless-deploy

結束語

本文著重使用 Ruby On Rails 來開發和部署 Web 應用時一些有用的具體實踐，沒有具體去介紹一些通常應用程序都需要面對的普遍問題，如數據庫的優化和分布式部署，這是一個大并發的 Web 應用都需要面對和解決的問題，比如可以采用 master-slave 的方式去部署分布式的數據庫，或者采用分庫或者分表的方式對數據庫進行拆分。另外，在運行 Rails 服務器或者其它后臺應用程序時，通過還需要另外的進程去進行監控，如用 God 去監控 Rails 進程也是一個 Rails 應用通常都會采用的策略。另外，很多時候，可以采用更敏捷更輕量級的 Rack 去代替 Rails 來進行更高效的開發的提供服務。并且，Engineyard ，Joyent 以及 Heroku 等這類 Rails 網絡提供商的涌現也在相當程度上堅定了用 Rails 開發和部署大規模大并發 Web 應用的信心。雖然 Ruby On Rails 自身的缺陷不可避免， 但是開發可伸縮的高性能的應用程序并不是不可能的。本文希望能夠幫助 Rails 開發人員快速掌握一些具體實踐，能夠編寫出并部署性能高伸縮性強的 Web 應用程序。