解說基于開源負載均衡的工作原理（負載均衡實現原理）

概要

負載均衡是對多臺業務服務器進行流量分發的負載均衡服務,可以通過流量分發擴展應用系統對外的服務能力,通過消除單點故障提升應用系統的可用性，是構建集群的核心，例如Web集群、數據庫集群、分布式緩存服務器集群等，負載均衡通常為四層（TCP/UDP），七層（HTTPS/HTTP）.

一、 負載均衡架構示意圖：

1.1、 下面將以Web服務器集群來討論負載均衡工作原理

在實際生產環境，Web應用集群的上層會部署負載一套負載均衡服務器（通常為高可用模式，常用的高可用組件keepalive，Heartbeat等），負載均衡的任務是作為web服務器流量的入口，負載均衡根據設置的輪詢計算模式選擇一臺后端WebServer，將客戶端請求轉發到指定的服務器進行處理，實現Client與Server端的透明轉發。

1.1.1、 Nginx、Lvs、 Haproxy是目前使用最廣泛的開源負載均衡軟件。

1、 Nginx：專為性能優化而開發，Nginx在反向代理、Rewrite規則、穩定性、靜態文件處理，內存消耗等方面，有很強的優勢，使用Nginx取代傳統的Apache服務器，會得到多方面的性能提升,官方測試報告表明能支持高達 50,000個并發連接數。（目前1.11以后支持UDP負載均衡）

2、HAProxy 是一款提供高可用性、負載均衡以及基于TCP（第四層）和HTTP（第七層）應用的代理軟件，支持虛擬主機，它是免費、快速并且可靠的一種解決方案。 HAProxy特別適用于那些負載特大的web站點，這些站點通常又需要會話保持或七層處理。HAProxy運行在時下的硬件上，完全可以支持數以萬計的 并發連接。并且它的運行模式使得它可以很簡單安全的整合進您當前的架構中， 同時可以保護你的web服務器不被暴露到網絡上。

3、LVS工作在四層，可以實現高性能，高可用的服務器集群技術。它易用，配置非常簡單，且有多種負載均衡的方法。其性能接近硬件負載均衡F5設備。

一般對負載均衡的使用是隨著網站規模的提升根據不同的階段來使用不同的技術。具體的應用需求還得具體分析，如果是中小型的 Web 應用，

比如日 PV 小于1000萬，用 Nginx 就完全可以了；如果機器不少，可以用 DNS 輪詢，LVS 所耗費的機器還是比較多的；大型網站或重要的服

務，且服務器比較多時，可以考慮用 LVS。

1.1.2、目前網站架構一般比較通用流行的架構方案：

1.? Web 前端采用 Nginx/HAProxy+Keepalived 作負載均衡器

2.? 后端數據庫采用 MySQL數據庫一主多從和讀寫分離，采用 LVS+Keepalived 的架構。（MySQL自帶主從設置，如何理解用LVS？）

1.1.3、LVS簡述：

LVS 是 Linux Virtual Server 的簡稱，也就是 Linux 虛擬服務器。現在 LVS 已經是 Linux 標準內核的一部分，從 Linux2.4 內核以后，

已經完全內置了 LVS 的各個功能模塊，無需給內核打任何補丁，可以直接使用 LVS 提供的各種功能。

1.1.4、LVS體系架構：

1.1.5、LVS結構：

1. 負載調度器(Load Blancer):是整個LVS集群對外的前端機器，負責敬愛嗯client的請求發送到一組服務器【多臺 LB IP】上執行，

而client則認為返回來是同一個IP(通常把這個IP成為虛擬ip或VIP)

2. 服務器池(server pool):一組真正執行clinet請求的服務器，一般是web服務器；除了web，還有FTP、MAIL、DNS等

3. 共享存儲(shared stord):它為server pool提供了一個共享的存儲區，很容易讓服務器池擁有相同的內容，提供相同的服務

1.1.6、LVS負載均衡工作原理

1. LVS DR模式

LVS DR原理：

用戶請求LVS到達director，director將請求的報文的目的MAC地址改為后端的realserver的MAC地址，目的IP為VIP(不變)，源IP為client IP地址(不變)，然后director將報文發送到realserver，realserver檢測到目的地址為自己本地的VIP，如果在同一網段，將請求直接返回給用戶，如果用戶跟realserver不在同一個網段，則需要通過網關返回給用戶。

