最初的理解
(也可以每個nginx都掛在上所有的應用服務器)
nginx大家都在用，估計也很熟悉了，在做負載均衡時很好用，安裝簡單、配置簡單、相關材料也特別多。
lvs是國內的章文嵩博士的大作，比nginx被廣泛接受還要早7年，並且已經被紅帽作為了系統內置軟件，可謂很牛了。lvs相對於nginx來說配置上就要相對復雜一些。
但是，有時候我們會看到大牛們分享的經驗里面是lvs+nginx作為負載均衡了，一直想不明白這是個什么道理。
為什么會出現兩者被同時使用呢？其實，這要從兩者的各自優勢來說了。
nginx用來做http的反向代理，能夠upsteam實現http請求的多種方式的均衡轉發。由於采用的是異步轉發可以做到如果一個服務器請求失敗，立即切換到其他服務器，直到請求成功或者最后一台服務器失敗為止。這可以最大程度的提高系統的請求成功率。
lvs采用的是同步請求轉發的策略。這里說一下同步轉發和異步轉發的區別。同步轉發是在lvs服務器接收到請求之后，立即redirect到一個后端服務器，由客戶端直接和后端服務器建立連接。異步轉發是nginx在保持客戶端連接的同時，發起一個相同內容的新請求到后端，等后端返回結果后，由nginx返回給客戶端。
進一步來說：當做為負載均衡服務器的nginx和lvs處理相同的請求時，所有的請求和響應流量都會經過nginx；但是使用lvs時，僅請求流量經過lvs的網絡，響應流量由后端服務器的網絡返回。
也就是，當作為后端的服務器規模龐大時，nginx的網絡帶寬就成了一個巨大的瓶頸。
但是僅僅使用lvs作為負載均衡的話，一旦后端接受到請求的服務器出了問題，那么這次請求就失敗了。但是如果在lvs的后端在添加一層nginx（多個），每個nginx后端再有幾台應用服務器，那么結合兩者的優勢，既能避免單nginx的流量集中瓶頸，又能避免單lvs時一錘子買賣的問題。
參考文章：
章文嵩：LVS項目介紹
moon：強大的nginx反向代理異步傳輸模式（原理）
yaoweibin:nginx健康檢查
追馬博客：LVS+keepalived+nginx+tomcat部署實現
補充（20160731 下午2：07）：
在后續繼續了解這部分內容時，發現了這兩個帖子：
1. 有了LVS，還要apache，nginx有什么用？
2.從一個開發的角度看負載均衡和LVS—–注意看最后一個lvs集群化的圖，nginx和rs是一對一連接的。
從以上文章來看，lvs+nginx組合使用的原因主要是用lvs來做負載均衡（因為工作在4層，效率高），nginx來做靜態文件的處理。
這里第二篇文章，和lvs的后續維護者之一的[吳佳明_普空的ppt](http://velocity.oreilly.com.cn/2012/ppts/pukong.pdf
)中比章博士的文章中多出了一種轉發模式，也就是full_nat模式，這種模式下，所有的響應也要經過lvs服務器作為出口返回給客戶端。
lvs在full_nat的模式下，是否還是同步的模式呢？我猜想應該是的，因為lvs工作在4層，所以可能當前出錯的響應要映射到之前的那一次請求（因為沒有解析http包），所以也就做不到把錯誤轉發到其他的應用服務器上重新處理。
另外，這個補充是不是就完全的否定了昨天（也就是補充之前的那一大段）的內容呢？我覺得並沒有。昨天的理解可能不是正規大型互聯網在使用的模式（當然，這里我不能確定，因為我沒有大型互聯網的經驗），但是理論應該是對的。
具體一點，lvs+nginx的組合nginx用來做靜態文件的處理的場景下，如果一次請求失敗了，那么久不能被重新處理了，當然你的nginx也可以后掛1個以上的應用服務器（這樣的話nginx實質上也是起到了lvs均衡補充的效果）。另外就是，nginx不是單單的作為靜態文件的處理，而是作為lvs的一個補充，互相彌補均衡上的不足。
那么你可能會說lvs在4層上處理的高效就不復存在了，確實是的，這點要承認，但是，我們提高了系統請求的成功率，兩者需要各自去選擇和權衡。
另外，需要說的一點是，靜態內容其實我們還可以借助cdn去處理，而不是單單的依靠nginx或者apache去處理。
補充（2016年12月17日 上午11：24）
現在到了比較大一些的互聯網公司，也看了京東的用法（可以看開濤的nginx+lua系列http://www.iteye.com/blogs/subjects/nginx-lua）。
lvs+nginx的使用中，nginx還可以作為一個中間環節來減小后端tomcat的服務壓力，以及做一些業務切換、分流、前置緩存的功能。
來源：http://blog.csdn.net/BuquTianya/article/details/52076153