lvs源碼分析
❶ keepalived+lvs能和haproxy同時使用嗎
可以放在相同的機器上，同樣也需要綁定lo網卡。
❷ 用calibre進行LVS，步驟是怎樣的
Calibre環境做LVS步驟（後面附註意事項，供參考）
1、LVS數據准備
在Astro中完成晶元後提取.fv文件及.gds文件，這兩個文件是做LVS必備的。.v文件用來生成在LVS過程中用來和Layout進行比對的.spi文件，而.gds文件用來讀入calibre得到Layout。 2、將.gds文件讀入calibre 具體步驟省略。 3、生成.spi文件
.spi文件是由.v和一些.cdl、.spi文件一同生成的。
生成.spi文件有一個腳本，以SMIC18 工藝xxx目錄為例： v2lvs \
-lsp xxx/smic18.cdl \ -lsp xxx/POR.cdl \
-lsp xxx/RAM256X8.cdl \ -lsp xxx/SP018W.sp \ -s xxx/smic18.cdl \ -s xxx/POR.cdl \
-s xxx/RAM256X8.cdl \ -s xxx/SP018W.sp \ -s0 VSS \ -s1 VDD \
-v $topCell.v \ -o $topCell.spi
格式是固定的，-lsp後面列出你所要做LVS的晶元用到的IP的.spi（.sp）文件，rom、ram、stdcell是.cdl文件。-s後面再把-lsp列出的文件重復一遍。-s0和-s1不變，-v後面寫你要進行轉換的.fv文件，-o後面寫你要輸出的.spi文件。
文件寫好後，在文件所在目錄直接鍵入文件名，文件即開始自動執行。執行後若無warning和error即可。
icc中提取出來的.v文件需要有phsical only的器件，但是不需要corner和filler pad，pcut和power IO必須加進去。還有一些格式要求，需要使用如下選項：
wirte_verilog –diode_ports –split_bus –no_pad_filler –no_corner_filler_cells -pg這些信息加好後，再進行上面轉換.spi文件的步驟。 4、完善layout和.spi文件
在smic工藝下： （1）、layout完善
此時要先檢查pad上面的text是否打好。之後要把FP打上。關於FP，以下是從smic的IO文檔中找到的解釋：
FP stands for 『From Power Pad』 and FP pin is for global signal. Under normal condition, FP is activated by PVDD2W of Standard I/O library SP018W to 『HIGH』 (3.3V). FP rail will be automatically connected while joining with other digital I/O cells.
打TEXT的時候要打FP，但是注意：只有digital pad有FP。 （2）、.spi完善
var script = document.createElement('script'); script.src = 'http://static.pay..com/resource/chuan/ns.js'; document.body.appendChild(script);
在.spi文件中要加入pcut的連接關系，即VSS1=…，VSS2=…。VSS1和VSS2是pcut的port名字，…處你要寫他們和什麼相連。
另外，一些打了字的pad也要寫清楚它的連接關系，如VSSD=VSSD_pad，等號前面是pad出的port，等號後面寫pad上打的text。
另外，在.spi文件中的出現的變數名，要寫在.GLOBAL後面，否則LVS的時候會報錯。如果有連接關系要註明，則在.spi文件後面寫*.CONNECT後面寫明兩個要連接的名字就可以了。 5、進行LVS
所有準備工作都做完了，開始LVS。 啟動calibre，選nmLVS，出現LVS界面。選左邊一欄的Rules，在Calibre Rules File中填入LVS的rule。一般我們在做LVS的時候，會先把rom，ram，analog等IP部分box起來不查，先讓其他部分的LVS通過了，再查整體的LVS。因此這個rule可以自己加一些box，格式是LVS BOX instance name。
在左邊一欄中選Inputs，Layout一欄不動，選Netlist，在Files處填入你修改好了的.spi文件。之後在上面一條菜單中選Setup>LVS Options，選Connect中的Connect nets with colon (:)。選好後，點左側的Run LVS，則LVS過程就開始了。
運行完後，如果沒有問題，則你會看到綠色的笑臉，如果有問題，則要進行分析，修改.spi或者layout來通過LVS。
補充資料：
Useful Abbreviations
SVRF——Standard Verification Rule Format Mentor Rule
RVE——Results Viewing Environment 顯示環境
SVDB——Standard Verification Rule Database （LVS results）
在LVS rule中寫上這句話，LVS會產生一個SVDB的文件夾存放一些中間結果文件。
ERC——Electrical Rule Verification PEX——Parasitic Ectraction
MDP——Mask Data Preparation 是foundary做的mask的ORC檢查。（ORC：optical rules checking 光學規則校驗）
TVF——Tcl Verification Format 65nm以下的rule file格式，SVRF很難cover所有的corner所以有TVF
Connect nets with colon (:) 虛擬連接，例如A:1和A:2將被認為是一條net
有時候smic18工藝中，ram,rom的LVS netlist文件.cdl是由dataprepare生成的，但是要把文件中N,P後面加上18變成N18和P18（必須保證stdcell和其rule的命名相匹配才可以）還有要把文件中DN改為NDIO18。
在.v轉換成.spi文件的過程中，會在instance前面加X。當有IP Merge時，一些IP的PIN、PORT都要當作BOX注釋掉，否則在LVS中會報錯。
❸ C++學習。。。
大一學習的c++，工作之後也一直用的c++。
1. 涵蓋c++入門到精通的圖書列表
《The C programming language》必讀
《C++ Primer》，號稱是一本可以讓你從C或java程序員轉為一個真正的C++程序員的入門參考書，必讀。
《The C++ programming language》，C++之父，人稱B教主著作，在看過C++ primer後，應該可以跳章選讀。
《Think in c++》，網上說此書的中文版翻譯質量奇差，推薦看影印版，選讀。
《Effective c++》，類似 Effective java，講的是最佳實踐，程序員必讀。
《More effective c++》，上書的補充。
《The C++ standard library》，會寫C，不會用標准庫怎麼行。這就跟java程序員不會用java.util包一樣，必讀。
《Effective STL》，STL庫的最佳實踐。Effective C++作者又一力作，必讀。
《The annotated STL source》，STL源碼分析，這本書應該算是深入/精通類了，選讀。
《Generic programming and STL》，號稱C++編程里，就是跟模板，泛型打交道，那麼精通泛型是勢在必行。
《C++ Template》，C++模板編程，代碼復用的經驗之道，必讀。
《Exceptional C++》，跟Effective C++類似，屬於最佳實踐和難題解析，書中列出了許多應用場景和實例代碼供讀者揣摩，選讀。
《More Exceptional C++》，上書的補充。
《Exceptional C++ Style》，上上書的補充
《Inside The C++ Object Model》，有了上面這些書做鋪墊，那麼終於可以讀此神書了。它會帶你游覽C++對象模型的底層實現機制。讀完此書，任何C++代碼看起來如同行雲流水，必讀。
2. 優秀的C/C++開源項目(閱讀代碼)
OS：linux kernel LVS、Linux應用程序
DB：Mysql、PostgreSQL
Complier：VM、GCC
Framework：OpenSip、SipProxy、
Net：ACE(Java Mina、Netty)、TCP/IP、HTTP協議棧
Cache：Memcached、Redis、
Library：STL（java util package）、Boost、Qt(UI)、
balance：Apache、Nginx
GSL
地址：https://github.com/microsoft/GSL
Boost文檔
地址：https://www.boost.org/doc/libs/
wxWidgets官網
地址：http://wxwidgets.org/
gtkmm
地址：https://www.gtkmm.org/en/
CopperSpice
地址：https://www.copperspice.com/
Qt
地址：https://www.qt.io/Eigen
地址：http://eigen.tuxfamily.org/index.php?title=Main_Page#Documentation
Plot utils
地址：https://www.gnu.org/software/plotutils/
Asio
地址：https://think-async.com/Asio/
POCO
地址：https://pocoproject.org/
abseil
地址：https://abseil.io/
C++開源庫匯總列表
地址：https://en.cppreference.com/w/cpp/links/libs
除了這些開源項目，也可以找一些免費的公開課，那這里也推薦一個ACM金牌大佬講授的免費C++課程，可以去體驗一下：
學好C++才是入職大廠的敲門磚！ 當年要是有這課，我的C++也不至於這樣
已失效
3.C++語法講解
語言基礎
詳細介紹變數、表達式、語句、指針、數組、流程式控制制、函數、文件組織等。抽象機制 - 面向對象編程
深入講解C++的抽象機制，封裝（類）、繼承、多態；操作符重載、函數對象、異常處理等。模板 - 泛型編程
詳細介紹C++的模板機制，類模板、函數模板、模板特化等方面的內容。引用和指針：為什麼引用很重要
const關鍵字：為什麼const很重要
名字空間 (namespace)
關於C++對象
內置類型的對象，如int、double對象，自定義類型的對象對象類型的定義
關鍵字class和struct
類成員：成員函數和數據成員
靜態數據成員
成員的訪問控制
對象的size
關於this指針
onst成員函數、const究竟修飾什麼
mutable數據成員
4種特殊成員函數：constructor、destructor、 constructor、operator=
對象的構造、初始化列表
對象的析構
對象的復制
什麼情況下有必要顯式定義4種特殊函數
C++對象生命周關於C++中操作符重載機制
重要操作符重載
算術運算：+, -, *, /, %, ++, --, ...
關系運算：>, <, ==, !=
下標存取：[ ]
函數調用：()，函數對象
類型轉換、單參數構造函數與隱式轉換、阻止隱式轉換 -- explicit關鍵字友元與成員
基類與派生類
再談對象的構造與析構
虛函數、純虛函數
派生類的內存布局、虛函數表
多態、多態類型、如何體現多態
虛析構、為什麼虛析構很重要
多繼承
虛繼承與虛基類
對基類的訪問、public / protected / private繼承
Down cast：static_cast<>和dynamic_cast<>
運行期類型識別 (RTTI)
C++語言機制提供了完整的OOP支持
超越繼承
OOP若干法則和設計模式
《C++ Primer》
最新版本：第三版（第四版國外已上架， 國內一些網上書店也在預訂中）
適合有豐富C經驗，缺乏C++經驗的。不過我個人一直認為此書帶著過於強烈的c語言的痕跡，對於C++的學習未必是 好事。
《The C++ Programming Language》/《C++程序設計語言》
最新版本：第三版特別版
簡稱 TC++PL，有其他語言的豐富經驗的。（也有人簡稱之為「TCPL」，但需與另一本《The C Programmer Language》區分開來）
《Essential C++》
《Accelerated C++》
這兩本薄一些，都是不錯的選擇。《Accelerated C++》本人沒有讀過，從各方面的評價來看，完全值得推薦。
以上幾本書都有相應的中文版，而且翻譯的質量都不錯。上面的書未必都需要讀一遍，但無論如何，TC++PL是應該閱讀的。
《Effective C++》
最新版本：第二版（第三版國外已上架，國內一些網上書店也在預訂中）
簡稱EC。C++程序員必讀！很多時候，我們說C++聖經不是指TC++PL，而是這一本。《The Pragmatic Programmer》一書中寫到：「一旦你發現自己要參與C++項目的開發，趕快跑（不要走）到書店去購買Scott Mayer的《Effective C++》，可能還要《More Effective C++》」。
《C++ Coding Standards: 101 Rules, Guidelines, and Best Practices》/《C++ 編程規范》
個人認為此書應為C++程序員必備的案頭書。幾乎Effective系列和Exceptional系 列都在這里得到了總結。最新的模版、異常的業界經驗都在這里的到了體現。可能的唯一缺陷就是對一個新手而言，關於「為什麼這么做」的問題，解釋的不夠。
我 的看法是：如果你不理解其中的條款，記憶，並且照做；如果你理解其中的條款，我猜你一定會同意書中的觀點。我認為這本書中的內容至少在2009年以前都不 會過時，人們將廣為傳誦它制定的101條戒律。
還不知道他的簡稱，也許「101」會成為一個候選者？
提到《Effective C++》，那麼另外三本書一一浮出水面：
《More Effective C++》
《Exceptional C++》
《More Exceptional C++》。
新書《Exceptional C++ Style》也是值得一看的好書。
上 述幾本書，一本也不應該放過。
個人建議上述書籍按順序閱讀。並且，在將來反復閱讀這幾本書。
4.深入c++面向對象
4.1、從C到C++
4.2、深入C++對象
4.3、操作符重載
4.4、面向對象基礎 -- 繼承
4.5、關於繼承更多的話題
4.6、C++與面向對象設計
5.C++泛型編程與STL
5.1、C++ 模板機制
5.2、STL 概要
5.3、STL容器
5.4、STL迭代
5.5、STL演算法
5.6、預與定義STL數對象
5.7、STL適配器
6. C++進階
《Thinking in C++》/《C++編程思想》
這本書及其中文版傳言好壞都有，沒有認真看過，不做評價，如果確有興趣，不妨嘗試 一下該書。
以下幾本書基本上涉及的都是語言本身，大體上可以按照以下的順序閱讀。
《C++必知必會》
如果早一年，這本書將是重量級的，然而它被101和《Exceptional C++ Style》蓋過一頭。
《C++ Gotchas: Avoiding Common Problems in Coding and Design》/《C++程序設計陷阱》
這又是一本我未曾讀過，而且廣受好評的書。
《STL 源碼剖析》
這本書我剛到手，就被人"借"走，以至於到現在也沒有看過。看過這本書的朋友，可以給一個合適的評價。
7. C++進階之數據結構基礎
這是所有編程語言中最應該學習的部分，程序組成的基礎之一。
順序存儲、鏈式存儲、循環鏈表；
雙向鏈表、棧(順序和鏈式)、隊列(順序和鏈式)；
棧的應用、樹基本概念及遍歷、二叉樹；
排序演算法、並歸演算法、選擇、插入、快速、希爾。
以上這些內容你知道嗎?
8. C++進階之UI界面開發
掌握QT類庫構架，圖形界面開發模型；
掌握QT開發技巧，消息機制，圖形處理；
掌握QT網路編程，UDP，TCP使用方式；
掌握QT文件處理方式，序列化；
掌握QT在windows，linux，ios，android不同平台下的移植技術。
9. C++進階之Unix/Linux網路伺服器
掌握Unix/Linux平台開發方式；
熟練使用系統調用；
熟練Unix/Linux內存管理，進程，線程調度；
熟悉網路伺服器開發方式，熟練編寫TCP，UCP網路服務程序；
掌握同步/非同步IO模型在網路編程中的使用方式。
10.C++進階之資料庫開發
掌握SQL語言的實用技巧。Oracle,MySQL資料庫的使用方式。
如果你能熟練掌握以上列出的技能，具備解決復雜問題和技術難點的能力，而且你能獨立開發一些比較復雜的功能模塊，那麼很榮幸地告訴你，你已經達到中級水平，薪資過萬對你來說簡直是小菜一碟。
11.C++標准參考
C++ reference
地址：https://en.cppreference.com/w/
C++ Coding Standard
地址：http://www.possibility.com/Cpp/CppCodingStandard.html
Standard C++
地址：https://isocpp.org/
State of C++ Evolution
地址：http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2597.html
The C++ Resources Network
地址：http://www.cplusplus.com/
Draft C++ Standard: Contents
地址：http://eel.is/c++draft/
關注一些公眾號，比如c語言與cpp編程
❹ 我用cadence導入layout後， 當我運行LVS時，有個Global error如下，求指教，謝謝先
layout 、extracted 保存一下，再做LVS
❺ nginx lvs haproxy哪個用的多
一、lvs的優勢：
1、抗負載能力強，因為lvs工作方式的邏輯是非常之簡單，而且工作在網路4層僅做請求分發之用，沒有流量，所以在效率上基本不需要太過考慮。在我手裡的 lvs，僅僅出過一次問題：在並發最高的一小段時間內均衡器出現丟包現象，據分析為網路問題，即網卡或linux2.4內核的承載能力已到上限，內存和 cpu方面基本無消耗。
2、配置性低，這通常是一大劣勢，但同時也是一大優勢，因為沒有太多可配置的選項，所以除了增減伺服器，並不需要經常去觸碰它，大大減少了人為出錯的幾率。
3、工作穩定，因為其本身抗負載能力很強，所以穩定性高也是順理成章，另外各種lvs都有完整的雙機熱備方案，所以一點不用擔心均衡器本身會出什麼問題，節點出現故障的話，lvs會自動判別，所以系統整體是非常穩定的。
4、無流量，上面已經有所提及了。lvs僅僅分發請求，而流量並不從它本身出去，所以可以利用它這點來做一些線路分流之用。沒有流量同時也保住了均衡器的IO性能不會受到大流量的影響。
5、基本上能支持所有應用，因為lvs工作在4層，所以它可以對幾乎所有應用做負載均衡，包括http、資料庫、聊天室等等。
另：lvs也不是完全能判別節點故障的，譬如在wlc分配方式下，集群里有一個節點沒有配置VIP，會使整個集群不能使用，這時使用wrr分配方式則會丟掉一台機。目前這個問題還在進一步測試中。所以，用lvs也得多多當心為妙。
二、nginx和lvs作對比的結果
1、nginx工作在網路的7層，所以它可以針對http應用本身來做分流策略，比如針對域名、目錄結構等，相比之下lvs並不具備這樣的功能，所以 nginx單憑這點可利用的場合就遠多於lvs了；但nginx有用的這些功能使其可調整度要高於lvs，所以經常要去觸碰觸碰，由lvs的第2條優點 看，觸碰多了，人為出問題的幾率也就會大。
2、nginx對網路的依賴較小，理論上只要ping得通，網頁訪問正常，nginx就能連得通，nginx同時還能區分內外網，如果是同時擁有內外網的 節點，就相當於單機擁有了備份線路；lvs就比較依賴於網路環境，目前來看伺服器在同一網段內並且lvs使用direct方式分流，效果較能得到保證。另 外注意，lvs需要向託管商至少申請多一個ip來做Visual IP，貌似是不能用本身的IP來做VIP的。要做好LVS管理員，確實得跟進學習很多有關網路通信方面的知識，就不再是一個HTTP那麼簡單了。
3、nginx安裝和配置比較簡單，測試起來也很方便，因為它基本能把錯誤用日誌列印出來。lvs的安裝和配置、測試就要花比較長的時間了，因為同上所述，lvs對網路依賴比較大，很多時候不能配置成功都是因為網路問題而不是配置問題，出了問題要解決也相應的會麻煩得多。
4、nginx也同樣能承受很高負載且穩定，但負載度和穩定度差lvs還有幾個等級：nginx處理所有流量所以受限於機器IO和配置；本身的bug也還是難以避免的；nginx沒有現成的雙機熱備方案，所以跑在單機上還是風險較大，單機上的事情全都很難說。
5、nginx可以檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點。目前lvs中 ldirectd也能支持針對伺服器內部的情況來監控，但lvs的原理使其不能重發請求。重發請求這點，譬如用戶正在上傳一個文件，而處理該上傳的節點剛 好在上傳過程中出現故障，nginx會把上傳切到另一台伺服器重新處理，而lvs就直接斷掉了，如果是上傳一個很大的文件或者很重要的文件的話，用戶可能 會因此而惱火。
6、nginx對請求的非同步處理可以幫助節點伺服器減輕負載，假如使用apache直接對外服務，那麼出現很多的窄帶鏈接時apache伺服器將會佔用大 量內存而不能釋放，使用多一個nginx做apache代理的話，這些窄帶鏈接會被nginx擋住，apache上就不會堆積過多的請求，這樣就減少了相 當多的內存佔用。這點使用squid也有相同的作用，即使squid本身配置為不緩存，對apache還是有很大幫助的。lvs沒有這些功能，也就無法能 比較。
7、nginx能支持http和email（email的功能估計比較少人用），lvs所支持的應用在這點上會比nginx更多。
在使用上，一般最前端所採取的策略應是lvs，也就是DNS的指向應為lvs均衡器，lvs的優點令它非常適合做這個任務。
重要的ip地址，最好交由lvs託管，比如資料庫的ip、webservice伺服器的ip等等，這些ip地址隨著時間推移，使用面會越來越大，如果更換ip則故障會接踵而至。所以將這些重要ip交給lvs託管是最為穩妥的，這樣做的唯一缺點是需要的VIP數量會比較多。
nginx可作為lvs節點機器使用，一是可以利用nginx的功能，二是可以利用nginx的性能。當然這一層面也可以直接使用squid，squid的功能方面就比nginx弱不少了，性能上也有所遜色於nginx。
nginx也可作為中層代理使用，這一層面nginx基本上無對手，唯一可以撼動nginx的就只有lighttpd了，不過lighttpd目前還沒有 能做到nginx完全的功能，配置也不那麼清晰易讀。另外，中層代理的IP也是重要的，所以中層代理也擁有一個VIP和lvs是最完美的方案了。
nginx也可作為網頁靜態伺服器，不過超出了本文討論的范疇，簡單提一下。
具體的應用還得具體分析，如果是比較小的網站（日PV<1000萬），用nginx就完全可以了，如果機器也不少，可以用DNS輪詢，lvs所耗費的機器還是比較多的；大型網站或者重要的服務，機器不發愁的時候，要多多考慮利用lvs。
****************************************************************************************************************
Nginx的優點:
性能好，可以負載超過1萬的並發。
功能多，除了負載均衡，還能作Web伺服器，而且可以通過Geo模塊來實現流量分配。
社區活躍，第三方補丁和模塊很多
支持gzip proxy
缺點:
不支持session保持。
對後端realserver的健康檢查功能效果不好。而且只支持通過埠來檢測，不支持通過url來檢測。
nginx對big request header的支持不是很好，如果client_header_buffer_size設置的比較小，就會返回400bad request頁面。
Haproxy的優點:
它的優點正好可以補充nginx的缺點。支持session保持，同時支持通過獲取指定的url來檢測後端伺服器的狀態。
支持tcp模式的負載均衡。比如可以給mysql的從伺服器集群和郵件伺服器做負載均衡。
缺點：
不支持虛擬主機(這個很傻啊)
目前沒有nagios和cacti的性能監控模板
LVS的優點:
性能好，接近硬體設備的網路吞吐和連接負載能力。
LVS的DR模式，支持通過廣域網進行負載均衡。這個其他任何負載均衡軟體目前都不具備。
缺點：
比較重型。另外社區不如nginx活躍。
*************************************************************************************
現在網路中常見的的負載均衡主要分為兩種：一種是通過硬體來進行進行，常見的硬體有比較昂貴的NetScaler、F5、Radware和Array等商用的負載均衡器，也有類似於LVS、Nginx、HAproxy的基於Linux的開源的負載均衡策略,
商用負載均衡裡面NetScaler從效果上比F5的效率上更高。對於負載均衡器來說，不過商用負載均衡由於可以建立在四~七層協議之上，因此適用 面更廣所以有其不可替代性，他的優點就是有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大，所以對於規模較小的網路服務來說暫時還沒有需要使用。
另一種負載均衡的方式是通過軟體：比較常見的有LVS、Nginx、HAproxy等，其中LVS是建立在四層協議上面的，而另外Nginx和HAproxy是建立在七層協議之上的，下面分別介紹關於
LVS：使用集群技術和Linux操作系統實現一個高性能、高可用的伺服器，它具有很好的可伸縮性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。
LVS的特點是：
1、抗負載能力強、是工作在網路4層之上僅作分發之用，沒有流量的產生；
2、配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的幾率；
3、工作穩定，自身有完整的雙機熱備方案；
4、無流量，保證了均衡器IO的性能不會收到大流量的影響；
5、應用范圍比較廣，可以對所有應用做負載均衡；
6、LVS需要向IDC多申請一個IP來做Visual IP，因此需要一定的網路知識，所以對操作人的要求比較高。
Nginx的特點是：
1、工作在網路的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構；
2、Nginx對網路的依賴比較小；
3、Nginx安裝和配置比較簡單，測試起來比較方便；
4、也可以承擔高的負載壓力且穩定，一般能支撐超過1萬次的並發；
5、Nginx可以通過埠檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點，不過其中缺點就是不支持url來檢測；
6、Nginx對請求的非同步處理可以幫助節點伺服器減輕負載；
7、Nginx能支持http和Email，這樣就在適用范圍上面小很多；
8、不支持Session的保持、對Big request header的支持不是很好，另外默認的只有Round-robin和IP-hash兩種負載均衡演算法。
HAProxy的特點是：
1、HAProxy是工作在網路7層之上。
2、能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作
3、支持url檢測後端的伺服器出問題的檢測會有很好的幫助。
4、更多的負載均衡策略比如：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現
5、單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。
6、HAProxy可以對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。
***********************************************************************************************
現在網站發展的趨勢對網路負載均衡的使用是隨著網站規模的提升根據不同的階段來使用不同的技術：
第一階段：利用Nginx或者HAProxy進行單點的負載均衡，這一階段伺服器規模剛脫離開單伺服器、單資料庫的模式，需要一定的負載均衡，但是 仍然規模較小沒有專業的維護團隊來進行維護，也沒有需要進行大規模的網站部署。這樣利用Nginx或者HAproxy就是第一選擇，此時這些東西上手快， 配置容易，在七層之上利用HTTP協議就可以。這時是第一選擇
第二階段：隨著網路服務進一步擴大，這時單點的Nginx已經不能滿足，這時使用LVS或者商用F5就是首要選擇，Nginx此時就作為LVS或者 F5的節點來使用，具體LVS或者F5的是選擇是根據公司規模，人才以及資金能力來選擇的，這里也不做詳談，但是一般來說這階段相關人才跟不上業務的提 升，所以購買商業負載均衡已經成為了必經之路。
第三階段：這時網路服務已經成為主流產品，此時隨著公司知名度也進一步擴展，相關人才的能力以及數量也隨之提升，這時無論從開發適合自身產品的定製，以及降低成本來講開源的LVS，已經成為首選，這時LVS會成為主流。
最終形成比較理想的狀態為：F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer。
❻ LVS負載均衡到後端apache的虛擬主機報404錯誤 檢查日誌發現：File does not exist: /etc/httpd/htdocs
錯誤日誌和訪問日誌一樣也是Apache的標准日誌。本文分析錯誤日誌的內容，介紹如何設置和錯誤日誌相關的選項，文檔錯誤和CGI錯誤的分類，以及如何方便地查看日誌內容，等等。
一、位置和內容
錯誤日誌無論在格式上還是在內容上都和訪問日誌不同。然而，錯誤日誌和訪問日誌一樣也提供豐富的信息，我們可以利用這些信息分析伺服器的運行情況、哪裡出現了問題。
錯誤日誌的文件名字是error_log，但如果是Windows平台，則錯誤日誌的文件名字是error.log。錯誤日誌的位置可以通過ErrorLog指令設置：
ErrorLog logs/error.log
除非文件位置用「/」開頭，否則這個文件位置是相對於ServerRoot目錄的相對路徑。如果Apache採用默認安裝方式安裝，那麼錯誤日誌的位置應該在/usr/local/apache/logs下。但是，如果Apache用某種包管理器安裝，錯誤日誌很可能在其他位置。
正如其名字所示，錯誤日誌記錄了伺服器運行期間遇到的各種錯誤，以及一些普通的診斷信息，比如伺服器何時啟動、何時關閉等。
我們可以設置日誌文件記錄信息級別的高低，控制日誌文件記錄信息的數量和類型。這是通過LogLevel指令設置的，該指令默認設置的級別是error，即記錄稱得上錯誤的事件。有關該指令中允許設置的各種選項的完整清單，請參見http://www.apache.org/docs/mod/core.html#loglevel的Apache文檔。
大多數情況下，我們在日誌文件中見到的內容分屬兩類：文檔錯誤和CGI錯誤。但是，錯誤日誌中偶爾也會出現配置錯誤，另外還有前面提到的伺服器啟動和關閉信息。
二、文檔錯誤
文檔錯誤和伺服器應答中的400系列代碼相對應，最常見的就是404錯誤——Document Not Found（文檔沒有找到）。除了404錯誤以外，用戶身份驗證錯誤也是一種常見的錯誤。
404錯誤在用戶請求的資源（即URL）不存在時出現，它可能是由於用戶輸入的URL錯誤，或者由於伺服器上原來存在的文檔因故被刪除或移動。
順便說一下，按照Jakob Nielson的意見，在不提供重定向或者其他補救措施的情況下，我們永遠不應該移動或者刪除Web網站的任何資源。Nielson的更多文章，請參見http://www.zdnet.com/devhead/alertbox/。
當用戶不能打開伺服器上的文檔時，錯誤日誌中出現的記錄如下所示：
[Fri Aug 18 22:36:26 2000] [error]
[client 192.168.1.6] File does not exist:
/usr/local/apache/bugletdocs/Img/south-korea.gif
可以看到，正如訪問日誌access_log文件一樣，錯誤日誌記錄也分成多個項。
錯誤記錄的開頭是日期/時間標記，注意它們的格式和access_log中日期/時間的格式不同。access_log中的格式被稱為「標准英文格式」，這或許是歷史跟我們開的一個玩笑，但現在要改變它已經太遲了。
錯誤記錄的第二項是當前記錄的級別，它表明了問題的嚴重程度。這個級別信息可能是LogLevel指令的文檔中所列出的任一級別（參見前面LogLevel的鏈接），error級別處於warn級別和crit級別之間。404屬於error錯誤級別，這個級別表示確實遇到了問題，但伺服器還可以運行。
錯誤記錄的第三項表示用戶發出請求時所用的IP地址。
記錄的最後一項才是真正的錯誤信息。對於404錯誤，它還給出了完整路徑指示伺服器試圖訪問的文件。當我們料想某個文件應該在目標位置卻出現了404錯誤時，這個信息是非常有用的。此時產生這種錯誤的原因往往是由於伺服器配置錯誤、文件實際所處的虛擬主機和我們料想的不同，或者其他一些意料不到的情況。
由於用戶身份驗證問題而出現的錯誤記錄如下所示：
[Tue Apr 11 22:13:21 2000]
[error] [client 192.168.1.3] user rbowen@rcbowen.
com: authentication failure for "/cgi-bin/hirecareers/company.cgi":
password mismatch
注意，由於文檔錯誤是用戶請求的直接結果，因此它們在訪問日誌中也會有相應的記錄。
三、CGI錯誤
錯誤日誌最主要的用途或許是診斷行為異常的CGI程序。為了進一步分析和處理方便，CGI程序輸出到STDERR（Standard Error，標准錯誤設備）的所有內容都將直接進入錯誤日誌。這意味著，任何編寫良好的CGI程序，如果出現了問題，錯誤日誌就會告訴我們有關問題的詳細信息。
然而，把CGI程序錯誤輸出到錯誤日誌也有它的缺點，錯誤日誌中將出現許多沒有標准格式的內容，這使得用錯誤日誌自動分析程序從中分析出有用的信息變得相當困難。
下面是一個例子，它是調試Perl CGI代碼時，錯誤日誌中出現的一個錯誤記錄：
[Wed Jun 14 16:16:37 2000] [error] [client 192.168.1.3] Premature
end of script headers: /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi
Global symbol "$rv" requires explicit package name at
/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 81.
Global symbol "%details" requires explicit package name at
/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 84.
Global symbol "$Config" requires explicit package name at
/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 133.
Execution of /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi
aborted e to compilation errors.
可以看到，CGI錯誤和前面的404錯誤格式相同，包含日期/時間、錯誤級別以及客戶地址、錯誤信息。但這個CGI錯誤的錯誤信息有好幾行，這往往會干擾一些錯誤日誌分析軟體的工作。
有了這個錯誤信息，即使是對Perl不太熟悉的人也能夠找出許多有關錯誤的信息，例如至少可以方便地得知是哪幾行代碼出現了問題。Perl在報告程序錯誤方面的機制是相當完善的。當然，不同的編程語言輸出到錯誤日誌的信息會有所不同。
由於CGI程序運行環境的特殊性，如果沒有錯誤日誌的幫助，大多數CGI程序的錯誤都將很難解決。
有不少人在郵件列表或者新聞組中抱怨說自己有一個CGI程序，當打開網頁時伺服器卻返回錯誤，比如「Internal Server Error」。我們可以肯定，這些人還沒有看過伺服器的錯誤日誌，或者根本不知道錯誤日誌的存在。決多大多數情況下，錯誤日誌能夠精確地指出CGI錯誤的所在以及如何修正這個錯誤。
四、查看日誌文件
我常常告訴別人說，在進行開發的同時我會不斷地檢查伺服器的日誌，以便能夠立即知道哪兒出了問題。但我得到的回答卻往往是沉默。起先我以為這種沉默意味著「你當然得這樣做」，後來我才發現這種沉默的真正含義是「我不知道別人的做法，但我自己是不幹的。」
雖然如此，下面我們還是要看看如何方便地查看伺服器日誌文件。用telnet連接到伺服器，然後輸入下面的命令：
tail -f /usr/local/apache/logs/error_log
該命令將顯示出日誌文件的最後幾行內容，如果有新的內容加入到日誌文件，它還會立即顯示出新加入的內容。
Windows用戶也同樣可以使用這種方法，比如可以使用各種為Windows提供的Unix工具軟體包。我個人愛好一個稱為AINTX的工具，它可以在http://maxx.mc.net/~jlh/nttools/index.htm找到。
還有一種替代方法是使用下面的Perl代碼，它利用了一個稱為File::Tail的模塊：
use File::Tail;
$file=File::Tail->new("/some/log/file");
while (defined($line=$file->read)) {
print "$line";
}
無論具體採用的是哪一種方法，同時打開多個終端窗口都是一種好習慣：比如在一個窗口中顯示錯誤日誌，在另一個窗口中顯示訪問日誌。這樣，我們就能夠隨時獲知網站上發生的事情並立即予以解決。轉載
❼ LVS負載均衡的總結
以上主要講述了LVS集群中的三種IP負載均衡技術。在分析網路地址轉換方法（VS/NAT）的缺點和網路服務的非對稱性的基礎上，我們給出了通過IP隧道實現虛擬伺服器的方法VS/TUN，和通過直接路由實現虛擬伺服器的方法VS/DR，極大地提高了系統的伸縮性。
❽ [已解決]LVS DR模式如何才能應用於UDP程序
求LVS DR UDP程序負載實例，謝謝
❾ 如何使用LVS構架負載均衡Linux集群系統
集群和負載均衡的區別如下：1、集群(Cluster)
所謂集群是指一組獨立的計算機系統構成的一個松耦合的多處理器系統,它們之間通過網路實現進程間的通信?應用程序可以通過網路共享內存進行消息傳送,實現分布式計算機?
2、負載均衡(Load Balance)
網路的負載均衡是一種動態均衡技術,通過一些工具實時地分析數據包,掌握網路中的數據流量狀況,把任務合理均衡地分配出去?這種技術基於現有網路結構,提供了一種擴展伺服器帶寬和增加伺服器吞吐量的廉價有效的方法,加強了網路數據處理能力,提高了網路的靈活性和可用性?
3、特點
(1)高可靠性(HA)?利用集群管理軟體,當主伺服器故障時,備份伺服器能夠自動接管主伺服器的工作,並及時切換過去,以實現對用戶的不間斷服務?
(2)高性能計算(HP)?即充分利用集群中的每一台計算機的資源,實現復雜運算的並行處理,通常用於科學計算領域,比如基因分析?化學分析等?
(3)負載平衡?即把負載壓力根據某種演算法合理分配到集群中的每一台計算機上,以減輕主伺服器的壓力,降低對主伺服器的硬體和軟體要求?
LVS系統結構與特點
1. Linux Virtual Server:簡稱LVS?是由中國一個Linux程序員章文嵩博士發起和領導的,基於Linux系統的伺服器集群解決方案,其實現目標是創建一個具有良好的擴展性?高可靠性?高性能和高可用性的體系?許多商業的集群產品,比如RedHat的Piranha? Turbo Linux公司的Turbo Cluster等,都是基於LVS的核心代碼的?
2. 體系結構:使用LVS架設的伺服器集群系統從體系結構上看是透明的,最終用戶只感覺到一個虛擬伺服器?物理伺服器之間可以通過高速的 LAN或分布在各地的WAN相連?最前端是負載均衡器,它負責將各種服務請求分發給後面的物理伺服器,讓整個集群表現得像一個服務於同一IP地址的虛擬伺服器?
3. LVS的三種模式工作原理和優缺點: Linux Virtual Server主要是在負載均衡器上實現的,負載均衡器是一台加了 LVS Patch的2.2.x版內核的Linux系統?LVS Patch可以通過重新編譯內核的方法加入內核,也可以當作一個動態的模塊插入現在的內核中?