LVS DR特性：

前端路由將目標地址為VIP報文統統發給Director Server

RS跟Director Server必須有一個網卡在同一個物理網絡中

所有的請求報文經由Director Server，但響應報文必須不能進過Director Server

所有的real server機器上都有VIP地址

2. LVS NAT模式

LVS NAT原理：

用戶請求LVS到達director，director將請求的報文的目的IP改為RIP，同時將報文的目標端口也改為realserver的相應端口，最后將報文發送到realserver上，realserver將數據返回給director，director再把數據發送給用戶

LVS NAT特性：

NAT模式修改的是目的ip，直接走的是switch不需要修改mac地址，所以VIP和RIP不需要在同一個網段內

NAT的包的進出都需要經過LVS，所以LVS可能會成為一個系統的瓶頸問題

3.? LVS TUN模式：

LVS TUN原理：

用戶請求LVS到達director，director通過IP-TUN加密技術將請求報文的包封裝到一個新的IP包里面，目的IP為VIP(不變)，然后director將報文發送到realserver，realserver基于IP-TUN解密，然后解析出來包的目的為VIP，檢測網卡是否綁定了VIP，綁定了就處理這個包，如果在同一個網段，將請求直接返回給用戶，否則通過網關返回給用戶；如果沒有綁定VIP就直接丟掉這個包

LVS TUN特性：

1. TUNNEL必須在所有的realserver上綁定VIP

2. realserver直接把包發給client

3. 隧道模式運維起來會比較難，所以一般不用

1.1.7、 LVS模式比較（此處我們這邊只針對以上三種模式進行比較，不針對FULLNAT模式進行介紹）

1. 是否需要VIP和realserver在同一網段，DR模式因為只修改包的MAC地址，需要通過ARP廣播找到realserver，

所以VIP和realserver必須在同一個網段，也就是說DR模式需要先確認這個IP是否只能掛在這個LVS下面；其他

模式因為都會修改目的地址為realserver的IP地址，所以不需要在同一個網段內。

2. 是否需要在realserver上綁定VIP，realserver在收到包之后會判斷目的地址是否

是自己的IP，DR模式的目的地址沒有修改，還是VIP，所以需要在realserver上綁定VIP

IP TUN模式值是對包重新包裝了一層，realserver解析后的包的IP仍然是VIP，所以也需要在realserver上綁定VIP

3. 四種模式的性能比較

DR模式、IP TUN模式都是在包進入的時候經過LVS，在包返回的時候直接返回給client；所以二者的性能比NAT高

但TUN模式更加復雜，所以性能不如DR

注：FULLNAT模式不僅更換目的IP還更換了源IP，所以性能比NAT下降10%（故生產環境也很少使用該模式）在此不做介紹

性能比較：DR>TUN>NAT>FULLNAT

1.1.8、LVS負載均衡算法

1. 輪叫調度 rr

均等地對待每一臺服務器，不管服務器上的實際連接數和系統負載

2. 加權輪叫 wrr

調度器可以自動問詢真實服務器的負載情況，并動態調整權值

3. 最少鏈接 lc

動態地將網絡請求調度到已建立的連接數最少的服務器上

如果集群真實的服務器具有相近的系統性能，采用該算法可以較好的實現負載均衡

4. 加權最少鏈接 wlc

調度器可以自動問詢真實服務器的負載情況，并動態調整權值

帶權重的誰不干活就給誰分配，機器配置好的權重高

5. 基于局部性的最少連接調度算法 lblc

這個算法是請求數據包的目標 IP 地址的一種調度算法，該算法先根據請求的目標 IP 地址尋找最近的該目標 IP 地址所有使用的服務器，

如果這臺服務器依然可用，并且有能力處理該請求，調度器會盡量選擇相同的服務器，否則會繼續選擇其它可行的服務器

6. 復雜的基于局部性最少的連接算法 lblcr

記錄的不是要給目標 IP 與一臺服務器之間的連接記錄，它會維護一個目標 IP 到一組服務器之間的映射關系，防止單點服務器負載過高。

