後端效能優化技術
前面討論了前端效能的優化技術，於是前端可能就不是瓶頸問題了。那麼效能問題就會到後端資料上來了。下面說幾個後端常見的效能優化技術。
一、資料冗餘
關於資料冗餘，也就是說，把我們的資料庫的資料冗餘處理，也就是減少表連線這樣的開銷比較大的操作，但這樣會犧牲資料的一致性。風險比較大。很多人把nosql用做資料，快是快了，因為資料冗餘了，但這對資料一致性有大的風險。這需要根據不同的業務進行分析和處理。（注意：用關係型資料庫很容易移植到nosql上，但是反過來從nosql到關係型就難了）
二、資料映象
幾乎所有主流的資料庫都支援映象，也就是replication。資料庫的映象帶來的好處就是可以做負載均衡。把一台資料庫的負載均分到多台上，同時又保證了資料一致性（oracle的scn）。最重要的是，這樣還可以有高可用性，一台廢了，還有另一台在服務。
資料映象的資料一致性可能是個複雜的問題，所以我們要在單條資料上進行資料分割槽，也就是說，把乙個暢銷商品的庫存均分到不同的伺服器上，如，乙個暢銷商品有1萬的庫存，我們可以設定10臺伺服器，每台伺服器上有1000個庫存，這就好像b2c的倉庫一樣。
三、資料分割槽
資料映象不能解決的乙個問題就是資料表裡的記錄太多，導致資料庫操作太慢。所以，把資料分割槽。資料分割槽有很多種做法，一般來說有下面這幾種：
1）把資料把某種邏輯來分類。比如火車票的訂票系統可以按各鐵路局來分，可按各種車型分，可以按始發站分，可以按目的地分……，反正就是把一張表拆成多張有一樣的字段但是不同種類的表，這樣，這些表就可以存在不同的機器上以達到分擔負載的目的。
2）把資料按字段分，也就是堅著分表。比如把一些不經常改的資料放在乙個表裡，經常改的資料放在另外多個表裡。把一張表變成1對1的關係，這樣，你可以減少表的字段個數，同樣可以提公升一定的效能。另外，欄位多會造成一條記錄的儲存會被放到不同的頁表裡，這對於讀寫效能都有問題。但這樣一來會有很多複雜的控制。
3）平均分表。因為第一種方法是並不一定平均分均，可能某個種類的資料還是很多。所以，也有採用平均分配的方式，通過主鍵id的範圍來分表。
4）同一資料分割槽。這個在上面資料映象提過。也就是把同一商品的庫存值分到不同的伺服器上，比如有10000個庫存，可以分到10臺伺服器上，一台上有1000個庫存。然後負載均衡。
這三種分割槽都有好有壞。最常用的還是第一種。資料一旦分割槽，你就需要有乙個或是多個排程來讓你的前端程式知道去**找資料。把火車票的資料分割槽，並放在各個省市，會對12306這個系統有非常有意義的質的效能的提高。
四、後端系統負載均衡
前面說了資料分割槽，資料分割槽可以在一定程度上減輕負載，但是無法減輕熱銷商品的負載，對於火車票來說，可以認為是大城市的某些主幹線上的車票。這就需要使用資料映象來減輕負載。使用資料映象，你必然要使用負載均衡，在後端，我們可能很難使用像路由器上的負載均衡器，因為那是均衡流量的，因為流量並不代表伺服器的繁忙程度。因此，我們需要乙個任務分配系統，其還能監控各個伺服器的負載情況。
我看到有很多系統都用靜態的方式來分配，有的用hash，有的就簡單地輪流分析。這些都不夠好，乙個是不能完美地負載均衡，另乙個靜態的方法的致命缺陷是，如果有一台計算伺服器宕機了，或是我們需要加入新的伺服器，對於我們的分配器來說，都需要知道的。
還有一種方法是使用搶占式的方式進行負載均衡，由下游的計算伺服器去任務伺服器上拿任務。讓這些計算伺服器自己決定自己是否要任務。這樣的好處是可以簡化系統的複雜度，而且還可以任意實時地減少或增加計算伺服器。但是唯一不好的就是，如果有一些任務只能在某種伺服器上處理，這可能會引入一些複雜度。不過總體來說，這種方法可能是比較好的負載均衡。
五、非同步、 throttle 和批量處理
非同步、throttle（節流閥）和批量處理都需要對併發請求數做佇列處理的。
非同步在業務上一般來說就是收集請求，然後延時處理。在技術上就是可以把各個處理程式做成並行的，也就可以水平擴充套件了。但是非同步的技術問題大概有這些，a）被呼叫方的結果返回，會涉及程序執行緒間通訊的問題。b）如果程式需要回滾，回滾會有點複雜。c）非同步通常都會伴隨多執行緒多程序，併發的控制也相對麻煩一些。d）很多非同步系統都用訊息機制，訊息的丟失和亂序也會是比較複雜的問題。
throttle 技術其實並不提公升效能，這個技術主要是防止系統被超過自己不能處理的流量給搞垮了，這其實是個保護機制。使用throttle技術一般來說是對於一些自己無法控制的系統，比如，和你**對接的銀行系統。
批量處理的技術，是把一堆基本相同的請求批量處理。比如，大家同時購買同乙個商品，沒有必要你買乙個我就寫一次資料庫，完全可以收集到一定數量的請求，一次操作。這個技術可以用作很多方面。比如節省網路頻寬，我們都知道網路上的mtu（最大傳輸單元），以態網是1500位元組，光纖可以達到4000多個位元組，如果你的乙個網路包沒有放滿這個mtu，那就是在浪費網路頻寬，因為網絡卡的驅動程式只有一塊一塊地讀效率才會高。因此，網路發包時，我們需要收集到足夠多的資訊後再做網路i/o，這也是一種批量處理的方式。批量處理的敵人是流量低，所以，批量處理的系統一般都會設定上兩個閥值，乙個是作業量，另乙個是timeout，只要有乙個條件滿足，就會開始提交處理。
12306系統架構優化
coolshell陳皓優化方案 原文 一 業務複雜度比對 二 瓶頸 庫存業務的操作模式基本是這樣的 1 佔住庫存 2 付款 3 扣除庫存 這個過程中，是要對資料進行加鎖的，高併發下資料的一致性保證非常之難。併發究竟有多大呢？12306的業務特點是，突然放票，大家去搶。幾十分鐘內，馬上幾千萬的訪問量，...
12306購票又報亂碼BUG
對12306別無所求，能用就行，畢竟使用者請求量太高，而且邏輯複雜。可是在軟體方面來說，乙個工程編碼統一性是很必要的，如果還出現亂碼，那真是乙個不應該的錯誤了。最近國慶快到了，購票的人也多了，最近博主在12306購票 又發現bug，而且貌似很多天都沒有解決，那就是出現了亂碼。博主搜尋了下從北京到石家...
12306購票時被攔截的原因
如果你是新手，會懷疑這個 是否是個釣魚 但幾經確認後，發現確實是瀏覽器攔截了官網你心中一定會有疑問 鐵道部到底在搞什麼鬼？如果你查閱原因，會有下面這句話 好吧。連電腦都不信任鐵道部。實際上，12306 並非所有的連線都被攔截，一些無關緊要的通知和說明，瀏覽器並沒有對其進行攔截。但是 一查詢重要的資訊...