昨天有點事耽誤了... 今天又接著改造... , 在改造的時候遇到了乙個之前就曾經發生的問題: 因為epoll_wait和event處理使用2個不同的執行緒, 這就導致了, 有可能出現, 當event處理執行緒釋放該connection, 但是epoll_wait執行緒已經獲取了該event通知, 並壓入event處理執行緒, 當event處理執行緒再次處理該事件時, 會訪問非法空間一致崩潰 ...
想了半天, 終於有了乙個好想法, 因為現在所有的事件都有乙個event_type, 但其容量很小, 這樣就可以將event_type和fd(或vfd)壓縮在乙個8位元組空間內, 犧牲1個位元組作為event_type, 已經非常滿足需求, 而event處理執行緒在拿到event時, 會先根據型別取出fd(或vfd), 檢視其有效性, 並繼續執行.
這樣就可以解決這種很尷尬的併發問題 :)
不過, 還需要額外注意乙個問題, 系統中現在有兩種event, 一種是使用者讀事件, 一種是timer事件, 這裡我採用hash_tbl作為執行緒之間的管道, 這是為了防止epoll_wait返回的事件具有重複性, 所以保證管道裡的事件具有唯一性, 需要採用k-v方式進行控制, 這樣key的選取就需要保持一致性, 現在考慮的策略就是採用統一的vfd生成管理器生成該key, 從而保證key的唯一有效不重複.
負載平衡問題（網路流）
建圖最大流即可，注意可以在連續運輸多次，剛開始直接從xi連向相鄰的yi了，這樣只是運輸一次，沒有考慮到運輸多次的情況 拆點，分xiyi，對應每個倉庫。從源點向xi連邊，容量為ri，費用為0 從yi向匯點連邊，容量為xba，費用為0 從xi向對應的yi連邊，容量為inf，費用為0 從yi向環形相鄰的x...
Nginx Tomcat負載平衡
最近專案要設計到併發，所以設計專案架構時考慮到用nginx搭建tomcat集群，再用redis搭建分布式session，下面將一步步分享我摸索的過程。nginx的負載均衡模組upstream模組主要支援如下4中排程演算法 1 伺服器輪詢 預設方式 每個請求訪問按照時間順序逐一分配到不同的伺服器端，如...
負載平衡問題
難怪評藍題，實在是太裸了。源點向每個點連邊，容量為這個點的現有貨物數。每個點向匯點連邊，容量為要求即sum n。每個點向其相鄰兩點連邊，容量無限，費用為1。然後跑一遍源點到匯點的費用流。看 includeusing namespace std define int long long define ...