訊息佇列作為一種基礎的抽象資料結構，被廣泛應用在各類程式設計與系統設計中。
同步vs非同步
通訊的乙個基本問題是：發出去的訊息什麼時候需要被接收到？這個問題引出了兩個基礎概念：「同步通訊」和「非同步通訊」。根據理論抽象模型，同步通訊和非同步通訊最本質的差別來自於時鐘機制的有無。同步通訊的雙方需要乙個校準的時鐘，非同步通訊的雙方不需要時鐘。現實的情況是，沒有完全校準的時鐘，所以沒有絕對的同步通訊。同樣，絕對非同步通訊意味著無法控制乙個發出去的訊息被接收到的時間點，無期限的等待乙個訊息顯然毫無實際意義。所以，實際程式設計中所有的通訊既不是「同步通訊」也不是「非同步通訊」；或者說，既是「同步通訊」也是「非同步通訊」。特別是對於應用層的通訊，其底層架構可能既包含「同步機制」也包含「非同步機制」。判斷「同步」和「非同步」訊息的標準問題太深，而不適合繼續展開。這裡給一些啟發式的建議：
當分析乙個通訊需求或者進行通訊構架的時候，工程師們被迫作出「同步」還是「非同步」的決定。當決策的結論是「非同步通訊」的時候，分布式佇列程式設計模型就是乙個備選項。傳送者接收者解耦
在進行通訊需求分析的時候，需要回答的另外乙個基本問題是：訊息的傳送方是否關心誰來接收訊息，或者反過來，訊息接收方是否關心誰來傳送訊息。訊息的傳送方和接收方不關心對方是誰、以及在**，分布式佇列程式設計模型就是乙個備選項。因為在這種場景下，分布式佇列架構所帶來的解耦能給系統架構帶來這些好處：
訊息暫存機制在進行通訊傳送方設計的時候，如果訊息無法被迅速處理掉而產生堆積怎麼辦、能否被直接拋棄？如果根據需求分析，確認存在訊息積存，並且訊息不應該被拋棄，就應該考慮分布式佇列程式設計模型構架，因為佇列可以暫存訊息。如何傳遞
對通訊需求進行架構，一系列的基礎挑戰會迎面而來，這包括：
效能
效能主要有兩個方面需要考慮：吞吐量（throughput）和響應時間（latency）。 不同的訊息佇列中介軟體的吞吐量和響應時間相差甚遠，在選型時可以去網上檢視一些效能對比報告。 對於同一種中介軟體，不同的配置方式也會影響效能。主要有如下幾方面的配置：
可靠性
可靠性主要包含：可用性、持久化、確認機制等。 高可用性的訊息中介軟體應該具備如下特徵：
高可靠的訊息中介軟體應該確保從傳送者接收到的訊息不會丟失。中介軟體**伺服器的宕機並不是小概率事件，所以儲存在記憶體中的訊息很容易發生丟失。大部分的訊息中介軟體都依賴於訊息的持久化去降低訊息丟失損失，即將接收到的訊息寫入磁碟。即使提供持久化，仍有兩個問題需要考慮：
確認機制本質上是通訊的握手機制（handshaking）。如果沒有該機制，訊息在傳輸過程中丟失將不會被發現。高敏感的訊息要求選取具備確認機制的訊息中介軟體。當然如果沒有接收到訊息中介軟體確認完成的指令，應用程式需要決定如何處理。典型的做法有兩個：
客戶端介面所支援語言
採用現存訊息中介軟體就意味著避免重複造輪子。如果某個訊息中介軟體未能提供對應語言的客戶端介面，則意味著極大的成本和相容性問題。
mysql 網際網路 MySQL網際網路業務使用建議
一 基礎規範 表儲存引擎必須使用innodb 表字符集預設使用utf8，必要時候使用utf8mb4 解讀 1 通用，無亂碼風險，漢字3位元組，英文1位元組 2 utf8mb4是utf8的超集，有儲存4位元組例如表情符號時，使用它 禁止使用儲存過程，檢視，觸發器，event 解讀 1 對資料庫效能影響...
網際網路架構
網際網路架構，主要追求的是高可用，可擴充套件 這兩個特性 在這裡做了一些個人的總結，算是給2014年的工作做個總結。推陳出新 一定要做的，死守積累會逐漸丟失人才，但凡技術公司都會不斷更新技術 kiss原則 keep it stupid優秀的 都會很簡單，簡單理解，簡單更改，能把複雜的事情做簡單是一種...
網際網路架構
使用者在同一時間內大量的訪問伺服器，tomcat伺服器併發能力為 200 250左右 jvm調優為1000 硬體條件 物理伺服器處理能力 網路頻寬 2.1 分布式計算 由多個執行緒，共同來完成某項特定的任務，拆合問題 2.2 分布式系統 distributed system 是建立在網路之上的軟體系...