隨著移動互聯網的加速，應用大規模同時使用的情況成為了常態，如微博、知乎、今日頭條等大型應用，作為Linux運維從業者，高并發場景的解決能力成為了高薪的關鍵。

今天我們特別邀請了資深的Linux運維老司機慘綠少年Linux來給大家普及高并發場景 LVS的實現過程，助你高薪之路順暢。

1.1負載均衡介紹

1.1.1負載均衡的妙用

負載均衡（Load Balance）集群提供了一種廉價、有效、透明的方法，來擴展網絡設備和服務器的負載、帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。

單臺計算機無法承受大規模的并發訪問或數據流量了，此時需要搭建負載均衡集群把流量分攤到多臺節點設備上分別處理，即減少用戶等待響應的時間又提升了用戶體驗；

7*24小時的服務保證，任意一個或多個有限后端節點設備宕機，不能影響整個業務的運行。

1.1.2為什么要用lvs

工作在網絡模型的7層，可以針對http應用做一些分流的策略，比如針對域名、目錄結構，Nginx單憑這點可利用的場合就遠多于LVS了。

最新版本的Nginx也支持4層TCP負載，曾經這是LVS比Nginx好的地方。

Nginx對網絡穩定性的依賴非常小，理論上能ping通就就能進行負載功能，這個也是它的優勢之一，相反LVS對網絡穩定性依賴比較大。

Nginx安裝和配置比較簡單，測試起來比較方便，它基本能把錯誤用日志打印出來。LVS的配置、測試就要花比較長的時間了，LVS對網絡依賴比較大。

那為什么要用lvs呢？

簡單一句話，當并發超過了Nginx上限，就可以使用LVS了。

日1000-2000W PV或并發請求1萬以下都可以考慮用Nginx。

大型門戶網站，電商網站需要用到LVS。

1.2 LVS介紹

LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集群系統，可以在UNIX/LINUX平臺下實現負載均衡集群功能。該項目在1998年5月由章文嵩博士組織成立，是中國國內最早出現的自由軟件項目之一。

1.2.1相關參考資料

LVS官網：http://www.linuxvirtualserver.org/index.html

相關中文資料

LVS項目介紹 http://www.linuxvirtualserver.org/zh/lvs1.html

LVS集群的體系結構 http://www.linuxvirtualserver.org/zh/lvs2.html

LVS集群中的IP負載均衡技術 http://www.linuxvirtualserver.org/zh/lvs3.html

LVS集群的負載調度 http://www.linuxvirtualserver.org/zh/lvs4.html

1.2.2 LVS內核模塊ip_vs介紹

早在2.2內核時，IPVS就已經以內核補丁的形式出現。

從2.4.23版本開始，IPVS軟件就合并到Linux內核的常用版本的內核補丁的集合。

從2.4.24以后IPVS已經成為Linux官方標準內核的一部分。

LVS無需安裝

安裝的是管理工具，第一種叫ipvsadm，第二種叫keepalive

ipvsadm是通過命令行管理，而keepalive讀取配置文件管理

后面我們會用Shell腳本實現keepalive的功能

1.3 LVS集群搭建

1.3.1集群環境說明

主機說明

[root@lb03 ~]# cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core) [root@lb03 ~]# uname -aLinux lb03 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux[root@lb03 ~]# systemctl status firewalld.service ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1)[root@lb03 ~]# getenforce Disabled

web環境說明

[root@lb03 ~]# curl 10.0.0.17web03[root@lb03 ~]# curl 10.0.0.18web04

web服務器的搭建參照：

Tomcat：http://www.cnblogs.com/clsn/p/7904611.html

Nginx：http://www.cnblogs.com/clsn/p/7750615.html

1.3.2安裝ipvsadm管理工具

安裝管理工具

yum -y install ipvsadm

查看當前LVS狀態，順便激活LVS內核模塊。

ipvsadm

查看系統的LVS模塊。

[root@lb03 ~]# lsmod|grep ip_vsip_vs_wrr 12697 1ip_vs 141092 3 ip_vs_wrrnf_conntrack 133387 1 ip_vslibcrc32c 12644 3 xfs,ip_vs,nf_conntrack

1.3.3 LVS集群搭建

配置LVS負載均衡服務（在lb03操作）

步驟1：在eth0網卡綁定VIP地址（ip）

步驟2：清除當前所有LVS規則（-C）

步驟3：設置tcp、tcpfin、udp鏈接超時時間（--set）