7. 目標地址散列調度算法 dh

該算法是根據目標 IP 地址通過散列函數將目標 IP 與服務器建立映射關系，出現服務器不可用或負載過高的情況下，發往該目標 IP 的請求會固定發給該服務器。

8. 源地址散列調度算法 sh

與目標地址散列調度算法類似，但它是根據源地址散列算法進行靜態分配固定的服務器資源。

9. 最少期望延遲 sed

不考慮非活動鏈接，誰的權重大，優先選擇權重大的服務器來接收請求，但權重大的機器會比較忙

10. 永不排隊 nq

無需隊列，如果有realserver的連接數為0就直接分配過去

1.1.9、 LVS 的優點

1. 抗負載能力強、工作在傳輸層上僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟件里的性能最強的，對內存和 cpu 資源消耗

比較低。

2. 配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以并不需要太多接觸，大大減少了人為出錯的幾率。

3. 工作穩定，因為其本身抗負載能力很強，自身有完整的雙機熱備方案，如 LVS+Keepalived。

4. 無流量，LVS 只分發請求，而流量并不從它本身出去，這點保證了均衡器 IO 的性能不會受到大流量的影響。

5. 應用范圍比較廣，因為 LVS 工作在傳輸層，所以它幾乎可以對所有應用做負載均衡，包括 http、數據庫、在線聊天室等等。

1.1.10、LVS 的缺點

1. 軟件本身不支持正則表達式處理，不能做動靜分離；而現在許多網站在這方面都有較強的需求，這個是 Nginx、HAProxy+Keepalived

的優勢所在。

2. 如果是網站應用比較龐大的話，LVS/DR+Keepalived 實施起來就比較復雜了，相對而言，Nginx/HAProxy+Keepalived就簡單多了

2.1、Nginx簡述：

Nginx 是一個強大的 Web 服務器軟件，用于處理高并發的 HTTP 請求和作為反向代理服務器做負載均衡。具有高性能、輕量級、內存消耗少，強大的負載均衡能力等優勢。

2.1.1、Nginx架構設計

Nginx服務器啟動后，產生一個主進程（master process），主進程執行一系列工作后產生一個或者多個工作進程（worker processes)。主進程主要進行Nginx配置文件解析、數據結構初始化、模塊配置和注冊、信號處理、網絡監聽生成、工作進程主要進行進程初始化、模塊調用和請求處理等工作，是Nginx服務器提供服務的主體。

在客戶端請求動態站點的過程中，Nginx服務器還涉及和后端服務器的通信。Nginx服務器還涉及和后端服務器的通信。Nginx服務器將接收到的Web請求通過代理轉發到后端服務器，由后端服務器進行數據處理和頁面組織，然后將結果返回。

另外，Nginx服務器為了提高對請求的響應效率，進一步降低網絡壓力，采用了緩存機制，將歷史應答數據緩存到本地。在每次Nginx服務器啟動后的一段時間內，會啟動專門的進程對本地緩存的內容重建索引，保證對緩存文件的快速訪問。

根據上面的分析，我們可以將Nginx服務器的結構大致分為主進程、工作進程、后端服務器和緩存等部分。

Nginx架構設計圖

Nginx常用部署架構

2.1.2、Nginx 負載均衡模式

Nginx 負載均衡主要是對四層、七層網絡通信模型中的四層（TCP/UDP(1.11以上)）/七層應用層上的 http、https 進行支持。

Nginx 是以反向代理的方式進行負載均衡的。反向代理（Reverse Proxy）方式是指以代理服務器來接受 Internet 上的連接請求，然后將請求轉發給內部網絡上的服務器，并將從服務器上得到的結果返回給 Internet 上請求連接的客戶端，此時代理服務器對外就表現為一個服務器。

Nginx 實現負載均衡的分配策略有很多，Nginx 的 upstream 目前支持以下幾種方式：

輪詢（默認）：每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器 down 掉，能自動剔除。

weight：指定輪詢幾率，weight 和訪問比率成正比，用于后端服務器性能不均的情況。

ip_hash：每個請求按訪問 ip 的 hash 結果分配，這樣每個訪客固定訪問一個后端服務器，可以解決 session 的問題。

