1. 前端圖表如果處理大量數據該怎麼辦
淺談一下Cognos處理大數據的思路，僅針對10.2.1以下的版本，對於10.2.1當中引入的hadloop等分布式數據倉庫等不做介紹。我們主要從一個一般中等項目當中，用怎樣的思路來優化我們的查詢。
我們主要從3個思路來思考大數據的處理
一、資料庫層次
現在主流的Cognos項目，主要的開發模式還是基於rolap的dmr報表建模。因此，資料庫的優化就顯得由為重要。主要通過以下幾個方面優化我們的資料庫：
(1)維度id，維度層次id等關鍵減縮欄位建立索引建立、維護。
(2)根據數據量的大小，按時間等進行分區優化。
(3)高速緩沖表MQT的使用
(4)表空間、緩沖池設置等
(5)資料庫性能優化
二、Cognos Server優化
Cognos優化包括對配置文件的優化，集群的搭建，服務和日誌的開啟等基於cognos 軟體安裝，配置的優化，主要包括以下幾個方面：
2.1 apache 配置優化
Timeout（超時）/MaxKeepAliveRequests（最大的請求數）/KeepAliveTimeout（請求超時）的優化配置
2.2Cognos自帶tomcat配置調優
(1)可修改TOMCAT配置文件CRN_ROOT\tomcat.\conf\server.xml。其參數集中在行：
可以對maxProcessors（最大進程數）/AcceptCount(最大連接數) ConnectionTimeout（連接超時）進行修改
(2)文件路徑：CRN_ROOT\tomcat.\conf\web.xml
可以對session-timeout進行修改.
2.3Cognos sever配置文件優化
2.3.1 reportservice.xml優化
文件路徑：CRN_ROOT\ webapps\p2pd\WEB-INF\services\ reportservice.xml
註：修改文件後，重啟服務後配置生效。
包括以下參數 max_process(交互報表處理進程數，和cpu有關) inger_process(交互報表初始化進程數，和cpu優關)
max_non_affine_connections_per_process(交互報表所佔線程數) idle_process_check_interval_ms(空閑檢測時間)
queue_time_limit_ms(報表服務隊列時間限制) async_wait_timeout_ms(Dispatcher請求等待同步時間)
2.3.2 batchreportservice.xml
文件路徑：CRN_ROOT\ webapps\p2pd\WEB-INF\services\ batchreportservice.xml
註：修改文件後，重啟服務後配置生效。
包括以下參數 max_process(服務批量報表處理所佔進程數) linger_process(服務批量報表處理初始化進程數)
max_non_affine_connections_per_process(服務批量報表處理所佔線程數) idle_process_check_interval_ms(空閑進程檢測時間間隔)
idle_process_max_idle_ticks(空閑進程檢測標記) queue_time_limit_ms(批量報表處理排隊時間限制) async_wait_timeout_ms(Dispatcher請求等待同步時間)
2.3.3 CQEConfig.xml
主要是與資料庫參數設置，文件路徑：CRN_ROOT\configuration\ CQEConfig.xml.sample
註：將CQEConfig.xml.sample文件名修改為CQEConfig.xml後，重啟服務後配置生效。
可以修改以下參數：Timeout(應用資料庫連接超時設置) PoolSize(應用資料庫連接池最大連接數設置) queryReuse(查詢緩沖設置)
2013-07-08 0
分享
答案對人有幫助，有參考價值1
曾力 - Cognos講師、Cognos獨立顧問、數據倉庫架構師 2013-07-08 回答
2.3.4 ppds_cfg.xml
主要進行緩存和日誌參數設置，文件路徑：\cognos\c8\configuration\ ppds_cfg.xml
註：重啟服務後配置生效。
可以修改以下參數：ReadCacheSize(可減少用戶訪問時伺服器的磁碟IO。提高訪問速度。) pcQueryLogFile(建議生產環境關閉該日誌的跟蹤，一般默認也是關閉狀態)
2.4 Cognos content store優化
2.4.1優化內容庫連接服務
內容庫最好外配為db2 oracle等資料庫，不要用自帶的derby.因為項目中的日誌信息會非常多，嚴重影響內容庫的效率。
Cognos Administration，在系統下選擇選擇對應的服務，選擇ContentManagerService的屬性，設置相應的連接參數信息。
2.4.2日誌優化
適當開啟各個cognos服務的日誌級別，越高級的級別對應更詳細，更明確的日誌，但也會影響整個系統的效率。
這是一把雙刃劍，需要適當調整。日誌級別設置得越高，就越降低系統性能。通常情況下，您可以將級別設置為
「最小」或「基本」來收集錯誤，或設置為「請求」來收集錯誤和警告。
2.5提高訪問資料庫速度
Cognos和資料庫間參數在cer\bin\cogdm.ini文件中,(根據版本不同是安裝目錄的數字，根據連接的資料庫不同，是對應資料庫名稱的關鍵字)
以oracle資料庫為例,參數在cogdmor.ini文件中，打開這個文件查找字元串Fetch Number of Rows=去掉這行前面的分號，將10改成2000；
這樣這行就成了Fetch Number of Rows=2000，表示是每次從資料庫取2000條數據。其他資料庫基本上都有類似的配置。用以提高從資料庫中提取數據的速度。
2.6加大緩存
cer\bin\Cer.ini(*根據版本不同是安裝目錄的數字)：
SortMemory=5120
（這里 SortMemory 單位是 2kbytes，5120代表 2k x 5120 = 10M）（技巧：一般 SortMemory 取空閑內存的十分之一到八分之一大小）
2.7修改cognos configuration中的參數來優化
在cognos configuration中有很多參數可以優化來提高整體軟體的運行效率，比如增加內存、增加查詢緩存
2.8分布式部署
分布式部署可以大大提升Cognos伺服器的負載能力，同時容錯保護功能可以使伺服器更為穩定的運行，很好的支持大用戶量的並發使用。
2013-07-08 0
答案對人有幫助，有參考價值1
曾力 - Cognos講師、Cognos獨立顧問、數據倉庫架構師 2013-07-08 回答
3.報表設計優化
Cognos報表作為一個工具，在非cube模式下，最終我們執行報表查詢的時候，我們的報表發送到資料庫進行查詢的本質還是sql，所以，在我們製作一張報表的時候，我們要盡可能的利用fm,rs當中的功能，優化報表最終執行生成的SQL實現整個報表的優化。而CUBE模式下，我們更多要考慮配置、存放和資料庫大小所造成的影響，下面我會細細說來。
2013-07-08 0
答案對人有幫助，有參考價值1
曾力 - Cognos講師、Cognos獨立顧問、數據倉庫架構師 2013-07-08 回答
3.1 FM建模優化
3.1.1手寫SQL定製查詢主題
右鍵點擊查詢主題的菜單項Edit Definition…可以進入SQL語句編寫框，調整查詢主題的SQL語句。默認情況下，這里的SQL語句為Cognos SQL類型。如果需要編寫應用資料庫可以直接運行的本地SQL需要將這里的SQL類型進行設置。點擊右上方的Options按鈕，選擇SQL Settings標簽頁，選擇SQL Type為Native。這個時候，我們手寫SQL就非常注重這個SQL的優化，盡量避免SELECT *,用EXISTS替代IN,多使用DECODE來進行判斷，條件語句注意點等常用SQL優化策略，編寫對應的SQL.
3.1.2盡量使用特定數據的資料庫函數
在菜單項Actions中選擇Specify Package Function List…指定報表定製中可以使用的資料庫函數列表。將除應用資料庫意外的其他資料庫類型從Selected function sets中選到Available function sets中，盡量使用特定資料庫的自帶函數可以提高查詢效率。
3.1.3表關聯設定
在建立表關聯盡量避免使用外關聯關系（包括左外關聯、右外關聯、全外關聯）。外關聯的使用會使資料庫的查詢壓力驟增，從而影響前端報表的生成。在星型結構、雪花型結構的數據倉庫模型中，盡量按照一對一、一對多的關聯關系設定維表與實事表之間的關聯，Cognos Server會依照這里的關聯關系自動優化提交給資料庫的SQL語句。如果關聯關系中出現了環狀連接關系，可以通過別名表或是快捷鍵的方式解決環狀連接問題.
3.1.4Edit Governors查詢性能設置
在菜單項Project中選擇Edit Governors，可以設置查詢的查詢性能
Report table limits 該屬性設置報表中運行SQL所涉及的TABLE數量
Data retrieval limits 該屬性設置報表中運行SQL返回結果的數量
Query execution time limits 該屬性設置報表中運行SQL的執行時間
Large text items limit 該屬性設置報表中運行SQL返回大文字塊的字元數量限制
2013-07-08 0
答案對人有幫助，有參考價值1
曾力 - Cognos講師、Cognos獨立顧問、數據倉庫架構師 2013-07-08 回答
3.2 RS報表調優
3.2.1報表函數的使用
在報表函數的使用上，盡可能使用應用資料庫能夠解析的本地資料庫函數，函數列表中的通用函數，在處理時會將函數放在報表伺服器進行運算，從而增大了報表伺服器的性能開銷。
3.2.2 觀察查詢的SQL
我們選擇查詢頁面，GENERATE SQL/MDX觀察這個報表生成的SQL並進行不斷優化，
3.3.33.2 RS報表調優
3.2.1報表函數的使用
在報表函數的使用上，盡可能使用應用資料庫能夠解析的本地資料庫函數，函數列表中的通用函數，在處理時會將函數放在報表伺服器進行運算，從而增大了報表伺服器的性能開銷。
3.2.2 觀察查詢的SQL
我們選擇查詢頁面，GENERATE SQL/MDX觀察這個報表生成的SQL並進行不斷優化，
3.3.3查詢欄位、查詢表順序調整
根據資料庫的優化策略，可能需要將查詢欄位的順序進行調整，可以在Data Items窗口中進行設置。查詢SQL語句中，From關鍵字後面的表順序是按照select關鍵字後出現的欄位順序進行設置的。在為表順序進行設置時，屬性為Identifier或Attribute的欄位比屬性為Fact的欄位在為表排序時的優先順序要高，即，先以Identifier、Attribute欄位的出現順序為表進行排序，如果沒有上述兩類欄位，才以Fact欄位的出現順序為表進行排序。
3.3.4聚合前後設置過濾條件
將過濾條件的Application屬性設置為After aggregation或Before aggregation可以調整過濾條件在聚合前或是聚合後生效。After aggregation生成過濾條件的SQL語句使用的是關鍵字having，而Before aggregation生成過濾條件的SQL語句使用的是關鍵字where。
3.3.5取消報表自動分組提高明細報表查詢速度
如果報表要展現明細數據，不想使用任何匯總，我們可以到此報表對應的查詢中將自動分組屬性定義為否。修改地方：對象的屬性Auto Group & Summarize可以設置當前SQL語句的查詢中是否加入distinct、sum、group by這樣的關鍵字。默認情況下，該屬性設置為Yes，可以根據查詢情況關掉此開關項，減少SQL語句的復雜度。
3.3.6自動排序設置
在Query的Auto-sort屬性中可以為查詢設置是否自動排序。如果選擇是，則會在生成的SQL語句中自動加入Order By關鍵字，排序欄位將自動根據數據項的屬性進行設置（如果查詢欄位的usage屬性為Attribute、Identifier則排序，如果為Fact則不排序）；如果選擇否、則不排序；如果選擇最小，則根據數據項的排序屬性進行排序設置。默認值為最小。
3.3.7報表Processing設置
在Query的Processing屬性中可以為查詢設置SQL的處理設置。Cognos Report Studio會將報表的所有設置首先轉換為Cognos SQL提交給報表伺服器，伺服器在進行必要處理後，會將SQL語句轉換為應用資料庫本地執行的SQL語句，進行資料庫處理。為提高報表的處理速度，要盡可能的將報表的處理運算放在資料庫進行，以保證其運行速度。將該屬性設置為Database only會將報表頁面生成的Cognos SQL不經報表伺服器處理全部轉換為資料庫能夠執行的本地資料庫SQL，如果將該屬性設置為Limited Local，則將報表頁面生成的Cognos SQL先進行必要的報表伺服器運算，然後再將剩餘的部分提交給資料庫進行本地SQL的處理。默認值為Framework中為Datasource對象的設置的queryProcessing屬性。
3.3.8使用With子句
在Query的Use SQL With Clause屬性中可以為查詢設置是否使用With子句。部分資料庫例如Oracle支持With關鍵字，當查詢中嵌套子查詢時，可以通過With子句的使用，減輕報表伺服器對Cognos SQL的處理，從而提升報表的運行性能。如果將該屬性設置為Yes，則允許使用With關鍵字，查詢中生成的Native SQL將出現With子句；如果將該屬性設置為No，雖然拒絕使用With關鍵字。默認值為Framework中Edit Governors下的Use WITH clause when generating SQL屬性設置。
3.3.9報表伺服器本地緩存設置
在Query的Use Local Cache屬性中可以為查詢設置是否使用本地緩存。如果將該屬性設置為Yes，則啟用伺服器的本地緩存，伺服器將為查詢結果保存在session中，當用戶在瀏覽器內再次打開同一張報表時，查詢結果將取自緩存，從而減輕了資料庫的負載壓力；如果將該屬性設置為No，則禁用伺服器的本地緩存，查詢結果全部取自資料庫的實時數據。默認值為Framework中Edit Governors下的Allow usage of local cache屬性設置。
我用的是finereport，比這個方便
2. spring boot 怎麼實現集群
Helloworld使用傳統的springmvc,需要配置web.xml,applicationContext.xml,然後打包為war在tomcat中運行，而如果使用springboot，一切都變得簡單起來了。下面使用Maven來創建springboot的webapp工程pom.xml4.0.0org.springframeworkgs-spring-boot0.1.0org.springframework.bootspring-boot-starter-parent1.3.3.RELEASEorg.springframework.bootspring-boot-starter-weborg.springframework.bootspring-boot-starter-testtest1.8org.springframework.bootspring-boot-maven-;importorg.springframework.web.bind.annotation.RequestMapping;importorg.springframework.web.bind.annotation.RestController;@{@RequestMapping("/")publicStringindex(){return"GreetingsfromSpringBoot!";}}其中：@RestController表示使用springmvc來接收request請求@RequestMapping映射到主頁當請求返回的時候，是純文本，那是因為@RestController是由@Controller和@ResponseBody組成Application@{publicstaticvoidmain(String[]args){ApplicationContextctx=SpringApplication.run(Application.class,args);System.out.println("Let':");}}其中：@SpringBootApplication代表了其有四個註解組成：@Configuration，@EnableAutoConfiguration，@EnableWebMvc，@ComponentScan在SpringApplication.run中會去自動啟動tomcatrun方法返回上下文，在這個上下文中可以拿到所有的bean沒有一行配置代碼、也沒有web.xml。基於SpringBoot的應用在大多數情況下都不需要我們去顯式地聲明各類配置，而是將最常用的默認配置作為約定，在不聲明的情況下也能適應大多數的開發場景。總體而言springboot是對javawebapp開發的簡化單元測試@RunWith(SpringJUnit4ClassRunner.class)@(classes=MockServletContext.class)@{privateMockMvcmvc;@Beforepublicvoidbefore()throwsException{mvc=MockMvcBuilders.standaloneSetup(newHelloController()).build();}@Afterpublicvoidafter()throwsException{}/****Method:index()**/@TestpublicvoidtestIndex()throwsException{//TODO:Testgoesheremvc.perform(MockMvcRequestBuilders.get("/").accept(MediaType.APPLICATION_JSON)).andExpect(status().isOk()).andExpect(content().string(equalTo("GreetingsfromSpringBoot!")));}}建立restfullweb伺服器接上，使用srpingboot建立web伺服器就非常簡單了，首先建立一個pojo類publicclassGreeting{privatefinallongid;privatefinalStringcontent;}然後使用control來handlehttp請求@{="Hello,%s!";privatefinalAtomicLongcounter=newAtomicLong();@RequestMapping("/greeting")publicGreetinggreeting(@RequestParam(value="name",defaultValue="World")Stringname){returnnewGreeting(counter.incrementAndGet(),String.format(template,name));}}其中：@RequestParam表明了參數要求，如果要必填則設置required=true返回是一個對象，會被自動轉換為json當我們訪問：greeting時候返回{"id":1,"content":"Hello,World!"}greeting?name=User時候返回{"id":2,"content":"Hello,User!"}資料庫訪問另一個非常常用的問題。在傳統開發中，我們需要配置：類路徑上添加數據訪問驅動實例化DataSource對象，指定url,username,password注入JdbcTemplate對象，如果使用Mybatis,還要配置框架信息下面一個例子講述用用springboot來代替。數據訪問層我們將使用SpringDataJPA和Hibernate（JPA的實現之一）。開始之前先介紹兩個概念springdata為了簡化程序與資料庫交互的代碼，spring提供了一個現成的層框架，spring家族提供的spring-data適用於關系型資料庫和nosql資料庫；例如SpringDataJPA,SpringDataHadoop,SpringDataMongoDB，SpringDataSolr等；具體的可以參考官網：.mysql.jdbc.Driverspring.datasource.password=xxx#SpecifytheDBMSspring.jpa.database=MYSQL#.jpa.show-sql=true#Hibernateddlauto(create,create-drop,update)spring.jpa.hibernate.ddl-auto=update#Namingstrategyspring.jpa.hibernate.naming-strategy=org.hibernate.cfg.ImprovedNamingStrategy#)spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL5Dialect其中，hibernate的ddl-auto=update配置表名，資料庫的表和列會自動創建寫下實體類：@Entity@Table(name="student")publicclassStudent{@Id@GeneratedValue(strategy=GenerationType.AUTO)privatelongid;@NotNullprivateStringname;privateStringage;}@Entity，說明被這個註解修飾的類應該與一張資料庫表相對應，表的名稱可以由類名推斷，當然了，也可以明確配置，只要加上@Table(name="books")即可。需要特別注意，每個Entity類都應該有一個protected訪問級別的無參構造函數，用於給Hibernate提供初始化的入口。@Idand@GeneratedValue：@Id註解修飾的屬性應該作為表中的主鍵處理、@GeneratedValue修飾的屬性應該由資料庫自動生成，而不需要明確指定。@ManyToOne,@ManyToMany表明具體的數據存放在其他表中，在這個例子里，書和作者是多對一的關系，書和出版社是多對一的關系，因此book表中的author和publisher相當於數據表中的外鍵；並且在Publisher中通過@OneToMany（mapped="publisher"）定義一個反向關聯（1——>n），表明book類中的publisher屬性與這里的books形成對應關系。@Repository用來表示訪問資料庫並操作數據的介面，同時它修飾的介面也可以被componentscan機制探測到並注冊為bean，這樣就可以在其他模塊中通過@Autowired織入。:@{ListfindByLastName(StringlastName);}詳細的可以看springjpa的具體介紹。最後使用：@{@AutowiredprivateStudentDao;@RequestMapping("/get-student-counts")@(){Liststudents=(List).findAll();returnString.format("%d",students.size());}}主要一點是：我在CustomerRepository實現中每天添加方法：findByLastName，@Autowired就會一直報錯。
3. 網站性能優化怎麼辦
一、前端優化
網站性能優化是一個很綜合的話題，涉及到伺服器的配置和網站前後端程序等各個方面，我只是從實際經歷出發，分享一下自己所嘗試過的網站性能優化方法。之所以在標題上掛一個web2.0，是因為本文更偏重於中小網站的性能優化，我所使用的系統也是典型web2.0的LAMP架構。
首先講講前端的優化，用戶訪問網頁的等待時間，有80%是發生在瀏覽器前端，特別是頁面和頁面中各種元素（圖片、CSS、Javascript、 flash…）的下載之上。因此在很多情況下，相對於把大量的時間花在艱苦而繁雜的程序改進上，前端的優化往往能起到事半功倍的作用。雅虎最近將內部使用的性能測試工具yslow向第三方公開，並發布了著名的網站性能優化的十三條規則，建議你下載並安裝yslow，並作為測評網站優化效果的工具。下面我挑其中特別有價值的具體說明一下優化的方法：
對於第一次訪問您網站，尚未在瀏覽器cache中緩存您網站內容的用戶，我們可以做的事情包括：
1）減少一個頁面訪問所產生的http連接次數
對於第一次訪問你網站的用戶，頁面所產生的http連接次數是影響性能的一個關鍵瓶頸。
對策：
- 盡量簡潔的頁面設計，最大程度減少圖片的使用，通過放棄一些不必要的頁面特效來減少javascript的使用。
- 使用一些優化技巧，比如利用圖片的背景位移減少圖片的個數；image map技術；使用Inline images將css圖片捆綁到網頁中。
- 盡量合並js和css文件，減少獨立文件個數。
2) 使用gzip壓縮網頁內容
使用gzip來壓縮網頁中的靜態內容，能夠顯著減少用戶訪問網頁時的等待時間（據說可達到60%）。主流的web伺服器都支持或提供gzip壓縮，如果使用apache伺服器，只需要在配置文件中開啟 mod_gzip（apache1.x）或mod_deflate(apache2.x)即可。凡是靜態的頁面，使用gzip壓縮都能夠顯著提高伺服器效率並減少帶寬支出，注意圖片內容本身已經是壓縮格式了，務必不要再進行壓縮。
3）將CSS放在頁面頂端，JS文件放在頁面底端
CSS的引用要放在html的頭部header中，JS文件引用盡量放在頁面底端標簽的後面，主要的思路是讓核心的頁面內容盡早顯示出來。不過要注意，一些大量使用js的頁面，可能有一些js文件放在底端會引起一些難以預料的問題，根據實際情況適當運用即可。
4）使JS文件內容最小化
具體來說就是使用一些javascript壓縮工具對js腳本進行壓縮，去除其中的空白字元、注釋，最小化變數名等。在使用gzip壓縮的基礎上，對js內容的壓縮能夠將性能再提高5%。
5）盡量減少外部腳本的使用，減少DNS查詢時間
不要在網頁中引用太多的外部腳本，首先，一次dns的解析過程會消耗20-120毫秒的時間；其次，如果在頁面中引用太多的外部文件（如各種廣告、聯盟等代碼），可能會因為外部文件的響應速度而將你的網站拖得很慢。如果不得不用，那麼就盡量將這些腳本放在頁腳吧。不過有一點需要提及，就是瀏覽器一般只能並行處理同一域名下的兩個請求，而對於不同子的域名則不受此限制，因此適當將本站靜態內容（css,js）放在其他的子域名下（如 static.xxx.com）會有利於提高瀏覽器並行下載網頁內容的能力。
對於您網站的經常性訪問用戶，主要的優化思路就是最大限度利用用戶瀏覽器的cache來減少伺服器的開銷。
1）在header中添加過期時間(Expires Header)
在header中給靜態內容添加一個較長的過期時間，這樣可以使用戶今後訪問只讀取緩存中的文件，而不會與伺服器產生任何的交互。不過這樣做也存在一些問題，當圖片、CSS和js文件更新時，用戶如果不刷新瀏覽器，就無法獲得此更新。這樣，我們在對圖片、css和js文件修改時，必須要進行重命名，才能保證用戶訪問到最新的內容。這可能會給開發造成不小的麻煩，因為這些文件可能被站點中的許多文件所引用。flickr提出的解決辦法是通過url rewrite使不同版本號的URL事實上指向同一個文件，這是一個聰明的辦法，因為url級別的操作效率是很高的，可以給開發過程提供不少便利。
要理解為什麼這樣做，必須要了解瀏覽器訪問url時的工作機制：
a. 第一次訪問url時，用戶從伺服器段獲取頁面內容，並把相關的文件（images,css,js…）放在高速緩存中，也會把文件頭中的expired time,last modified, ETags等相關信息也一同保留下來。
b. 用戶重復訪問url時，瀏覽器首先看高速緩存中是否有本站同名的文件，如果有，則檢查文件的過期時間；如果尚未過期，則直接從緩存中讀取文件，不再訪問伺服器。
c. 如果緩存中文件的過期時間不存在或已超出，則瀏覽器會訪問伺服器獲取文件的頭信息，檢查last modifed和ETags等信息，如果發現本地緩存中的文件在上次訪問後沒被修改，則使用本地緩存中的文件；如果修改過，則從伺服器上獲取最新版本。
我的經驗，如果可能，盡量遵循此原則給靜態文件添加過期時間，這樣可以大幅度減少用戶對伺服器資源的重復訪問。
2）將css和js文件放在獨立外部文件中引用
將css和js文件放在獨立文件中，這樣它們會被單獨緩存起來，在訪問其他頁面時可以從瀏覽器的高速緩存中直接讀取。一些網站的首頁可能是例外的，這些首頁的自身瀏覽可能並不大，但卻是用戶訪問網站的第一印象以及導向到其他頁面的起點，也可能這些頁面本身使用了大量的ajax局部刷新及技術，這時可以將 css和js文件直接寫在頁面中。
3）去掉重復的腳本
在IE中，包含重復的js腳本會導致瀏覽器的緩存不被使用，仔細檢查一下你的程序，去掉重復引用的腳本應該不是一件很難的事情。
4）避免重定向的發生
除了在header中人為的重定向之外，網頁重定向常在不經意間發生，被重定向的內容將不會使用瀏覽器的緩存。比如用戶在訪問www.xxx.com，伺服器會通過301轉向到www.xxx.com/，在後面加了一個「/」。如果伺服器的配置不好，這也會給伺服器帶來額外的負擔。通過配置apache的 alias或使用mod_rewrite模塊等方法，可以避免不必要的重定向。
還有一些，比如使用CDN分發機制、避免CSS表達式等、避免使用ETags等，因為不太常用，這里就不再贅述了。
做完了上述的優化，可以試著用yslow測試一下網頁的性能評分，一般都可以達到70分以上了。
當然，除了瀏覽器前端和靜態內容的優化之外，還有針對程序腳本、伺服器、資料庫、負載的優化，這些更深層次的優化方法對技術有更高的要求。本文的後半部分將重點探討後端的優化。
二、後端優化
上次寫完web2.0網站前端優化篇之後，一直想寫寫後端優化的方法，今天終於有時間將思路整理了出來。
前端優化可以避免我們造成無謂的伺服器和帶寬資源浪費，但隨著網站訪問量的增加，僅靠前端優化已經不能解決所有問題了，後端軟體處理並行請求的能力、程序運 行的效率、硬體性能以及系統的可擴展性，將成為影響網站性能和穩定的關鍵瓶頸所在。優化系統和程序的性能可以從以下的方面來入手：
1）apache、mysql等軟體的配置的優化
盡管apache和mysql等軟體在安裝後使用的默認設置足以使你的網站運行起來，但是通過調整mysql和apache的一些系統參數，還是可以追求更高的效率和穩定性。這個領域中有很多專業的文章和論壇（比如： http://www.mysqlperformanceblog.com/），要想掌握也需要進行深入的研究和實踐，這里就不重點討論了。
2）應用程序環境加速
這里僅以我最常應用的php開發環境為例，有一些工具軟體可以通過優化PHP運行環境來達到提速的目的，其基本原理大致是將PHP代碼預編譯並緩存起來，而不需要改變任何代碼，所以比較簡單，可以將php的運行效率提升50%以上。比較常用的免費php加速工具有：APC( http: //pecl.php.net/package-info.php?package=APC)、Turck MMCache（ http://turck-mmcache.sourceforge.net）、php accelebrator(www.php-accelerator.co.uk)，還有收費的Zend Performance Suite
3）將靜態內容和動態內容分開處理
apache是一個功能完善但比較龐大的web server，它的資源佔用基本上和同時運行的進程數呈正比，對伺服器內存的消耗比較大，處理並行任務的效率也一般。在一些情況下，我們可以用比較輕量級的web server來host靜態的圖片、樣式表和javascript文件，這樣可以大大提升靜態文件的處理速度，還可以減少對內存佔用。我使用的web server是來自俄羅斯的nginx，其他選擇方案還包括lighttpd和thttpd等。
4）基於反向代理的前端訪問負載均衡
當一台前端伺服器不足以應付用戶訪問時，通過前端機實現web訪問的負載均衡是最快速可行的方案。通過apache的mod_proxy可以實現基於反向代理的負載均衡，這里推薦使用nginx做代理伺服器，處理速度較apache更快一些。
5）應用緩存技術提高資料庫效能，文件緩存和分布式緩存
資料庫訪問處理並發訪問的能力是很多網站應用的關鍵瓶頸，在想到使用主從結構和多farm的方式構建伺服器集群之前，首先應該確保充分使用了資料庫查詢的緩存。一些資料庫類型（如mysql的innoDB）自身內置對緩存的支持，此外，還可以利用程序方法將常用的查詢通過文件或內存緩存起來。比如通過 php中的ob_start和文件讀寫函數可以很方便的實現文件形式的緩存，而如果你擁有多台伺服器，可以通過memcache技術通過分布式共享內存來對資料庫查詢進行緩存，不僅效率高而且擴展性好，memcache技術在livejournal和Craigslist.org等知名網站應用中都得到了檢驗。
6）伺服器運行狀態的檢測，找到影響性能的瓶頸所在
系統優化沒有一勞永逸的方法，需要通過檢測伺服器的運行狀態來及時發現影響性能的瓶頸，以及可能存在的潛在問題，因為網站的性能，永遠取決於木桶中的短板。可以編寫一些腳本來檢測web服務的運行，也有一些開源的軟體也提供了很好的功能
7）良好的擴展架構是穩定和性能的基礎
一些技巧和竅門可以幫你度過眼前的難關，但要想使網站具備應付大規模訪問的能力，則需要從系統架構上進行徹底的規劃，好在很多前人無私的把他們架構
網站的經驗分享給我們，使我們可以少走甚多彎路。我最近讀到的兩篇有啟發的文章：
- 從LiveJournal後台發展看大規模網站性能優化方法
- Myspace的六次重構
最後不得不提到程序編碼和資料庫結構對性能的影響，一系列糟糕的循環語句，一個不合理的查詢語句、一張設計不佳的數據表或索引表，都足以會使應用程序運行的速度成倍的降低。培養全局思考的能力，養成良好的編程習慣，並對資料庫運行機制有所了解，是提高編程質量的基礎。
4. 分布式資料庫與資料庫集群的區別到底是什麼哪位高手幫忙解惑下~~~~~~~~~~跪求
（1）另外一位博主的觀點（http://blog.csdn.net/bluishglc/article/details/5483162）
博主有對他的表述有作一點修改補充，方便各位猿友明了他的意思。
簡單說，分布式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數來提升效率。
例如：
如果一個任務由10個子任務組成，每個子任務單獨執行需1小時，則在一台伺服器上執行改任務需10小時。
採用分布式方案，提供10台伺服器，每台伺服器只負責處理一個子任務，不考慮子任務間的依賴關系，執行完這個任務只需一個小時。(這種工作模式的一個典型代表就是Hadoop的Map/Rece分布式計算模型）
而採用集群方案，同樣提供10台伺服器，每台伺服器都能獨立處理這個任務。假設有10個任務同時到達，10個伺服器將同時工作，10小後，10個任務同時完成，這樣，整身來看，還是平均1小時完成一個任務！（注意這里的任務和子任務的區別）
（2）知乎（https://www.hu.com/question/20004877）
這個猿友描述得很簡單明了：
分布式：一個業務分拆多個子業務，部署在不同的伺服器上
集群：同一個業務，部署在多個伺服器上
另外一位猿友從另外一個角度去表述：
集群是個物理形態，分布式是個工作方式。
這位猿友的描述也很簡潔，但是比較抽象：
按照我的理解，集群是解決高可用的，而分布式是解決高性能、高並發的
（3）網路（http://ke..com/view/4804677.htm、http://ke..com/view/3022776.htm）
集群：
集群是一組相互獨立的、通過高速網路互聯的計算機，它們構成了一個組，並以單一系統的模式加以管理。一個客戶與集群相互作用時，集群像是一個獨立的伺服器。集群配置是用於提高可用性和可縮放性。
分布式：
一種基於網路的計算機處理技術，與集中式相對應。由於個人計算機的性能得到極大的提高及其使用的普及，使處理能力分布到網路上的所有計算機成為可能。分布式計算是和集中式計算相對立的概念，分布式計算的數據可以分布在很大區域。
看完這些是不是有種似懂非懂的感覺？博主也是一樣！所以我們接下來繼續了解。
上面博主有說過自己有接觸過分布式服務框架Dubbo，那麼我們看看它為什麼說自己是分布式服務架構？（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%83%8C%E6%99%AF）
分布式服務架構
當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
此時，用於提高業務復用及整合的 分布式服務框架(RPC) 是關鍵。
偶然之間，有發現據說「Git就是分布式版本控制系統」，為什麼它是分布式的呢？
Git就是分布式版本控制系統，對應的是集中式的版本控制如SVN。簡單的說，分布式的版本控制就是每個人都可以創建一個獨立的代碼倉庫用於管理，各種版本控制的操作都可以在本地完成。每個人修改的代碼都可以推送合並到另外一個代碼倉庫中。而像SVN這樣，只有一個中央控制，所有的開發人員都必須依賴於這個代碼倉庫。每次版本控制的操作也必須鏈接到伺服器才能完成。很多公司喜歡用集中式的版本控制是為了更好的控制代碼。如果個人開發，就可以選擇Git這種分布式的。
從一般開發者的角度來看，git有以下功能：
1、從伺服器上克隆完整的Git倉庫（包括代碼和版本信息）到單機上。
2、在自己的機器上根據不同的開發目的，創建分支，修改代碼。
3、在單機上自己創建的分支上提交代碼。
4、在單機上合並分支。
5、把伺服器上最新版的代碼fetch下來，然後跟自己的主分支合並。
6、生成補丁（patch），把補丁發送給主開發者。
7、看主開發者的反饋，如果主開發者發現兩個一般開發者之間有沖突（他們之間可以合作解決的沖突），就會要求他們先解決沖突，然後再由其中一個人提交。如果主開發者可以自己解決，或者沒有沖突，就通過。
8、一般開發者之間解決沖突的方法，開發者之間可以使用pull 命令解決沖突，解決完沖突之後再向主開發者提交補丁。
看了分布式服務框架Dubbo和分布式版本控制系統Git的這些描述後，細想一下，似乎和上面的「分布式：一個業務分拆多個子業務，部署在不同的伺服器上，集群：同一個業務，部署在多個伺服器上」的觀點些相似。
Dubbo將核心業務抽取出來，作為獨立的服務模塊，各個模塊之間只需要依賴介面，介面實現分離，那麼開發人員可以各自完成自己負責的服務模塊，最後完成一個完整的系統。他們的目標是完成一個系統，而各個子服務模塊相當於子業務。Git也類似。
事實上，分布式很多時候都開不了集群的，在Dubbo、Hadoop、Elasticsearch都有體現。
現在分布式概念可能我們相對比較清晰了，集群概念可能還比較模糊。另外，集群是如何跟分布式配合的呢，接下來我們繼續了解集群。
集群主要分成三大類 （高可用集群， 負載均衡集群，科學計算集群）
高可用集群( High Availability Cluster)
負載均衡集群(Load Balance Cluster)
科學計算集群(High Performance Computing Cluster)
1、高可用集群(High Availability Cluster)
常見的就是2個節點做成的HA集群，有很多通俗的不科學的名稱，比如」雙機熱備」, 「雙機互備」, 「雙機」。
高可用集群解決的是保障用戶的應用程序持續對外提供服務的能力。 (請注意高可用集群既不是用來保護業務數據的，保護的是用戶的業務程序對外不間斷提供服務，把因軟體/硬體/人為造成的故障對業務的影響降低到最小程度)。
2、負載均衡集群(Load Balance Cluster)
負載均衡系統：集群中所有的節點都處於活動狀態，它們分攤系統的工作負載。一般Web伺服器集群、資料庫集群和應用伺服器集群都屬於這種類型。
負載均衡集群一般用於相應網路請求的網頁伺服器，資料庫伺服器。這種集群可以在接到請求時，檢查接受請求較少，不繁忙的伺服器，並把請求轉到這些伺服器上。從檢查其他伺服器狀態這一點上看，負載均衡和容錯集群很接近，不同之處是數量上更多。
3、科學計算集群(High Performance Computing Cluster)
高性能計算(High Perfermance Computing)集群，簡稱HPC集群。這類集群致力於提供單個計算機所不能提供的強大的計算能力。
高性能計算分類：
3.1、高吞吐計算(High-throughput Computing)
有一類高性能計算，可以把它分成若干可以並行的子任務，而且各個子任務彼此間沒有什麼關聯。象在家搜尋外星人（ SETI@HOME – Search for Extraterrestrial Intelligence at Home ）就是這一類型應用。
這一項目是利用Internet上的閑置的計算資源來搜尋外星人。SETI項目的伺服器將一組數據和數據模式發給Internet上參加SETI的計算節點，計算節點在給定的數據上用給定的模式進行搜索，然後將搜索的結果發給伺服器。伺服器負責將從各個計算節點返回的數據匯集成完整的 數據。因為這種類型應用的一個共同特徵是在海量數據上搜索某些模式，所以把這類計算稱為高吞吐計算。
所謂的Internet計算都屬於這一類。按照 Flynn的分類，高吞吐計算屬於SIMD（Single Instruction/Multiple Data）的范疇。
3.2、分布計算(Distributed Computing)
另一類計算剛好和高吞吐計算相反，它們雖然可以給分成若干並行的子任務，但是子任務間聯系很緊密，需要大量的數據交換。按照Flynn的分類，分布式的高性能計算屬於MIMD（Multiple Instruction/Multiple Data）的范疇。
下面說說這幾種集群的應用場景：
高可用集群這里不多作說明。
想Dubbo是比較偏向於負載均衡集群，用過的猿友應該知道（不知道的可以自行了解一下），Dubbo同一個服務是可以有多個提供者的，當一個消費者過來，它要消費那個提供者，這里是有負載均衡機制在裡面的。
搜索引擎Elasticsearch比較偏向於科學計算集群的分布計算。
而到這里，可能不少猿友都知道，集群的一些術語：集群容錯、負載均衡。
我們以Dubbo為例：
集群容錯（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E9%9B%86%E7%BE%A4%E5%AE%B9%E9%94%99）
Dubbo提供了這些容錯策略：
集群容錯模式：
可以自行擴展集群容錯策略，參見：集群擴展
Failover Cluster
失敗自動切換，當出現失敗，重試其它伺服器。(預設)
通常用於讀操作，但重試會帶來更長延遲。
可通過retries="2"來設置重試次數(不含第一次)。
Failfast Cluster
快速失敗，只發起一次調用，失敗立即報錯。
通常用於非冪等性的寫操作，比如新增記錄。
Failsafe Cluster
失敗安全，出現異常時，直接忽略。
通常用於寫入審計日誌等操作。
Failback Cluster
失敗自動恢復，後台記錄失敗請求，定時重發。
通常用於消息通知操作。
Forking Cluster
並行調用多個伺服器，只要一個成功即返回。
通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。
可通過forks="2"來設置最大並行數。
Broadcast Cluster
廣播調用所有提供者，逐個調用，任意一台報錯則報錯。(2.1.0開始支持)
通常用於通知所有提供者更新緩存或日誌等本地資源信息。
負載均衡（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1）
Dubbo提供了這些負載均衡策略：
Random LoadBalance
隨機，按權重設置隨機概率。
在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。
RoundRobin LoadBalance
輪循，按公約後的權重設置輪循比率。
存在慢的提供者累積請求問題，比如：第二台機器很慢，但沒掛，當請求調到第二台時就卡在那，久而久之，所有請求都卡在調到第二台上。
LeastActive LoadBalance
最少活躍調用數，相同活躍數的隨機，活躍數指調用前後計數差。
使慢的提供者收到更少請求，因為越慢的提供者的調用前後計數差會越大。
ConsistentHash LoadBalance
一致性Hash，相同參數的請求總是發到同一提供者。
當某一台提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。
演算法參見：http://en.wikipedia.org/wiki/Consistent_hashing。
預設只對第一個參數Hash，如果要修改，請配置<bbo:parameter key="hash.arguments" value="0,1" />
預設用160份虛擬節點，如果要修改，請配置<bbo:parameter key="hash.nodes" value="320" />
還有比較好奇它們是怎麼通信的？
像早期版本的Elasticsearch的話，自動發現節點機制，ES是一個基於p2p的系統，它先通過廣播尋找存在的節點，再通過多播協議來進行節點之間的通信，同時也支持點對點的交互。
而Dubbo是有個注冊中心，它支持多個注冊中心，但是推薦使用ZooKeeper。關於ZooKeeper可以自行了解，很多集群相關的框架都有使用到它。當然像Elasticsearch是自己有相應的機制實現的。
5. 「分布式」與「集群」的區別是什麼
簡單說，分布式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數來提升效率。
例如：
如果一個任務由10個子任務組成，每個子任務單獨執行需1小時，則在一台伺服器上執行改任務需10小時。
採用分布式方案，提供10台伺服器，每台伺服器只負責處理一個子任務，不考慮子任務間的依賴關系，執行完這個任務只需一個小時。(這種工作模式的一個典型代表就是Hadoop的Map/Rece分布式計算模型）
而採用集群方案，同樣提供10台伺服器，每台伺服器都能獨立處理這個任務。假設有10個任務同時到達，10個伺服器將同時工作，10小後，10個任務同時完成，這樣，整身來看，還是1小時內完成一個任務！
以下是摘抄自網路文章：
一、集群概念
1. 兩大關鍵特性
集群是一組協同工作的服務實體，用以提供比單一服務實體更具擴展性與可用性的服務平台。在客戶端看來，一個集群就象是一個服務實體，但事實上集群由一組服務實體組成。與單一服務實體相比較，集群提供了以下兩個關鍵特性：
· 可擴展性－－集群的性能不限於單一的服務實體，新的服務實體可以動態地加入到集群，從而增強集群的性能。
· 高可用性－－集群通過服務實體冗餘使客戶端免於輕易遇到out of service的警告。在集群中，同樣的服務可以由多個服務實體提供。如果一個服務實體失敗了，另一個服務實體會接管失敗的服務實體。集群提供的從一個出 錯的服務實體恢復到另一個服務實體的功能增強了應用的可用性。
2. 兩大能力
為了具有可擴展性和高可用性特點，集群的必須具備以下兩大能力：
· 負載均衡－－負載均衡能把任務比較均衡地分布到集群環境下的計算和網路資源。
· 錯誤恢復－－由於某種原因，執行某個任務的資源出現故障，另一服務實體中執行同一任務的資源接著完成任務。這種由於一個實體中的資源不能工作，另一個實體中的資源透明的繼續完成任務的過程叫錯誤恢復。
負載均衡和錯誤恢復都要求各服務實體中有執行同一任務的資源存在，而且對於同一任務的各個資源來說，執行任務所需的信息視圖（信息上下文）必須是一樣的。
3. 兩大技術
實現集群務必要有以下兩大技術：
· 集群地址－－集群由多個服務實體組成，集群客戶端通過訪問集群的集群地址獲取集群內部各服務實體的功能。具有單一集群地址（也叫單一影像）是集群的一個基本特徵。維護集群地址的設置被稱為負載均衡器。負載均衡器內部負責管理各個服務實體的加入和退出，外部負責集群地址向內部服務實體地址的轉換。有的負載均衡器實現真正的負載均衡演算法，有的只支持任務的轉換。只實現任務轉換的負載均衡器適用於支持ACTIVE-STANDBY的集群環境，在那裡，集群中只有一個服務實體工作，當正在工作的服務實體發生故障時，負載均衡器把後來的任務轉向另外一個服務實體。
· 內部通信－－為了能協同工作、實現負載均衡和錯誤恢復，集群各實體間必須時常通信，比如負載均衡器對服務實體心跳測試信息、服務實體間任務執行上下文信息的通信。
具有同一個集群地址使得客戶端能訪問集群提供的計算服務，一個集群地址下隱藏了各個服務實體的內部地址，使得客戶要求的計算服務能在各個服務實體之間分布。內部通信是集群能正常運轉的基礎，它使得集群具有均衡負載和錯誤恢復的能力。
二、集群分類
Linux集群主要分成三大類(高可用集群， 負載均衡集群，科學計算集群)
高可用集群(High Availability Cluster)
負載均衡集群(Load Balance Cluster)
科學計算集群(High Performance Computing Cluster)
具體包括：
Linux High Availability 高可用集群
(普通兩節點雙機熱備，多節點HA集群，RAC, shared, share-nothing集群等)
Linux Load Balance 負載均衡集群
(LVS等....)
Linux High Performance Computing 高性能科學計算集群
(Beowulf 類集群....)
三、詳細介紹
1. 高可用集群(High Availability Cluster)
常見的就是2個節點做成的HA集群，有很多通俗的不科學的名稱，比如"雙機熱備"，"雙機互備"，"雙機"。
高可用集群解決的是保障用戶的應用程序持續對外提供服務的能力。 (請注意高可用集群既不是用來保護業務數據的，保護的是用戶的業務程序對外不間斷提供服務，把因軟體/硬體/人為造成的故障對業務的影響降低到最小程度)。
2. 負載均衡集群(Load Balance Cluster)
負載均衡系統：集群中所有的節點都處於活動狀態，它們分攤系統的工作負載。一般Web伺服器集群、資料庫集群和應用伺服器集群都屬於這種類型。
負載均衡集群一般用於相應網路請求的網頁伺服器，資料庫伺服器。這種集群可以在接到請求時，檢查接受請求較少，不繁忙的伺服器，並把請求轉到這些伺服器上。從檢查其他伺服器狀態這一點上看，負載均衡和容錯集群很接近，不同之處是數量上更多。
3. 科學計算集群(High Performance Computing Cluster)
高性能計算(High Perfermance Computing)集群，簡稱HPC集群。這類集群致力於提供單個計算機所不能提供的強大的計算能力。
3.1 高性能計算分類
3.1.1 高吞吐計算(High-throughput Computing)
有一類高性能計算，可以把它分成若干可以並行的子任務，而且各個子任務彼此間沒有什麼關聯。象在家搜尋外星人（ SETI@HOME -- Search for Extraterrestrial Intelligence at Home ）就是這一類型應用。這一項目是利用Internet上的閑置的計算資源來搜尋外星人。SETI項目的伺服器將一組數據和數據模式發給Internet上參加SETI的計算節點，計算節點在給定的數據上用給定的模式進行搜索，然後將搜索的結果發給伺服器。伺服器負責將從各個計算節點返回的數據匯集成完整的 數據。因為這種類型應用的一個共同特徵是在海量數據上搜索某些模式，所以把這類計算稱為高吞吐計算。所謂的Internet計算都屬於這一類。按照 Flynn的分類，高吞吐計算屬於SIMD（Single Instruction/Multiple Data）的范疇。
3.1.2 分布計算(Distributed Computing)
另一類計算剛好和高吞吐計算相反，它們雖然可以給分成若干並行的子任務，但是子任務間聯系很緊密，需要大量的數據交換。按照Flynn的分類，分布式的高性能計算屬於MIMD（Multiple Instruction/Multiple Data）的范疇。
四、分布式（集群）與集群的聯系與區別
分布式是指將不同的業務分布在不同的地方；而集群指的是將幾台伺服器集中在一起，實現同一業務。
分布式中的每一個節點，都可以做集群。 而集群並不一定就是分布式的。
舉例：就比如新浪網，訪問的人多了，他可以做一個群集，前面放一個響應伺服器，後面幾台伺服器完成同一業務，如果有業務訪問的時候，響應伺服器看哪台伺服器的負載不是很重，就將給哪一台去完成。
而分布式，從窄意上理解，也跟集群差不多， 但是它的組織比較鬆散，不像集群，有一個組織性，一台伺服器垮了，其它的伺服器可以頂上來。
分布式的每一個節點，都完成不同的業務，一個節點垮了，那這個業務就不可訪問了。
6. 應用伺服器，資料庫伺服器，前端數據對接伺服器這三種伺服器配置上是不是都是相同的只是說法不一樣
配置不一樣的，型號一樣不一樣我覺得沒關系，主要配置要合適，本質其實都是普通伺服器，現在也有雲伺服器，利用虛擬技術搞的，我也不是特別懂
應用伺服器，一般部署應用代碼，配置不用很高，也要看用的人和並發量，一般8-16G內存，4-8核CPU就夠了，主要看代碼裡面多線程等代碼復雜程度，一般多台機器集群
資料庫伺服器，這個部署資料庫，一般配置會高，因為所有應用伺服器一般都會鏈接資料庫，CPU要多，內存要大。一般是個大集群，還要主庫備庫，各種優化
前端數據對接伺服器不知道指的是什麼，我個人理解是VIP，負載均衡，對接客戶前端的，主要做分流，存一點小數據等，對接應用伺服器，這個配置也不用很高，也是個集群
7. 前端框架
1.前端框架一般指用於簡化網頁設計的框架，比如，jquery，extjs，bootstrap等等，這些框架封裝了一些功能，比如html文檔操作，漂亮的各種控制項(按鈕，表單等等)。
2.使用前段框架可以降低界面開發周期和提高界面的美觀性。
3.有些框架比較輕量，比如jquery，有些框架比較重量，比如extjs。一般來說重量的框架會封裝更多的功能，比如extjs，封裝的grid控制項有很強的數據展示和操作功能。
1.對用戶的價值：
大部分產品對用戶的核心價值是功能和內容提供的，而不是由表現層和交互。譬如支付、電商、新聞、交友。
後端解決有還是無的問題，開天闢地。
前端解決有了以後好用的問題，錦上添花，在競爭激烈的領域確實至關重要。
2.技術廣度和難度：
廣度上後端工作在伺服器領域，能控制的硬體基本沒有極限，CPU、存儲、網路、集群等等，因此技術領域極廣。一個優秀的後端需要掌握或了解大量技術如：並發、業務架構、資料庫、幾打流行框架、性能調優、分布式計算、集群架構、容災、安全、運維等等，一層知銷和挖透了還有下一層。幾十年計算機發展歷史中大量的技術沉澱在伺服器端。
Web前端一直工作在一個瀏覽器盒子里，先天不足，能承載的可能性太小，技術廣度不足。
深度上，現代計算機領域的難題如大規模負載，海量數據處理，實時計算也是後端的，前端集中在表示層，這一層雖然也很復雜，但能稱之為難題的技術幾乎沒有，也很容易復制。
前端要說深度也不是沒有，但這一步需要跨到圖形領域(如網頁游戲)，不是常見場景。
說到底前端代碼能控制的硬體確實不如後端，因此在技術上，前端更容易。現在為什麼說前端會比後端更值錢呢?那是因為前端對硬體的控制能力提升了(html5odejsmobile)，而後端分化得比較厲害，有一批後端專門只寫業務邏輯，框架是別人寫的，系統架構是別人搭的，伺服器跑在雲里，連機器物理地址都不知道。世人眼裡可能覺得這種寫MVC代碼的人才斗褲是後端，這種被限制在一個「虛擬盒子」里的後端確實不怎麼難上手。
一般而言網上說的互聯網行業的技術含量排名大概是這樣：
產品經理<設計師<前端<後端<其他更高級職位，比如演算法工程師等等。
在廣大中小公司，很多產品經理都是不會代碼，不會設計。很多技校學藝術設計的畢業生，當上了美工。這些都是真，所以能力低，乾的人多，自然搭盯就低。然而，你問Google設計師掙多少了嘛?
門檻低不等於技術含量低。