2009年8月28日
1.使用DNS輪詢.
2.使用Apache R-proxy方式。
3.使用Apache mod_jk方式.
DNS輪詢的缺點是，當集群中某臺服務器停止之后，用戶由于dns緩存的緣故，便無法訪問服務，
必須等到dns解析更新，或者這臺服務器重新啟動。
還有就是必須把集群中的所有服務端口暴露給外界，沒有用apache做前置代理的方式安全，
并且占用大量公網IP地址，而且tomcat還要負責處理靜態網頁資源，影響效率。
優點是集群配置最簡單，dns設置也非常簡單。
R-proxy的缺點是，當其中一臺tomcat停止運行的時候，apache仍然會轉發請求過去，導致502網關錯誤。
但是只要服務器再啟動就不存在這個問題。
mod_jk方式的優點是，Apache 會自動檢測到停止掉的tomcat，然后不再發請求過去。
缺點就是，當停止掉的tomcat服務器再次啟動的時候，Apache檢測不到，仍然不會轉發請求過去。
R-proxy和mod_jk的共同優點是.可以只將Apache置于公網，節省公網IP地址資源。
可以通過設置來實現Apache專門負責處理靜態網頁，讓Tomcat專門負責處理jsp和servlet等動態請求。
共同缺點是：如果前置Apache代理服務器停止運行，所有集群服務將無法對外提供。
R-proxy和mod_jk對靜態頁面請求的處理，都可以通設置來選取一個盡可能優化的效果。
這三種方式對實現最佳負載均衡都有一定不足，mod_jk相對好些，可以通過設置lbfactor參數來分配請求任務，但又因為mod_jk2方式不被推薦，mod_jk2已經不再被更新了。郁悶中……
哈哈，發現apache2.2以后與tomcat做負載均衡不需要用mod_jk2,在配置文件中稍做修改就OK
posted @
2009-08-28 15:08 kit_lo 閱讀(2729) |
評論 (5) |
編輯 收藏
Java EE應用的性能問題對嚴肅的項目和產品來說是一個非常重要的問題。特別是企業級的應用，并發用戶多，數據傳輸量大，業務邏輯復雜，占用系統資源多，因此性能問題在企業級應用變得至關重要，它和系統的穩定性有著直接的聯系。更加重要的是，性能好的應用在完成相同任務的條件下，能夠占用更少的資源，獲得更好的用戶體驗，換句話說，就是能夠節省費用和消耗，獲得更高的利潤。
要獲得更好的性能，就需要對原來的系統進行性能調優。對運行在Glassfish上的JavaEE應用，調優是一件相對復雜的事情。在調優以前必須要認識到：對JavaEE的系統，調優是多層次的。一個JavaEE的應用其實是整個系統中很少的一部分。開發人員所開發的JavaEE程序，無論是JSP還是 EJB，都是運行在JavaEE應用服務器（Glassfish）之上。而應用服務器本身也是Java語言編寫的，需要運行在Java虛擬機之上。 Java虛擬機也只不過是操作系統的一個應用而已，和其他的應用（如Apache）對于操作系統來說沒有本質的區別。而操作系統卻運行在一定的硬件環境中，包括CPU，內存，網卡和硬盤等等。在這么多的層次中，每一個層次的因素都會影響整個系統的性能。因此，對一個系統的調優，事實上需要同時對每個層次都要調優。JavaEE應用性能調優不僅僅和Glassfish有關，Java語言有關，還要和操作系統以及硬件都有關系，需要調優者有綜合的知識和技能。這些不同層面的方法需要綜合縱效，結合在一起靈活使用，才能快速有效的定位性能瓶頸。下面是一些具體的案例分析:
內存泄漏問題
某個JavaEE應用運行在8顆CPU的服務器上。上線運行發現性能不穩定。性能隨著時間的增加而越來越慢。通過操作系統的工具（mpstat），發現在系統很慢的時候，只有一顆CPU很忙，其他的CPU都很空閑。因此懷疑是Java虛擬機經常進行內存回收，因為虛擬機在內存回收的時候，有的回收算法通常只能運行在一個CPU上。通過Java虛擬機的工具“jstat”可以清楚的看到，Java虛擬機進行內存回收的頻率非常高，幾乎每5秒中就有一次，每次回收的時間為2秒鐘。另外，通過“jstat”的輸出還發現每次回收釋放的內存非常有限，大多數對象都無法回收。這種現象很大程度上暗示著內存泄漏。使用 Java虛擬機的工具“jmap”來獲得當前的一個內存映象。發現有很多（超過10000）個的session對象。這是不正常的一個現象。一般來說， session對應于一個用戶的多次訪問，當用戶退出的時候，session就應該失效，對象應該被回收。當我們和這個系統的開發工程師了解有關 session的設置，發現當他們部署應用的時候，竟然將session的timeout時間設置為50分鐘，并且沒有提供logout的接口。這樣的設置下，每個session的數據都會保存50分鐘才會被回收。根據我們的建議，系統提供了logout的鏈接，并且告訴用戶如果退出應用，應該點擊這個 logout的鏈接；并且將session的timeout時間修改為5分鐘。通過幾天的測試，證明泄漏的問題得到解決。
數據庫連接池問題
某財務應用運行在JavaEE服務器上，后臺連接Oracle數據庫。并發用戶數量超過100人左右的時候系統停止響應。通過操作系統層面的進程監控工具發現進程并沒有被殺死或掛起，而CPU使用率幾乎為零。那么是什么原因導致系統停止響應用戶請求呢？我們利用Java虛擬機的工具（kill -3 pid）將當前的所有線程狀態DUMP出來，發現JavaEE服務器的大部分處理線程都在等待數據庫連接池的連接，而那些已經獲得數據庫連接的線程卻處于阻塞狀態。數據庫管理員應要求檢查了數據庫的狀態，發現所有的連接的session都處于死鎖狀態。顯然，這是因為數據庫端出現了死鎖的操作，阻塞了那些有數據庫操作的請求，占用了所有數據庫連接池中的連接。后續的請求如果還要從連接池中獲取連接，就會阻塞在連接池上。當解決數據庫死鎖的問題之后，性能問題迎刃而解。
大對象緩存問題
電信應用運行在64位Java虛擬機上，系統運行得很不穩定，系統經常停止響應。使用進程工具查看，發現進程并沒有被殺死或掛起。利用Java虛擬機的工具發現系統在長時間的進行內存回收，內存回收的時間長達15分鐘，整個系統在內存回收的時候就像掛起一樣。另外還觀察到系統使用了12G的內存（因為是 64位虛擬機所以突破了4G內存的限制）。從開發人員那里了解到，這個應用為了提高性能，大量使用了對象緩存，但是事與愿違，在Java中使用過多的內存，雖然在正常運行的時候能夠獲得很好的性能，但是會大大增加內存回收的時間。特別是對象緩存，本系統使用了8G的緩存空間，共緩存了6000多萬個對象，對這些對象的遍歷導致了長時間的內存回收。根據我們的建議，將緩存空間減少到1G，并調整回收算法（使用增量回收的算法），使得系統由于內存回收而造成的最大停頓時間減少到4秒，基本滿足用戶的需求。
外部命令問題
數字校園應用運行在4CPU的Solaris10服務器上，中間件為JavaEE服務器。系統在做大并發壓力測試的時候，請求響應時間比較慢，通過操作系統的工具（mpstat）發現CPU使用率比較高。并且系統占用絕大多數的CPU資源而不是應用本身。這是個不正常的現象，通常情況下用戶應用的CPU占用率應該占主要地位，才能說明系統是正常工作。通過Solaris 10的Dtrace腳本，我們查看當前情況下哪些系統調用花費了最多的CPU資源，竟然發現最花費CPU的系統調用是“fork”。眾所周知， “fork”系統調用是用來產生新的進程，在Java虛擬機中只有線程的概念，絕不會有進程的產生。這是個非常異常的現象。通過本系統的開發人員，我們找到了答案：每個用戶請求的處理都包含執行一個外部shell腳本，來獲得系統的一些信息。這是通過Java的“Runtime.getRuntime ().exec”來完成的，但是這種方法在Java中非常消耗資源。Java虛擬機執行這個命令的方式是：首先克隆一個和當前虛擬機一樣的進程，再用這個新的進程去執行外部命令，最后再退出這個進程。如果頻繁執行這個操作，系統的消耗會很大，不僅在CPU，內存操作也很重。用戶根據建議去掉這個shell 腳本執行的語句，系統立刻回復了正常。
文件操作問題
內容管理（CMS）系統運行在JavaEE服務器上，當系統長時間運行以后，性能非常差，用戶請求的延時比系統剛上線的時候要大很多，并且用戶的并發量很小，甚至是單個用戶也很慢。通過操作系統的工具觀察，一切都很正常，CPU利用率不高，IO也不是很大，內存很富余，網絡幾乎沒有壓力（因為并發用戶少）。先不考慮線程互鎖的問題，因為單個用戶性能也不好。通過Java虛擬機觀察也沒有發現什么問題（內存回收很少發生）。這使得我們不得不使用代碼跟蹤器來全程跟蹤代碼。我們采用了Netbeans的Profiler，跟蹤的結果非常意外，用戶請求的90％的時間在創建新文件。從系統設計人員了解到，此系統使用了一個目錄用于保存所有上傳和共享的文件，文件用其命名方式來唯一區別于其他文件。我們查看了那個文件目錄，發現該目錄下已經擁有80萬個文件了。這時候我們才定位到問題了：在同個目錄下放置太多的文件，在創建新文件的時候，系統的開銷是比較大的，例如為了防止重名，文件系統會遍歷當前目錄下所有的文件名等等。根據我們的建議，將文件分類保存在不同的目錄下，性能有了大幅度的提高。
高速緩存命中率問題
運行在JavaEE服務器上的ERP系統，在CPU充分利用的情況下性能仍然不太好。從操作系統層面上觀察不到什么大問題，而且ERP系統過于復雜，代碼跟蹤比較困難。于是進行了CPU狀態的進一步檢查，發現CPU的TLB命中率不是很高，于是對Java虛擬機的啟動參數進行了修改，強迫虛擬機使用大尺寸的內存頁面，提高TLB的命中率。下面的參數是在Sun的HOTSPOT中調整大尺寸（4M）頁面的設置：
-XX:+AggressiveHeap
-XX:LargePageSizeInBytes=256m
通過調整，TLB命中明顯提高，性能也得到近40％的提升。
轉載之：http://developers.sun.com.cn/blog/yutoujava/entry/8
posted @
2009-08-28 15:07 kit_lo 閱讀(1972) |
評論 (1) |
編輯 收藏
負載均衡器通常稱為四層交換機或七層交換機。四層交換機主要分析IP層及TCP/UDP層，實現四層流量負載均衡。七層交換機除了支持四層負載均衡以外，還有分析應用層的信息，如HTTP協議URI或Cookie信息。
一、F5配置步驟：
1、F5組網規劃
(1)組網拓樸圖（具體到網絡設備物理端口的分配和連接，服務器網卡的分配與連接）
(2)IP地址的分配（具體到網絡設備和服務器網卡的IP地址的分配）
(3)F5上業務的VIP、成員池、節點、負載均衡算法、策略保持方法的確定
2、F5配置前的準備工作
(1)版本檢查
f5-portal-1:~# b version
Kernel:
BIG-IP Kernel 4.5PTF-07 Build18
(2)時間檢查－－如不正確，請到單用戶模式下進行修改
f5-portal-1:~# date
Thu May 20 15:05:10 CST 2004
(3)申請license－－現場用的F5都需要自己到F5網站上申請license
3、F5 的通用配置
(1)在安全要求允許的情況下，在setup菜單中可以打開telnet及ftp功能，便于以后方便維護
(2)配置vlan unique_mac選項，此選項是保證F5上不同的vlan 的MAC地址不一樣。在缺省情況下，F5的各個vlan的MAC地址是一樣的，建議在配置時，把此項統一選擇上。可用命令ifconfig –a來較驗
具體是system/Advanced Properties/vlan unique_mac
(3)配置snat any_ip選項選項，此選項為了保證內網的機器做了snat后，可以對ping的數據流作轉換。Ping是第三層的數據包，缺省情況下F5是不對ping的數據包作轉換，也就是internal vlan的主機無法ping external vlan的機器。（注意：還可以采用telnet來驗證。）
具體是system/Advanced Properties/snat any_ip
4、F5 的初始化配置
建議在對F5進行初始時都用命令行方式來進行初始化（用Web頁面初始化的方式有時會有問題）。登錄到命令行上，運行config或setup命令可以進行初始化配置。初次運行時會提示一些license的信息。
default:~# config
5、F5雙機切換監控配置（有F5雙機時需要）
(1)在web頁面中選擇相應的vlan，在arm failsafe選擇則可。Timeout為從F5收不到包的時間起，經過多長時間就發生切換。此配置不能同步，需要在F5的主備機上同時配置。每個vlan都可以配置vlan arm failsafe。
具體在Network下
(2)在web頁面中選擇system，在redundant properties中把gateway failsafe選擇則可。Router是需要監控的地址。此配置不能同步，需要在F5的主備機上同時配置。一套F5上只能配置一個gateway failsafe
具體在system/redundant properties/gateway failsafe
6、F5 MAC masquerade配置
Mac Masquerading是F5的Shared IP Address (Floating)的MAC地址，F5如果不配置此項，則shared IP Address的MAC地址與每臺F5的vlan self IP Address的MAC地址是一樣的。
一般服務器是以shared IP Address為網關，在兩臺F5上都配置了Mac Masquerade（相同的MAC地址），這樣當F5發生切換后，服務器上shared IP address的MAC不變，保證了業務的不中斷
具體在Network下
7、F5的pool配置
(1)在配置工具Web頁面的導航面板中選擇“Pools”中的“Pools”標簽，點擊“ADD”按鈕添加服務器池(Pool)。
(2)在池屬性（Pool Properties）中的“Load Balancing Method”表格中選擇負載均衡策略，通常采用默認策略：“Round Robin”
(3)在“Resouces”表格中的“Member Address”文本框輸入成員IP地址，在“Service”文本框中輸入服務端口，點擊“>>”添加到“Current Members”當前成員列表中。
(4)添加所有組成員，點擊“Done”完成配置。
(5)在“Pools”中的“Pool Name”列選中特定池，然后池屬性頁面中選擇“Persistence”標簽。
(6)在“Persistence Type”表格中選定會話保持類型。點擊“Apply”應用配置。
8、F5的virtual server配置
(1)在配置工具Web頁面的導航面板中選擇“Virtual Servers”中的“Virtual Servers”標簽，點擊“ADD”按鈕添加虛擬服務器。
(2)在“Add Virtual Server”窗口的“Address”文本框中輸入虛擬服務器IP地址，并在“Service”文本框中輸入服務端口號或在下拉框中選擇現有的服務名稱，點擊“Next”執行下一步。
(3)在“Add Virtual Server”窗口的“Configure Basic Properties”頁面中點擊“Next”執行下一步。 在“Add Virtual Server”窗口的“Select Physical Resources”頁面中點擊單選按鈕“Pool”，并在下拉框中選擇虛擬服務器對應的負載均衡池。
(4)按“Done”完成創建虛擬服務器。
9、F5的monitor的配置
(1)在配置工具Web頁面的導航面板中選擇“Monitor”中的“Monitors”標簽，點擊“ADD”按鈕添加監控
(2)根據需要選擇相關關聯類型：“Node Associations”標簽、Node Address Associations”標簽、Service Associations”標簽。
(3)被選關聯標簽中，在“Choose Monitor”表格中選擇監控名稱，點擊“>>”按鈕添加到“Monitor Rule”監控規格文本框中。監控規則可以為一條或多條。
(4)選擇監控規則后，在對應節點的“Associate Current Monitor Rule”復選框中選中。如果欲刪除監控關聯，則選中對應節點的“Delete Existing Assocation”復選框。
(5)點擊“Apply”關聯監控
10、F5的SNAT配置
(1)在配置工具Web頁面的導航面板中選擇“NATs”中的“SNATs”標簽，點擊“ADD”按鈕添加SNAT地址。
(2)在“Add SNAT”窗口中“Translation Address”的“IP”文本框中輸入SNAT IP地址，并在“Origin List”的“Origin Address”文本框中輸入節點IP地址或在“Origin VLAN”下拉框中選擇VLAN名稱，點擊“>>”加入“Current List”列表。
(3)按“Done”完成添加SNAT IP地址。
11、F5主備機同步及切換校驗
具體在system/Redundant Properties/synchonize Config...
12、業務的校驗
F5主備機切換的校驗
F5主備機業務運行的校驗
其中1~6是基本配置，7~10業務配置，11~12校驗
二、F5負載均衡器的維護
1、F5節點及應用的檢查
通過“System -> Network Map”頁面查看節點及應用狀態
綠色:節點或虛擬服務器為“UP”
紅色:節點或虛擬服務器狀態為“Down”
灰色:節點或虛擬服務器被禁用
2、日志的檢查
(1)當天日志：從web上查看logs中的system log、bigip log、monitor log，看日志中是否有異常。
(2)7天內的日志
系統日志文件 - /var/log/messages消息, 系統消息
BIG-IP 日志文件 - /var/log/bigip
“External” BIG-IP events
Monitor 日志文件 - /var/log/bigd
“Internal” BIG-IP Events
3DNS 日志文件 - /var/log/3dns
3DNS Information
用gzcat、more、vi命令打開
3、F5流量的檢查
(1)業務上的基本維護主要是在F5上查看F5分發到各節點的connect是否負載均衡，一般不應有數量級的差別
(2)通過WEB->pool-> pool statistics中查看connection項中的total和current項，不應有明顯的數量級的差別
(3)F5 qkview命令
執行qkview，執行完成后將輸出信息保存在文件“/var/tmp/-tech.out”中，供高級技術支持用
(4)F5 tcpdump命令
TCPDUMP是Unix系統常用的報文分析工具，TCPDUMP經常用于故障定位，如會話保持失效、SNAT通信問題等
tcpdump [ -adeflnNOpqRStvxX ] [ -c count ] [ -F file ]
[ -i interface ] [ -m module ] [ -r file ]
[ -s snaplen ] [ -T type ] [ -w file ]
[ -E algo:secret ] [ expression ]
posted @
2009-08-28 15:06 kit_lo 閱讀(3620) |
評論 (0) |
編輯 收藏
1. Tomcat是Apache鼎力支持的Java Web應用服務器，由于它優秀的穩定性以及豐富的文檔資料，廣泛的使用人群，從而在開源領域受到最廣泛的青睞。
2. Jboss作為Java EE應用服務器，它不但是Servlet容器，而且是EJB容器，從而受到企業級開發人員的歡迎，從而彌補了Tomcat只是一個Servlet容器的缺憾。
3. Resin也僅僅是一個Servlet容器，然而由于它優秀的運行速度，使得它在輕量級Java Web領域備受喜愛，特別是在互聯網Web服務領域，眾多知名公司都采用其作為他們的Java Web應用服務器，譬如163、ku6等。
在商用應用服務器里主要有：Weblogic、Websphere，其中Weblogic我也使用過很長一段時間，當時也只用其當Servlet容器，然而就在同等條件下，在性能及易用性等方面，要比Tomcat優秀很多。
4.glassfish是Sun公司推出的Java EE服務器，一個比較活躍的開源社區,不斷的通過社區的反饋來提高其的可用性,經過glassfish v1 glassfish v2 到今天的glassfish v3 ,它已經走向成熟.Glassfish是一個免費、開放源代碼的應用服務，它實現了Java EE 5，Java EE 5 平臺包括了以下最新技術：EJB 3.0、JSF 1.2、Servlet 2.5、JSP 2.1、JAX-WS 2.0、JAXB 2.0、 Java Persistence 1.0、Common Annonations 1.0、StAX 1.0等.
支持集群,通過內存中會話狀態復制,增強了部署體系結構的可用性與可伸縮性,它對集群有著很好的支持,可以簡單到通過添加機器,就可輕松的提高網站的帶負載能力,在解析能力方面,它對html的吞吐能力與apache服務器不分上下,就是tomcat所不能比的,支持目錄部署,熱部署,解決了tomcat對熱部署能力的缺陷.在版本方面做的更加人性化,有開發時用的簡化版,專門用于部署web項目的版本,還要完全符合j2ee標準的版本.
posted @
2009-08-28 15:05 kit_lo 閱讀(5556) |
評論 (0) |
編輯 收藏為應用程序添加搜索能力經常是一個常見的需求。本文介紹了一個框架，開發者可以使用它以最小的付出實現搜索引擎功能，理想情況下只需要一個配置文件。該框架基于若干開源的庫和工具，如 Apache Lucene，Spring 框架，cpdetector 等。它支持多種資源。其中兩個典型的例子是數據庫資源和文件系統資源。Indexer 對配置的資源進行索引并傳輸到中央服務器，之后這些索引可以通過 API 進行搜索。Spring 風格的配置文件允許清晰靈活的自定義和調整。核心 API 也提供了可擴展的接口。
引言
為應用程序添加搜索能力經常是一個常見的需求。盡管已經有若干程序庫提供了對搜索基礎設施的支持，然而對于很多人而言，使用它們從頭開始建立一個搜索引擎將是一個付出不小而且可能乏味的過程。另一方面，很多的小型應用對于搜索功能的需求和應用場景具有很大的相似性。本文試圖以對多數小型應用的適用性為出發點，用 Java 語言構建一個靈活的搜索引擎框架。使用這個框架，多數情形下可以以最小的付出建立起一個搜索引擎。最理想的情況下，甚至只需要一個配置文件。特殊的情形下，可以通過靈活地對框架進行擴展滿足需求。當然，如題所述，這都是借助開源工具的力量。
基礎知識
Apache Lucene 是開發搜索類應用程序時最常用的 Java 類庫，我們的框架也將基于它。為了下文更好的描述，我們需要先了解一些有關 Lucene 和搜索的基礎知識。注意，本文不關注索引的文件格式、分詞技術等話題。
什么是搜索和索引
從用戶的角度來看，搜索的過程是通過關鍵字在某種資源中尋找特定的內容的過程。而從計算機的角度來看，實現這個過程可以有兩種辦法。一是對所有資源逐個與關鍵字匹配，返回所有滿足匹配的內容；二是如同字典一樣事先建立一個對應表，把關鍵字與資源的內容對應起來，搜索時直接查找這個表即可。顯而易見，第二個辦法效率要高得多。建立這個對應表事實上就是建立逆向索引（inverted index）的過程。
Lucene 基本概念
Lucene 是 Doug Cutting 用 Java 開發的用于全文搜索的工具庫。在這里，我假設讀者對其已有基本的了解，我們只對一些重要的概念簡要介紹。要深入了解可以參考 參考資源 中列出的相關文章和圖書。下面這些是 Lucene 里比較重要的類。
Document：索引包含多個 Document。而每個 Document 則包含多個 Field 對象。Document 可以是從數據庫表里取出的一堆數據，可以是一個文件，也可以是一個網頁等。注意，它不等同于文件系統中的文件。
Field：一個 Field 有一個名稱，它對應 Document的一部分數據，表示文檔的內容或者文檔的元數據（與下文中提到的資源元數據不是一個概念）。一個 Field 對象有兩個重要屬性：Store ( 可以有 YES, NO, COMPACT 三種取值 ) 和 Index ( 可以有 TOKENIZED, UN_TOKENIZED, NO, NO_NORMS 四種取值 )
Query：抽象了搜索時使用的語句。
IndexSearcher：提供Query對象給它，它利用已有的索引進行搜索并返回搜索結果。
Hits：一個容器，包含了指向一部分搜索結果的指針。
使用 Lucene 來進行編制索引的過程大致為：將輸入的數據源統一為字符串或者文本流的形式，然后從數據源提取數據，創建合適的 Field 添加到對應該數據源的 Document 對象之中。
系統概覽
要建立一個通用的框架，必須對不同情況的共性進行抽象。反映到設計需要注意兩點。一是要提供擴展接口；二是要盡量降低模塊之間的耦合程度。我們的框架很簡單地分為兩個模塊：索引模塊和搜索模塊。索引模塊在不同的機器上各自進行對資源的索引，并把索引文件（事實上，下面我們會說到，還有元數據）統一傳輸到同一個地方（可以是在遠程服務器上，也可以是在本地）。搜索模塊則利用這些從多個索引模塊收集到的數據完成用戶的搜索請求。
圖 1 展現了整體的框架。可以看到，兩個模塊之間相對是獨立的，它們之間的關聯不是通過代碼，而是通過索引和元數據。在下文中，我們將會詳細介紹如何基于開源工具設計和實現這兩個模塊。
圖 1. 系統架構圖
建立索引
可以進行索引的對象有很多，如文件、網頁、RSS Feed 等。在我們的框架中，我們定義可以進行索引的一類對象為資源。從實現細節上來說，從一個資源中可以提取出多個 Document 對象。文件系統資源和數據庫結果集資源都是資源的代表性例子。
前面提到，從資源中收集到的索引被統一傳送到同一個地方，以被搜索模塊所用。顯然除了索引之外，搜索模塊需要有對資源更多的了解，如資源的名稱、搜索該資源后搜索結果的呈現格式等。這些額外的附加信息稱為資源的元數據。元數據和索引數據一同被收集起來，放置到某個特定的位置。
簡要地介紹過資源的概念之后，我們首先為其定義一個 Resource 接口。這個接口的聲明如下。
清單 1. Resource 接口
public interface Resource {
// RequestProcessor 對象被動地從資源中提取 Document，并返回提取的數量
public int extractDocuments(ResourceProcessor processor);
// 添加的 DocumentListener 將在每一個 Document 對象被提取出時被調用
public void addDocumentListener(DocumentListener l);
// 返回資源的元數據
public ResourceMetaData getMetaData();
}
其中元數據包含的字段見下表。在下文中，我們還會對元數據的用途做更多的介紹。
表 1. 資源元數據包含的字段
屬性 類型 含義
resourceName String 資源的唯一名稱
resourceDescription String 資源的介紹性文字
hitTextPattern String 當文檔被搜索到時，這個 pattern 規定了結果顯示的格式
searchableFields String[] 可以被搜索的字段名稱
而 DocumentListener 的代碼如下。
清單 2. DocumentListener 接口
public interface DocumentListener extends EventListener {
public void documentExtracted(Document doc);
}
為了讓索引模塊能夠知道所有需要被索引的資源，我們在這里使用 Spring 風格的 XML 文件配置索引模塊中的所有組件，尤其是所有資源。您可以在 下載部分 查看一個示例配置文件。
為什么選擇使用 Spring 風格的配置文件？
這主要有兩個好處：
僅依賴于 Spring Core 和 Spring Beans 便免去了定義配置機制和解析配置文件的負擔；
Spring 的 IoC 機制降低了框架的耦合性，并使擴展框架變得簡單；
基于以上內容，我們可以大致描述出索引模塊工作的過程：
首先在 XML 配置的 bean 中找出所有 Resource 對象；
對每一個調用其 extractDocuments() 方法，這一步除了完成對資源的索引外，還會在每次提取出一個 Document 對象之后，通知注冊在該資源上的所有 DocumentListener；
接著處理資源的元數據（getMetaData() 的返回值）；
將緩存里的數據寫入到本地磁盤或者傳送給遠程服務器；
在這個過程中，有兩個地方值得注意。
第一，對資源可以注冊 DocumentListener 使得我們可以在運行時刻對索引過程有更為動態的控制。舉一個簡單例子，對某個文章發布站點的文章進行索引時，一個很正常的要求便是發布時間更靠近當前時間的文章需要在搜索結果中排在靠前的位置。每篇文章顯然對應一個 Document 對象，在 Lucene 中我們可以通過設置 Document 的 boost 值來對其進行加權。假設其中文章發布時間的 Field 的名稱為 PUB_TIME，那么我們可以為資源注冊一個 DocumentListener，當它被通知時，則檢測 PUB_TIME 的值，根據距離當前時間的遠近進行加權。
第二點很顯然，在這個過程中，extractDocuments() 方法的實現依不同類型的資源而各異。下面我們主要討論兩種類型的資源：文件系統資源和數據庫結果集資源。這兩個類都實現了上面的 接口。
文件系統資源
對文件系統資源的索引通常從一個基目錄開始，遞歸處理每個需要進行索引的文件。該資源有一個字符串數組類型的 excludedFiles 屬性，表示在處理文件時需要排除的文件絕對路徑的正則表達式。在遞歸遍歷文件系統樹的同時，絕對路徑匹配 excludedFiles 中任意一項的文件將不會被處理。這主要是考慮到一般我們只需要對一部分文件夾（比如排除可能存在的備份目錄）中的一部分文件（如 doc, ppt 文件等）進行索引。
除了所有文件共有的文件名、文件路徑、文件大小和修改時間等 Field，不同類型的文件需要有不同的處理方法。為了保留靈活性，我們使用 Strategy 模式封裝對不同類型文件的處理方式。為此我們抽象出一個 DocumentBuilder 的接口，該接口僅定義了一個方法如下：
清單 3. DocumentBuilder 接口
public interface DocumentBuilder {
Document buildDocument(InputStream is);
}
什么是 Strategy 模式？
根據 Design patterns: Elements of reusable object orientated software 一書：Strategy 模式“定義一系列的算法，把它們分別封裝起來，并且使它們相互可以替換。這個模式使得算法可以獨立于使用它的客戶而變化。”
不同的 DocumentBuilder（Strategy） 用于從一個輸入流中讀取數據，處理不同類型的文件。對于常見的文件格式來說，都有合適的開源工具幫助進行解析。在下表中我們列舉一些常見文件類型的解析辦法。
文件類型 常用擴展名 可以使用的解析辦法
純文本文檔 txt 無需類庫解析
RTF 文檔 rtf 使用 javax.swing.text.rtf.RTFEditorKit 類
Word 文檔（非 OOXML 格式） doc Apache POI （可配合使用 POI Scratchpad）
PowerPoint 演示文稿（非 OOXML 格式） xls Apache POI （可配合使用 POI Scratchpad）
PDF 文檔 pdf PDFBox（可能中文支持欠佳）
HTML 文檔 htm, html JTidy, Cobra
這里以 Word 文件為例，給出一個簡單的參考實現。
清單 4. 解析純文本內容的實現
// WordDocument 是 Apache POI Scratchpad 中的一個類
Document buildDocument(InputStream is) {
String bodyText = null;
try {
WordDocument wordDoc = new WordDocument(is);
StringWriter sw = new StringWriter();
wordDoc.writeAllText(sw);
sw.close();
bodyText = sw.toString();
} catch (Exception e) {
throw new DocumentHandlerException("Cannot extract text from a Word document", e);
}
if ((bodyText != null) && (bodyText.trim().length() > 0)) {
Document doc = new Document();
doc.add(new Field("body", bodyText, Field.Store.YES, Field.Index.TOKENIZED));
return doc;
}
return null;
}
那么如何選擇合適的 Strategy 來處理文件呢？UNIX 系統下的 file(1) 工具提供了從 magicnumber 獲取文件類型的功能，我們可以使用 Runtime.exec() 方法調用這一命令。但這需要在有 file(1) 命令的情況下，而且并不能識別出所有文件類型。在一般的情況下我們可以簡單地根據擴展名來使用合適的類處理文件。擴展名和類的映射關系寫在 properties 文件中。當需要添加對新的文件類型的支持時，我們只需添加一個新的實現 DocumentBuilder 接口的類，并在映射文件中添加一個映射關系即可。
數據庫結果集資源
大多數應用使用數據庫作為永久存儲，對數據庫查詢結果集索引是一個常見需求。
生成一個數據庫結果集資源的實例需要先提供一個查詢語句，然后執行查詢，得到一個結果集。這個結果集中的內容便是我們需要進行索引的對象。extractDocuments 的實現便是為結果集中的每一行創建一個 Document 對象。和文件系統資源不同的是，數據庫資源需要放入 Document 中的 Field 一般都存在在查詢結果集之中。比如一個簡單的文章發布站點，對其后臺數據庫執行查詢 SELECT ID, TITLE, CONTENT FROM ARTICLE 返回一個有三列的結果集。對結果集的每一行都會被提取出一個 Document 對象，其中包含三個 Field，分別對應這三列。
然而不同 Field 的類型是不同的。比如 ID 字段一般對應 Store.YES 和 Index.NO 的 Field；而 TITLE 字段則一般對應 Store.YES 和 Index.TOKENIZED 的 Field。為了解決這個問題，我們在數據庫結果集資源的實現中提供一個類型為 Properties 的 fieldTypeMappings 屬性，用于設置數據庫字段所對應的 Field 的類型。對于前面的情況來說，這個屬性可能會被配置成類似這樣的形式：
ID = YES, NO
TITLE = YES, TOKENIZED
CONTENT = NO, TOKENIZED
配合這個映射，我們便可以生成合適類型的 Field，完成對結果集索引的工作。
收集索引
完成對資源的索引之后，還需要讓索引為搜索模塊所用。前面我們已經說過這里介紹的框架主要用于小型應用，考慮到復雜性，我們采取簡單地將分布在各個機器上的索引匯總到一個地方的策略。
匯總索引的傳輸方式可以有很多方案，比如使用 FTP、HTTP、rsync 等。甚至索引模塊和搜索模塊可以位于同一臺機器上，這種情況下只需要將索引進行本地拷貝即可。同前面類似，我們定義一個 Transporter 接口。
清單 5. Transporter 接口
public interface Transporter {
public void transport(File file);
}
以 FTP 方式傳輸為例，我們使用 Commons Net 完成傳輸的操作。
public void transport(File file) throws TransportException {
FTPClient client = new FTPClient();
client.connect(host);
client.login(username, password);
client.changeWorkingDirectory(remotePath);
transportRecursive(client, file);
client.disconnect();
}
public void transportRecursive(FTPClient client, File file) {
if (file.isFile() && file.canRead()) {
client.storeFile(file.getName(), new FileInputStream(file));
} else if (file.isDirectory()) {
client.makeDirectory(file.getName());
client.changeWorkingDirectory(file.getName());
File[] fileList = file.listFiles();
for (File f : fileList) {
transportRecursive(client, f);
}
}
}
對其他傳輸方案也有各自的方案進行處理，具體使用哪個 Transporter 的實現被配置在 Spring 風格的索引模塊配置文件中。傳輸的方式是靈活的。比如當需要強調安全性時，我們可以換用基于 SSL 的 FTP 進行傳輸。所需要做的只是開發一個使用 FTP over SSL 的 Transporter 實現，并在配置文件中更改 Transporter 的實現即可。
進行搜索
在做了這么多之后，我們開始接觸和用戶關聯最為緊密的搜索模塊。注意，我們的框架不包括一個基于已經收集好的索引進行搜索是個很簡單的過程。Lucene 已經提供了功能強大的 IndexSearcher 及其子類。在這個部分，我們不會再介紹如何使用這些類，而是關注在前文提到過的資源元數據上。元數據從各個資源所在的文件夾中讀取得到，它在搜索模塊中扮演重要的角色。
構建一個查詢
對不同資源進行搜索的查詢方法并不一樣。例如搜索一個論壇里的所有留言時，我們關注的一般是留言的標題、作者和內容；而當搜索一個 FTP 站點時，我們更多關注的是文件名和文件內容。另一方面，我們有時可能會使用一個查詢去搜索多個資源的結果。這正是之前我們在前面所提到的元數據中 searchableFields 和 resourceName 屬性的作用。前者指出一個資源中哪些字段是參與搜索的；后者則用于在搜索時確定使用哪個或者哪些索引。從技術細節來說，只有有了這些信息，我們才可以構造出可用的 Query 對象。
呈現搜索結果
當從 IndexSearcher 對象得到搜索結果（Hits）之后，當然我們可以直接從中獲取需要的值，再格式化予以輸出。但一來格式化輸出搜索結果（尤其在 Web 應用中）是個很常見的需求，可能會經常變更；二來結果的呈現格式應該是由分散的資源各自定義，而不是交由搜索模塊來定義。基于上面兩個原因，我們的框架將使用在資源收集端配置結果輸出格式的方式。這個格式由資源元數據中的 hitTextPattern 屬性定義。該屬性是一個字符串類型的值，支持兩種語法
形如 ${field_name} 的子字符串都會被動態替換成查詢結果中各個 Document 內 Field 的值。
形如 $function(...) 的被解釋為函數，括號內以逗號隔開的符號都被解釋成參數，函數可以嵌套。
例如搜索“具體”返回的搜索結果中包含一個 Document 對象，其 Field 如下表：
Field 名稱 Field 內容
url http://example.org/article/1.html
title 示例標題
content 這里是具體的內容。
那么如果 hitTextPatten 被設置為“${title}
$highlight(${content}, 5, "", "")”，返回的結果經瀏覽器解釋后可能的顯示結果如下（這只是個演示鏈接，請不要點擊）：
示例標題
這里是具體...
上面提到的 $highlight() 函數用于在搜索結果中取得最匹配的一段文本，并高亮顯示搜索時使用的短語，其第一個參數是高亮顯示的文本，第二個參數是顯示的文本長度，第三和第四個參數是高亮文本時使用的前綴和后綴。
可以使用正則表達式和文本解析來實現前面所提到的語法。我們也可以使用 JavaCC 定義 hitTextPattern 的文法，進而生成詞法分析器和語法解析器。這是更為系統并且相對而言不易出錯的方法。對 JavaCC 的介紹不是本文的重點，您可以在下面的 閱讀資源 中找到學習資料。
下面列出的是一些與我們所提出的框架所相關或者類似的產品，您可以在 學習資料 中更多地了解他們。
IBM?OmniFind?Family
OmniFind 是 IBM 公司推出的企業級搜索解決方案。基于 UIMA (Unstructured Information Management Architecture) 技術，它提供了強大的索引和獲取信息功能，支持巨大數量、多種類型的文檔資源（無論是結構化還是非結構化），并為 Lotus?Domino?和 WebSphere?Portal 專門進行了優化。
Apache Solr
Solr 是 Apache 的一個企業級的全文檢索項目，實現了一個基于 HTTP 的搜索服務器，支持多種資源和 Web 界面管理，它同樣建立在 Lucene 之上，并對 Lucene 做了很多擴展，例如支持動態字段及唯一鍵，對查詢結果進行動態分組和過濾等。
Google SiteSearch
使用 Google 的站點搜索功能可以方便而快捷地建立一個站內搜索引擎。但是 Google 的站點搜索基于 Google 的網絡爬蟲，所以無法訪問受保護的站點內容或者 Intranet 上的資源。另外，Google 所支持的資源類型也是有限的，我們無法對其進行擴展。
SearchBlox?
SearchBlox 是一個商業的搜索引擎構建框架。它本身是一個 J2EE 組件，和我們的框架類似，也支持對網頁和文件系統等資源進行索引，進而進行搜索。
還需考慮的問題
本文介紹的思想試圖利用開源的工具解決中小型應用中的常見問題。當然，作為一個框架，它還有很多不足，下面列舉出一些可以進行改進的地方。
性能考慮
當需要進行索引的資源數目不多時，隔一定的時間進行一次完全索引不會占用很長時間。使用一臺 2G 內存，Xeon 2.66G 處理器的服務器進行實際測試，發現對數據庫資源的索引占用的時間很少，一千多條記錄花費的時間在 1 秒到 2 秒之內。而對 1400 多個文件進行索引耗時大約十幾秒。但在大型應用中，資源的容量是巨大的，如果每次都進行完整的索引，耗費的時間會很驚人。我們可以通過跳過已經索引的資源內容，刪除已不存在的資源內容的索引，并進行增量索引來解決這個問題。這可能會涉及文件校驗和索引刪除等。
另一方面，框架可以提供查詢緩存來提高查詢效率。框架可以在內存中建立一級緩存，并使用如 OSCache 或 EHCache 實現磁盤上的二級緩存。當索引的內容變化不頻繁時，使用查詢緩存更會明顯地提高查詢速度、降低資源消耗。
分布式索引
我們的框架可以將索引分布在多臺機器上。搜索資源時，查詢被 flood 到各個機器上從而獲得搜索結果。這樣可以免去傳輸索引到某一臺中央服務器的過程。當然也可以在非結構化的 P2P 網絡上實現分布式哈希表 (DHT)，配合索引復制 (Replication)，使得應用程序更為安全，可靠，有伸縮性。在閱讀資料中給出了 一篇關于構建分布式環境下全文搜索的可行性的論文。
安全性
目前我們的框架并沒有涉及到安全性。除了依賴資源本身的訪問控制（如受保護的網頁和文件系統等）之外，我們還可以從兩方面增強框架本身的安全性：
考慮到一個組織的搜索功能對不同用戶的權限設置不一定一樣，可以支持對用戶角色的定義，實行對搜索模塊的訪問控制。
在資源索引模塊中實現一種機制，讓資源可以限制自己暴露的內容，從而縮小索引模塊的索引范圍。這可以類比 robots 文件可以規定搜索引擎爬蟲的行為。
通過上文的介紹，我們認識了一個可擴展的框架，由索引模塊和搜索模塊兩部分組成。它可以靈活地適應不同的應用場景。如果需要更獨特的需求，框架本身預留了可以擴展的接口，我們可以通過實現這些接口完成功能的定制。更重要的是這一切都是建立在開源軟件的基礎之上。希望本文能為您揭示開源的力量，體驗用開源工具組裝您自己的解決方案所帶來的莫大快樂。
posted @
2009-08-28 15:03 kit_lo 閱讀(1558) |
評論 (0) |
編輯 收藏第一步：加入log4j-1.2.8.jar到lib下。
第二步：在CLASSPATH下建立log4j.properties。內容如下：
1 log4j.rootCategory=INFO, stdout , R
2
3 log4j.appender.stdout=org.apache.log4j.ConsoleAppender
4 log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
5 log4j.appender.stdout.layout.ConversionPattern=[QC] %p [%t] %C.%M(%L) | %m%n
6
7 log4j.appender.R=org.apache.log4j.DailyRollingFileAppender
8 log4j.appender.R.File=D:\Tomcat 5.5\logs\qc.log
9 log4j.appender.R.layout=org.apache.log4j.PatternLayout
10 log4j.appender.R.layout.ConversionPattern=%d-[TS] %p %t %c - %m%n
11
12 log4j.logger.com.neusoft=DEBUG
13 log4j.logger.com.opensymphony.oscache=ERROR
14 log4j.logger.net.sf.navigator=ERROR
15 log4j.logger.org.apache.commons=ERROR
16 log4j.logger.org.apache.struts=WARN
17 log4j.logger.org.displaytag=ERROR
18 log4j.logger.org.springframework=DEBUG
19 log4j.logger.com.ibatis.db=WARN
20 log4j.logger.org.apache.velocity=FATAL
21
22 log4j.logger.com.canoo.webtest=WARN
23
24 log4j.logger.org.hibernate.ps.PreparedStatementCache=WARN
25 log4j.logger.org.hibernate=DEBUG
26 log4j.logger.org.logicalcobwebs=WARN
第三步：相應的修改其中屬性，修改之前就必須知道這些都是干什么的，在第二部分講解。
第四步：在要輸出日志的類中加入相關語句：
定義屬性：protected final Log log = LogFactory.getLog(getClass());
在相應的方法中：
if (log.isDebugEnabled())
{
log.debug(“System …..”);
}
二、Log4j說明
1 log4j.rootCategory=INFO, stdout , R
此句為將等級為INFO的日志信息輸出到stdout和R這兩個目的地，stdout和R的定義在下面的代碼，可以任意起名。等級可分為OFF、 FATAL、ERROR、WARN、INFO、DEBUG、ALL，如果配置OFF則不打出任何信息，如果配置為INFO這樣只顯示INFO, WARN, ERROR的log信息，而DEBUG信息不會被顯示，具體講解可參照第三部分定義配置文件中的logger。
3 log4j.appender.stdout=org.apache.log4j.ConsoleAppender
此句為定義名為stdout的輸出端是哪種類型，可以是
org.apache.log4j.ConsoleAppender（控制臺），
org.apache.log4j.FileAppender（文件），
org.apache.log4j.DailyRollingFileAppender（每天產生一個日志文件），
org.apache.log4j.RollingFileAppender（文件大小到達指定尺寸的時候產生一個新的文件）
org.apache.log4j.WriterAppender（將日志信息以流格式發送到任意指定的地方）
具體講解可參照第三部分定義配置文件中的Appender。
4 log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
此句為定義名為stdout的輸出端的layout是哪種類型，可以是
org.apache.log4j.HTMLLayout（以HTML表格形式布局），
org.apache.log4j.PatternLayout（可以靈活地指定布局模式），
org.apache.log4j.SimpleLayout（包含日志信息的級別和信息字符串），
org.apache.log4j.TTCCLayout（包含日志產生的時間、線程、類別等等信息）
具體講解可參照第三部分定義配置文件中的Layout。
5 log4j.appender.stdout.layout.ConversionPattern= [QC] %p [%t] %C.%M(%L) | %m%n
如果使用pattern布局就要指定的打印信息的具體格式ConversionPattern，打印參數如下：
%m 輸出代碼中指定的消息
%p 輸出優先級，即DEBUG，INFO，WARN，ERROR，FATAL
%r 輸出自應用啟動到輸出該log信息耗費的毫秒數
%c 輸出所屬的類目，通常就是所在類的全名
%t 輸出產生該日志事件的線程名
%n 輸出一個回車換行符，Windows平臺為“rn”，Unix平臺為“n”
%d 輸出日志時間點的日期或時間，默認格式為ISO8601，也可以在其后指定格式，比如：%d{yyyy MMM dd HH:mm:ss,SSS}，輸出類似：2002年10月18日 22：10：28，921
%l 輸出日志事件的發生位置，包括類目名、發生的線程，以及在代碼中的行數。
[QC]是log信息的開頭，可以為任意字符，一般為項目簡稱。
輸出的信息
[TS] DEBUG [main] AbstractBeanFactory.getBean(189) | Returning cached instance of singleton bean 'MyAutoProxy'
具體講解可參照第三部分定義配置文件中的格式化日志信息。
7 log4j.appender.R=org.apache.log4j.DailyRollingFileAppender
此句與第3行一樣。定義名為R的輸出端的類型為每天產生一個日志文件。
8 log4j.appender.R.File=D:\Tomcat 5.5\logs\qc.log
此句為定義名為R的輸出端的文件名為D:\Tomcat 5.5\logs\qc.log
可以自行修改。
9 log4j.appender.R.layout=org.apache.log4j.PatternLayout
與第4行相同。
10 log4j.appender.R.layout.ConversionPattern=%d-[TS] %p %t %c - %m%n
與第5行相同。
12 log4j.logger.com. neusoft =DEBUG
指定com.neusoft包下的所有類的等級為DEBUG。
可以把com.neusoft改為自己項目所用的包名。
13 log4j.logger.com.opensymphony.oscache=ERROR
14 log4j.logger.net.sf.navigator=ERROR
這兩句是把這兩個包下出現的錯誤的等級設為ERROR，如果項目中沒有配置EHCache，則不需要這兩句。
15 log4j.logger.org.apache.commons=ERROR
16 log4j.logger.org.apache.struts=WARN
這兩句是struts的包。
17 log4j.logger.org.displaytag=ERROR
這句是displaytag的包。（QC問題列表頁面所用）
18 log4j.logger.org.springframework=DEBUG
此句為Spring的包。
24 log4j.logger.org.hibernate.ps.PreparedStatementCache=WARN
25 log4j.logger.org.hibernate=DEBUG
此兩句是hibernate的包。
以上這些包的設置可根據項目的實際情況而自行定制。
三、log4j詳解
1、定義配置文件
Log4j支持兩種配置文件格式，一種是XML格式的文件，一種是Java特性文件log4j.properties（鍵=值）。下面將介紹使用log4j.properties文件作為配置文件的方法:
①、配置根Logger
Logger 負責處理日志記錄的大部分操作。
其語法為：
log4j.rootLogger = [ level ] , appenderName, appenderName, …
其中，level 是日志記錄的優先級，分為OFF、FATAL、ERROR、WARN、INFO、DEBUG、ALL或者自定義的級別。Log4j建議只使用四個級別，優 先級從高到低分別是ERROR、WARN、INFO、DEBUG。通過在這里定義的級別，您可以控制到應用程序中相應級別的日志信息的開關。比如在這里定 義了INFO級別，只有等于及高于這個級別的才進行處理，則應用程序中所有DEBUG級別的日志信息將不被打印出來。ALL:打印所有的日志，OFF：關 閉所有的日志輸出。 appenderName就是指定日志信息輸出到哪個地方。可同時指定多個輸出目的地。
②、配置日志信息輸出目的地 Appender
Appender 負責控制日志記錄操作的輸出。
其語法為：
log4j.appender.appenderName = fully.qualified.name.of.appender.class
log4j.appender.appenderName.option1 = value1
…
log4j.appender.appenderName.optionN = valueN
這里的appenderName為在①里定義的，可任意起名。
其中，Log4j提供的appender有以下幾種：
org.apache.log4j.ConsoleAppender（控制臺），
org.apache.log4j.FileAppender（文件），
org.apache.log4j.DailyRollingFileAppender（每天產生一個日志文件），
org.apache.log4j.RollingFileAppender（文件大小到達指定尺寸的時候產生一個新的文件），可通過 log4j.appender.R.MaxFileSize=100KB設置文件大小，還可通過 log4j.appender.R.MaxBackupIndex=1設置為保存一個備份文件。
org.apache.log4j.WriterAppender（將日志信息以流格式發送到任意指定的地方）
例如：log4j.appender.stdout=org.apache.log4j.ConsoleAppender
定義一個名為stdout的輸出目的地，ConsoleAppender為控制臺。
③、配置日志信息的格式（布局）Layout
Layout 負責格式化Appender的輸出。
其語法為：
log4j.appender.appenderName.layout = fully.qualified.name.of.layout.class
log4j.appender.appenderName.layout.option1 = value1
…
log4j.appender.appenderName.layout.optionN = valueN
其中，Log4j提供的layout有以下幾種：
org.apache.log4j.HTMLLayout（以HTML表格形式布局），
org.apache.log4j.PatternLayout（可以靈活地指定布局模式），
org.apache.log4j.SimpleLayout（包含日志信息的級別和信息字符串），
org.apache.log4j.TTCCLayout（包含日志產生的時間、線程、類別等等信息）
2、格式化日志信息
Log4J采用類似C語言中的printf函數的打印格式格式化日志信息，打印參數如下：
%m 輸出代碼中指定的消息
%p 輸出優先級，即DEBUG，INFO，WARN，ERROR，FATAL
%r 輸出自應用啟動到輸出該log信息耗費的毫秒數
%c 輸出所屬的類目，通常就是所在類的全名
%t 輸出產生該日志事件的線程名
%n 輸出一個回車換行符，Windows平臺為“rn”，Unix平臺為“n”
%d 輸出日志時間點的日期或時間，默認格式為ISO8601，也可以在其后指定格式，比如：%d{yyyy MMM dd HH:mm:ss,SSS}，輸出類似：2002年10月18日 22：10：28，921
%l 輸出日志事件的發生位置，包括類目名、發生的線程，以及在代碼中的行數。
3、在代碼中使用Log4j
我們在需要輸出日志信息的類中做如下的三個工作：
1、導入所有需的commongs-logging類：
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
2、在自己的類中定義一個org.apache.commons.logging.Log類的私有靜態類成員：
private final Log log = LogFactory.getLog(getClass());
LogFactory.getLog()方法的參數使用的是當前類的class。
3、使用org.apache.commons.logging.Log類的成員方法輸出日志信息：
if (log.isDebugEnabled())
{
log.debug("111");
}
if (log.isInfoEnabled())
{
log.info("222");
}
if (log.isWarnEnabled())
{
log.warn("333");
}
if (log.isErrorEnabled())
{
log.error("444");
}
if (log.isFatalEnabled())
{
log.fatal("555")
}
posted @
2009-08-28 15:00 kit_lo 閱讀(194508) |
評論 (29) |
編輯 收藏目標驅動，系統思維，風險意識，數據量化
凡事預則立，不預則廢。如果你不知道要到哪里？給你一張地圖也沒有用。目標驅動首先要有最基本的計劃管理和時間管理能力。對于一個項目，我們過程中做的所有工作都是為了要達到項目目標，因此在項目各個階段所有活動都需要考慮對達成目標的影響，當發現偏差后及時糾正。目標驅動讓我們從無目的的事后應急變成了有計劃有目的的事前預測。目標驅動不是要拋棄過程，項目的成功涉及到過程，人和方法工具技術。為了達到項目目標，我們要根據項目的實際情況采取一系列項目原來已經總結的最佳實踐形成一套過程，高效的過程和積極心態的人是保證項目目標達成的關鍵。因此作為項目經理要時刻問自己，項目的目標是什么？項目當前狀態和我達成目標的差距是什么？我如何解決和應對。
項目的成功受到多方面的因素的影響，而且各個因素之間還存在正反作用力。系統思維就是要讓我們能夠清楚的認識到影響項目目標和成功的各個要素，以及它們之間存在的關系。形成一種適合項目的動態系統模型，通過這個動態模型去平衡項目各方干系人的利益，平衡項目四要素之間的關系，平衡項目的短期和長期的利益。項目經理的一個重要能力就是平衡，沒有最優解，只有滿意解，懂得了平衡就知道當項目出現變更和調整的時候如何更好的應對。從單要素最優的單向思維過渡到關注整個系統的全局思維模式上。
風險意識簡單來講就是項目在執行過程中可能發生的各種問題我都事先預見到了而采取了適當的緩解措施，這樣才能夠真正的讓項目能夠按照預先制定的計劃和目標進行。再簡單點就是如果風險管理做得好，項目是不應該失敗的。君子安而不忘危，存而不忘亡，治而不忘亂。風險管理的重點正是在于要形成風險意識，要能夠通過歷史經驗的積累，能夠把項目的關鍵風險識別出來，使項目能夠從事后的救火轉變到事前的防備，使項目能夠在前面緊張后面輕松。
要談及量化管理首先應該要培訓用數據說話的分析思維。在軟件項目管理中我們做度量的目的，就是要收集和分析各種歷史數據，通過對數據的分析來知道項目真正的效率，同時為后續項目提供各種估算參數數據。以數據說話讓我們從全憑主觀經驗臆斷轉變到對事物的客觀數據分析上。只有能夠收集數據，分析數據我們才可能持續改進。有了數據意識后就是要有統計和量化管理方面的意識，利用統計學的思維和量化管理手段不僅僅是讓我們的過程穩定和受控制，能夠去發現項目執行過程中特殊原因引起的波動，針對特殊波動進行根源分析并采取糾正行動；還能夠讓我們能夠根據預測模型更加準確的預測項目能夠達成目標的程度和概率。
----------------------------------------
努力使自己成為工作的終結者
posted @
2009-08-28 14:53 kit_lo 閱讀(460) |
評論 (1) |
編輯 收藏
大家喝的是啤酒。這時你入座了。
你給自己倒了杯可樂，這叫低配置。
你給自己倒了杯啤酒，這叫標準配置。
你給自己倒了杯茶水，這茶的顏色還跟啤酒一樣，這叫木馬。
你給自己倒了杯可樂，還滴了幾滴醋，不僅顏色跟啤酒一樣，而且不冒熱氣還有泡泡，這叫超級木馬。
你的同事給你倒了杯白酒，這叫推薦配置。
人到齊了，酒席開始了。
你先一個人喝了一小口，這叫單元測試。
你跟旁邊的人說哥們咱們隨意，這叫交叉測試。
但是他說不行，這杯要干了，這叫壓力測試。
于是你說那就大家一起來吧，這叫內部測試。
這個時候boss向全場舉杯了，這叫集成測試。
菜過三巡，你就不跟他們客氣了。
你向對面的人敬酒，這叫p2p.
你向對面的人敬酒，他回敬你，你又再敬他……，這叫tcp.
你向一桌人挨個敬酒，這叫令牌環。
你說只要是兄弟就干了這杯，這叫廣播。
可是你的女上司聽了不高興了：只有兄弟么，罰酒三杯。這叫炸彈。
可是你的女下屬聽了不高興了：我喝一口，你喝一杯，這叫惡意攻擊。
有一個人過來向這桌敬酒，你說不行你先過了我這關，這叫防火墻。
你的小弟們過來敬你酒，這叫一對多。
你是boss，所有人過來敬你酒，這叫服務器。
酒是一樣的，可是喝法是不同的。
你喝了一杯，boss喝了一口，這叫c#。
你喝了一杯，mm喝了一口，這叫vb。
你喝了一杯，你大哥喝了半杯，這叫c++。
你喝了半杯，你小弟喝了一杯，這叫匯編。
你喝了一杯，你的搭檔也喝了一杯，這叫c。
酒是一樣的，可是喝酒的人是不同的。
你越喝臉越紅，這叫資源釋放。
你越喝臉越白，這叫資源獨占。
你已經醉了，卻說我還能喝，叫做虛擬內存。
你明明能喝，卻說我已經醉了，叫做資源保留。
你喝一段時間就上廁所，這叫cache。
酒過三巡，你也該活動活動了。
你一桌一桌的走，這叫輪巡。
你突然看到某一桌的漂亮mm，走了過去，這叫激活事件。
你去了坐下來就不打算走了，這叫死循環。
你的老大舉杯邀你過去，你只好過去，這叫優先級。
你向一桌敬酒，他們說不行不行我們都喝白的，于是你也喝白的，這叫本地化。
你向boss敬酒，可是boss被圍了起來，你只能站在外圈，這叫隊列。
你終于到了內圈，小心翼翼的向前一步，這叫訪問臨界區。
你拍著boss的肩膀說哥們咱們喝一杯，這叫越界。
你不知喝了幾圈了，只會說兩個字，干了，這叫udp。
可是還有人拿著酒瓶跑過來說，剛才都沒跟你喝，這叫丟包。
喝酒喝到最后的結果都一樣
你突然跑向廁所，這叫捕獲異常錯誤。
你在廁所吐了，反而覺得狀態不錯，這叫釋放內存。
你在臺面上吐了，覺得很慚愧，這叫時實錯誤。
你在boss面前吐了，覺得很害怕，這叫災難性錯誤。
你吐到了boss身上，只能索性暈倒了，這叫Shut Down。
posted @
2009-08-28 14:52 kit_lo 閱讀(460) |
評論 (1) |
編輯 收藏