步驟4：添加虛擬服務（-A），-t指定虛擬服務的IP端口，-s指定調度算法調度算法見man ipvsadm，rr wrr權重輪詢-p指定超時時間

步驟5：將虛擬服務關聯到真實服務上（-a）-r指定真實服務的IP端口-g LVS的模式DR模式-w指定權重

步驟6：查看配置結果（-ln）

命令集：

ip addr add 10.0.0.13/24 dev eth0ipvsadm -C ipvsadm --set 30 5 60 ipvsadm -A -t 10.0.0.13:80 -s wrr -p 20 ipvsadm -a -t 10.0.0.13:80 -r 10.0.0.17:80 -g -w 1 ipvsadm -a -t 10.0.0.13:80 -r 10.0.0.18:80 -g -w 1ipvsadm -ln

檢查結果：

[root@lb03 ~]# ipvsadm -lnIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 10.0.0.13:80 wrr persistent 20 -> 10.0.0.17:80 Route 1 0 0 -> 10.0.0.18:80 Route 1 0 0

ipvsadm參數說明：(更多參照man ipvsadm)

1.3.4在web瀏覽器配置操作

步驟1：在lo網卡綁定VIP地址（ip）

步驟2：修改內核參數抑制ARP響應

命令集：

ip addr add 10.0.0.13/32 dev locat >>/etc/sysctl.conf<

至此LVS集群配置完畢！

1.3.5進行訪問測試

瀏覽器訪問：

命令行測試：

[root@lb04 ~]# curl 10.0.0.13web03

抓包查看結果：

arp解析查看：

[root@lb04 ~]# arp -nAddress HWtype HWaddress Flags Mask Iface10.0.0.254 ether 00:50:56:e9:9f:2c C eth010.0.0.18 ether 00:0c:29:ea:ca:55 C eth010.0.0.13 ether 00:0c:29:de:7c:97 C eth0172.16.1.15 ether 00:0c:29:de:7c:a1 C eth110.0.0.17 ether 00:0c:29:4a:ac:4a C eth0

1.4負載均衡（LVS）相關名詞

術語說明：

DS：Director Server。指的是前端負載均衡器節點。RS：Real Server。后端真實的工作服務器。VIP：向外部直接面向用戶請求，作為用戶請求的目標的IP地址。DIP：Director Server IP，主要用于和內部主機通訊的IP地址。RIP：Real Server IP，后端服務器的IP地址。CIP：Client IP，訪問客戶端的IP地址。

1.4.1 LVS集群的工作模式--DR直接路由模式

DR模式是通過改寫請求報文的目標MAC地址，將請求發給真實服務器的，而真實服務器將響應后的處理結果直接返回給客戶端用戶。

DR技術可極大地提高集群系統的伸縮性。但要求調度器LB與真實服務器RS都有一塊物理網卡連在同一物理網段上，即必須在同一局域網環境。

DR直接路由模式說明：

a)通過在調度器LB上修改數據包的目的MAC地址實現轉發。注意，源IP地址仍然是CIP，目的IP地址仍然是VIP。b)請求的報文經過調度器，而RS響應處理后的報文無需經過調度器LB，因此，并發訪問量大時使用效率很高，比Nginx代理模式強于此處。c)因DR模式是通過MAC地址的改寫機制實現轉發的，因此，所有RS節點和調度器LB只能在同一個局域網中。需要注意RS節點的VIP的綁定(lo:vip/32)和ARP抑制問題。d)強調下：RS節點的默認網關不需要是調度器LB的DIP，而應該直接是IDC機房分配的上級路由器的IP(這是RS帶有外網IP地址的情況)，理論上講，只要RS可以出網即可，不需要必須配置外網IP，但走自己的網關，那網關就成為瓶頸了。e)由于DR模式的調度器僅進行了目的MAC地址的改寫，因此，調度器LB無法改變請求報文的目的端口。LVS DR模式的辦公室在二層數據鏈路層（MAC），NAT模式則工作在三層網絡層（IP）和四層傳輸層（端口）。f)當前，調度器LB支持幾乎所有UNIX、Linux系統，但不支持windows系統。真實服務器RS節點可以是windows系統。g)總之，DR模式效率很高，但是配置也較麻煩。因此，訪問量不是特別大的公司可以用haproxy/Nginx取代之。這符合運維的原則：簡單、易用、高效。日1000-2000W PV或并發請求1萬以下都可以考慮用haproxy/Nginx(LVS的NAT模式)h)直接對外的訪問業務，例如web服務做RS節點，RS最好用公網IP地址。如果不直接對外的業務，例如：MySQL，存儲系統RS節點，最好只用內部IP地址。

