最近我做的專案是進行公司廣州合作機房到aws亞馬遜機房之間產生的延時，其中此鏈路的線路如下：
廣州合作機房---->深圳自研機房---->北美自研機房---->aws
針對於這個鏈路，我們需要在深圳自研機房和北美自研機房上分別架上haproxy**進行訊息的**，而由於測速是使用自己用socket寫的tcp ping包，就要求tcp包能沿著源鏈路返回到廣州節點上，也就是說其是雙向通訊的。
剛開始我的配置檔案如下：
####################全域性配置資訊########################
#######引數是程序級的，通常和作業系統（os）相關#########
global
log 127.0.0.1 local0 #[err warning info debug]
uid 1005 #所屬執行的使用者uid
gid 1005 #所屬執行的使用者組
daemon #以後臺形式執行haproxy
pidfile /var/run/haproxy.pid #haproxy的pid存放路徑,啟動程序的使用者必須有許可權訪問此檔案
maxconn 4096
##################預設的全域性設定####################
defaults
log global
retries 3
maxconn 2000
mode tcp #所處理的類別 (#7層 http;4層tcp)
option redispatch #serverid對應的伺服器掛掉後,強制定向到其他健康的伺服器
timeout connect 5000 #連線超時
timeout client 50000 #客戶端超時
timeout server 50000 #伺服器超時
timeout check 2000 #心跳檢測超時
####################監控頁面的設定####################
listen admin_status
bind 0.0.0.0:3306 #監聽埠
mode http #http的7層模式
option httplog #http日誌
maxconn 10 #最大連線數
log 127.0.0.1 local0 err #錯誤日誌記錄
stats refresh 10s #每隔10秒自動重新整理監控頁面
stats uri /admin?stats #監控頁面的url
stats auth admin:admin #監控頁面的使用者和密碼admin,可以設定多個使用者名稱
stats hide-version #隱藏統計頁面上的haproxy版本資訊
########frontend配置############
#####注意：frontend配置裡面可以定義多個acl進行匹配操作########
frontend tcp_in
bind 0.0.0.0:3366 #監聽埠
default_backend myback
backend myback
balance roundrobin
listen 3366
bind 0.0.0.0:3366
mode tcp
以上是我在北美的ha的配置，可是測試了很久，也改了很久，經測試後訊息可以從廣州發到aws上，但是卻不能從aws返回到廣州，剛開始以為是我的超時這些設定有問題，可是改了之後還是不行，然後就決定再把haproxy配置的各個屬性重新複習一下，後來發現backend裡面的balance配置分為兩種：roundrobin和source模式。
其中關於這兩種模式的介紹如下：
balance 選項：
balance source ：如果想讓haproxy按照客戶端的ip位址進行負載均衡策略，即同一ip位址的所有請求都傳送到同一伺服器時，需要配置此選項。
balance roundrobin ：haproxy把請求輪流的**到每乙個伺服器上，依據每台伺服器的權重，此權重會動態調整。最常見的預設配置。
由於我只是專線，並不需要進行負載均衡，因此需要把balance設定成source，至此重新測試，一切正常。
如果你在這次面試中沒有被錄用，你怎麼打算？
成功的背後有許多的困難和挫折,如果這次失敗了也僅僅是一次而已,只有經過經驗經歷的積累才能塑造出乙個完全的成功者。我會從以下幾個方面來正確看待這次失敗.第一 要敢於面對,面對這次失敗不氣餒,接受已經失去了這次機會就不會回頭這個現實,從心理意志和精神上體現出對這次失敗的抵抗力。要有自信,相信自己經歷了這...