fair（第三方）：按后端服務器的響應時間來分配請求，響應時間短的優先分配。

url_hash（第三方）：按訪問 url 的 hash 結果來分配請求，使每個 url 定向到同一個后端服務器，后端服務器為緩存時比較有效。

2.1.3、Nginx 的優點

跨平臺：Nginx 可以在大多數 Unix like OS編譯運行，而且也有 Windows 的移植版本

配置異常簡單：非常容易上手。配置風格跟程序開發一樣，神一般的配置

非阻塞、高并發連接：官方測試能夠支撐5萬并發連接，在實際生產環境中跑到2～3萬并發連接數

事件驅動：通信機制采用 epoll 模型，支持更大的并發連接

Master/Worker 結構：一個 master 進程，生成一個或多個 worker 進程

內存消耗小：處理大并發的請求內存消耗非常小。在3萬并發連接下，開啟的10個 Nginx 進程才消耗150M 內存（15M*10=150M）

內置的健康檢查功能：如果 Nginx 代理的后端的某臺 Web 服務器宕機了，不會影響前端訪問

節省帶寬：支持 GZIP 壓縮，可以添加瀏覽器本地緩存的 Header 頭

穩定性高：用于反向代理，宕機的概率微乎其微

2.1.4、Nginx 的缺點

對后端服務器的健康檢查，只支持通過端口來檢測，不支持通過 ur l來檢測。

不支持 Session 的直接保持，但能通過 ip_hash 來解決

3.1、 Haproxy簡述

HAProxy 是一款提供高可用性、負載均衡以及基于TCP（第四層）和HTTP（第七層）應用的代理軟件，支持虛擬主機，它是免費、快速并且可靠的一種解決方案。 HAProxy特別適用于那些負載特大的web站點，這些站點通常又需要會話保持或七層處理。HAProxy運行在時下的硬件上，完全可以支持數以萬計的 并發連接。并且它的運行模式使得它可以很簡單安全的整合進您當前的架構中， 同時可以保護你的web服務器不被暴露到網絡上。

HAProxy 實現了一種事件驅動、單一進程模型，此模型支持非常大的并發連接數。多進程或多線程模型受內存限制 、系統調度器限制以及無處不在的鎖限制，很少能處理數千并發連接。事件驅動模型因為在有更好的資源和時間管理的用戶端(User-Space) 實現所有這些任務，所以沒有這些問題。此模型的弊端是，在多核系統上，這些程序通常擴展性較差。這就是為什么他們必須進行優化以 使每個CPU時間片(Cycle)做更多的工作。

HAProxy 支持連接拒絕 : 因為維護一個連接的打開的開銷是很低的，有時我們很需要限制攻擊蠕蟲（attack bots），也就是說限制它們的連接打開從而限制它們的危害。 這個已經為一個陷于小型DDoS攻擊的網站開發了而且已經拯救了很多站點，這個優點也是其它負載均衡器沒有的。

HAProxy 支持全透明代理（已具備硬件防火墻的典型特點）: 可以用客戶端IP地址或者任何其他地址來連接后端服務器. 這個特性僅在Linux 2.4/2.6內核打了cttproxy補丁后才可以使用. 這個特性也使得為某特殊服務器處理部分流量同時又不修改服務器的地址成為可能。

3.1.1、 性能

HAProxy借助于OS上幾種常見的技術來實現性能的最大化。

單進程、事件驅動模型顯著降低了上下文切換的開銷及內存占用。

O(1)事件檢查器(event checker)允許其在高并發連接中對任何連接的任何事件實現即時探測。

在任何可用的情況下，單緩沖(single buffering)機制能以不復制任何數據的方式完成讀寫操作，這會節約大量的CPU時鐘周期及內存帶寬；

借助于Linux 2.6 (>= 2.6.27.19)上的splice()系統調用，HAProxy可以實現零復制轉發(Zero-copy forwarding)，在Linux 3.5及以上的OS中還可以實現零復制啟動(zero-starting)；

內存分配器在固定大小的內存池中可實現即時內存分配，這能夠顯著減少創建一個會話的時長；

優化的HTTP首部分析：優化的首部分析功能避免了在HTTP首部分析過程中重讀任何內存區域；