DR的實現原理和數據包的改變

(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈(c) IPVS比對數據包請求的服務是否為集群服務，若是，將請求報文中的源MAC地址修改為DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，然后將數據包發至POSTROUTING鏈。 此時的源IP和目的IP均未修改，僅修改了源MAC地址為DIP的MAC地址，目標MAC地址為RIP的MAC地址(d) 由于DS和RS在同一個網絡中，所以是通過二層來傳輸。POSTROUTING鏈檢查目標MAC地址為RIP的MAC地址，那么此時數據包將會發至Real Server。(e) RS發現請求報文的MAC地址是自己的MAC地址，就接收此報文。處理完成之后，將響應報文通過lo接口傳送給eth0網卡然后向外發出。 此時的源IP地址為VIP，目標IP為CIP(f) 響應報文最終送達至客戶端

1.5在web端的操作有什么含義？

1.5.1 RealServer為什么要在lo接口上配置VIP？

既然要讓RS能夠處理目標地址為vip的IP包，首先必須要讓RS能接收到這個包。

在lo上配置vip能夠完成接收包并將結果返回client。

1.5.2在eth0網卡上配置VIP可以嗎？

不可以，將VIP設置在eth0網卡上,會影響RS的arp請求,造成整體LVS集群arp緩存表紊亂，以至于整個負載均衡集群都不能正常工作。

1.5.3為什么要抑制ARP響應？

①arp協議說明

ARP協議,全稱"Address Resolution Protocol",中文名是地址解析協議，使用ARP協議可實現通過IP地址獲得對應主機的物理地址(MAC地址)。

ARP協議要求通信的主機雙方必須在同一個物理網段（即局域網環境）！

為了提高IP轉換MAC的效率，系統會將解析結果保存下來，這個結果叫做ARP緩存。

Windows查看ARP緩存命令 arp -aLinux查看ARP緩存命令 arp -nLinux解析IP對應的MAC地址 arping -c 1 -I eth0 10.0.0.6

ARP緩存表是把雙刃劍

a)主機有了arp緩存表，可以加快ARP的解析速度，減少局域網內廣播風暴。因為arp是發廣播解析的，頻繁的解析也是消耗帶寬的，尤其是機器多的時候。

b)正是有了arp緩存表，給惡意黑客帶來了攻擊服務器主機的風險，這個就是arp欺騙攻擊。

c)切換路由器，負載均衡器等設備時，可能會導致短時網絡中斷。因為所有的客戶端ARP緩存表沒有更新

②服務器切換ARP問題

當集群中一臺提供服務的lb01機器宕機后，然后VIP會轉移到備機lb02上，但是客戶端的ARP緩存表的地址解析還是宕機的lb01的MAC地址。從而導致，即使在lb02上添加VIP，也會發生客戶端無法訪問的情況。

解決辦法是：當lb01宕機，VIP地址遷移到lb02時，需要通過arping命令通知所有網絡內機器更新本地的ARP緩存表，從而使得客戶機訪問時重新廣播獲取MAC地址。

這個是自己開發服務器高可用腳本及所有高可用軟件必須考慮到的問題。

ARP廣播進行新的地址解析

arping -I eth0 -c 1 -U VIParping -I eth0 -c 1 -U 10.0.0.13

測試命令

ip addr del 10.0.0.13/24 dev eth0ip addr add 10.0.0.13/24 dev eth0ip addr show eth0arping -I eth0 -c 1 -U 10.0.0.13

windows查看arp -a

接口: 10.0.0.1 --- 0x12 Internet 地址 物理地址 類型 10.0.0.13 00-0c-29-de-7c-97 動態 10.0.0.15 00-0c-29-de-7c-97 動態 10.0.0.16 00-0c-29-2e-47-20 動態 10.0.0.17 00-0c-29-4a-ac-4a 動態 10.0.0.18 00-0c-29-ea-ca-55 動態

③arp_announce和arp_ignore詳解

# 配置的內核參數net.ipv4.conf.all.arp_ignore = 1net.ipv4.conf.all.arp_announce = 2net.ipv4.conf.lo.arp_ignore = 1net.ipv4.conf.lo.arp_announce = 2

lvs在DR模式下需要關閉arp功能

arp_announce

對網絡接口上，本地IP地址的發出的，ARP回應，作出相應級別的限制:

確定不同程度的限制,宣布對來自本地源IP地址發出Arp請求的接口

arp_ignore定義

對目標地定義對目標地址為本地IP的ARP詢問不同的應答模式0

