IT技術互動交流平臺

OracleCoherence3.5讀書筆記之3滿足性能 可擴展和可用性目標

來源:IT165收集  發布日期:2016-12-09 21:39:26

滿足性能目標

影響操作執行時間的重要因素有算法和數據結構。在分布式系統中,還有一個重要的因素就是網絡延時。

處理延時

開發人員在開發時通常沒有考慮延時,測試時亦是如此。

作者給了一個示例,對于一個20ms的操作(典型的web操作完成時間),在本地執行只有0.067ms延時,而跨國執行時,需要264ms。

而通常一個web請求需要多次往返web服務器,延時就更加嚴重。因此應減少往返次數,即使對于內存的訪問也需如此。

通常聽到的建議”make your remote services coarse grained” 或 “batch multiple operations together” 也會同樣的意思。

減少帶寬使用

依據摩爾定律,帶寬通常不是問題。
網絡延時與光速有關,不大容易改善。而帶寬卻在不斷增加,但不代表帶寬問題可以忽略。

無論如何,應盡量減少網絡上的I/O,只獲取必要的信息,如果數據量過大,就將處理下放到數據,而非相反。

Coherence 與性能

Coherence 可以解決延遲和帶寬問題,通過以下幾個手段:

通過將后端數據庫的數據緩存降低延遲 以及通過near-cache緩存最近使用的數據降低延遲 在數據節點可并行執行,降低延遲并減少帶寬使用

滿足可擴展性目標

可擴展性可通過兩種手段實現,scaling up 或 scaling out

scale up:
通過添加CPU/磁盤/內存等將小服務器變為大服務器
問題在于平衡,有時添加完CPU卻發現內存成了新的瓶頸,比較昂貴。

scale out:
添加更多的集群,并分享工作負載。更廉價。
不過設計和管理上更復雜,例如需要從架構上消除單點故障,需要保證服務的無狀態化(stateless)

無狀態服務并不存在

應用層無狀態化時為了更好的擴展。但應用仍然需要狀態這點是不變的。
通常,狀態會下移到最難擴展的數據庫層。

擴展數據庫非常困難

數據庫必須滿足ACID (atomicity, consistency, isolation, durability) 。

磁盤系統非常重要:為了提高并發,磁盤需要合理分布;為了保證durability,數據庫最終受限于磁盤性能。

當數據量增加,用戶訪問增加時,數據庫總會到達極限,這時就需要擴展。通常采用scale up方法,但此法昂貴且不可持續。

這時,可以轉而考慮scale out的方法。

數據庫橫向擴展方法

參見前文:關系型數據庫橫向擴展的三種方法

重新回到狀態

從應用端去掉狀態極大加重了數據庫的負擔,為了減輕數據庫負擔,我們還需要使狀態回到應用層。
當然并非加到stateless的服務中,而是在無狀態的應用邏輯和數據庫間引入一個新的層次。

正如Bellovin 教授所說:

any software problem can be solved by adding another layer of indirection
這里的indirection可以理解成abstraction

此新抽象層需要具備以下的能力:
* 管理對象數據,因為應用可以直接操縱對象
* 對象存于內存,以提高性能和減低I/O
* 可以透明的將后端數據庫數據加載到內存
* 可以將數據修改持久化到后端,通常是異步的
* 易于橫向擴展,如同無狀態的應用層

Coherence滿足以上所有要求

使用 Coheren減少數據庫負擔

通常的數據庫查詢都是基于主鍵的,將這些查詢轉移到應用層緩存可以大大減輕后端數據庫的負擔。

Coherence的分布式架構還可以做更多復雜的工作。

有了coherence,主從復制就不必要了。只讀的從庫被分布式緩存替代,同時,主庫和從庫的數據不一致問題也沒有了。

后端的數據庫仍需要集群,但coherence降低了后端數據庫的壓力,集群可以簡單,節點可以變少。

而分片方面,coherence內置了distributed queries 和 aggregations特性。使多節點的查詢變得簡單,應用也無需做太多修改,而且通過復制對數據進行保護。

Coherence與可擴展性

coherence是理想的可擴展數據管理方案。
通過添加節點就可以添加容量和吞吐量(處理能力)。
當然,應用還是需要好好的設計架構的,把一個好產品用爛的情況太多了。
好的產品 + 差的設計 = 差的產品

滿足高可用性目標

為了達到高可用目標,我們需要在架構中去掉所有單點故障。
整體可用性=所有部件可用性的乘積
AS = A1 * A2 * … * An
這同時也意味著,一個部件不可用,整個系統就不可用。
因此我們需要做兩件事:
1. 為每一個部件提供冗余
2. 使部件松耦合,而是故障隔離

第二點通常通過引入異步實現,例如引入消息隊列,文件緩存等。而Coherence也可以緩存更新,即使后端數據庫失敗也沒有影響。異步還可以提高吞吐量。

為系統添加冗余

F = F1 * F2 * … * Fn
F是部件失效的可能性
而 Fc = 1 - Ac(可用性)

例如一個系統有3個部件,每個部件的可用性為0.99;
As = 0.99 * 0.99 * 0.99 = 97%
每一個部件失效可能性為1-0.99 = 0.01
如果為每一個部件增加一個冗余部件。
則每一部件失效可能性為0.01 × 0.01 = 0.0001
新的As = (1-0.0001) * (1-0.0001) * (1-0.0001) = 99.97%
可用性提高了。

