① 五款常用mysql slow log分析工具的比較
mysql slow log 是用來記錄執行時間較長(超過long_query_time秒)的sql的一種日誌工具
啟用 slow log
有兩種啟用方式:
在f 里 通過 log slow queries[=file_name]
在mysqld進程啟動時 指定–log slow queries[=file_name]選項
比較的五款常用工具
mysqlmpslow mysqlsla myprofi mysql explain slow log mysqllogfilter
mysqlmpslow mysql官方提供的慢查詢日誌分析工具 輸出圖表如下:
主要功能是 統計不同慢sql的
出現次數(Count)
執行最長時間(Time)
累計總耗費時間(Time)
等待鎖的時間(Lock)
發送給客戶端的行總數(Rows)
掃描的行總數(Rows)
用戶以及sql語句本身(抽象了一下格式 比如 limit 用 limit N N 表示)
mysqlsla 推出的一款日誌分析工具(該網站還維護了 mysqlreport mysqlidxc 等比較實用的mysql工具)
整體來說 功能非常強大 數據報表 非常有利於分析慢查詢的原因 包括執行頻率 數據量 查詢消耗等
格式說明如下:
總查詢次數 (queries total) 去重後的sql數量 (unique)
輸出報表的內容排序(sorted by)
最重大的慢sql統計信息 包括 平均執行時間 等待鎖時間 結果行的總數 掃描的行總數
Count sql的執行次數及占總的slow log數量的百分比
Time 執行時間 包括總時間 平均時間 最小 最大時間 時間佔到總慢sql時間的百分比
% of Time 去除最快和最慢的sql 覆蓋率占 %的sql的執行時間
Lock Time 等待鎖的時間
% of Lock %的慢sql等待鎖時間
Rows sent 結果行統計數量 包括平均 最小 最大數量
Rows examined 掃描的行數量
Database 屬於哪個資料庫
Users 哪個用戶 IP 佔到所有用戶執行的sql百分比
Query abstract 抽象後的sql語句
Query sample sql語句
除了以上的輸出 官方還提供了很多定製化參數 是一款不可多得的好工具
mysql explain slow log 德國人寫的一個perl腳本
功能上有點瑕疵 不僅把所有的 slow log 列印到屏幕上 而且統計也只有數量而已 不推薦使用
mysql log filter google code上找到的一個分析工具 提供了 python 和 php 兩種可執行的腳本
log filter/
功能上比官方的mysqlmpslow 多了查詢時間的統計信息(平均 最大 累計) 其他功能都與 mysqlmpslow類似
特色功能除了統計信息外 還針對輸出內容做了排版和格式化 保證整體輸出的簡潔 喜歡簡潔報表的朋友 推薦使用一下
myprofi 純php寫的一個開源分析工具 項目在 sourcefe 上
功能上 列出了總的慢查詢次數和類型 去重後的sql語句 執行次數及其占總的slow log數量的百分比
從整體輸出樣式來看 比mysql log filter還要簡潔 省去了很多不必要的內容 對於只想看sql語句及執行次數的用戶來說 比較推薦
總結
工具/功能 一般統計信息 高級統計信息 腳本 優勢 mysqlmpslow 支持 不支持 perl mysql官方自帶 mysqlsla 支持 支持 perl 功能強大 數據報表齊全 定製化能力強 mysql explain slow log 支持 不支持 perl 無 mysql log filter 支持 部分支持 python or php 不失功能的前提下 保持輸出簡潔 myprofi 支持 不支持 php 非常精簡
lishixin/Article/program/MySQL/201311/29428
② Python - pytest
目錄
pytest是Python的單元測試框架，同自帶的unittest框架類似，但pytest框架使用起來更簡潔，效率更高。
pytest特點
安裝
測試
在測試之前要做的准備
我的演示腳本處於這樣一個的目錄中：
踩坑：你創建的pytest腳本名稱中不允許含有 . ，比如 1.簡單上手.py ，這樣會報錯。當然，可以這么寫 1-簡單上手.py
demo1.py ：
上例中，當我們在執行（就像Python解釋器執行普通的Python腳本一樣）測試用例的時候， pytest.main(["-s", "demo1.py"]) 中的傳參需要是一個元組或者列表（我的pytest是5.2.2版本），之前的版本可能需要這么調用 pytest.main("-s demo1.py") ，傳的參數是str的形式，至於你使用哪種，取決於報不報錯：
遇到上述報錯，就是參數需要一個列表或者元組的形式，而我們使用的是str形式。
上述代碼正確的執行結果是這樣的：
大致的信息就是告訴我們:
pytest.main(["-s", "demo1.py"])參數說明
除了上述的函數這種寫法，也可以有用例類的寫法：
用法跟unittest差不多，類名要以 Test 開頭，並且其中的用例方法也要以 test 開頭，然後執行也一樣。
執行結果：
那麼，你這個時候可能會問，我記得unittest中有setup和teardown的方法，難道pytest中沒有嘛？你怎麼提都不提？穩住，答案是有的。
接下來，我們來研究一下pytest中的setup和teardown的用法。
我們知道，在unittest中，setup和teardown可以在每個用例前後執行，也可以在所有的用例集執行前後執行。那麼在pytest中，有以下幾種情況：
來一一看看各自的用法。
模塊級別setup_mole/teardown_mole
執行結果：
類級別的setup_class/teardown_class
執行結果：
類中方法級別的setup_method/teardown_method
執行結果：
函數級別的setup_function/teardown_function
執行結果：
小結
該腳本有多種運行方式，如果處於PyCharm環境，可以使用右鍵或者點擊運行按鈕運行，也就是在pytest中的主函數中運行：
也可以在命令行中運行：
這種方式，跟使用Python解釋器執行Python腳本沒有什麼兩樣。也可以如下面這么執行：
當然，還有一種是使用配置文件運行，來看看怎麼用。
在項目的根目錄下，我們可以建立一個 pytest.ini 文件，在這個文件中，我們可以實現相關的配置：
那這個配置文件中的各項都是什麼意思呢？
首先， pytest.ini 文件必須位於項目的根目錄，而且也必須叫做 pytest.ini 。
其他的參數：
OK，來個示例。
首先，（詳細目錄參考開頭的目錄結構）在 scripts/test_case_01.py 中：
在 scripts/test_case_dir1/test_case02.py 中：
那麼，在不同的目錄或者文件中，共有5個用例將被執行，而結果則是兩個失敗三個成功。來執行驗證一下，因為有了配置文件，我們在終端中（前提是在項目的根目錄），直接輸入 pytest 即可。
由執行結果可以發現， 2 failed, 3 passed ，跟我們的預期一致。
後續執行相關配置都來自配置文件，如果更改，會有相應說明，終端都是直接使用 pytest 執行。
我們知道在unittest中，跳過用例可以用 skip ，那麼這同樣是適用於pytest。
來看怎麼使用：
跳過用例，我們使用 @pytest.mark.skipif(condition, reason) ：
然後將它裝飾在需要被跳過用例的的函數上面。
效果如下：
上例執行結果相對詳細，因為我們在配置文件中為 addopts 增加了 -v ，之前的示例結果中，沒有加！
另外，此時，在輸出的控制台中， 還無法列印出 reason 信息，如果需要列印，則可以在配置文件中的 addopts 參數的 -s 變為 -rs ：
如果我們事先知道測試函數會執行失敗，但又不想直接跳過，而是希望顯示的提示。
Pytest 使用 pytest.mark.xfail 實現預見錯誤功能：：
需要掌握的必傳參數的是：
那麼關於預期失敗的幾種情況需要了解一下：
結果如下：
pytest 使用 x 表示預見的失敗（XFAIL）。
如果預見的是失敗，但實際運行測試卻成功通過，pytest 使用 X 進行標記（XPASS）。
而在預期失敗的兩種情況中，我們不希望出現預期失敗，結果卻執行成功了的情況出現，因為跟我們想的不一樣嘛，我預期這條用例失敗，那這條用例就應該執行失敗才對，你雖然執行成功了，但跟我想的不一樣，你照樣是失敗的！
所以，我們需要將預期失敗，結果卻執行成功了的用例標記為執行失敗，可以在 pytest.ini 文件中，加入：
這樣就就把上述的情況標記為執行失敗了。
pytest身為強大的單元測試框架，那麼同樣支持DDT數據驅動測試的概念。也就是當對一個測試函數進行測試時，通常會給函數傳遞多組參數。比如測試賬號登陸，我們需要模擬各種千奇百怪的賬號密碼。
當然，我們可以把這些參數寫在測試函數內部進行遍歷。不過雖然參數眾多，但仍然是一個測試，當某組參數導致斷言失敗，測試也就終止了。
通過異常捕獲，我們可以保證程所有參數完整執行，但要分析測試結果就需要做不少額外的工作。
在 pytest 中，我們有更好的解決方法，就是參數化測試，即每組參數都獨立執行一次測試。使用的工具就是 pytest.mark.parametrize(argnames, argvalues) 。
使用就是以裝飾器的形式使用。
只有一個參數的測試用例
來看（重要部分）結果：：
可以看到，列表內的每個手機號，都是一條測試用例。
多個參數的測試用例
（重要部分）結果：
可以看到，每一個手機號與每一個驗證碼都組合一起執行了，這樣就執行了4次。那麼如果有很多個組合的話，用例數將會更多。我們希望手機號與驗證碼一一對應組合，也就是只執行兩次，怎麼搞呢？
在多參數情況下，多個參數名是以 , 分割的字元串。參數值是列表嵌套的形式組成的。
固件（Fixture）是一些函數，pytest 會在執行測試函數之前（或之後）載入運行它們，也稱測試夾具。
我們可以利用固件做任何事情，其中最常見的可能就是資料庫的初始連接和最後關閉操作。
Pytest 使用 pytest.fixture() 定義固件，下面是最簡單的固件，訪問主頁前必須先登錄：
結果：
在之前的示例中，你可能會覺得，這跟之前的setup和teardown的功能也類似呀，但是，fixture相對於setup和teardown來說更靈活。pytest通過 scope 參數來控制固件的使用范圍，也就是作用域。
比如之前的login固件，可以指定它的作用域：
很多時候需要在測試前進行預處理（如新建資料庫連接），並在測試完成進行清理（關閉資料庫連接）。
當有大量重復的這類操作，最佳實踐是使用固件來自動化所有預處理和後處理。
Pytest 使用 yield 關鍵詞將固件分為兩部分， yield 之前的代碼屬於預處理，會在測試前執行； yield 之後的代碼屬於後處理，將在測試完成後執行。
以下測試模擬資料庫查詢，使用固件來模擬資料庫的連接關閉：
結果：
可以看到在兩個測試用例執行前後都有預處理和後處理。
pytest中還有非常多的插件供我們使用，我們來介紹幾個常用的。
先來看一個重要的，那就是生成測試用例報告。
想要生成測試報告，首先要有下載，才能使用。
下載
如果下載失敗，可以使用PyCharm下載，怎麼用PyCharm下載這里無需多言了吧。
使用
在配置文件中，添加參數：
效果很不錯吧！
沒完，看我大招
Allure框架是一個靈活的輕量級多語言測試報告工具，它不僅以web的方式展示了簡潔的測試結果，而且允許參與開發過程的每個人從日常執行的測試中最大限度的提取有用信息。
從開發人員（dev，developer）和質量保證人員（QA，Quality Assurance）的角度來看，Allure報告簡化了常見缺陷的統計：失敗的測試可以分為bug和被中斷的測試，還可以配置日誌、步驟、fixture、附件、計時、執行 歷史 以及與TMS和BUG管理系統集成，所以，通過以上配置，所有負責的開發人員和測試人員可以盡可能的掌握測試信息。
從管理者的角度來看，Allure提供了一個清晰的「大圖」，其中包括已覆蓋的特性、缺陷聚集的位置、執行時間軸的外觀以及許多其他方便的事情。allure的模塊化和可擴展性保證了我們總是能夠對某些東西進行微調。
少扯點，來看看怎麼使用。
Python的pytest中allure下載
但由於這個 allure-pytest 插件生成的測試報告不是 html 類型的，我們還需要使用allure工具再「加工」一下。所以說，我們還需要下載這個allure工具。
allure工具下載
在現在allure工具之前，它依賴java環境，我們還需要先配置Java環境。
注意，如果你的電腦已經有了Java環境，就無需重新配置了。
配置完了Java環境，我們再來下載allure工具，我這里直接給出了網路雲盤鏈接，你也可以去其他鏈接中自行下載：
下載並解壓好了allure工具包之後，還需要將allure包內的 bin 目錄添加到系統的環境變數中。
完事後打開你的終端測試：
返回了版本號說明安裝成功。
使用
一般使用allure要經歷幾個步驟：
來看配置 pytest.ini ：
就是 --alluredir ./report/result 參數。
在終端中輸入 pytest 正常執行測試用例即可：
執行完畢後，在項目的根目下，會自動生成一個 report 目錄，這個目錄下有：
接下來需要使用allure工具來生成HTML報告。
此時我們在終端（如果是windows平台，就是cmd），路徑是項目的根目錄，執行下面的命令。
PS：我在pycharm中的terminal輸入allure提示'allure' 不是內部或外部命令，也不是可運行的程序或批處理文件。但windows的終端沒有問題。
命令的意思是，根據 reportresult 目錄中的數據（這些數據是運行pytest後產生的）。在 report 目錄下新建一個 allure_html 目錄，而這個目錄內有 index.html 才是最終的allure版本的HTML報告；如果你是重復執行的話，使用 --clean 清除之前的報告。
結果很漂亮：
allure open
默認的，allure報告需要HTTP伺服器來打開，一般我們可以通過pycharm來完成，另外一種情況就是通過allure自帶的open命令來完成。
allure的其他用法
當然，故事還是沒有完！在使用allure生成報告的時候，在編寫用例階段，還可以有一些參數可以使用：
allure.title與allure.description
feature和story
由上圖可以看到，不同的用例被分為不同的功能中。
allure.severity
allure.severity 用來標識測試用例或者測試類的級別，分為blocker，critical，normal，minor，trivial5個級別。
severity的默認級別是normal，所以上面的用例5可以不添加裝飾器了。
allure.dynamic
在之前，用例的執行順序是從上到下依次執行：
正如上例的執行順序是 3 1 2 。
現在，來看看我們如何手動控制多個用例的執行順序，這里也依賴一個插件。
下載
使用
手動控制用例執行順序的方法是在給各用例添加一個裝飾器：
那麼， 現在的執行順序是 2 1 3 ，按照order指定的排序執行的。
如果有人較勁傳個0或者負數啥的，那麼它們的排序關系應該是這樣的：
失敗重試意思是指定某個用例執行失敗可以重新運行。
下載
使用
需要在 pytest.ini 文件中， 配置：
給 addopts 欄位新增（其他原有保持不變） --reruns=3 欄位，這樣如果有用例執行失敗，則再次執行，嘗試3次。
來看示例：
結果：
我們也可以從用例報告中看出重試的結果：
上面演示了用例失敗了，然後重新執行多少次都沒有成功，這是一種情況。
接下來，來看另一種情況，那就是用例執行失敗，重新執行次數內通過了，那麼剩餘的重新執行的次數將不再執行。
通過 random 模塊幫助我們演示出在某次執行中出現失敗的情況，而在重新執行的時候，會出現成功的情況，看結果：
可以看到，用例 02 重新執行了一次就成功了，剩餘的兩次執行就終止了。
一條一條用例的執行，肯定會很慢，來看如何並發的執行測試用例，當然這需要相應的插件。
下載
使用
在配置文件中添加：
就是這個 -n=auto ：
並發的配置可以寫在配置文件中，然後其他正常的執行用例腳本即可。另外一種就是在終端中指定，先來看示例：
結果：
pytest-sugar 改變了 pytest 的默認外觀，添加了一個進度條，並立即顯示失敗的測試。它不需要配置，只需 下載插件即可，用 pytest 運行測試，來享受更漂亮、更有用的輸出。
下載
其他照舊執行用例即可。
pytest-cov 在 pytest 中增加了覆蓋率支持，來顯示哪些代碼行已經測試過，哪些還沒有。它還將包括項目的測試覆蓋率。
下載
使用
在配置文件中：
也就是配置 --cov=./scripts ，這樣，它就會統計所有 scripts 目錄下所有符合規則的腳本的測試覆蓋率。
執行的話，就照常執行就行。
結果：
更多插件參考：https://zhuanlan.hu.com/p/50317866
有的時候，在 pytest.ini 中配置了 pytest-html 和 allure 插件之後，執行後報錯：
出現了這個報錯，檢查你配置的解釋器中是否存在 pytest-html 和 allure-pytest 這兩個模塊。如果是使用的pycharm ide，那麼你除了檢查settings中的解釋器配置之外，還需要保證運行腳本的編輯器配置是否跟settings中配置一致。
③ 又漲知識了，清華大學教授推薦Python400集視頻教程，拿走
Python是世界上功能最多，功能最強大的編程語言之一。通過Python，可以編寫自己的應用程序，創建 游戲 ，設計演算法，甚至編程機器人。而且Python的熱度現在一直高居不下，比如，完成同一個任務，C語言要寫1000行代碼，Java只需要寫100行，而Python可能只要20行。
清華北大教授萬贊Python全集視頻教程，這就是你需要的
如果你想選擇一種語言來入門編程，那麼Python絕對是首選！其非常接近自然語言，精簡了很多不必要的分號和括弧，非常容易閱讀理解。編程簡單直接，更適合初學編程者，讓其專注於編程邏輯，而不是困惑於晦澀的語法細節上，比起JAVA、C#和C/C++這些編程語言相對容易很多。
因此，即使是非計算機專業或者沒有基礎的小白，也能分分鍾入門。
但是呢，前提是一定要堅持學習！！！
階段一：Python基礎知識和高級特性
階段二：linux基礎
階段三：資料庫原理和sql優化
階段四：前端web開發
階段五：Python Web後端開發
階段六：爬蟲和數據分析
階段七：Python人工智慧
Python基礎語法的掌握
清華北大教授萬贊Python全集視頻教程，這就是你需要的
1. Python基礎語法的掌握是必備技能，認識到了Python語言的優雅，即使你之前用過其他開發語言，也會轉到Python的行列中
2. 掌握字元串的解析
3. 未來你會意識到各種各樣的程序直接就是把字元串傳來傳去，包括海量日誌分析，日誌即字元串，所以字元串操作就是未來做項目的基礎對文件的操作
4. Linux中一切皆文件，對文件的操作掌握了那麼你會發現在此時你有能力將之前的Linux中的Shell腳本改寫成Python腳本，至於為啥要改寫？腳本更加簡潔、易讀嘛！
5. 掌握面向對象的思想
6. 面向對象思想對於開發程序員來說，不管未來你選擇做哪一方面，使用什麼語言開發，都是必須要掌握的，對於一個開發企業級的持續可擴展的項目至關重要
7. 掌握常見設計模式和排序演算法
8. 設計模式的掌握可以讓你的項目變得更好維護，是一種經驗的總結，排序演算法很多種，項目經常會有取TopN的需求，所以常見設計模式和演算法排序面試官們很喜歡問，也是為後面的項目打好一個扎實的基礎
下面是北京大學畢業的高琪老師親手打造的python學習路線和視頻。共分為7大階段.
現在免費分享給大家哦！獲取在文末！！！
清華北大教授萬贊Python全集視頻教程，這就是你需要的
清華北大教授萬贊Python全集視頻教程，這就是你需要的
第一階段
清華北大教授萬贊Python全集視頻教程，這就是你需要的
python開發基礎和核心特性
1.變數及運算符
2.分支及循環
3.循環及字元串
4.列表及嵌套列表
5.字典及項目練習
6.函數的使用
7.遞歸及文件處理
8.文件
9.面向對象
10.設計模式及異常處理
11.異常及模塊的使用
12.坦克大戰
13.核心編程
14.高級特性
15.內存管理
第二階段
清華北大教授萬贊Python全集視頻教程，這就是你需要的
資料庫和linux基礎
1.並發編程
2.網路通信
3.MySQL
4.Linux
5.正則表達式
第三階段
清華北大教授萬贊Python全集視頻教程，這就是你需要的
web前端開發基礎
1.html基本標簽
2.css樣式
3.css浮動和定位
4.js基礎
5.js對象和函數
6.js定時器和DOM
7.js事件響應
8.使用jquery
9.jquery動畫特效
10.Ajax非同步網路請求
第四階段
清華北大教授萬贊Python全集視頻教程，這就是你需要的
Python Web框架階段
1.Django-Git版本控制
2.Django-博客項目
3.Django-商城項目
4.Django模型層
5.Django入門
6.Django模板層
7.Django視圖層
8.Tornado框架
第五階段
清華北大教授萬贊Python全集視頻教程，這就是你需要的
Python 爬蟲實戰開發
1.Python爬蟲基礎
2.Python爬蟲Scrapy框架
以上這python自學教程我已經為大家打包準備好了，希望對正在學習的你有所幫助！
④ python腳本分析/var/log/secure登錄日誌並處理
因為自己有伺服器，發現/var/log/secure 日誌中最近出現大量驗證失敗的日誌，故找了個腳本跑了下，具體如下
創建成功後給腳本加執行許可權後即可運行，默認將失敗IP錯誤次數達到50次以上的就會加入到/etc/hosts.deny中進行拒絕連接處理。
建議將腳本增加crontab 定時任務自動處理，間隔10分鍾處理一次
⑤ Python日誌—Python日誌模塊logging介紹
從事與軟體相關工作的人，應該都聽過「日誌」一詞。
日誌就是跟蹤軟體運行時事件的方法，為了能夠在程序運行過程中記錄錯誤。
通過日誌記錄程序的運行，方便我們查詢信息，以便追蹤問題、進行維護和調試、還是數據分析。
並且各編程語言都形成了各自的日誌體系和相應的框架。
日誌的作用總結：
首先我們要樹立一個觀點，那就是「不是為了記錄日誌而記錄日誌，日誌也不是隨意記的」。要實現能夠只通過日誌文件還原整個程序執行的過程，達到能透明地看到程序里執行情況，每個線程每個過程到底執行結果的目的。日誌就像飛機的黑匣子一樣，應當能夠復原異常的整個現場乃至細節。
在項目中，日誌這個功能非常重要，我們要重視起來。
在Python中，使用logging模塊來進行日誌的處理。
logging是Python的內置模塊，主要用於將日誌信息進行格式化內容輸出，可將格式化內容輸出到文件，也可輸出到屏幕。
我們在開發過程中，常用print()函數來進行調試，但是在實際應用的部署時，我們要將日誌信息輸出到文件中，方便後續查找以及備份。
在我們使用日誌管理時，我們也可以將日誌格式化成Json對象轉存到ELK中方便圖形化查看及管理。
logging模塊將日誌系統從高向低依次定義了四個類，分別是logger（日誌器）、handler（處理器）、filter(過濾器)和formatter(格式器)。其中由日誌器生成的實例將接管原本日誌記錄函數logging.log的功能。
說明：
我們先來思考下下面的兩個問題：
在軟體開發階段或部署開發環境時，為了盡可能詳細的查看應用程序的運行狀態來保證上線後的穩定性，我們可能需要把該應用程序所有的運行日誌全部記錄下來進行分析，這是非常耗費機器性能的。
當應用程序正式發布或在生產環境部署應用程序時，我們通常只需要記錄應用程序的異常信息、錯誤信息等，這樣既可以減小伺服器的I/O壓力，也可以避免我們在排查故障時被淹沒在日誌的海洋里。
那麼怎樣才能在不改動應用程序代碼的情況下，根據事件的重要性或者稱之為等級，實現在不同的環境中，記錄不同詳細程度的日誌呢？
這就是日誌等級的作用了，我們通過配置文件指定我們需要的日誌等級就可以了。
說明：
總結：
開發應用程序時或部署開發環境時，可以使用DEBUG或INFO級別的日誌獲取盡可能詳細的日誌信息，可以方便進行開發或部署調試。 應用上線或部署生產環境時，應用使用WARNING或ERROR或CRITICAL級別的日誌，來降低機器的I/O壓力和提高獲取錯誤日誌信息的效率。 日誌級別的指定通常都是在應用程序的配置文件中進行指定的。 不同的應用程序所定義的日誌等級會有所差別，根據實際需求來決定。
⑥ python代碼沒錯但運行不出來
python代碼沒錯但運行不出來是什麼原因呢？不知道的小夥伴來看看今天的分享吧！⑦ Loguru：Python 日誌終極解決方案
日誌的作用非常重要，日誌可以記錄用戶的操作、程序的異常，還可以為數據分析提供依據，日誌的存在意義就是為了能夠在程序在運行過程中記錄錯誤，方便維護和調試，能夠快速定位出錯的地方，減少維護成本。每個程序員都應該知道，不是為了記錄日誌而記錄日誌，日誌也不是隨意記的。要實現能夠只通過日誌文件還原整個程序執行的過程，達到能透明地看到程序里執行情況，每個線程、每個過程到底執行到哪的目的。日誌就像飛機的黑匣子一樣，應當能夠復原異常的整個現場乃至細節！
最常見的是把輸出函數 print() 當作日誌記錄的方式，直接列印各種提示信息，常見於個人練習項目里，通常是懶得單獨配置日誌，而且項目太小不需要日誌信息，不需要上線，不需要持續運行，完整的項目不推薦直接列印日誌信息，現實中也幾乎沒有人這么做。
我們可以在不少小項目裡面看到作者自己寫了一個日誌模板，通常利用 print() 或者 sys.stdout 稍微封裝一下即可實現簡單的日誌輸出，這里的 sys.stdout 是 Python 中的標准輸出流， print() 函數是對 sys.stdout 的高級封裝，當我們在 Python 中列印對象調用 print(obj) 時候，事實上是調用了 sys.stdout.write(obj+'\n') ， print() 將內容列印到了控制台，然後追加了一個換行符 \n 。
自寫日誌模板適合比較小的項目，可以按照自己的喜好編寫模板，不需要太多復雜配置，方便快捷，但是這種記錄日誌的方式並不是很規范，有可能你自己覺得閱讀體驗不錯，但是別人在接觸你的項目的時候往往需要花費一定的時間去學習日誌的邏輯、格式、輸出方式等，比較大的項目同樣不推薦這種方法。
一個簡單的自寫日誌模板舉例：
日誌模板 log.py：
調用日誌模塊：
日誌輸出：
在一個完整的項目中，大多數人都會引入專門的日誌記錄庫，而 Python 自帶的標准庫 logging 就是專門為日誌記錄而生的，logging 模塊定義的函數和類為應用程序和庫的開發實現了一個靈活的事件日誌系統。由標准庫模塊提供日誌記錄 API 的關鍵好處是所有 Python 模塊都可以使用這個日誌記錄功能。所以，你的應用日誌可以將你自己的日誌信息與來自第三方模塊的信息整合起來。
logging 模塊雖然強大，但是其配置也是比較繁瑣的，在大型項目中通常需要單獨初始化日誌、配置日誌格式等等，K哥在日常使用中通常都會對 logging 做如下的封裝寫法，使日誌可以按天保存，保留15天的日誌，可以配置是否輸出到控制台和文件，如下所示：
輸出日誌：
它在控制台中是這樣的：
當然，如果你不需要很復雜的功能，希望簡潔一點，僅僅需要在控制台輸出一下日誌的話，也可以只進行簡單的配置：
對於 logging 模塊，即便是簡單的使用，也需要自己定義格式，這里介紹一個更加優雅、高效、簡潔的第三方模塊：loguru，官方的介紹是：Loguru is a library which aims to bring enjoyable logging in Python. Loguru 旨在為 Python 帶來愉快的日誌記錄。這里引用官方的一個 GIF 來快速演示其功能：
Loguru 僅支持 Python 3.5 及以上的版本，使用 pip 安裝即可：
Loguru 的主要概念是只有一個：logger
控制台輸出：
可以看到不需要手動設置，Loguru 會提前配置一些基礎信息，自動輸出時間、日誌級別、模塊名、行號等信息，而且根據等級的不同，還自動設置了不同的顏色，方便觀察，真正做到了開箱即用！
如果想自定義日誌級別，自定義日誌格式，保存日誌到文件該怎麼辦？與 logging 模塊不同，不需要 Handler，不需要 Formatter，只需要一個 add() 函數就可以了，例如我們想把日誌儲存到文件：
我們不需要像 logging 模塊一樣再聲明一個 FileHandler 了，就一行 add() 語句搞定，運行之後會發現目錄下 test.log 裡面同樣出現了剛剛控制台輸出的 debug 信息。
與 add() 語句相反， remove() 語句可以刪除我們添加的配置：
此時控制台會輸出兩條 debug 信息：
而 test.log 日誌文件裡面只有一條 debug 信息，原因就在於我們在第二條 debug 語句之前使用了 remove() 語句。
Loguru 對輸出到文件的配置有非常強大的支持，比如支持輸出到多個文件，分級別分別輸出，過大創建新文件，過久自動刪除等等。 下面我們來詳細看一下 add() 語句的詳細參數：
基本語法：
基本參數釋義：
當且僅當 sink 是協程函數時，以下參數適用：
當且僅當 sink 是文件路徑時，以下參數適用：
這么多參數可以見識到 add() 函數的強大之處，僅僅一個函數就能實現 logging 模塊的諸多功能，接下來介紹幾個比較常用的方法。
add() 函數的 rotation 參數，可以實現按照固定時間創建新的日誌文件，比如設置每天 0 點新創建一個 log 文件：
設置超過 500 MB 新創建一個 log 文件：
設置每隔一個周新創建一個 log 文件：
add() 函數的 retention 參數，可以設置日誌的最長保留時間，比如設置日誌文件最長保留 15 天：
設置日誌文件最多保留 10 個：
也可以是一個 datetime.timedelta 對象，比如設置日誌文件最多保留 5 個小時：
add() 函數的 compression 參數，可以配置日誌文件的壓縮格式，這樣可以更加節省存儲空間，比如設置使用 zip 文件格式保存：
其格式支持： gz 、 bz2 、 xz 、 lzma 、 tar 、 tar.gz 、 tar.bz2 、 tar.xz
Loguru 在輸出 log 的時候還提供了非常友好的字元串格式化功能，相當於 str.format() ：
輸出：
在 Loguru 里可以直接使用它提供的裝飾器就可以直接進行異常捕獲，而且得到的日誌是無比詳細的：
日誌輸出：
在控制台的輸出是這樣的：
相比 Logging，Loguru 無論是在配置方面、日誌輸出樣式還是異常追蹤，都遠優於 Logging，使用 Loguru 無疑能提升開發人員效率。本文僅介紹了一些常用的方法，想要詳細了解可參考 Loguru 官方文檔 或關注 Loguru GitHub 。
⑧ 消息中間件（一）MQ詳解及四大MQ比較
一、消息中間件相關知識
1、概述
消息隊列已經逐漸成為企業IT系統內部通信的核心手段。它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成為非同步RPC的主要手段之一。當今市面上有很多主流的消息中間件，如老牌的ActiveMQ、RabbitMQ，炙手可熱的Kafka，阿里巴巴自主開發RocketMQ等。
2、消息中間件的組成
2.1 Broker
消息伺服器，作為server提供消息核心服務
2.2 Procer
消息生產者，業務的發起方，負責生產消息傳輸給broker，
2.3 Consumer
消息消費者，業務的處理方，負責從broker獲取消息並進行業務邏輯處理
2.4 Topic
2.5 Queue
2.6 Message
消息體，根據不同通信協議定義的固定格式進行編碼的數據包，來封裝業務數據，實現消息的傳輸
3 消息中間件模式分類
3.1 點對點
PTP點對點:使用queue作為通信載體
說明：
消息生產者生產消息發送到queue中，然後消息消費者從queue中取出並且消費消息。
消息被消費以後，queue中不再存儲，所以消息消費者不可能消費到已經被消費的消息。 Queue支持存在多個消費者，但是對一個消息而言，只會有一個消費者可以消費。
說明：
queue實現了負載均衡，將procer生產的消息發送到消息隊列中，由多個消費者消費。但一個消息只能被一個消費者接受，當沒有消費者可用時，這個消息會被保存直到有一個可用的消費者。
4 消息中間件的優勢
4.1 系統解耦
交互系統之間沒有直接的調用關系，只是通過消息傳輸，故系統侵入性不強，耦合度低。
4.2 提高系統響應時間
例如原來的一套邏輯，完成支付可能涉及先修改訂單狀態、計算會員積分、通知物流配送幾個邏輯才能完成；通過MQ架構設計，就可將緊急重要（需要立刻響應）的業務放到該調用方法中，響應要求不高的使用消息隊列，放到MQ隊列中，供消費者處理。
4.3 為大數據處理架構提供服務
通過消息作為整合，大數據的背景下，消息隊列還與實時處理架構整合，為數據處理提供性能支持。
4.4 Java消息服務——JMS
Java消息服務（Java Message Service，JMS）應用程序介面是一個Java平台中關於面向消息中間件（MOM）的API，用於在兩個應用程序之間，或分布式系統中發送消息，進行非同步通信。
5 消息中間件應用場景
5.1 非同步通信
有些業務不想也不需要立即處理消息。消息隊列提供了非同步處理機制，允許用戶把一個消息放入隊列，但並不立即處理它。想向隊列中放入多少消息就放多少，然後在需要的時候再去處理它們。
5.2 解耦
降低工程間的強依賴程度，針對異構系統進行適配。在項目啟動之初來預測將來項目會碰到什麼需求，是極其困難的。通過消息系統在處理過程中間插入了一個隱含的、基於數據的介面層，兩邊的處理過程都要實現這一介面，當應用發生變化時，可以獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的介面約束。
5.3 冗餘
有些情況下，處理數據的過程會失敗。除非數據被持久化，否則將造成丟失。消息隊列把數據進行持久化直到它們已經被完全處理，通過這一方式規避了數據丟失風險。許多消息隊列所採用的」插入-獲取-刪除」範式中，在把一個消息從隊列中刪除之前，需要你的處理系統明確的指出該消息已經被處理完畢，從而確保你的數據被安全的保存直到你使用完畢。
5.4 擴展性
因為消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變代碼、不需要調節參數。便於分布式擴容。
5.5 過載保護
在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量無法提取預知；如果以為了能處理這類瞬間峰值訪問為標准來投入資源隨時待命無疑是巨大的浪費。使用消息隊列能夠使關鍵組件頂住突發的訪問壓力，而不會因為突發的超負荷的請求而完全崩潰。
5.6 可恢復性
系統的一部分組件失效時，不會影響到整個系統。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統恢復後被處理。
5.7 順序保證
在大多使用場景下，數據處理的順序都很重要。大部分消息隊列本來就是排序的，並且能保證數據會按照特定的順序來處理。
5.8 緩沖
在任何重要的系統中，都會有需要不同的處理時間的元素。消息隊列通過一個緩沖層來幫助任務最高效率的執行，該緩沖有助於控制和優化數據流經過系統的速度。以調節系統響應時間。
5.9 數據流處理
分布式系統產生的海量數據流，如：業務日誌、監控數據、用戶行為等，針對這些數據流進行實時或批量採集匯總，然後進行大數據分析是當前互聯網的必備技術，通過消息隊列完成此類數據收集是最好的選擇。
6 消息中間件常用協議
6.1 AMQP協議
AMQP即Advanced Message Queuing Protocol,一個提供統一消息服務的應用層標准高級消息隊列協議,是應用層協議的一個開放標准,為面向消息的中間件設計。基於此協議的客戶端與消息中間件可傳遞消息，並不受客戶端/中間件不同產品，不同開發語言等條件的限制。
優點：可靠、通用
6.2 MQTT協議
MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）是IBM開發的一個即時通訊協議，有可能成為物聯網的重要組成部分。該協議支持所有平台，幾乎可以把所有聯網物品和外部連接起來，被用來當做感測器和致動器（比如通過Twitter讓房屋聯網）的通信協議。
優點：格式簡潔、佔用帶寬小、移動端通信、PUSH、嵌入式系統
6.3 STOMP協議
STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息協議，是一種為MOM(Message Oriented Middleware，面向消息的中間件)設計的簡單文本協議。STOMP提供一個可互操作的連接格式，允許客戶端與任意STOMP消息代理（Broker）進行交互。
優點：命令模式（非topicqueue模式）
6.4 XMPP協議
XMPP（可擴展消息處理現場協議，Extensible Messaging and Presence Protocol）是基於可擴展標記語言（XML）的協議，多用於即時消息（IM）以及在線現場探測。適用於伺服器之間的准即時操作。核心是基於XML流傳輸，這個協議可能最終允許網際網路用戶向網際網路上的其他任何人發送即時消息，即使其操作系統和瀏覽器不同。
優點：通用公開、兼容性強、可擴展、安全性高，但XML編碼格式佔用帶寬大
6.5 其他基於TCP/IP自定義的協議
有些特殊框架（如：redis、kafka、zeroMq等）根據自身需要未嚴格遵循MQ規范，而是基於TCPIP自行封裝了一套協議，通過網路socket介面進行傳輸，實現了MQ的功能。
7 常見消息中間件MQ介紹
7.1 RocketMQ
阿里系下開源的一款分布式、隊列模型的消息中間件，原名Metaq，3.0版本名稱改為RocketMQ，是阿里參照kafka設計思想使用java實現的一套mq。同時將阿里系內部多款mq產品（Notify、metaq）進行整合，只維護核心功能，去除了所有其他運行時依賴，保證核心功能最簡化，在此基礎上配合阿里上述其他開源產品實現不同場景下mq的架構，目前主要多用於訂單交易系統。
具有以下特點：
官方提供了一些不同於kafka的對比差異：
https://rocketmq.apache.org/docs/motivation/
7.2 RabbitMQ
使用Erlang編寫的一個開源的消息隊列，本身支持很多的協議：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它變的非常重量級，更適合於企業級的開發。同時實現了Broker架構，核心思想是生產者不會將消息直接發送給隊列，消息在發送給客戶端時先在中心隊列排隊。對路由(Routing)，負載均衡(Load balance)、數據持久化都有很好的支持。多用於進行企業級的ESB整合。
7.3 ActiveMQ
Apache下的一個子項目。使用Java完全支持JMS1.1和J2EE 1.4規范的 JMS Provider實現，少量代碼就可以高效地實現高級應用場景。可插拔的傳輸協議支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多種語言客戶端 C++、Java、.Net,、Python、 Php、 Ruby等。
7.4 Redis
使用C語言開發的一個Key-Value的NoSQL資料庫，開發維護很活躍，雖然它是一個Key-Value資料庫存儲系統，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務來使用。對於RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試數據分為128Bytes、512Bytes、1K和10K四個不同大小的數據。實驗表明：入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而如果數據大小超過了10K，Redis則慢的無法忍受；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低於Redis。
7.5 Kafka
Apache下的一個子項目，使用scala實現的一個高性能分布式Publish/Subscribe消息隊列系統，具有以下特性：
7.6 ZeroMQ
號稱最快的消息隊列系統，專門為高吞吐量/低延遲的場景開發，在金融界的應用中經常使用，偏重於實時數據通信場景。ZMQ能夠實現RabbitMQ不擅長的高級/復雜的隊列，但是開發人員需要自己組合多種技術框架，開發成本高。因此ZeroMQ具有一個獨特的非中間件的模式，更像一個socket library，你不需要安裝和運行一個消息伺服器或中間件，因為你的應用程序本身就是使用ZeroMQ API完成邏輯服務的角色。但是ZeroMQ僅提供非持久性的隊列，如果down機，數據將會丟失。如：Twitter的Storm中使用ZeroMQ作為數據流的傳輸。
ZeroMQ套接字是與傳輸層無關的：ZeroMQ套接字對所有傳輸層協議定義了統一的API介面。默認支持 進程內(inproc) ，進程間(IPC) ，多播，TCP協議，在不同的協議之間切換只要簡單的改變連接字元串的前綴。可以在任何時候以最小的代價從進程間的本地通信切換到分布式下的TCP通信。ZeroMQ在背後處理連接建立，斷開和重連邏輯。
特性：
二、主要消息中間件的比較
⑨ 使用Python解析nginx日誌文件
本文使用Python2.7解析nginx日誌文件，並把nginx的時間轉化為時間戳（1970紀元後經過的浮點秒數），並存放到特定文件中。
Nginx的http日誌格式：
示例如下：
這里使用Python的glob模塊來獲取所有日誌文件。日誌文件每天0時進行備份，命名為nginx.log.YYMMDD。
模塊linecache允許從任何文件里得到任何的行，並且使用緩存進行優化，常見的情況是從單個文件讀取多行。
使用python的re模塊解析每一條日誌。
其中body_bytes捕獲非空字元串，而不是數字，因為日誌里可能存在該欄位值為「-」，即沒有請求體。
date、method、request等參數可以採用以下方式進行提取。
使用python的time模塊把時間轉為時間戳。
產生文件time.log，內容如下：
⑩ 大型的PHP應用，通常使用什麼應用做消息隊列
一、消息隊列概述x0dx0a消息隊列中間件是分布式系統中重要的組件，主要解決應用耦合，非同步消息，流量削鋒等問題。實現高性能，高可用，可伸縮和最終一致性架構。是大型分布式系統不可缺少的中間件。x0dx0a目前在生產環境，使用較多的消息隊列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。x0dx0a二、消息隊列應用場景x0dx0a以下介紹消息隊列在實際應用中常用的使用場景。非同步處理，應用解耦，流量削鋒和消息通訊四個場景。x0dx0a2.1非同步處理x0dx0a場景說明：用戶注冊後，需要發注冊郵件和注冊簡訊。傳統的做法有兩種1.串列的方式；2.並行方式。x0dx0a（1）串列方式：將注冊信息寫入資料庫成功後，發送注冊郵件，再發送注冊簡訊。以上三個任務全部完成後，返回給客戶端。（架構KKQ：466097527，歡迎加入）x0dx0a（2）並行方式：將注冊信息寫入資料庫成功後，發送注冊郵件的同時，發送注冊簡訊。以上三個任務完成後，返回給客戶端。與串列的差別是，並行的方式可以提高處理的時間。x0dx0a假設三個業務節點每個使用50毫秒鍾，不考慮網路等其他開銷，則串列方式的時間是150毫秒，並行的時間可能是100毫秒。x0dx0a因為CPU在單位時間內處理的請求數是一定的，假設CPU1秒內吞吐量是100次。則串列方式1秒內CPU可處理的請求量是7次（1000/150）。並行方式處理的請求量是10次（1000/100）。x0dx0a小結：如以上案例描述，傳統的方式系統的性能（並發量，吞吐量，響應時間）會有瓶頸。如何解決這個問題呢？x0dx0a引入消息隊列，將不是必須的業務邏輯，非同步處理。改造後的架構如下：x0dx0a按照以上約定，用戶的響應時間相當於是注冊信息寫入資料庫的時間，也就是50毫秒。注冊郵件，發送簡訊寫入消息隊列後，直接返回，因此寫入消息隊列的速度很快，基本可以忽略，因此用戶的響應時間可能是50毫秒。因此架構改變後，系統的吞吐量提高到每秒20 QPS。比串列提高了3倍，比並行提高了兩倍。x0dx0a2.2應用解耦x0dx0a場景說明：用戶下單後，訂單系統需要通知庫存系統。傳統的做法是，訂單系統調用庫存系統的介面。如下圖：x0dx0a傳統模式的缺點：x0dx0a1） 假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗；x0dx0a2） 訂單系統與庫存系統耦合；x0dx0a如何解決以上問題呢？引入應用消息隊列後的方案，如下圖：x0dx0a訂單系統：用戶下單後，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功。x0dx0a庫存系統：訂閱下單的消息，採用拉/推的方式，獲取下單信息，庫存系統根據下單信息，進行庫存操作。x0dx0a假如：在下單時庫存系統不能正常使用。也不影響正常下單，因為下單後，訂單系統寫入消息隊列就不再關心其他的後續操作了。實現訂單系統與庫存系統的應用解耦。x0dx0a2.3流量削鋒x0dx0a流量削鋒也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。x0dx0a應用場景：秒殺活動，一般會因為流量過大，導致流量暴增，應用掛掉。為解決這個問題，一般需要在應用前端加入消息隊列。x0dx0a可以控制活動的人數；x0dx0a可以緩解短時間內高流量壓垮應用；x0dx0a用戶的請求，伺服器接收後，首先寫入消息隊列。假如消息隊列長度超過最大數量，則直接拋棄用戶請求或跳轉到錯誤頁面；x0dx0a秒殺業務根據消息隊列中的請求信息，再做後續處理。x0dx0a2.4日誌處理x0dx0a日誌處理是指將消息隊列用在日誌處理中，比如Kafka的應用，解決大量日誌傳輸的問題。架構簡化如下：x0dx0a日誌採集客戶端，負責日誌數據採集，定時寫受寫入Kafka隊列；x0dx0aKafka消息隊列，負責日誌數據的接收，存儲和轉發；x0dx0a日誌處理應用：訂閱並消費kafka隊列中的日誌數據；x0dx0a以下是新浪kafka日誌處理應用案例：x0dx0a(1)Kafka：接收用戶日誌的消息隊列。x0dx0a(2)Logstash：做日誌解析，統一成JSON輸出給Elasticsearch。x0dx0a(3)Elasticsearch：實時日誌分析服務的核心技術，一個schemaless，實時的數據存儲服務，通過index組織數據，兼具強大的搜索和統計功能。x0dx0a(4)Kibana：基於Elasticsearch的數據可視化組件，超強的數據可視化能力是眾多公司選擇ELK stack的重要原因。x0dx0a2.5消息通訊x0dx0a消息通訊是指，消息隊列一般都內置了高效的通信機制，因此也可以用在純的消息通訊。比如實現點對點消息隊列，或者聊天室等。x0dx0a點對點通訊：x0dx0a客戶端A和客戶端B使用同一隊列，進行消息通訊。x0dx0a聊天室通訊：x0dx0a客戶端A，客戶端B，客戶端N訂閱同一主題，進行消息發布和接收。實現類似聊天室效果。x0dx0a以上實際是消息隊列的兩種消息模式，點對點或發布訂閱模式。模型為示意圖，供參考。x0dx0a三、消息中間件示例x0dx0a3.1電商系統x0dx0a消息隊列採用高可用，可持久化的消息中間件。比如Active MQ，Rabbit MQ，Rocket Mq。（1）應用將主幹邏輯處理完成後，寫入消息隊列。消息發送是否成功可以開啟消息的確認模式。（消息隊列返回消息接收成功狀態後，應用再返回，這樣保障消息的完整性）x0dx0a（2）擴展流程（發簡訊，配送處理）訂閱隊列消息。採用推或拉的方式獲取消息並處理。x0dx0a（3）消息將應用解耦的同時，帶來了數據一致性問題，可以採用最終一致性方式解決。比如主數據寫入資料庫，擴展應用根據消息隊列，並結合資料庫方式實現基於消息隊列的後續處理。x0dx0a3.2日誌收集系統x0dx0a分為Zookeeper注冊中心，日誌收集客戶端，Kafka集群和Storm集群（OtherApp）四部分組成。x0dx0aZookeeper注冊中心，提出負載均衡和地址查找服務；x0dx0a日誌收集客戶端，用於採集應用系統的日誌，並將數據推送到kafka隊列；x0dx0a四、JMS消息服務x0dx0a講消息隊列就不得不提JMS 。JMS（Java Message Service,Java消息服務）API是一個消息服務的標准/規范，允許應用程序組件基於JavaEE平台創建、發送、接收和讀取消息。它使分布式通信耦合度更低，消息服務更加可靠以及非同步性。x0dx0a在EJB架構中，有消息bean可以無縫的與JM消息服務集成。在J2EE架構模式中，有消息服務者模式，用於實現消息與應用直接的解耦。x0dx0a4.1消息模型x0dx0a在JMS標准中，有兩種消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。x0dx0a4.1.1 P2P模式x0dx0aP2P模式包含三個角色：消息隊列（Queue），發送者(Sender)，接收者(Receiver)。每個消息都被發送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留著消息，直到他們被消費或超時。x0dx0aP2P的特點x0dx0a每個消息只有一個消費者（Consumer）(即一旦被消費，消息就不再在消息隊列中)x0dx0a發送者和接收者之間在時間上沒有依賴性，也就是說當發送者發送了消息之後，不管接收者有沒有正在運行，它不會影響到消息被發送到隊列x0dx0a接收者在成功接收消息之後需向隊列應答成功x0dx0a如果希望發送的每個消息都會被成功處理的話，那麼需要P2P模式。（架構KKQ：466097527，歡迎加入）x0dx0a4.1.2 Pub/sub模式x0dx0a包含三個角色主題（Topic），發布者（Publisher），訂閱者（Subscriber） 。多個發布者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。x0dx0aPub/Sub的特點x0dx0a每個消息可以有多個消費者x0dx0a發布者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須創建一個訂閱者之後，才能消費發布者的消息。x0dx0a為了消費消息，訂閱者必須保持運行的狀態。x0dx0a為了緩和這樣嚴格的時間相關性，JMS允許訂閱者創建一個可持久化的訂閱。這樣，即使訂閱者沒有被激活（運行），它也能接收到發布者的消息。x0dx0a如果希望發送的消息可以不被做任何處理、或者只被一個消息者處理、或者可以被多個消費者處理的話，那麼可以採用Pub/Sub模型。x0dx0a4.2消息消費x0dx0a在JMS中，消息的產生和消費都是非同步的。對於消費來說，JMS的消息者可以通過兩種方式來消費消息。x0dx0a（1）同步x0dx0a訂閱者或接收者通過receive方法來接收消息，receive方法在接收到消息之前（或超時之前）將一直阻塞；x0dx0a（2）非同步x0dx0a訂閱者或接收者可以注冊為一個消息監聽器。當消息到達之後，系統自動調用監聽器的onMessage方法。x0dx0aJNDI：Java命名和目錄介面,是一種標準的Java命名系統介面。可以在網路上查找和訪問服務。通過指定一個資源名稱，該名稱對應於資料庫或命名服務中的一個記錄，同時返回資源連接建立所必須的信息。x0dx0aJNDI在JMS中起到查找和訪問發送目標或消息來源的作用。（架構KKQ：466097527，歡迎加入）x0dx0a4.3JMS編程模型x0dx0a(1) ConnectionFactoryx0dx0a創建Connection對象的工廠，針對兩種不同的jms消息模型，分別有QueueConnectionFactory和TopicConnectionFactory兩種。可以通過JNDI來查找ConnectionFactory對象。x0dx0a(2) Destinationx0dx0aDestination的意思是消息生產者的消息發送目標或者說消息消費者的消息來源。對於消息生產者來說，它的Destination是某個隊列（Queue）或某個主題（Topic）;對於消息消費者來說，它的Destination也是某個隊列或主題（即消息來源）。x0dx0a所以，Destination實際上就是兩種類型的對象：Queue、Topic可以通過JNDI來查找Destination。x0dx0a(3) Connectionx0dx0aConnection表示在客戶端和JMS系統之間建立的鏈接（對TCP/IP socket的包裝）。Connection可以產生一個或多個Session。跟ConnectionFactory一樣，Connection也有兩種類型：QueueConnection和TopicConnection。x0dx0a(4) Sessionx0dx0aSession是操作消息的介面。可以通過session創建生產者、消費者、消息等。Session提供了事務的功能。當需要使用session發送/接收多個消息時，可以將這些發送/接收動作放到一個事務中。同樣，也分QueueSession和TopicSession。x0dx0a(5) 消息的生產者x0dx0a消息生產者由Session創建，並用於將消息發送到Destination。同樣，消息生產者分兩種類型：QueueSender和TopicPublisher。可以調用消息生產者的方法（send或publish方法）發送消息。x0dx0a(6) 消息消費者x0dx0a消息消費者由Session創建，用於接收被發送到Destination的消息。兩種類型：QueueReceiver和TopicSubscriber。可分別通過session的createReceiver(Queue)或createSubscriber(Topic)來創建。當然，也可以session的creatDurableSubscriber方法來創建持久化的訂閱者。x0dx0a(7) MessageListenerx0dx0a消息監聽器。如果注冊了消息監聽器，一旦消息到達，將自動調用監聽器的onMessage方法。EJB中的MDB（Message-Driven Bean）就是一種MessageListener。x0dx0a深入學習JMS對掌握JAVA架構，EJB架構有很好的幫助，消息中間件也是大型分布式系統必須的組件。本次分享主要做全局性介紹，具體的深入需要大家學習，實踐，總結，領會。x0dx0a五、常用消息隊列x0dx0a一般商用的容器，比如WebLogic，JBoss，都支持JMS標准，開發上很方便。但免費的比如Tomcat，Jetty等則需要使用第三方的消息中間件。本部分內容介紹常用的消息中間件（Active MQ,Rabbit MQ，Zero MQ,Kafka）以及他們的特點。x0dx0a5.1 ActiveMQx0dx0aActiveMQ 是Apache出品，最流行的，能力強勁的開源消息匯流排。ActiveMQ 是一個完全支持JMS1.1和J2EE 1.4規范的 JMS Provider實現，盡管JMS規范出台已經是很久的事情了，但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。x0dx0aActiveMQ特性如下：x0dx0a⒈ 多種語言和協議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應用協議： OpenWire,Stomp REST,WS Notification,XMPP,AMQPx0dx0a⒉ 完全支持JMS1.1和J2EE 1.4規范 （持久化，XA消息，事務)x0dx0a⒊ 對spring的支持，ActiveMQ可以很容易內嵌到使用Spring的系統裡面去，而且也支持Spring2.0的特性x0dx0a⒋ 通過了常見J2EE伺服器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試，其中通過JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動的部署到任何兼容J2EE 1.4 商業伺服器上x0dx0a⒌ 支持多種傳送協議：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTAx0dx0a⒍ 支持通過JDBC和journal提供高速的消息持久化x0dx0a⒎ 從設計上保證了高性能的集群，客戶端-伺服器，點對點x0dx0a⒏ 支持Ajaxx0dx0a⒐ 支持與Axis的整合x0dx0a⒑ 可以很容易得調用內嵌JMS provider，進行測試x0dx0a5.2 RabbitMQx0dx0aRabbitMQ是流行的開源消息隊列系統，用erlang語言開發。RabbitMQ是AMQP（高級消息隊列協議）的標准實現。支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX，持久化。用於在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。x0dx0a幾個重要概念：x0dx0aBroker：簡單來說就是消息隊列伺服器實體。x0dx0aExchange：消息交換機，它指定消息按什麼規則，路由到哪個隊列。x0dx0aQueue：消息隊列載體，每個消息都會被投入到一個或多個隊列。x0dx0aBinding：綁定，它的作用就是把exchange和queue按照路由規則綁定起來。x0dx0aRouting Key：路由關鍵字，exchange根據這個關鍵字進行消息投遞。x0dx0avhost：虛擬主機，一個broker里可以開設多個vhost，用作不同用戶的許可權分離。x0dx0aprocer：消息生產者，就是投遞消息的程序。x0dx0aconsumer：消息消費者，就是接受消息的程序。x0dx0achannel：消息通道，在客戶端的每個連接里，可建立多個channel，每個channel代表一個會話任務。x0dx0a消息隊列的使用過程，如下：x0dx0a（1）客戶端連接到消息隊列伺服器，打開一個channel。x0dx0a（2）客戶端聲明一個exchange，並設置相關屬性。x0dx0a（3）客戶端聲明一個queue，並設置相關屬性。x0dx0a（4）客戶端使用routing key，在exchange和queue之間建立好綁定關系。x0dx0a（5）客戶端投遞消息到exchange。x0dx0aexchange接收到消息後，就根據消息的key和已經設置的binding，進行消息路由，將消息投遞到一個或多個隊列里。x0dx0a5.3 ZeroMQx0dx0a號稱史上最快的消息隊列，它實際類似於Socket的一系列介面，他跟Socket的區別是：普通的socket是端到端的（1:1的關系），而ZMQ卻是可以N：M 的關系，人們對BSD套接字的了解較多的是點對點的連接，點對點連接需要顯式地建立連接、銷毀連接、選擇協議（TCP/UDP）和處理錯誤等，而ZMQ屏蔽了這些細節，讓你的網路編程更為簡單。ZMQ用於node與node間的通信，node可以是主機或者是進程。x0dx0a引用官方的說法： 「ZMQ(以下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層，像框架一樣的一個socket library，他使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫，可在多個線程、內核和主機盒之間彈性伸縮。ZMQ的明確目標是「成為標准網路協議棧的一部分，之後進入Linux內核」。現在還未看到它們的成功。但是，它無疑是極具前景的、並且是人們更加需要的「傳統」BSD套接字之上的一 層封裝。ZMQ讓編寫高性能網路應用程序極為簡單和有趣。」x0dx0a特點是：x0dx0a高性能，非持久化；x0dx0a跨平台：支持Linux、Windows、OS X等。x0dx0a多語言支持； C、C++、Java、.NET、Python等30多種開發語言。x0dx0a可單獨部署或集成到應用中使用；x0dx0a可作為Socket通信庫使用。x0dx0a與RabbitMQ相比，ZMQ並不像是一個傳統意義上的消息隊列伺服器，事實上，它也根本不是一個伺服器，更像一個底層的網路通訊庫，在Socket API之上做了一層封裝，將網路通訊、進程通訊和線程通訊抽象為統一的API介面。支持「Request-Reply 「，」Publisher-Subscriber「，」Parallel Pipeline」三種基本模型和擴展模型。x0dx0aZeroMQ高性能設計要點：x0dx0a1、無鎖的隊列模型x0dx0a對於跨線程間的交互（用戶端和session）之間的數據交換通道pipe，採用無鎖的隊列演算法CAS；在pipe兩端注冊有非同步事件，在讀或者寫消息到pipe的時，會自動觸發讀寫事件。x0dx0a2、批量處理的演算法x0dx0a對於傳統的消息處理，每個消息在發送和接收的時候，都需要系統的調用，這樣對於大量的消息，系統的開銷比較大，zeroMQ對於批量的消息，進行了適應性的優化，可以批量的接收和發送消息。x0dx0a3、多核下的線程綁定，無須CPU切換x0dx0a區別於傳統的多線程並發模式，信號量或者臨界區， zeroMQ充分利用多核的優勢，每個核綁定運行一個工作者線程，避免多線程之間的CPU切換開銷。x0dx0a5.4 Kafkax0dx0aKafka是一種高吞吐量的分布式發布訂閱消息系統，它可以處理消費者規模的網站中的所有動作流數據。 這種動作（網頁瀏覽，搜索和其他用戶的行動）是在現代網路上的許多社會功能的一個關鍵因素。 這些數據通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。 對於像Hadoop的一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行載入機制來統一線上和離線的消息處理，也是為了通過集群機來提供實時的消費。x0dx0aKafka是一種高吞吐量的分布式發布訂閱消息系統，有如下特性：x0dx0a通過O(1)的磁碟數據結構提供消息的持久化，這種結構對於即使數以TB的消息存儲也能夠保持長時間的穩定性能。（文件追加的方式寫入數據，過期的數據定期刪除）x0dx0a高吞吐量：即使是非常普通的硬體Kafka也可以支持每秒數百萬的消息。x0dx0a支持通過Kafka伺服器和消費機集群來分區消息。x0dx0a支持Hadoop並行數據載入。x0dx0aKafka相關概念x0dx0aBrokerx0dx0aKafka集群包含一個或多個伺服器，這種伺服器被稱為broker[5]x0dx0aTopicx0dx0a每條發布到Kafka集群的消息都有一個類別，這個類別被稱為Topic。（物理上不同Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的Topic即可生產或消費數據而不必關心數據存於何處）x0dx0aPartitionx0dx0aParition是物理上的概念，每個Topic包含一個或多個Partition.x0dx0aProcerx0dx0a負責發布消息到Kafka brokerx0dx0aConsumerx0dx0a消息消費者，向Kafka broker讀取消息的客戶端。x0dx0aConsumer Groupx0dx0a每個Consumer屬於一個特定的Consumer Group（可為每個Consumer指定group name，若不指定group name則屬於默認的group）。x0dx0a一般應用在大數據日誌處理或對實時性（少量延遲），可靠性（少量丟數據）要求稍低的場景使用。