抑制RS端arp前的廣播情況

抑制RS端arp后廣播情況

1.6 LVS集群的工作模式

DR（Direct Routing）直接路由模式 NAT（Network Address Translation） TUN（Tunneling）隧道模式 FULLNAT（Full Network Address Translation）

1.6.1 LVS集群的工作模式--NAT

通過網絡地址轉換，調度器LB重寫請求報文的目標地址，根據預設的調度算法，將請求分派給后端的真實服務器，真實服務器的響應報文處理之后，返回時必須要通過調度器，經過調度器時報文的源地址被重寫，再返回給客戶，完成整個負載調度過程。

收費站模式---來去都要經過LB負載均衡器。

NAT方式的實現原理和數據包的改變

lRS應該使用私有地址，RS的網關必須指向DIP

(a). 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP(b). PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈(c). IPVS比對數據包請求的服務是否為集群服務，若是，修改數據包的目標IP地址為后端服務器IP，然后將數據包發至POSTROUTING鏈。 此時報文的源IP為CIP，目標IP為RIP(d). POSTROUTING鏈通過選路，將數據包發送給Real Server(e). Real Server比對發現目標為自己的IP，開始構建響應報文發回給Director Server。 此時報文的源IP為RIP，目標IP為CIP(f). Director Server在響應客戶端前，此時會將源IP地址修改為自己的VIP地址，然后響應給客戶端。 此時報文的源IP為VIP，目標IP為CIP

LVS-NAT模型的特性

lDIP和RIP必須在同一個網段內

l請求和響應報文都需要經過Director Server，高負載場景中，Director Server易成為性能瓶頸

l支持端口映射

lRS可以使用任意操作系統

l缺陷：對Director Server壓力會比較大，請求和響應都需經過director server

1.6.2 LVS集群的工作模式--隧道模式TUN

采用NAT技術時，由于請求和響應的報文都必須經過調度器地址重寫，當客戶請求越來越多時，調度器的處理能力將成為瓶頸，為了解決這個問題，調度器把請求的報文通過IP隧道(相當于ipip或ipsec )轉發至真實服務器，而真實服務器將響應處理后直接返回給客戶端用戶，這樣調度器就只處理請求的入站報文。由于一般網絡服務應答數據比請求報文大很多，采用VS/TUN技術后，集群系統的最大吞吐量可以提高10倍。

VS/TUN工作流程,它的連接調度和管理與VS/NAT中的一樣，只是它的報文轉發方法不同。調度器根據各個服務器的負載情況，連接數多少，動態地選擇一臺服務器，將原請求的報文封裝在另一個IP報文中，再將封裝后的IP報文轉發給選出的真實服務器；真實服務器收到報文后，先將收到的報文解封獲得原來目標地址為VIP地址的報文,服務器發現VIP地址被配置在本地的IP隧道設備上(此處要人為配置)，所以就處理這個請求，然后根據路由表將響應報文直接返回給客戶。

TUN原理和數據包的改變

(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP 。(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈(c) IPVS比對數據包請求的服務是否為集群服務，若是，在請求報文的首部再次封裝一層IP報文，封裝源IP為為DIP，目標IP為RIP。然后發至POSTROUTING鏈。 此時源IP為DIP，目標IP為RIP(d) POSTROUTING鏈根據最新封裝的IP報文，將數據包發至RS（因為在外層封裝多了一層IP首部，所以可以理解為此時通過隧道傳輸）。 此時源IP為DIP，目標IP為RIP(e) RS接收到報文后發現是自己的IP地址，就將報文接收下來，拆除掉最外層的IP后，會發現里面還有一層IP首部，而且目標是自己的lo接口VIP，那么此時RS開始處理此請求，處理完成之后，通過lo接口送給eth0網卡，然后向外傳遞。 此時的源IP地址為VIP，目標IP為CIP(f) 響應報文最終送達至客戶端

lRIP、VIP、DIP全是公網地址LVS-Tun模型特性

lRS的網關不會也不可能指向DIP

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

l不支持端口映射

lRS的系統必須支持隧道

1.6.3 LVS集群的工作模式--FULLNAT

LVS的DR和NAT模式要求RS和LVS在同一個vlan中，導致部署成本過高；TUNNEL模式雖然可以跨vlan，但RealServer上需要部署ipip隧道模塊等，網絡拓撲上需要連通外網，較復雜，不易運維。

為了解決上述問題，開發出FULLNAT，該模式和NAT模式的區別是：數據包進入時，除了做DNAT，還做SNAT（用戶ip->內網ip），從而實現LVS-RealServer間可以跨vlan通訊，RealServer只需要連接到內網。

類比地鐵站多個閘機。

1.7 IPVS調度器實現了如下八種負載調度算法：

a)輪詢（Round Robin）RR

調度器通過"輪叫"調度算法將外部請求按順序輪流分配到集群中的真實服務器上，它均等地對待每一臺服務器，而不管服務器上實際的連接數和系統負載。

b)加權輪叫（Weighted Round Robin）WRR

