① Linux c語言 C/S程序，客戶端發送的數據和伺服器端接收到的數據不一樣，求解
估計你是用的tcp socket，導致「videlord」網友說的情況：對於tcp socket，send與recv不是對等的，recv時只要緩沖有數據就會收上來。簡單說就是你send 4次，比如分別為10 10 10 10位元組，對端可以一次recv到這40位元組數據，也可以recv 40次、每次1位元組。
解決辦法有兩種：
改用udp socket，send/recv自然對等了
繼續用tcp socket，自己進行數據分段：比如自行約定在數據前約定4個位元組用於描述數據長度，這樣發送時，send 4+33位元組，send 4+35位元組；接收時，先獲取描述長度的4位元組獲得長度，再按照長度接收數據（可能需要多次recv湊齊指定長度）。
② mysql_query之後不調用mysql_free_result會導致內存泄漏嗎
未必，如果是長連接，多線程。。。
③ 如何實現支持數億用戶的長連消息系統
此文是根據周洋在【高可用架構群】中的分享內容整理而成，轉發請註明出處。
周洋，360手機助手技術經理及架構師，負責360長連接消息系統，360手機助手架構的開發與維護。
不知道咱們群名什麼時候改為「Python高可用架構群」了，所以不得不說，很榮幸能在接下來的一個小時里在Python群里討論golang....
360消息系統介紹
360消息系統更確切的說是長連接push系統，目前服務於360內部多個產品，開發平台數千款app，也支持部分聊天業務場景，單通道多app復用，支持上行數據，提供接入方不同粒度的上行數據和用戶狀態回調服務。
目前整個系統按不同業務分成9個功能完整的集群，部署在多個idc上（每個集群覆蓋不同的idc），實時在線數億量級。通常情況下，pc，手機，甚至是智能硬體上的360產品的push消息，基本上是從我們系統發出的。
關於push系統對比與性能指標的討論
很多同行比較關心go語言在實現push系統上的性能問題，單機性能究竟如何，能否和其他語言實現的類似系統做對比么？甚至問如果是創業,第三方雲推送平台，推薦哪個?
其實各大廠都有類似的push系統，市場上也有類似功能的雲服務。包括我們公司早期也有erlang，nodejs實現的類似系統，也一度被公司要求做類似的對比測試。我感覺在討論對比數據的時候，很難保證大家環境和需求的統一，我只能說下我這里的體會，數據是有的，但這個數據前面估計會有很多定語~
第一個重要指標：單機的連接數指標
做過長連接的同行，應該有體會，如果在穩定連接情況下，連接數這個指標，在沒有網路吞吐情況下對比，其實意義往往不大，維持連接消耗cpu資源很小，每條連接tcp協議棧會占約4k的內存開銷，系統參數調整後，我們單機測試數據，最高也是可以達到單實例300w長連接。但做更高的測試，我個人感覺意義不大。
因為實際網路環境下，單實例300w長連接，從理論上算壓力就很大：實際弱網路環境下，移動客戶端的斷線率很高，假設每秒有1000分之一的用戶斷線重連。300w長連接，每秒新建連接達到3w，這同時連入的3w用戶，要進行注冊，載入離線存儲等對內rpc調用，另外300w長連接的用戶心跳需要維持,假設心跳300s一次，心跳包每秒需要1w tps。單播和多播數據的轉發，廣播數據的轉發，本身也要響應內部的rpc調用，300w長連接情況下，gc帶來的壓力，內部介面的響應延遲能否穩定保障。這些集中在一個實例中，可用性是一個挑戰。所以線上單實例不會hold很高的長連接,實際情況也要根據接入客戶端網路狀況來決定。
第二個重要指標:消息系統的內存使用量指標
這一點上，使用go語言情況下，由於協程的原因，會有一部分額外開銷。但是要做兩個推送系統的對比，也有些需要確定問題。比如系統從設計上是否需要全雙工（即讀寫是否需要同時進行）如果半雙工，理論上對一個用戶的連接只需要使用一個協程即可（這種情況下，對用戶的斷線檢測可能會有延時），如果是全雙工，那讀/寫各一個協程。兩種場景內存開銷是有區別的。
另外測試數據的大小往往決定我們對連接上設置的讀寫buffer是多大，是全局復用的，還是每個連接上獨享的，還是動態申請的。另外是否全雙工也決定buffer怎麼開。不同的策略，可能在不同情況的測試中表現不一樣。
第三個重要指標：每秒消息下發量
這一點上，也要看我們對消息到達的QoS級別(回復ack策略區別），另外看架構策略，每種策略有其更適用的場景，是純粹推？還是推拉結合？甚至是否開啟了消息日誌？日誌庫的實現機制、以及緩沖開多大？flush策略……這些都影響整個系統的吞吐量。
另外為了HA，增加了內部通信成本，為了避免一些小概率事件，提供閃斷補償策略，這些都要考慮進去。如果所有的都去掉，那就是比較基礎庫的性能了。
所以我只能給出大概數據，24核，64G的伺服器上，在QoS為message at least，純粹推，消息體256B~1kB情況下，單個實例100w實際用戶（200w+）協程，峰值可以達到2~5w的QPS...內存可以穩定在25G左右，gc時間在200~800ms左右（還有優化空間）。
我們正常線上單實例用戶控制在80w以內，單機最多兩個實例。事實上，整個系統在推送的需求上，對高峰的輸出不是提速，往往是進行限速，以防push系統瞬時的高吞吐量，轉化成對接入方業務伺服器的ddos攻擊所以對於性能上，我感覺大家可以放心使用，至少在我們這個量級上，經受過考驗，go1.5到來後，確實有之前投資又增值了的感覺。
消息系統架構介紹
下面是對消息系統的大概介紹，之前一些同學可能在gopher china上可以看到分享，這里簡單講解下架構和各個組件功能，額外補充一些當時遺漏的信息：
架構圖如下，所有的service都 written by golang.
幾個大概重要組件介紹如下：
dispatcher service根據客戶端請求信息，將應網路和區域的長連接伺服器的，一組IP傳送給客戶端。客戶端根據返回的IP，建立長連接，連接Room service.
room Service，長連接網關，hold用戶連接，並將用戶注冊進register service，本身也做一些接入安全策略、白名單、IP限制等。
register service是我們全局session存儲組件，存儲和索引用戶的相關信息，以供獲取和查詢。
coordinator service用來轉發用戶的上行數據，包括接入方訂閱的用戶狀態信息的回調，另外做需要協調各個組件的非同步操作，比如kick用戶操作,需要從register拿出其他用戶做非同步操作.
saver service是存儲訪問層，承擔了對redis和mysql的操作，另外也提供部分業務邏輯相關的內存緩存，比如廣播信息的載入可以在saver中進行緩存。另外一些策略，比如客戶端sdk由於被惡意或者意外修改，每次載入了消息，不回復ack，那服務端就不會刪除消息，消息就會被反復載入，形成死循環，可以通過在saver中做策略和判斷。（客戶端總是不可信的）。
center service提供給接入方的內部api伺服器，比如單播或者廣播介面，狀態查詢介面等一系列api,包括運維和管理的api。
舉兩個常見例子，了解工作機制：比如發一條單播給一個用戶，center先請求Register獲取這個用戶之前注冊的連接通道標識、room實例地址，通過room service下發給長連接 Center Service比較重的工作如全網廣播，需要把所有的任務分解成一系列的子任務，分發給所有center，然後在所有的子任務里，分別獲取在線和離線的所有用戶，再批量推到Room Service。通常整個集群在那一瞬間壓力很大。
deployd/agent service用於部署管理各個進程，收集各組件的狀態和信息,zookeeper和keeper用於整個系統的配置文件管理和簡單調度
關於推送的服務端架構
常見的推送模型有長輪訓拉取，服務端直接推送（360消息系統目前主要是這種），推拉結合（推送只發通知，推送後根據通知去拉取消息）.
拉取的方式不說了，現在並不常用了，早期很多是nginx+lua+redis，長輪訓，主要問題是開銷比較大，時效性也不好，能做的優化策略不多。
直接推送的系統，目前就是360消息系統這種，消息類型是消耗型的，並且對於同一個用戶並不允許重復消耗,如果需要多終端重復消耗，需要抽象成不同用戶。
推的好處是實時性好，開銷小，直接將消息下發給客戶端，不需要客戶端走從接入層到存儲層主動拉取.
但純推送模型，有個很大問題，由於系統是非同步的，他的時序性無法精確保證。這對於push需求來說是夠用的，但如果復用推送系統做im類型通信，可能並不合適。
對於嚴格要求時序性，消息可以重復消耗的系統，目前也都是走推拉結合的模型，就是只使用我們的推送系統發通知，並附帶id等給客戶端做拉取的判斷策略，客戶端根據推送的key，主動從業務伺服器拉取消息。並且當主從同步延遲的時候，跟進推送的key做延遲拉取策略。同時也可以通過消息本身的QoS，做純粹的推送策略，比如一些「正在打字的」低優先順序消息，不需要主動拉取了，通過推送直接消耗掉。
哪些因素決定推送系統的效果？
首先是sdk的完善程度，sdk策略和細節完善度，往往決定了弱網路環境下最終推送質量.
SDK選路策略,最基本的一些策略如下：有些開源服務可能會針對用戶hash一個該接入區域的固定ip，實際上在國內環境下不可行，最好分配器（dispatcher）是返回散列的一組，而且埠也要參開，必要時候，客戶端告知是retry多組都連不上，返回不同idc的伺服器。因為我們會經常檢測到一些case，同一地區的不同用戶，可能對同一idc內的不同ip連通性都不一樣，也出現過同一ip不同埠連通性不同，所以用戶的選路策略一定要靈活，策略要足夠完善.另外在選路過程中，客戶端要對不同網路情況下的長連接ip做緩存，當網路環境切換時候（wifi、2G、3G)，重新請求分配器，緩存不同網路環境的長連接ip。
客戶端對於數據心跳和讀寫超時設置,完善斷線檢測重連機制
針對不同網路環境，或者客戶端本身消息的活躍程度，心跳要自適應的進行調整並與服務端協商，來保證鏈路的連通性。並且在弱網路環境下，除了網路切換（wifi切3G）或者讀寫出錯情況，什麼時候重新建立鏈路也是一個問題。客戶端發出的ping包，不同網路下，多久沒有得到響應，認為網路出現問題，重新建立鏈路需要有個權衡。另外對於不同網路環境下，讀取不同的消息長度，也要有不同的容忍時間，不能一刀切。好的心跳和讀寫超時設置，可以讓客戶端最快的檢測到網路問題，重新建立鏈路，同時在網路抖動情況下也能完成大數據傳輸。
結合服務端做策略
另外系統可能結合服務端做一些特殊的策略，比如我們在選路時候，我們會將同一個用戶盡量映射到同一個room service實例上。斷線時，客戶端盡量對上次連接成功的地址進行重試。主要是方便服務端做閃斷情況下策略，會暫存用戶閃斷時實例上的信息，重新連入的 時候，做單實例內的遷移，減少延時與載入開銷.
客戶端保活策略
很多創業公司願意重新搭建一套push系統，確實不難實現，其實在協議完備情況下（最簡單就是客戶端不回ack不清數據），服務端會保證消息是不丟的。但問題是為什麼在消息有效期內,到達率上不去？往往因為自己app的push service存活能力不高。選用雲平台或者大廠的，往往sdk會做一些保活策略，比如和其他app共生，互相喚醒，這也是雲平台的push service更有保障原因。我相信很多雲平台旗下的sdk，多個使用同樣sdk的app，為了實現服務存活，是可以互相喚醒和保證活躍的。另外現在push sdk本身是單連接，多app復用的，這為sdk實現，增加了新的挑戰。
綜上，對我來說，選擇推送平台，優先會考慮客戶端sdk的完善程度。對於服務端，選擇條件稍微簡單，要求部署接入點（IDC）越要多，配合精細的選路策略，效果越有保證，至於想知道哪些雲服務有多少點，這個群里來自各地的小夥伴們，可以合夥測測。
go語言開發問題與解決方案
下面講下，go開發過程中遇到挑戰和優化策略，給大家看下當年的一張圖，在第一版優化方案上線前一天截圖~
可以看到，內存最高佔用69G，GC時間單實例最高時候高達3~6s.這種情況下，試想一次悲劇的請求，經過了幾個正在執行gc的組件，後果必然是超時... gc照成的接入方重試，又加重了系統的負擔。遇到這種情況當時整個系統最差情況每隔2，3天就需要重啟一次~
當時出現問題，現在總結起來，大概以下幾點
1.散落在協程里的I/O，Buffer和對象不復用。
當時（12年）由於對go的gc效率理解有限，比較奔放，程序里大量short live的協程，對內通信的很多io操作，由於不想阻塞主循環邏輯或者需要及時響應的邏輯，通過單獨go協程來實現非同步。這回會gc帶來很多負擔。
針對這個問題，應盡量控制協程創建，對於長連接這種應用，本身已經有幾百萬並發協程情況下，很多情況沒必要在各個並發協程內部做非同步io，因為程序的並行度是有限，理論上做協程內做阻塞操作是沒問題。
如果有些需要非同步執行，比如如果不非同步執行，影響對用戶心跳或者等待response無法響應，最好通過一個任務池，和一組常駐協程，來消耗，處理結果，通過channel再傳回調用方。使用任務池還有額外的好處，可以對請求進行打包處理，提高吞吐量，並且可以加入控量策略.
2.網路環境不好引起激增
go協程相比較以往高並發程序，如果做不好流控，會引起協程數量激增。早期的時候也會發現，時不時有部分主機內存會遠遠大於其他伺服器，但發現時候，所有主要profiling參數都正常了。
後來發現，通信較多系統中，網路抖動阻塞是不可免的(即使是內網)，對外不停accept接受新請求，但執行過程中，由於對內通信阻塞，大量協程被 創建，業務協程等待通信結果沒有釋放，往往瞬時會迎來協程暴漲。但這些內存在系統穩定後，virt和res都並沒能徹底釋放，下降後，維持高位。
處理這種情況，需要增加一些流控策略，流控策略可以選擇在rpc庫來做，或者上面說的任務池來做，其實我感覺放在任務池裡做更合理些，畢竟rpc通信庫可以做讀寫數據的限流，但它並不清楚具體的限流策略，到底是重試還是日誌還是緩存到指定隊列。任務池本身就是業務邏輯相關的，它清楚針對不同的介面需要的流控限制策略。
3.低效和開銷大的rpc框架
早期rpc通信框架比較簡單，對內通信時候使用的也是短連接。這本來短連接開銷和性能瓶頸超出我們預期，短連接io效率是低一些，但埠資源夠，本身吞吐可以滿足需要，用是沒問題的，很多分層的系統，也有http短連接對內進行請求的
但早期go版本，這樣寫程序，在一定量級情況，是支撐不住的。短連接大量臨時對象和臨時buffer創建，在本已經百萬協程的程序中，是無法承受的。所以後續我們對我們的rpc框架作了兩次調整。
第二版的rpc框架，使用了連接池，通過長連接對內進行通信（復用的資源包括client和server的：編解碼Buffer、Request/response），大大改善了性能。
但這種在一次request和response還是佔用連接的，如果網路狀況ok情況下，這不是問題，足夠滿足需要了，但試想一個room實例要與後面的數百個的register，coordinator，saver，center，keeper實例進行通信，需要建立大量的常駐連接，每個目標機幾十個連接，也有數千個連接被佔用。
非持續抖動時候（持續逗開多少無解），或者有延遲較高的請求時候，如果針對目標ip連接開少了，會有瞬時大量請求阻塞，連接無法得到充分利用。第三版增加了Pipeline操作，Pipeline會帶來一些額外的開銷，利用tcp的全雙特性，以盡量少的連接完成對各個服務集群的rpc調用。
4.Gc時間過長
Go的Gc仍舊在持續改善中，大量對象和buffer創建，仍舊會給gc帶來很大負擔，尤其一個佔用了25G左右的程序。之前go team的大咖郵件也告知我們，未來會讓使用協程的成本更低，理論上不需要在應用層做更多的策略來緩解gc.
改善方式，一種是多實例的拆分，如果公司沒有埠限制，可以很快部署大量實例，減少gc時長，最直接方法。不過對於360來說，外網通常只能使用80和433。因此常規上只能開啟兩個實例。當然很多人給我建議能否使用SO_REUSEPORT，不過我們內核版本確實比較低，並沒有實踐過。
另外能否模仿nginx，fork多個進程監控同樣埠，至少我們目前沒有這樣做，主要對於我們目前進程管理上，還是獨立的運行的，對外監聽不同埠程序，還有配套的內部通信和管理埠，實例管理和升級上要做調整。
解決gc的另兩個手段，是內存池和對象池,不過最好做仔細評估和測試，內存池、對象池使用，也需要對於代碼可讀性與整體效率進行權衡。
這種程序一定情況下會降低並行度，因為用池內資源一定要加互斥鎖或者原子操作做CAS，通常原子操作實測要更快一些。CAS可以理解為可操作的更細行為粒度的鎖（可以做更多CAS策略，放棄運行，防止忙等）。這種方式帶來的問題是，程序的可讀性會越來越像C語言，每次要malloc，各地方用完後要free，對於對象池free之前要reset，我曾經在應用層嘗試做了一個分層次結構的「無鎖隊列」
上圖左邊的數組實際上是一個列表，這個列表按大小將內存分塊，然後使用atomic操作進行CAS。但實際要看測試數據了，池技術可以明顯減少臨時對象和內存的申請和釋放，gc時間會減少，但加鎖帶來的並行度的降低，是否能給一段時間內的整體吞吐量帶來提升，要做測試和權衡…
在我們消息系統，實際上後續去除了部分這種黑科技，試想在百萬個協程裡面做自旋操作申請復用的buffer和對象，開銷會很大，尤其在協程對線程多對多模型情況下，更依賴於golang本身調度策略，除非我對池增加更多的策略處理，減少忙等，感覺是在把runtime做的事情，在應用層非常不優雅的實現。普遍使用開銷理論就大於收益。
但對於rpc庫或者codec庫，任務池內部，這些開定量協程，集中處理數據的區域，可以嘗試改造~
對於有些固定對象復用，比如固定的心跳包什麼的，可以考慮使用全局一些對象，進行復用，針對應用層數據，具體設計對象池，在部分環節去復用，可能比這種無差別的設計一個通用池更能進行效果評估.
消息系統的運維及測試
下面介紹消息系統的架構迭代和一些迭代經驗，由於之前在其他地方有過分享，後面的會給出相關鏈接，下面實際做個簡單介紹，感興趣可以去鏈接裡面看
架構迭代~根據業務和集群的拆分，能解決部分灰度部署上線測試，減少點對點通信和廣播通信不同產品的相互影響，針對特定的功能做獨立的優化.
消息系統架構和集群拆分，最基本的是拆分多實例，其次是按照業務類型對資源佔用情況分類，按用戶接入網路和對idc布點要求分類（目前沒有條件，所有的產品都部署到全部idc）
系統的測試go語言在並發測試上有獨特優勢。
對於壓力測試，目前主要針對指定的伺服器，選定線上空閑的伺服器做長連接壓測。然後結合可視化，分析壓測過程中的系統狀態。但壓測早期用的比較多，但實現的統計報表功能和我理想有一定差距。我覺得最近出的golang開源產品都符合這種場景，go寫網路並發程序給大家帶來的便利，讓大家把以往為了降低復雜度，拆解或者分層協作的組件，又組合在了一起。
Q&A
Q1:協議棧大小，超時時間定製原則？
移動網路下超時時間按產品需求通常2g，3G情況下是5分鍾，wifi情況下5~8分鍾。但對於個別場景，要求響應非常迅速的場景，如果連接idle超過1分鍾，都會有ping，pong，來校驗是否斷線檢測，盡快做到重新連接。
Q2:消息是否持久化？
消息持久化，通常是先存後發，存儲用的redis，但落地用的mysql。mysql只做故障恢復使用。
Q3:消息風暴怎麼解決的？
如果是發送情況下，普通產品是不需要限速的，對於較大產品是有發送隊列做控速度，按人數，按秒進行控速度發放，發送成功再發送下一條。
Q4:golang的工具鏈支持怎麼樣？我自己寫過一些小程序千把行之內，確實很不錯，但不知道代碼量上去之後，配套的debug工具和profiling工具如何，我看上邊有分享說golang自帶的profiling工具還不錯，那debug呢怎麼樣呢，官方一直沒有出debug工具，gdb支持也不完善，不知你們用的什麼？
是這樣的，我們正常就是println，我感覺基本上可以定位我所有問題，但也不排除由於並行性通過println無法復現的問題，目前來看只能靠經驗了。只要常見並發嘗試，經過分析是可以找到的。go很快會推出調試工具的~
Q5:協議棧是基於tcp嗎？
是否有協議拓展功能？協議棧是tcp，整個系統tcp長連接，沒有考慮擴展其功能~如果有好的經驗，可以分享~
Q6:問個問題，這個系統是接收上行數據的吧，系統接收上行數據後是轉發給相應系統做處理么，是怎麼轉發呢，如果需要給客戶端返回調用結果又是怎麼處理呢？
系統上行數據是根據協議頭進行轉發，協議頭裡面標記了產品和轉發類型，在coordinator裡面跟進產品和轉發類型，回調用戶，如果用戶需要阻塞等待回復才能後續操作，那通過再發送消息，路由回用戶。因為整個系統是全非同步的。
Q7:問個pushsdk的問題。pushsdk的單連接，多app復用方式，這樣的情況下以下幾個問題是如何解決的：1）系統流量統計會把所有流量都算到啟動連接的應用吧？而啟動應用的連接是不固定的吧？2）同一個pushsdk在不同的應用中的版本號可能不一樣，這樣暴露出來的介面可能有版本問題，如果用單連接模式怎麼解決？
流量只能算在啟動的app上了，但一般這種安裝率很高的app承擔可能性大，常用app本身被檢測和殺死可能性較少，另外消息下發量是有嚴格控制 的。整體上用戶還是省電和省流量的。我們pushsdk盡量向上兼容，出於這個目的，push sdk本身做的工作非常有限，抽象出來一些常見的功能，純推的系統，客戶端策略目前做的很少，也有這個原因。
Q8:生產系統的profiling是一直打開的么？
不是一直打開，每個集群都有采樣，但需要開啟哪個可以後台控制。這個profling是通過介面調用。
Q9:面前系統中的消息消費者可不可以分組？類似於Kafka。
客戶端可以訂閱不同產品的消息，接受不同的分組。接入的時候進行bind或者unbind操作
Q10:為什麼放棄erlang,而選擇go，有什麼特別原因嗎？我們現在用的erlang？
erlang沒有問題，原因是我們上線後，其他團隊才做出來，經過qa一個部門對比測試，在沒有顯著性能提升下，選擇繼續使用go版本的push，作為公司基礎服務。
Q11:流控問題有排查過網卡配置導致的idle問題嗎？
流控是業務級別的流控，我們上線前對於內網的極限通信量做了測試，後續將請求在rpc庫內，控制在小於內部通信開銷的上限以下.在到達上限前作流控。
Q12:服務的協調調度為什麼選擇zk有考慮過raft實現嗎？golang的raft實現很多啊，比如Consul和ectd之類的。
3年前，還沒有後兩者或者後兩者沒聽過應該。zk當時公司內部成熟方案，不過目前來看，我們不準備用zk作結合系統的定製開發，准備用自己寫的keeper代替zk，完成配置文件自動轉數據結構，數據結構自動同步指定進程，同時裡面可以完成很多自定義的發現和控制策略，客戶端包含keeper的sdk就可以實現以上的所有監控數據，profling數據收集，配置文件更新，啟動關閉等回調。完全抽象成語keeper通信sdk，keeper之間考慮用raft。
Q13:負載策略是否同時在服務側與CLIENT側同時做的 (DISPATCHER 會返回一組IP)？另外，ROOM SERVER/REGISTER SERVER連接狀態的一致性|可用性如何保證? 服務側保活有無特別關注的地方? 安全性方面是基於TLS再加上應用層加密?
會在server端做，比如重啟操作前，會下發指令類型消息，讓客戶端進行主動行為。部分消息使用了加密策略，自定義的rsa+des，另外滿足我們安全公司的需要，也定製開發很多安全加密策略。一致性是通過冷備解決的，早期考慮雙寫，但實時狀態雙寫同步代價太高而且容易有臟數據，比如register掛了，調用所有room，通過重新刷入指定register來解決。
Q14:這個keeper有開源打算嗎？
還在寫，如果沒耦合我們系統太多功能，一定會開源的，主要這意味著，我們所有的bind在sdk的庫也需要開源~
Q15:比較好奇lisence是哪個如果開源？
④ 關於mosquitto怎麼用c語言實現消息的訂閱和發送（mqtt）
1.目標：測試Mosquitto使用MQTT協議發消息的相關性能指標，包含發送速度，並發負載能力，資源佔用，消息到達率。
2.MQTT協議簡介：
1).建立長連接。客戶端發起請求和服務端建立長連接，建立成功後，服務端會返回ACK(CONNACK)
2).客戶端訂閱：客戶端發起訂閱，訂閱成功後，服務端會返回ACK(SUBACK)
3).發消息：發布者會給服務端發消息，服務端在把消息給合適的客戶端。
Qos=0(服務質量)：客戶端消息收到後，不會發出ACK給服務端(PUBACK)。
Qos =1:服務端會發ACK給發布者，客戶端收到消息後會發ACK給服務端。
4).取消訂閱：客戶端發起取消訂閱，服務端返回ACK(UNSUBACK)
5)Pingreq&Pingresp:客戶端和服務端會保持心跳。
3.存在問題：
1. 如何模擬出40W的用戶
2. 如何長連接，訂閱，發消息，取消訂閱，Pingreq行為如何實現。
4. python開源庫 Mosquitto.py，解決所有問題
1. 模擬40W用戶
a)可以使用虛擬機和Mosquitto.py實現，具體為：一般一台虛擬機最多是6W+的模擬數據（需要修改句柄數，我使用5W），方法是Client_id可以簡單的做出5W個來，然後調用Mosquitto裡面的connect方法，建立長連接。准備8台虛擬機就可以實現40W客戶端的模擬
2.行為的模擬
a)訂閱：Mosquitto.subscribe / 發消息：Mosquitto.publish / 取消訂閱：Mosquitto.unsubscribe。 簡單一句話 Mosquitto庫實現所有的行為.
5. 指標：發送速度，到達率，並發負載，資源佔用。
a. 發送速度：服務端日誌記錄，分析解決
b. 到達率： 1.客戶端記錄下收到消息，分析計算。2.計算服務端收到的PUBACK（客戶端收到消息返回的ACK），進行計算
c. 並發負載：5W 用戶不斷增加，注意觀察服務端的負載情況。
e.資源佔用：其實主要是cpu/mem/帶寬：cpu多核的話需要觀察top命令下的_id欄位, mem可以觀察free -h命令的剩餘mem, 帶寬可以使用mpstat進行觀察
6. 可以遇見問題：
a. 模擬客戶端的虛擬機需要修改句柄數才能支持5W的客戶端模擬數量
b. 要先吃透MQTT協議的流程，吃透了進行測試會非常的方便
c. Clear session，設置為true則不為客戶端保留休息，設置為false保留消息。其實就是客戶端離線後在連接上可以收到之前推出的消息。
⑤ TUXEDO調服務時，客戶端返回tpcall錯誤：tpforward tpacall failure TPENOENT - no entry found。
Tuxedo介紹 原創
2016-04-02 21:23:02
11點贊
waterxcfg304
碼齡14年
關注
1、Tuxedo介紹
Tuxedo 是什麼？
Tuxedo是BEA公司（現已被Oracle公司收購）的一個客戶機/伺服器的「中間件」產品，它在客戶機和伺服器之間進行調節，以保證正確地處理事務。它用C語言技術開發的並且有很高性能。
TUXEDO是在、Internet 這樣的分布式運算環境中開發和管理三層結構的客戶/伺服器型關鍵任務應用系統的強有力工具。它具備分布式事務處理和應用通信功能，並提供完善的各種服務來建立、運行和管理關鍵任務應用系統。開發人員能夠用它建立跨多個硬體平台、資料庫和操作系統的可互操作的應用系統。
Tuxedo 的主要作用是：
屏蔽分布式環境中各種通信協議、硬體體系結構、操作系統、資料庫和其它應用服務等方面的差異，使分布於網路節點上的應用程序的各個單元部件之間能夠進行互操作，並協調操作的一致性和完整性，最大限度地節省系統資源，提高系統性能。
* Tuxedo 已經廣泛地應用於金融、電信、製造業等各行各業的核心業務系統。
三層架構
從左邊往右依次為：客戶端層（表現層），中間件服務層（業務邏輯層），資料庫伺服器層（數據層）。這種典型的三層架構應用非常廣泛。對於應用weblogic中間件的系統一般採用的B/S架構，絕大部分採用HTTP協議，少量的系統用java編寫的客戶端，使用的是RMI 協議，或J2EE里的其它協議。
對於tuxedo中間件使用的是tuxedo協議，前端開發工具可以是各式各樣，VC++ 、java 、Delphi 、VB 等。
Tuxedo 的通訊過程
Tuxedo 伺服器處理請求的方式與apache有本質的區別。
Apache伺服器處理請求，由客戶端發出請求到伺服器，由伺服器對請求進行處理後將數據返回給客戶端。
Tuxedo 伺服器一次請求需要兩次進行兩次交互，Tuxedo有兩個負責通訊的進程，一個為WSL，WSL的數量可以進行配置，典型的配置一般兩、三個；WSH可以有N多個。客戶端通過IP地址和埠號與WSL建立連接，由WSL認證請求是否合法，在WSL的響應中包含了另外一個IP地址和埠號；然後，客戶端通過拿到的新的IP地址和埠號去請求WSH 。
客戶端程序由GUI 與 Tuxeo通訊兩部分組成，GUI部分主要由開發人員關心如何設計，通訊部分可能設計成幾個函數供開發人員調用。對於性能測試人員可能更關心客戶端與伺服器之間的通訊過程。
2、tuxedo相關概念
IPC: Inter-Process Communication 進程間通信: 管道、信號量（semaphore）、共享內存（shared memory）、消息隊列（Message Queue）。
管道是UNIX系統IPC的最古老形式，數據只能單向流動。
Tuxedo在客戶機和伺服器通信中大量使用UNIX系統的消息隊列。
SSSO(Single Server Single Queue)模式：每個客戶機都有一個響應隊列來接受客戶端請求。
MSSO(Multiple Server Single Queue)模式：多個伺服器共享同一個請求隊列。
信號量包含一個計數器，表示某個資源正在被訪問和訪問的次數，用來控制多線程對共享數據的訪問。
Tuxedo使用共享內存存儲公告牌，用來公告進程狀態信息和需要在進程間共享或傳遞的數據。
-------------------------------------------------------------
Tuxedo的配置文件稱為UBBCONFIG或ubb，包含了域（Domain）、邏輯機器(Machine)、伺服器組(Group)、服務進程(Server)、服務(Service)的定義。運行前，需要把UBBCONFIG裝載成二進制文件，稱為TUXCONFIG。
Tuxedo服務啟動時，執行tpsvrinit()函數，可以打開一些如資料庫之類的資源供以後使用
Tuxedo服務停止時，執行tpsvrdown()函數，關閉資源
服務程序調用tpreturn()函數來結束服務請求，並返回一個緩沖區，必要時，將它傳給客戶程序。
--------------------------------------------------------
ATMI環境支持的C/S通信方式：請求/應答式通信、回話通信、隊列通信、事件代理通信、消息通知
請求/應答式通信：同步調用(tpcall)、非同步調用(tpacall)、嵌套調用、轉發調用(tpforward)
轉發調用和嵌套調用類似，不同的是最里層的嵌套服務可以直接給客戶程序一個響應，而不必按照調用棧 逐級返回。
回話方式：tpsend()/tprecv() 基於事件，分通告和代理
void (**p)(): 定義了一個指向函數指針的指針p
tpsetunsol(p) : 將p指向的函數func設置為客戶機的事件處理器。
tpchkunsol(): 檢查意外事件
事件代理： tppost()/tpsubscribe() 消息發布/訂閱
Tuxedo提供了兩個事件代理器(TMUSREVT TMSYSEVT)來處理訂閱請求。
隊列存儲： tpenqueue() / tpdequeue()
Tuxedo/Q用到了Tuxedo提供的兩個伺服器：消息隊列伺服器(TMQUEUE)和消息轉發伺服器(TMQFORWARD)
---------------------------
多系統多機之間通信需要每台機器上都有一個Bridge進程，通過TCP/IP通信，Bridge進程維持一個長連接，一旦建立不會斷掉。
TUXEDO應用系統的客戶端訪問TUXEDO伺服器上的服務的過程圖:
說明：
WS（Workstation Extension Proct）用於指TUXEDO產品的客戶端部分
WSC Workstation Client
WSL（Workstation Listener） TUXEDO系統自帶的一個SERVER，它偵聽一個指定的埠，WSC最初與該SERVER建立連接
WSH（Workstation Handler）TUXEDO系統自帶的一個SERVER，由它處理WSC與TUXEDO SERVER之間的通訊。
Bulletin Board（公告板）TUXEDO把系統的配置保存在一個共享內存中，該共享內存稱為公告板（BB）
BBL TUXEDO的管理進程，主要對公告板等進行管理
Workstation Client與TUXEDO SERVER建立連接的過程為：
1． WSC 調用tpinit()或tpchkauth()
2． WSC採用在WSNADDR中指定的IP地址與服務端的WSL建立連接
3． WSL為該WSC指定一個WSH，並把該WSH的偵聽埠返回給WSC
4． WSC採用返回的埠與指定的WSH建立連接，並與WSL斷開連接，這之後WSC與TUXEDO SERVER之間的通訊通過WSH進行處理，與WSL無關。
5． tpinit()或tpchkauth()調用返回。
----------------------------------------------------------
單域模式Single-Domain Model。單機模式 Single Host Model, 多機模式Multi-Processor Model
多域模式Multi-Domain Model
⑥ 急求C語言實現雙工非同步長連接源碼！
雙工?就是讀寫分開線程。。。。。。。。。。。如果連接被關閉,就重新打開連接
⑦ c語言epool怎麼和線程池一起使用
一, 背景
先說下我要實現的功能，server端一直在linux平台下面跑，當客戶端有請求過來的時候server端接受到請求，拿到客戶端的數據，根據拿到的數據做出相應的處理，得到處理的結果直接把結果數據發送給客戶端。這樣一個連接的請求結束，我的不是長連接的情況，不會一直保持客戶端的連接。來一個處理一個處理完了就結束了。
二，源碼下載（包括客戶端測試代碼）
我把邏輯處理部分簡單化了，如果這份代碼對你們有用的話，可以自己實現邏輯處理部分。
代碼是要傳入參數的，埠
代碼我已經在Linux下面編譯過了，也測試號了，因為代碼中用到了資料庫，如果你沒有編譯過可能要在Linux下裝MySQL資料庫。
源碼下載地址
三，代碼的簡單介紹
socket接受線程：C語言為了高並發所以選擇了epoll。當程序啟動的時候（g_net_update.c文件中main函數，會啟動一個thread見函數create_accept_task）這個thread就處理一件事情，只管接收客戶端的連接，當有連接進來的時候 通過epoll_ctl函數，把socket fd 加入到epoll裡面去，epoll設置監聽事件EPOLLIN | EPOLLET; 主要是監聽的是加入到epoll中的socket是否可讀(因為我的需求是客戶端連上了server就會馬上向server發送一份數據的)。其它的部分在主線程中處理。
主線程：是一個無線循環，epoll_wait 函數相當於把客戶端的連接從epoll中拿出來（因為我們監聽的是EPOLLIN | EPOLLET）說明這個時候客戶端有數據發送過來）。再通過recv_buffer_from_fd 函數把客戶端發送過來的數據讀出來。然後其他的一切就拋給線程池去處理。
線程池：(代碼中我會在池裡面創建15個線程) 雙向鏈表。加入線程就是在鏈表後面加一個鏈表項，鏈表的前面會一個一個被拿出來處理。主要是malloc 函數free函數，sem_wait函數sem_post的處理（sem_wait 會阻塞當值大於0是會減一，sem_post是值加一）。typedef void* (FUNC)(void arg, int index);是我們自定義的線程的邏輯處理部分，arg是參數，index是第幾個線程處理(我們隱形的給每個線程都標了號)，例如代碼中的respons_stb_info，更加具體可以看看代碼裡面是怎麼實現的。聰明的你也可以改掉這塊的內容改成動態線程池，當某個時刻的處理比較多的時候能夠動態的增加線程，而不像我代碼裡面的是固定的。
資料庫連接池：按照我的需求在處理客戶端請求數據的時候是要訪問資料庫的。就是一下子創建出一堆的數據連接。要訪問資料庫的時候先去資料庫連接池中找出空閑的連接，具體可以看下代碼。使用的時候可以參考下database_process.c文件（代碼中資料庫連接池和線程池中的個數是一樣的）。這里我想說下get_db_connect_from_pool這個函數，我用了隨機數，我是為了不想每次都從0開始去判斷哪個連接沒有用到。為了資料庫連接池中的每個鏈接都能等概率的使用到，具體的還是可以看下代碼的實現。
log文件，代碼中是可以自動保存log信息到文件中去的，具體可以看下代碼。
四，碰到的一些問題和解決辦法
最初的時候server程序跑起來佔掉了linux 90%多的使用率，因為是我們在create_accept_task 中socket沒有設置成阻塞的。
server經常碰到一些莫名其妙的死機，沒辦法用了core mp 去抓死機的堆棧信息看在哪個函數死機的。
在處理資料庫的時候有的數據會自動的斷掉(說是說8個小時) 後來採用的辦法是每次都先mysql_ping一次讓他重新連接上。
就說幾點吧，其實還有好多其他的就不說了。
五，在Linux下面用到的幾個命令
./server程序名 & //加&後台運行。
killall server程序名 // 停掉server的運行。要在server目錄下面執行
netstat -antp|grep :埠號 // 查看埠下的socket狀態
ps -eaf | grep server程序名 // 檢查程序是否在運行，不過我一般是netstat -antp|grep :埠號 來看程序是否在運行。
好了 就到這里吧，如果你想實現Java的高並發可以稍微看下 Linux java + apache mina + maven 實現高並發伺服器
頂
2
踩
⑧ 為了項目應用，我要學阿里雲伺服器開發，有javase基礎，我是做c語言嵌入式開發的
首先，要注冊域名和購買主機（雲伺服器）。現在的域名都要實名認證了，若是購買國內的主機，域名還需要進行備案才行。假如沒有做備案的准備，可以用香港或者國外主機。
其次，主機購買好後，要搭建好相應的環境。
最後，把項目通過FTP或者其他工具上傳到主機（雲主機）上，綁定好域名做好解析，就可以實現intent訪問了。
樓主如果有域名和伺服器上相關問題，可以與我一起交流！
⑨ tcp長連接編程和短連接編程的區別
長連接就是建立TCP連接後，一直保持這個連接，一般會中間彼此發送心跳來確認對應的存在，中間會做多次業務數據傳輸，一般不會主動斷開連接。
短連接一般指建立連接後，做一些操作 如：http請求，然後就關掉這個連接。所以就做短連接。
⑩ 誰了解長連接半雙工，幫解釋下
短鏈接：connect ...dosometingclose長鏈接：connect...for (; { /* 如果有需要，加個心跳報文用於檢測鏈路狀態，如果鏈路異常，看需求決定是直接close()，還是新連接鏈路。 */ dosometing}永遠不close()雙工：任何 一個套接字都是雙工的，即既可以send，也可以recv。怎麼實現單工： --不知道樓主的半雙工是否指單工邏輯上的單工：創建兩個套接字，一個只用來發，一個只用來收。物理上的單工：在邏輯上的單工基礎上，你也可以使用shutdown來關閉發套接字的接收功能，關閉收套接字的發送功能。但是要切記，shutdow(fd, write) ，是會發送fin的，會讓對方誤以為，你close了，因此，建議僅僅使用邏輯上的單工怎麼實現長鏈單工：創建兩個套接字，一個規定只用來發，一個規定只用來收。 道理同pipe。一個套接字:connect到對方for(; { do something --收或者發，只允許選擇一個}不close。另一個套接字:listenacceptfor(; { do something --收或者發，只允許選擇一個同上面相反的。} 查看原帖>>