精心地降低了昂貴的系統調用，大部分工作都在用戶空間完成，如時間讀取、緩沖聚合及文件描述符的啟用和禁用等；

所有的這些細微之處的優化實現了在中等規模負載之上依然有著相當低的CPU負載，甚至于在非常高的負載場景中，5%的用戶空間占用率和95%的系統空間占用率也是非常普遍的現象，這意味著HAProxy進程消耗比系統空間消耗低20倍以上。因此，對OS進行性能調優是非常重要的。即使用戶空間的占用率提高一倍，其CPU占用率也僅為10%，這也解釋了為何7層處理對性能影響有限這一現象。由此，在高端系統上HAProxy的7層性能可輕易超過硬件負載均衡設備。

在生產環境中，在7層處理上使用HAProxy作為昂貴的高端硬件負載均衡設備故障故障時的緊急解決方案也時長可見。硬件負載均衡設備在“報文”級別處理請求，這在支持跨報文請求(request across multiple packets)有著較高的難度，并且它們不緩沖任何數據，因此有著較長的響應時間。對應地，軟件負載均衡設備使用TCP緩沖，可建立極長的請求，且有著較大的響應時間。

3.1.2、Haproxy調度算法

roundrobin

基于權重進行輪叫，在服務器的處理時間保持均勻分布時，這是最平衡、最公平的算法。此算法是動態的，這表示其權重可以在運行時進行調整，不過，在設計上，每個后端服務器僅能最多接受4128個連接

static-rr

基于權重進行輪叫，與roundrobin類似，但是為靜態方法，在運行時調整其服務器權重不會生效；不過，其在后端服務器連接數上沒有限制

leastconn

新的連接請求被派發至具有最少連接數目的后端服務器；在有著較長時間會話的場景中推薦使用此算法，如LDAP、SQL等，其并不太適用于較短會話的應用層協議，如HTTP；此算法是動態的，可以在運行時調整其權重

source

將請求的源地址進行hash運算，并由后端服務器的權重總數相除后派發至某匹配的服務器；這可以使得同一個客戶端IP的請求始終被派發至某特定的服務器；不過，當服務器權重總數發生變化時，如某服務器宕機或添加了新的服務器，許多客戶端的請求可能會被派發至與此前請求不同的服務器；常用于負載均衡無cookie功能的基于TCP的協議；其默認為靜態，不過也可以使用hash-type修改此特性

uri

對URI的左半部分(“問題”標記之前的部分)或整個URI進行hash運算，并由服務器的總權重相除后派發至某匹配的服務器；這可以使得對同一個URI的請求總是被派發至某特定的服務器，除非服務器的權重總數發生了變化；此算法常用于代理緩存或反病毒代理以提高緩存的命中率；需要注意的是，此算法僅應用于HTTP后端服務器場景；其默認為靜態算法，不過也可以使用hash-type修改此特性

uri-param

通過為URL指定的參數在每個HTTP GET請求中將會被檢索；如果找到了指定的參數且其通過等于號“=”被賦予了一個值，那么此值將被執行hash運算并被服務器的總權重相除后派發至某匹配的服務器；此算法可以通過追蹤請求中的用戶標識進而確保同一個用戶ID的請求將被送往同一個特定的服務器，除非服務器的總權重發生了變化；如果某請求中沒有出現指定的參數或其沒有有效值，則使用輪叫算法對相應請求進行調度；此算法默認為靜態的，不過其也可以使用hash-type修改此特性

hdr(name)

對于每個HTTP請求，通過指定的HTTP首部將會被檢索；如果相應的首部沒有出現或其沒有有效值，則使用輪叫算法對相應請求進行調度；其有一個可選選項“use_domain_only”，可在指定檢索類似Host類的首部時僅計算域名部分(比如通過www.jinjianginns.com來說，僅計算jinjianginns字符串的hash值)以降低hash算法的運算量；此算法默認為靜態的，不過其也可以使用hash-type修改此特性

rdp-cookie(name)

表示根據據 cookie(name)來鎖定并哈希每一次 TCP 請求。

3.1.3、Haproxy優點

支持8中負載均衡算法，同時也支持session會話保持

可靠性和穩定性可以硬件級的F5相媲美