調度器通過"加權輪叫"調度算法根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況，并動態地調整其權值。

c)最少鏈接（Least Connections）LC

調度器通過"最少連接"調度算法動態地將網絡請求調度到已建立的鏈接數最少的服務器上。如果集群系統的真實服務器具有相近的系統性能，采用"最小連接"調度算法可以較好地均衡負載。

d)加權最少鏈接（Weighted Least Connections）Wlc

在集群系統中的服務器性能差異較大的情況下，調度器采用"加權最少鏈接"調度算法優化負載均衡性能，具有較高權值的服務器將承受較大比例的活動連接負載。調度器可以自動問詢真實服務器的負載情況，并動態地調整其權值。

e)基于局部性的最少鏈接（Locality-Based Least Connections）Lblc

"基于局部性的最少鏈接"調度算法是針對目標IP地址的負載均衡，目前主要用于Cache集群系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處于一半的工作負載，則用"最少鏈接"的原則選出一個可用的服務器，將請求發送到該服務器。

f)帶復制的基于局部性最少鏈接（Locality-Based Least Connections with Replication）

"帶復制的基于局部性最少鏈接"調度算法也是針對目標IP地址的負載均衡，目前主要用于Cache集群系統。它與LBLC算法的不同之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組，按"最小連接"原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器，若服務器超載；則按"最小連接"原則從這個集群中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復制的程度。

g)目標地址散列（Destination Hashing）Dh

"目標地址散列"調度算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。

h)源地址散列（Source Hashing）SH

"源地址散列"調度算法根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。

1.8 LVS+Keepalived方案實現

1.8.1 keepalived功能

1.添加VIP

2.添加LVS配置

3.高可用（VIP漂移）

4. web服務器健康檢查

1.8.2在負載器安裝Keepalived軟件

yum -y install keepalived

#檢查軟件是否安裝

[root@lb03 ~]# rpm -qa keepalivedkeepalived-1.3.5-1.el7.x86_64

1.8.3修改配置文件

lb03上keepalied配置文件

lb03 /etc/keepalived/keepalived.conf

lb04的Keepalied配置文件

lb04 /etc/keepalived/keepalived.conf

keepalivedpersistence_timeout參數意義LVS Persistence參數的作用

http://blog.csdn.net/nimasike/article/details/53911363

1.8.4啟動keepalived服務

[root@lb03 ~]# systemctl restart keepalived.service # 檢查lvs狀態[root@lb03 ~]# ipvsadm -lnIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 10.0.0.13:80 wrr persistent 50 -> 10.0.0.17:80 Route 1 0 0 -> 10.0.0.18:80 Route 1 0 0 # 檢查虛擬ip[root@lb03 ~]# ip a s eth02: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:0c:29:de:7c:97 brd ff:ff:ff:ff:ff:ff inet 10.0.0.15/24 brd 10.0.0.255 scope global eth0 valid_lft forever preferred_lft forever inet 10.0.0.13/24 scope global secondary eth0 valid_lft forever preferred_lft forever inet6 fe80::20c:29ff:fede:7c97/64 scope link valid_lft forever preferred_lft forever

1.8.5在web服務器上進行配置

（在web03/web04同時操作下面步驟）步驟1：在lo網卡綁定VIP地址（ip）步驟2：修改內核參數抑制ARP響應ip addr add 10.0.0.13/32 dev locat >>/etc/sysctl.conf<

注意：web服務器上的配置為臨時生效，可以將其寫入rc.local文件，注意文件的執行權限。

使用curl命令進行測試

[root@lb04 ~]# curl 10.0.0.13web03

至此keepalived+lvs配置完畢

1.9常見LVS負載均衡高可用解決方案

開發類似keepalived的腳本，早期的辦法，現在不推薦使用。

heartbeat+lvs+ldirectord腳本配置方案，復雜不易控制，不推薦使用

RedHat工具piranha，一個web界面配置LVS。

LVS-DR+keepalived方案，推薦最優方案，簡單、易用、高效。

1.9.1 lvs排錯思路