在進行乙個系統的設計時，有這樣的需求，我們面對幾個稀有的資源，卻有大量的併發請求，它們毫無疑問將會是我們將來系統中的瓶頸所在，在實際系統設計中，怎麼樣去解決這些資源的獲取、分配、釋放、以及爭用解決？本文是我在即將過去的今天（還有不到乙個小時）躺在床上抱著本本用比較放鬆的心態，本著交流和**的目的，進行的一些經驗分享。
我不想去涉及具體哪門技術，僅僅只是以方法而論。假設，我們有10個併發請求，但是卻只有三個資源（比如網絡卡、usb介面等裝置)存在，我們要最大限度地利用好這三個資源。最本能的思路是：先想辦法把這3歌資源編到乙個列表中去，來乙個請求，開啟乙個執行緒，去列表中檢視是否有可用的資源，如果存在，鎖定該資源，進行運算，並在運算結束的時候將該裝置解鎖，放回到原來的列表中。而在列表中沒有獲取到資源的請求執行緒則掛起一段時間片，迴圈獲取，設定乙個迴圈超時時間，超時則意味了獲取資源失敗，結束程序。 基本上沒有人不能理解這種模式，這是一種公平爭用模式，易於理解和實現。但是需要提醒大家注意的是，當我們的原子操作對資源呼叫是獨立的時候，這是一種值得推薦的方式，但是當乙個執行緒中的原子操作需要涉及到兩級甚至以上的資源呼叫時候，不要忘記解決好死鎖的問題。
事實上這種公平競爭的模式是不能符合大多數需求的，於是就有了優先順序的出現。跟我們處理執行緒一樣，在上述分配的基礎上給我們的請求加上優先順序機制，即每乙個請求物件都附屬乙個優先順序屬性，我們通過一定規則去設定每個請求物件的優先順序，有空閒資源的時候，優先給優先順序高的請求呼叫。怎麼去設定優先順序由您的需求而定，您甚至可以開啟乙個獨立的執行緒，不斷去check請求列表，並根據您的需要設定優先順序。優先順序就像是一種特別通行證，在公平競爭機制基礎上新增了一種特殊屬性設定介面。這種設計在我所遇到的專案中應用還是比較廣的。
還有一種處理方式，和上述兩種方法有本質的區別。我們這次不去管理資源，而去管理請求。比如，我們依然還是10個併發請求，、3個故鄉資源設 備。和上述不同的是，這次我們不對資源進行列表，每次請求物件過來，我們將他們入隊，並用相應獨立的執行緒去檢測請求是否超期，或者修改物件的優先順序。每當乙個資源裝置空閒的時候，我們定義乙個事件，這個事件觸發執行緒去請求列表中獲取乙個請求，並響應該請求。這樣做的好處是類似於arraylist對於array的優點一樣，你不必在程式執行之前就知道資源的數目，並在元算的過程中對裝置列表進行維護，甚至一些缺乏經驗的設計會使得系統執行一段時間之後因為個別裝置發生異常，卻無法直接反饋給執行緒中的列表，導致沒有意義的異常。而以資源為主動的方式，不需要預先知道到底多少中終端資源，是可以根據實際資源的請求訊號進行繫結。
老婆睡了，偶也老打錯字，不行了，明天繼續！
高併發的解決方案
在大型 中，我們不得不面臨高併發的問題，下面分別介紹一些解決方案。當併發量達到一定程度時，我們可以將靜態資源儲存到專門的伺服器中，這樣主伺服器就可以盡量只處理業務相關的操作。頁面快取是將應用生成的頁面快取起來，這樣就不需要每次都重新生成頁面，從而節省大量cpu資源。如果靜態頁面中有動態資料，只需在頁...
高併發的解決方案
除了資料量大，另乙個常見的問題就是併發量高，很多架構就是針對這個問題設計出來的，下面分別介紹。1.應用和靜態資源分離 2.頁面快取 頁面快取是將應用生成的頁面快取起來，這樣 就不 需要 每次 都 重新 生成 頁面 了，從而 可以 節省 大量 cpu 資源，如果 將 快取 的 頁面 放到 記憶體 中 ...
家庭寬頻共享的解決方案
下面是我配置家庭寬頻共享的一些經驗，分享給需要的朋友。所用的裝置是路由器 交換機，現在這玩意兒都很便宜，一百元基本上可以擁有兩層交換的網路。下面先簡單看看路由器的，這些都是網上找來的，方便理解敘述 下面有三種方案，前兩種最常見不過了，並且前兩種都是從網上找個來說明的，自己懶的畫圖了，第三種是我自己動...