最高可以同時處理40000~50000個并發連接，單位時間內處理最大的請求出可達20000個

Haproxy是基于第三方應用實現的負載均衡，工作四層和七層的負載均衡軟件，可以實現tcp和http應用的負載均衡解決方案

在狀態檢測方面功能強大，可支持端口，url以及腳本等多種狀態檢測方式

3.1.4、 Haproxy缺點

haproxy安裝簡單，但是配置復雜

整體處理能力要低于四層負載均衡的LVS，和lvs相比，lvs擁有接近硬件設備的網絡吞吐量和連接負載能力

4

4.1、 Keepalive簡述：

Keepalived的作用是檢測web服務器的狀態，如果有一臺web服務器死機，或工作出現故障，Keepalived將檢測到，并將有故障的web服務器從系統中剔除，當web服務器工作正常后Keepalived自動將web服務器加入到服務器群中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復故障的web服務器。

Keepalived軟件起初是專為LVS負載均衡軟件設計的，用來管理并監控LVS集群系統中各個服務節點的狀態，后來又加入了可以實現高可用的VRRP功能。因此，Keepalived除了能夠管理LVS軟件外，還可以作為其他服務（例如：Nginx、Haproxy、MySQL等）的高可用解決方案軟件。

Keepalived采用模塊化設計，不同模塊實現不同的功能

Keepalivd主要有三個模塊，分別是core，check，vrrp

core：是Keepalived的核心，負責主進程的啟動和維護，全局配置文件的加載解析等

check：負責healthchecker（健康檢查）

vrpp：VRRPD子進程，VRRPD子進程就是來實現VRRP協議的

4.1.1、 Keepalive工作原理：

通過vrrp協議廣播，每個keepalived vrrp都去爭取master

以virtual_router_id為組隊標識。 ?同為一個vip服務的keepalived的virtual_router_id相同

以priority 為權值，同一個virtual_router_id下那個priority大那個就是master,其它為backup

在Keepalived服務正常工作時，主master節點會不斷的向備節點發送心跳信息，用來告訴備Backup節點自己還活著，當主master節點發生故障時候，就無法發送心跳信息了，備節點也就因此無法繼續檢測到來自主 Master節點的心跳了，于是調用自身的接管程序，接管主Master節點的 IP資源及服務。而當主 Master節點恢復時，備Backup節點又會釋放主節點故障時自身接管的IP資源及服務，恢復到原來的備用角色。

4.1.2、 keeplive腦裂與解決思路：

keepalive產生腦裂有以下幾種原因：

高可用服務器對之間心跳線鏈路發生故障，導致無法正常通信。

心跳線壞了（包括斷了，老化）。

網卡及相關驅動壞了，ip配置及沖突問題（網卡直連）。

心跳線間連接的設備故障（網卡及交換機）。

仲裁的機器出問題（采用仲裁的方案）。

高可用服務器上開啟了 iptables防火墻阻擋了心跳消息傳輸。

高可用服務器上心跳網卡地址等信息配置不正確，導致發送心跳失敗。

其他服務配置不當等原因，如心跳方式不同，心跳廣插沖突、軟件Bug等。

Keepalived配置里VRRP實例如果 virtual_router_id兩端參數配置不一致也會導致裂腦問題發生。

keepalive解決腦裂思路：

同時使用串行電纜和以太網電纜連接，同時用兩條心跳線路，這樣一條線路壞了，另一個還是好的，依然能傳送心跳消息。

當檢測到裂腦時強行關閉一個心跳節點（這個功能需特殊設備支持，如Stonith、feyce）。相當于備節點接收不到心跳消患，通過單獨的線路發送關機命令關閉主節點的電源。

做好對裂腦的監控報警（如郵件及手機短信等或值班）.在問題發生時人為第一時間介入仲裁，降低損失。

管理員可以通過手機回復對應數字或簡單的字符串操作返回給服務器.讓服務器根據指令自動處理相應故障這樣解決故障的時間更短。

4.1.3 當前keepalive與Nginx的Web架構，Keepalive與Mysql架構示例比較常用如下：

基于keepalive與Nginx的web架構

常用的基于keepalive高可用的Mysql主從架構

負載均衡緩存 Nginx

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。