4月12日，gops全球運維大會在深圳隆重召開，全球運維大會是國內第乙個運維行業大會，愛可開源社群在基礎架構及devops解決方案專場分享了《基於分布式中介軟體的sql改造指南》的主題演講。
「以下為正文部分」
在一般sql中，乙個單錶查詢的sql往往是最簡單的，而在中介軟體中也沒什麼區別，中介軟體中將乙個對於單錶的字段查詢作為最簡單的sql進行處理。
下面先來簡單的回顧下中介軟體中的**處理的最基礎方式。
中介軟體會按照在配置檔案中既定的資料拆分的設定，對於「使用者表」這個**的資料進行拆分，將每條通過中介軟體插入的資料按照規則進行分布，圖上給的例子是按照「使用者表」的id奇偶性進行了資料的拆分。
有了合理的資料分布之後就是中介軟體是如何在需要的時候取用資料，在中介軟體中，對於基礎sql，也就是單錶的資料查詢分為一下兩個情況：
在查詢的簡單sql附帶有分片條件時，中介軟體根據sql語**析的結果，根據這個分片條件對於資料可能存在的db進行計算，最終把sql**到對應的db中進行執行，查詢出最終的正確結果。
在這個過程中就存在乙個現象，即「這乙個查詢需要等待最慢的那個db查詢結束」。
上文中有提及廣播型別的簡單sql存在乙個特徵「需要等待最慢的那個db查詢結束」，當分片數量持續上公升的時候，如下圖所示的場景，需要等待的連線數量會持續變多。
可以通過概率的方法分析下當連線數量增長的時候會發生什麼變化：
通過matlab對於中介軟體廣播查詢的場景進行了如下的模擬，可以發現在隨著需要等待連線數量的上公升，整體的中介軟體響應速度會有乙個成倍的下降，從單個連線平均5ms的查詢延遲一直上公升到100連線時候的接近15ms的整體延遲。
針對以上的場景，提出在中介軟體中進行單錶查詢的時候，盡量降低單個sql涉及到的後端db數量，具體方法是在sql中給**新增分片列的限定條件，就像select * from 使用者表 where id = 1中的這個條件id =1。
單錶查詢不能覆蓋應用對於sql的需求，中介軟體中就引入了er關係的概念。
er關係指的是兩個**在邏輯上就擁有的從屬關係，如下圖中所示的使用者表和訂單表：
當兩個表或者更多的**存在這樣邏輯上的從屬關係的時候，在中介軟體中把這些關係定義為er關係，並且當乙個查詢語句有且僅有存在er關係的**關聯組成的時候，這個sql被稱為「er**join」。
當兩個**能夠被定義為er關係的時候，中介軟體能夠按照之間的關聯關係組織資料的儲存，最後的儲存方式如下圖所示：
可以看到大致的結果就是子表（訂單表）的資料會被存放在父表（使用者表）對應資料的db節點。
當出現這種資料分布的時候，就可以在db1中查詢到上例中張三的使用者和他的所有資料，所以中介軟體就能直接把sql語句下發到對應節點進行執行。
可以看到er的這種查詢方式是有一定的侷限的，需要把查詢的**宣告為er關係，並且er關係還是單向的，就是乙個表只能是某乙個表的子表，乙個分片表不能擁有兩個父表。
其次就是由於這個er關聯的查詢處理是和上文的簡單查詢在本質上是一樣的，就是查詢sql下發到db中來執行，所以在注意事項上也是一致的，盡量在使用的時候提供能夠確定分片的限定條件。
事實上上文所有的查詢方法限制都是非常大的，但是往往應用的sql無法滿足於被限制在這麼侷限的範圍內，那中介軟體中就有另一種機制來實現更廣泛意義上的sql執行，跨庫**關聯查詢。
當我的sql內容無法被定義進入上文的兩個「簡單sql」或者是「er sql」的時候，中介軟體就會使用這種跨庫**join的方式來處理這個問題，當然並非所有的中介軟體都有實現對應的功能，在這裡僅討論實現的部分中介軟體的實現邏輯。
以下是在中介軟體中執行跨庫表查詢的這麼乙個大致執行邏輯圖，圖中可以看到整體的執行邏輯是從每個db中分別取tablea和tableb的資料，最終在中介軟體中進行資料的整理組織和對比:
具體的跨庫查詢的執行過程可以被歸納為以下的幾個步驟：
在這個過程中會產生幾個方面的資源消耗：
另乙個方面就是中介軟體由於不能儲存真實的資料，所以無法像mysql優化器一樣提前計算不同**的聚合代價，這麼一來，中介軟體就直接按照sql中原有的**聚合順序進行資料的聚合和整理，這可能帶來以下的sql執行的計畫。
案例中使用者表由於**順序的問題先和沒有直接關係的商品表進行了表關聯,這樣一來這裡的中間結果就出現了乙個笛卡爾積,也就是無條件無字段的關聯結果,其結果為雙邊資料的乘積：
1000x1000=1000000
如果sql中的**順序進行進一步的優化,則可以在同樣的sql中獲得以下圖中的執行順序。
這次我們優化完成之後的查詢中間結果將由使用者表和有關係的訂單表優先聚合完成，因為他們之間的關係，最多存在2000條中間結果，相比與上例中的1000000條來說，整個sql執行效率上得到了很大的優化。
針對以上的幾種消耗型別，可以通過以下的幾個手段進行降低消耗的量以獲取最好的執行效果：
1.在中介軟體中盡量使用分片條件進行資料的查詢，不論整個sql是屬於簡單sql，er查詢或者是複雜查詢。
2.在複雜查詢的狀態下，優化方向為中介軟體中處理的資料盡量少，此目標可以通過給**新增限定條件，選擇更加重複率低的關聯列以及調整sql中的**關聯順序來達成。
基於訊息中介軟體的分布式事務
關於分布式事務的實現，網上有很多解說，當然這也是面試官的常備面試題。很多朋友在工作中很少接觸到分布式事務，認為這個玩意互動太多，沒必要。其實我也是這麼想的，想要完成乙個完整的分布式事務鏈路，通訊開銷實在太多。而現如今，微服務架構在行業內大行其道，恨不得所有模組都用上微服務來管理，而不知道自己已經慢慢...
分布式訊息中介軟體
一 分布式訊息中介軟體入門 訊息中介軟體主要實現分布式系統中解耦 非同步訊息 流量銷鋒 日誌處理等場景。現在生產中用得最多的訊息佇列有 activemq,rabbitmq,kafka,rocketmq 等。jms 規範 類似於 jdbc 的一套介面規範，但不同的是他是面向的訊息服務，提供一套標準 a...
訊息中介軟體MQ 基於RabbitMQ分布式事務處理
rabbitmq是開源的amqp 一種訊息佇列協議，適合金融行業，高可靠性 實現，在分布系統訊息可靠性，支援集群，豐富的訊息分發機制表現不錯，客戶端與spring整合緊密。可以使用managment外掛程式實現web監控和管理。rabbitmq核心概念 支援訊息持久化 exchange持久化 que...