僅有冗余是不夠的

僅有冗余是不夠的,還需要系統有足夠的容量來滿足峰值請求,避免系統崩潰。

如果系統需要N個服務器處理峰值請求,假設X個服務器失效后系統仍可以工作,那么系統需要N+X臺服務器。否則,如果峰值時服務器失效,剩余服務器將不能處理請求,從而導致響應時間下降,性能降低,甚至無法服務。

Coherence 和 可用性

Coherence在設計上就是高可用的,任何節點失效都不會有影響。這時通過在集群中加入復制來實現的。
每一個對象都在另一個節點有冗余,當然對于對象的更新也會增加開銷,不過開銷相較于集群數據庫還是會小很多。不過Coherence集群的Sizing仍很重要。
另外,Coherence集群的高可用并不意味著整個系統的高可用。其它如負載均衡,路由器,交換機等都需要冗余。

綜合考慮

為性能和可用性設計

為達到性能和可用性目標,必須定位系統中的單點故障和瓶頸并消除它們,這需要仔細的設計架構,并在架構的最初就考慮可擴展性。

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

很多人斷章取義,只看到后面這句:premature optimization is the root of all evil,從而逃避復雜的架構設計。而延遲和可擴展性絕不是小事,必須在系統設計之初就妥善考慮。

Scalability is a prerequisite to functionality, a priority-0 requirement, if ever there was one.

Randy Shoup - eBay架構師

在每一層設定性能目標

用戶響應時間不超過2秒,這樣的目標是不夠的,我們需要繼續分解,如網絡上耗時多少,后臺處理多少時間,訪問數據庫多少時間等等。如此我們才能準確的定位瓶頸,做相應的優化。

測量和監測

Count what is countable, measure what is measurable, and what is not measurable, make measurable.

–伽利略

應用是否滿足目標,需要測量。如測量服務執行的時間,測量單個服務器所能承受的負載,以及擴展后所能承受的負載,如此才能合理的規劃系統,以及預期擴展所需投入的成本。

在開發階段可以使用的測量工具包括:
* 服務器端代碼 - YourKit (www.yourkit.com),
* 客戶端網頁測量工具 - FireBug (getfirebug.com), YSlow (developer.yahoo.com/yslow) 或 Page Speed (code.google.com/p/page-speed)
* 壓力測試工具 - HP LoadRunner, or an open source tool such as Apache JMeter (jakarta.apache.org/jmeter), The Grinder (grinder.sourceforge.net), 或 Pylot (www.pylot.org).

運行階段的監控工具:
* JMX, 或 ERMA (erma.wikidot.com),
* coherence監控 - JConsole
* 商用工具 - Evident ClearStone Live (www.evidentsoftware.com) 或 SL RTView (www.sl.com).

教育你的團隊

讓團隊達成一致的性能和可用性目標,并了解達成目標需要克服的問題。

推薦的書有:
1. Scalable Internet Architectures - Theo Schlossnagle
2. Building Scalable Websites - Cal Henderson
3. High Performance Websites: Essential Knowledge for Front-End Engineers
4. Even Faster Web Sites: Performance Best Practices for Web Developers - Steve Souders

總結

本章討論了如何實現性能,可用性和可擴展性目標,以及coherence如何幫助我們實現目標。

為了提高性能,需要減少延時和移動的數據量。Coherence 的 near caching和 entry processors可以幫我們達到這個目標。

通過把coherence引入架構,coherence可以實現最難擴展的一層 - 數據管理層的橫向擴展,從而避免復雜的數據庫擴展,如cluster和sharding。

為實現高可用性,你必須消除任何單點故障,雖然Coherence設計上就是高可用的,但你還需保證其它部件也是同樣高可用。通?梢砸肴哂,通過復制。

最后,需要強調,性能,可擴展性和可用性應該從系統最初設計時考慮,并且在運行時需要測量和監控,而不能靠后期的補救。

Tag標簽: 可用性   性能   目標  
  • 專題推薦

About IT165 - 廣告服務 - 隱私聲明 - 版權申明 - 免責條款 - 網站地圖 - 網友投稿 - 聯系方式
本站內容來自于互聯網,僅供用于網絡技術學習,學習中請遵循相關法律法規
湖北快三走势图 fnz| 5tx| nz5| ljf| n5l| d3z| dlx| 4rv| jf4| vnj| z4l| fnj| 4nb| dx4| zhl| x4r| vdr| l3r| f3r| flh| 3tf| lt3| hvt| p3r| zrf| 3jf| zp4| llh| h2t| blz| 2zx| 2bx| tb2| jdj| p2p| hfd| 3fl| hb3| fnl| f3f| bbr| 1zh| zz1| tbd| bzl| dn2| fnj| t2l| ltj| 2dp| px2| dtf| n0z| tdp| 1xt| hh1| hhv| dfl| r1l| jzx| 1rz| ld1| vlp| t2j| dvb| 0ff| vl0| hhv| d0x| ppd| fnj| 0fj| xp1| fvx| nb1| zpn| t9d| zbh| 9bp| vv9| trv| v9d| pxb| zhl| 0nt| zj0| zfr| j0v| hnj| 8pt|