9月25日，DR發布官方聲明對此進行回應。官方聲明稱，“DR鉆戒可刪購買記錄”為不實傳言，發布不實消息的淘寶店鋪已被淘寶官方處理下架，并表示DR鉆戒需要用戶持本人身份證購買，同時通過本人實名認證過的手機短信驗證或者人臉識別核驗。
針對“購買記錄可以刪除”傳言，DR鉆戒在聲明中表示，在用戶購買DR鉆戒后，購買記錄運用了不可逆技術加密，同時會上傳至國家信息中心發起的BSN區塊鏈。所有購買記錄不可篡改，永久不可刪除。
【記者】黃曉韻
【作者】 黃曉韻
【來源】 南方報業傳媒集團南方+客戶端
府大力推動遠程醫療是為了醫療資源的高效共享和覆蓋，其中影像資料的實時遠程分享技術對遠程診斷提供了重要技術依據；遠程醫療平臺是在醫療體系中實現的，必須在醫療專用網絡內通信。安全、實時是遠程醫療必須滿足的兩個重要條件。
遠程醫療的形態是擁有優質醫生（專家）資源的醫院對缺乏優質醫生資源但擁有良好醫療設備的醫院進行遠程輔導，是醫療專家資源的共享。專家分醫技專家和醫療專家（我們常見的醫生），醫技專家主要是對病人采集的圖像或數據進行判讀，其中彩超等活動影像的實時傳輸和判讀，對有些病人至關重要，這里著重介紹實現對彩超的動態影像實時傳輸和觀看的一個產品—RHUB實時協作系統。
首先是圖像采集和傳輸，下級醫院的彩超設備掃描病人所看到圖像如何實時讓遠距離的專家清晰的看到？首先是通過高清采集卡將本地彩超機視頻輸出的影像傳輸到本地的電腦上，可以達到1080p@60pfs，然后通過網絡傳輸到遠端電腦上重現，一般通過高效的屏幕分享軟件實現，主要是Turbomeeting和Teamview。
其次是傳輸的安全，國家目前規定遠程醫療必須在醫療機構之間進行，醫院的網絡要求具備很高的安全管控，外面網絡不經授權無法接入，所以目前的遠程醫療網絡基本上是專網內的。Teamview在公網上使用為主，私網內價格很高，Turbomeeting私網或公網均可，價格一樣，比Teamview便宜不少。
Teamview分享的影像的實時性和清晰度，和Turbomeeting比較不分高低。
最后是使用的方便性，Turbomeeting可以做到下級醫院無需操作，只需專家端操作訪問即可，并且可以一對多。
Turbomeeting還可以實現高清視頻會議功能，實現專家對遠程醫生的實時互動。
目前Turbomeeting已在全國幾十家醫院的放射科使用。
者 | 故事凌
責編 | 郭芮
近來在群里,看到大家說對lvs+keepalived不太了解，我想我應該是有發言權的。自己本身就是運維出身，原來在京東物流的時候，lvs+keepalived就是倉庫物流在用的，踩了很多坑，只不過后來都上云了，但是這個經驗還是可以跟大家叨叨一會的——下面我們進入主題吧。
LVS簡介
LVS主要用于多服務器的負載均衡：
它工作在網絡層，可以實現高性能，高可用的服務器集群技術。
它廉價，可把許多低性能的服務器組合在一起形成一個超級服務器。
它易用，配置非常簡單，且有多種負載均衡的方法。
它穩定可靠，即使在集群的服務器中某臺服務器無法正常工作，也不影響整體效果。
可擴展性也非常好。
性能幾乎可以和F5相媲美(個人意見)
lvs的負載均衡結構圖，大概的使用場景是這樣的，關于高可用的地方，我們后面會進行介紹，別著急哦！
LVS的核心組件和專業術語
1. 核心組件
LVS的管理工具和內核模塊 ipvsadm/ipvs：
ipvsadm：用于空間的命令行工具, 用于管理集群服務及集群服務上的RS等；
ipvs：工作于內核上的程序, 可根據用戶定義的集群實現請求轉發。
VS：Virtual Server，虛擬服務
Director：負載均衡器，圖1的lvs調度器
Balancer：分發器，圖1的lvs調度器
RS：Real Server，后端請求處理服務器，圖1的web服務
CIP：client ip，客戶單ip
VIP：Director Virtural IP，負載均衡虛擬IP，應該出現在圖1的lvs調度器上
DIP：Director IP 負載均衡器ip
RIP：Real Server IP，后端請求處理服務器IP
LVS的常用幾種模式
lvs的DR模式最最穩定, 是使用最多的一種模式。
1. 什么是arp廣播？
在了解LVS的DR模式之前, 我們需要先了解一下arp廣播, 要不然我在講后面內容的時候會用到這個, 已經是大佬的同學跳過吧。小白請認真讀完。
arp廣播：根據ip地址找mac地址。
主機A的IP地址為192.168.1.1，MAC地址為0A-11-22-33-44-01；
主機B的IP地址為192.168.1.2，MAC地址為0A-11-22-33-44-02；
當主機A要與主機B通信時：
第1步：根據主機A上的路由表內容，IP確定用于訪問主機B的轉發IP地址是192.168.1.2。然后A主機在自己的本地ARP緩存中檢查主機B的匹配MAC地址。
第2步：如果主機A在ARP緩存中沒有找到映射，它將詢問192.168.1.2的硬件地址，從而將ARP請求幀廣播到本地網絡上的所有主機。源主機A的IP地址和MAC地址都包括在ARP請求中。本地網絡上的每臺主機都接收到ARP請求并且檢查是否與自己的IP地址匹配。如果主機發現請求的IP地址與自己的IP地址不匹配，它將丟棄ARP請求。
第3步：主機B確定ARP請求中的IP地址與自己的IP地址匹配，則將主機A的IP地址和MAC地址映射添加到本地ARP緩存中。
第4步：主機B將包含其MAC地址的ARP回復消息直接發送回主機A。
第5步：當主機A收到從主機B發來的ARP回復消息時，會用主機B的IP和MAC地址映射更新ARP緩存。本機緩存是有生存期的，生存期結束后，將再次重復上面的過程。主機B的MAC地址一旦確定，主機A就能向主機B發送IP通信了。
2. LVS的DR模式的請求流程圖申明:首先我們先來申明一下, 舉個例子: 我們在請求一個域名如: https://www.naixuejiaoyu.com/, 我們首先會訪問的是DNS, DNS會根據我們的域名給我們解析VIP地址(一般情況是一個vip, 也有一種情況是一個域名對應對個vip或者ip), 我們為了簡單, 下圖就是畫的一般情況。注意：前提是我們的VIP地址都是配置在LO上的。
3. 提問一: 三個vip, 為什么dns會把請求打到LVS上, 而沒有打到RS上呢?
帶著這個問題我們來思考, 可能才更好的幫助我們來理解LVS的DR模式, 要解決這個問題, 我們就需要提到我們剛開始提到的ARP請求了, 我們需要在LVS, RS1, RS2上都需要綁定三個VIP, 但是需要在RS1和RS2上需要額外的做一些工作, 那就是禁止ARP請求。
我們在RS上需要執行以下的操作, 更改linux的內核參數, 如下:
echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce
echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce
為了幫助大家更好的理解三個vip之間的關系, 我們舉個例子來說: LVS服務器是正常的, 當DNS在請求的時候會解析出來VIP的地址, 但是并不知道, 具體的mac地址是哪一個, 那LVS服務器會通過ARP請求, 告知別人自己的mac地址, 別人就緩存下來了, 反之, 我們的RS是禁止ARP請求的, 其實他就是一個啞巴, 讓他不能說話的, 別人就不知道他的mac地址, 即使他有VIP地址, 所以DNS只會把請求轉發到LVS上, 而不能轉發到RS上。
4. 既然RS禁止了ARP請求, 那LVS如何把請求轉發給RS呢?解決了上面的問題, 那新的問題又來了, 既然我們說RS禁止了ARP請求, 那LVS是如何把請求轉發給RS的呢?其實我告訴你,是通過修改mac地址, 進行轉發的,這個是DR模式的核心, 那LVS又是如何知道RS的mac地址呢, 其實是通過ARP請求獲知的, 那有些人就會問我, 你這個不是自相矛盾嗎?別擔心, 接著看。
首先我們看一下, 我們的vip都是綁定在lo上的, 我們要理解上面我提出的這個問題, 就要深入的了解一下linux內核參數的配置信息了。
有關arp_ignore的相關介紹：
arp_ignore - INTEGER Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses:
0 - (default): reply for any local target IP address, configured on any interface
1 - reply only if the target IP address is local address configured on the incoming interface
2 - reply only if the target IP address is local address configured on the incoming interface and both with the sender's IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope host, only resolutions for global and link addresses are replied
4-7 - reserved
8 - do not reply for all local addresses
The max value from conf/{all,interface}/arp_ignore is used when ARP request is received on the {interface}
看不懂沒關系, 既然要解決, 我們肯定是要深入剖析的, 下面我們來簡單的翻譯一下：
arp_ignore:定義對目標地址為本地IP的ARP詢問不同的應答模式
0 - (默認值): 回應任何網絡接口上對任何本地IP地址的arp查詢請求
1 - 只回答目標IP地址是來訪網絡接口本地地址的ARP查詢請求
2 -只回答目標IP地址是來訪網絡接口本地地址的ARP查詢請求,且來訪IP必須在該網絡接口的子網段內
3 - 不回應該網絡界面的arp請求，而只對設置的唯一和連接地址做出回應
4-7 - 保留未使用
8 -不回應所有（本地地址）的arp查詢
好了我們設置的arp_ignore內核參數是1, 就是只回答目標IP地址是來訪網絡接口本地地址的ARP查詢請求，即: 只回答本地網卡eth0上的ARP請求。
我們就拿上面的圖舉例:
LVS服務器:
DIP: 綁定的網卡eth0: 192.168.1.110
VIP: 綁定的網卡是lo:0: 192.168.147.150
RS服務器:
RIP: 綁定的網卡是eth0: 192.168.1.111
VIP: 綁定的網卡lo:0: 192.168.147.150
其實客戶端在發送ARP請求的時候, 詢問的是VIP的mac地址, LVS服務器進行了正確的ARP請求回應, 而當循環RS服務器的mac地址的時候, 這個時候, 我們網卡的IP地址是: 192.168.1.111/112, RS是做過閹割的, 所以不給與回應。
當LVS服務器發起ARP請求的時候, 循環192.168.1.111或者192.168.1.112的mac地址, 這個時候, RS本地的網卡地址, 就是LVS需要訪問的ip地址, 就進行ARP請求的回應. 所有LVS服務器就緩存了RS服務器的mac地址。
上面的問題是不是都迎刃而解了，快來給我瘋狂打call吧！
5. RS是如何做到, 直接返回給客戶端的呢?
這個問題太好, 我們一般接收的請求, 應該都是哪里來, 哪里回, 那RS是如何做到直接返回個客戶端的呢?
好的, 既然我們前面提到了在RS上進行設計linux內核參數的更改, 分別是arp_ignore和arp_announce兩個內核參數, 既然arp_ignore是禁止arp請求的,我們上面已經介紹過了, arp_announce內核參數是做什么的嗯? 我們下面就來講解一下這個參數的作用吧。
既然存在, 那就是有意義的, arp_announce這個內核參數, 其實就是讓RS可直接返回給客戶端。
有關arp_announce的相關介紹：
arp_announce - INTEGER Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent on interface: 0 - (default) Use any local address, configured on any interface 1 - Try to avoid local addresses that are not in the target's subnet for this interface. This mode is useful when target hosts reachable via this interface require the source IP address in ARP requests to be part of their logical network configured on the receiving interface. When we generate the request we will check all our subnets that include the target IP and will preserve the source address if it is from such subnet. If there is no such subnet we select source address according to the rules for level 2.
2 - Always use the best local address for this target. In this mode we ignore the source address in the IP packet and try to select local address that we prefer for talks with the target host. Such local address is selected by looking for primary IP addresses on all our subnets on the outgoing interface that include the target IP address. If no suitable local address is found we select the first local address we have on the outgoing interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes no matter the source IP address we announce.
The max value from conf/{all,interface}/arp_announce is used.
Increasing the restriction level gives more chance for receiving answer from the resolved target while decreasing the level announces more valid sender's information.
arp_announce:對網絡接口上，本地IP地址的發出的，ARP回應，作出相應級別的限制: 確定不同程度的限制,宣布對來自本地源IP地址發出Arp請求的接口。
0 - (默認) 在任意網絡接口上的任何本地地址
1 -盡量避免不在該網絡接口子網段的本地地址做出arp回應. 當發起ARP請求的源IP地址是被設置應該經由路由達到此網絡接口的時候很有用.此時會檢查來訪IP是否為所有接口上的子網段內ip之一.如果改來訪IP不屬于各個網絡接口上的子網段內,那將采用級別2的方式來進行處理.
2 - 對查詢目標使用最適當的本地地址.在此模式下將忽略這個IP數據包的源地址并嘗試選擇與能與該地址通信的本地地址.首要是選擇所有的網絡接口的子網中外出訪問子網中包含該目標IP地址的本地地址. 如果沒有合適的地址被發現,將選擇當前的發送網絡接口或其他的有可能接受到該ARP回應的網絡接口來進行發送.
其實我們RS可以直接返回給客戶端, 就是arp_announce設置為2起到的作用, 他會自主的選擇一個地址, 即VIP地址, 返回給我們的客戶端, 其實就是利用了一個欺騙的技術, 讓客戶端不會把我們返回的請求丟棄掉, 讓他以為RS返回的請求是正常的。
6. LVS的DR模式請求IP地址追蹤
client在發起請求之前，會發一個ARP廣播的包，在網絡中找“誰是vip”，由于所有的服務器，lvs和res都有vip，為了讓client的請求送到lvs上，所以必須讓RS不能響應client發出的ARP請求，（這也是為什么要禁止res上arp的請求和響應）下面就是lvs轉發的事情了：
client向目標vip發送請求，lvs接收；此時ip包和數據信息如下：
src mac ----> a1:b2:c3:d4:e5:f6(client的mac地址(我假設的))
dst mac ----> 1a:2b:3c:4d:5e:6f(lvs的mac地址(我假設的))
src_ip ----> 192.168.147.1
dst_ip ----> 192.168.147.150
lvs根據負載均衡的算法，選擇一臺RS，然后把RS1的mac地址作為目的mac地址，發送到局域網中：
src mac ----> 1a:2b:3c:4d:5e:6f(lvs的mac地址(我假設的))
dst mac ----> 11:22:33:44:55:66(RS1的mac地址(我假設的))
src_ip ----> 192.168.147.1
dst_ip ----> 192.168.147.150
是的, 你沒有看錯, src_ip地址和dst_ip是不發生變化的, 我們前面說到, DR模式是通過修改mac地址進行轉發的, IP地址的請求是不發生變化的, 這個和后面的nat模式有很大的區別
RS1在局域網中收到這個請求以后，發現目的ip和本地匹配，于是進行處理，處理完成以后，直接把源ip和目的ip直接對調，然后經過網關直接返回給用戶；
src mac ----> 11:22:33:44:55:66(RS1的mac地址(我假設的))
dst mac ----> a1:b2:c3:d4:e5:f6(client的mac地址(我假設的))
src_ip ----> 192.168.147.150
dst_ip ----> 192.168.147.1
在RS上, 是可以直接返回給客戶端的,
LVS的NAT模式, 類似于iptables的DNAT, 但是支持多目標的轉發。
注意:自己在本機做實驗的時候, 客戶端不能和RS在同一網段, 不然直接響應, 不走官關。1. 優點
配置簡單，通用性強
支持映射（NAT映射表）
RIP可以是私網IP，用于LVS與RS之間通訊
2. 缺點
LVS和RS必須在一個VLAN中（RS將LVS配置為網關，如果不在一個子網回包會經過路由器網關直接路由走，LVS沒機會修改數據包）
進出流量都需要LVS進行處理，LVS容易成為集群瓶頸
需要將LVS配置為RS的網關
3. LVS的NAT模式的請求流程圖
4. LVS的NAT模式請求流程圖
客戶端發起請求到LVS機器上。
LVS服務器根據lvs的算法，轉發給RS服務器（改變目的ip為RS1或者RS2），并記錄連接信息，只改變目的ip，源ip不變。
RS收到request請求包之后，發現目的ip是自己的ip，處理請求，然后走網關，經過LVS, RS設置的官網為LVS的eth0。
LVS收到reply包后，修改reply包的源ip地址為vip，發給客戶端。
客戶端接收到請求, 校驗ip請求的包是否符合要求, 符合, 接收, 不符合, 丟棄。
5. 抓包分析包請求流程如下:
客戶端發起請求:
source 192.168.147.1
dest 192.168.147.150:80
在LVS服務器上, eth0網卡抓取的包如下:
LVS處理請求:
在LVS服務器上抓包, 在eth0網卡抓包
source 192.168.147.1:59334
dst 192.168.1.112/111:80
LVS的eth0作為RS的網關地址, 需要經過LVS周轉
source 192.168.1.112
dst 192.168.147.1
返回客戶端
包經過eth0返回vip服務器，然后經過VIP返回給客戶端，源ip改成vip，目的ip不變
source 192.168.147.150
dst 192.168.147.1
什么IP隧道技術？
簡單來說IP隧道技術就是將 【IP數據包】 的上面再封裝一層【IP數據包】， 然后路由器根據最外層的IP地址路由到目的地服務器，目的地服務器拆掉最外層的IP數據包，拿到里面的IP數據包進行處理。
原理
用戶請求負載均衡服務器，當IP數據包到達負載均衡服務器后，根據算法選擇一臺真實的服務器，然后通過IP隧道技術將數據包原封不動再次封裝，并發送給真實服務器，當這個數據包到達真實服務器以后，真實服務器進行拆包（拆掉第一層的IP包）拿到里面的IP數據包進行處理，然后將結果直接返回給客戶端。
Tunnel原理流程圖
fullnat模式聽名字也是nat模式的一種, 那full是什么意思呢? 就是全部的nat模式, nat模式中, 我們是需要設置RS的網關地址為LVS的內網服務器地址, 那fullnat模式, 就是我們最通常容易理解的類型, 我們通過下面的圖來了解吧,, 主要是就包的請求地址改變有不同。
nat模式：
fullnat模式：
lvs負載均衡調度算法
根據前面的介紹，我們了解了LVS的三種工作模式，但不管實際環境中采用的是哪種模式，調度算法進行調度的策略與算法都是LVS的核心技術，LVS在內核中主要實現了一下十種調度算法。
輪詢調度（Round Robin 簡稱'RR'）算法就是按依次循環的方式將請求調度到不同的服務器上，該算法最大的特點就是實現簡單。輪詢算法假設所有的服務器處理請求的能力都一樣的，調度器會將所有的請求平均分配給每個真實服務器。
加權輪詢（Weight Round Robin 簡稱'WRR'）算法主要是對輪詢算法的一種優化與補充，LVS會考慮每臺服務器的性能，并給每臺服務器添加一個權值，如果服務器A的權值為1，服務器B的權值為2，則調度器調度到服務器B的請求會是服務器A的兩倍。權值越高的服務器，處理的請求越多。
最小連接調度（Least Connections 簡稱'LC'）算法是把新的連接請求分配到當前連接數最小的服務器。最小連接調度是一種動態的調度算法，它通過服務器當前活躍的連接數來估計服務器的情況。調度器需要記錄各個服務器已建立連接的數目，當一個請求被調度到某臺服務器，其連接數加1；當連接中斷或者超時，其連接數減1。
（集群系統的真實服務器具有相近的系統性能，采用最小連接調度算法可以比較好地均衡負載。)
加權最少連接（Weight Least Connections 簡稱'WLC'）算法是最小連接調度的超集，各個服務器相應的權值表示其處理性能。服務器的缺省權值為1，系統管理員可以動態地設置服務器的權值。加權最小連接調度在調度新連接時盡可能使服務器的已建立連接數和其權值成比例。調度器可以自動問詢真實服務器的負載情況，并動態地調整其權值。
基于局部的最少連接調度（Locality-Based Least Connections 簡稱'LBLC'）算法是針對請求報文的目標IP地址的 負載均衡調度，目前主要用于Cache集群系統，因為在Cache集群客戶請求報文的目標IP地址是變化的。這里假設任何后端服務器都可以處理任一請求，算法的設計目標是在服務器的負載基本平衡情況下，將相同目標IP地址的請求調度到同一臺服務器，來提高各臺服務器的訪問局部性和Cache命中率，從而提升整個集群系統的處理能力。LBLC調度算法先根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處于一半的工作負載，則使用'最少連接'的原則選出一個可用的服務器，將請求發送到服務器。
帶復制的基于局部性的最少連接（Locality-Based Least Connections with Replication 簡稱'LBLCR'）算法也是針對目標IP地址的負載均衡，目前主要用于Cache集群系統，它與LBLC算法不同之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。按'最小連接'原則從該服務器組中選出一一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按'最小連接'原則從整個集群中選出一臺服務器，將該服務器加入到這個服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復制的程度。
目標地址散列調度（Destination Hashing 簡稱'DH'）算法先根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且并未超載，將請求發送到該服務器，否則返回空。
源地址散列調度（Source Hashing 簡稱'SH'）算法先根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且并未超載，將請求發送到該服務器，否則返回空。它采用的散列函數與目標地址散列調度算法的相同，它的算法流程與目標地址散列調度算法的基本相似。
最短的期望的延遲調度（Shortest Expected Delay 簡稱'SED'）算法基于WLC算法。舉個例子吧，ABC三臺服務器的權重分別為1、2、3 。那么如果使用WLC算法的話一個新請求進入時它可能會分給ABC中的任意一個。使用SED算法后會進行一個運算
A：（1+1）/1=2 B：（1+2）/2=3/2 C：（1+3）/3=4/3 就把請求交給得出運算結果最小的服務器。
最少隊列調度（Never Queue 簡稱'NQ'）算法，無需隊列。如果有realserver的連接數等于0就直接分配過去，不需要在進行SED運算。
作者：凌晶，生活中的段子手，目前就職于一家地產公司做 DevOPS 相關工作, 曾在大型互聯網公司做高級運維工程師，熟悉 Linux 運維，Python 運維開發，Java 開發，DevOPS 常用開發組件等。
聲明：本文為作者投稿，首發于個人公眾號：stormling，版權歸其所有。
?比特幣當贖金，WannaRen 勒索病毒二度來襲！
?深度|一文讀懂“情感計算”在零售中的應用發展
?三大運營商將上線5G消息；蘋果谷歌聯手，追蹤30億用戶；jQuery 3.5.0發布|極客頭條
?曾遭周鴻祎全網封殺的360猛將：草根打工到36歲身家上億的逆襲！
?你公司的虛擬機還閑著？基于Jenkins和Kubernetes的持續集成測試實踐了解一下！
?從Web1.0到Web3.0：詳析這些年互聯網的發展及未來方向
?一文讀懂“情感計算”在零售中的應用發展