最近寫畢設的時候，寫到了資料庫部分，想要非同步操作mysql，發現mysql並未提供對應非同步介面，於是我開始思考是否有辦法自己實現乙個非同步介面。
想實現乙個非同步介面需要什麼條件？
（1）不應該在io操作上阻塞
（2）每條訊息（查詢）必須要有相應標識
對於（1）不必所說，（2）的意思是每條訊息發出去後，非同步callback的時候你要知道這是哪條資訊的回覆。舉個例子，你分別向伺服器傳送了兩個查詢，「小明的id是什麼？」和「小紅的id是什麼？」，過了一會伺服器給你回覆了「1」，「2」。這時候小明的id一定是1嗎？不一定，有可能伺服器先接收到了第二個查詢，然後回覆，也可能是伺服器先接收到了第乙個查詢，但是你收到回覆卻是先收到第二條。這時候非同步是無法保證順序的，因此需要對資訊進行標識。
如何對資訊進行標識呢？方法很多，同步是最容易的一種。「小明的id是什麼？」「1」「小紅的id是什麼？」「2」。這樣一來一回絕對不會出錯。但是我們現在是非同步，那又要怎麼做呢？最暴力的方法是使用短連線，對於每個連線，我就只發一條資訊，利用連線作為訊息的標識。意思就是，連線a傳送了「小明的id是什麼？」連線b傳送了「小紅的id是什麼？」這樣收到訊息也不會亂。這樣做缺點也很明顯，短連線的缺點就是建立和銷毀連線開銷大。還有一種方法是用長連線的，長連線需要在訊息上帶上乙個標識位，比如「訊息id為1，查詢是小明的id是什麼？」「訊息id為2，查詢是小紅的id是什麼？」，收到的回覆是「訊息id為1，答覆是1」「訊息id為2，答覆是2」。這樣也不會亂了。但是這需要伺服器提供對應的介面，需要能回覆帶上訊息id。
說了這麼多，進入例項，如何在mysql上用上這個邏輯？我們操作mysql的時候，都是用官方給的介面，比如c++就有對應的mysql connector。如果這些介面不提供非同步介面，比如說查詢就乙個query介面，你一定要阻塞在那裡直到回覆，那麼很遺憾，上述兩種方法你都用不上。十分悲慘的是，我在mysql connector上沒有找到非同步介面，所以我開始找其他方法。
我想到可以利用協程去解決，但是協程只能解決短連線問題，而且從總體上看，這應該是乙個同步非阻塞模型而非非同步模型。
實在不行，還可以自己封裝乙個mysql connector，只要知道與msql通訊的具體協議就可以做了。但是這樣同樣無法支援長連線的帶訊息id的做法，因為伺服器本身並不支援。對於mysql有個比較投機取巧的方法，就是每次查詢帶上乙個「select msgid」，例如「select 1 and id where name = 小明」。但是我覺得這種方法可能不能做通用，比如不支援update等操作。
最後無計可施，我開始思考是否真的需要非同步。其實要訪問mysql服務的程序和mysql是在同一臺機器上的，這時候同步非同步效能差異並不大，非同步的優勢在於能將等待時間利用流水線優化掉，同機器操作可以忽略等待時間。何況資料庫查詢一般都是最後的步驟了，阻塞非阻塞沒什麼意義，所以我可以直接使用阻塞模型。
如果訪問mysql服務的程序和mysql不在同個機器，非同步是很有必要的。這時候我想到個更合理的做法，就是在mysql服務的機器上增加乙個mysql**，**可以提供非阻塞介面，但是連線mysql服務是阻塞的。可以採用epoll接收請求，然後將請求交給訊息佇列，然後多工作執行緒去佇列獲取請求並阻塞請求mysql。這樣做需要自己定協議，工作量也不小，但是相對於修改mysql的協議來說合理很多。
關於js中Ajax的同步 非同步使用
下面乙個簡單的例子，說明前後端互動中，ajax同步和非同步的使用 1 設定簡單的乙個div，包含觸發事件 companytype hidden id branchhidden name branchhidden value hidden id companytype name companytype...
網路IO模型（同步非同步，阻塞非阻塞）
摘錄自 網路應用需要處理的無非兩大類問題 網路i o,資料計算 網路io的模型大致有如下幾種 同步模型 阻塞非阻塞 多路復用 訊號驅動式 非同步io 網路io的本質是socket的讀取，socket在linux系統被抽象為流，io可以理解為對流的操作。這個操作分為2個階段 1 等待流資料準備 2 從...
關於模型優化的思考
1 提高深度學習模型識別率的準確率的思考 1 資料增強技術 影象翻轉 白化 對訓練資料做一些處理增加資料的抗造效能 2 模型改進，嘗試多種模型 3 調整學習率首先使用較大的學習率進行訓練，觀察目標函式值和驗證集準確率的收斂曲線，如果目標函式值下降速度和驗證集準確率上公升速度出現減緩時，減小學習率。迴...