2017上海QCon之旅總結（上）
本來這個公眾號的交流消息中間件相關的技術的。這周去上海參加了QCon，第一次參加這樣的技術會議，感受挺多的，所以整理一下自己的一些想法接公眾號和大家交流一下。
下面進入正題，從自己參加了的一些分享中挑一些有趣的議題來和大家討論。
《“深藍”20年之後的人工智能》
2017年可以說是人工智能的元年了，AlphaGo戰勝李世石然人工智能一下進入了大眾的視野。之後以Master的身份60連勝，接著戰勝長期世界排名第一的柯潔，QCon期間AlphaGo Zero通過3天自學的方式就以100:0的方式戰勝了AlphaGo，可以說在棋類領域人類對人工智能已經沒有任何勝算了。
這次QCon，復旦大學的危輝教授從人工智能的歷史說起，之後從人工智能的問題域、解題步驟步步深入，清晰的描述了目前人工智能領域的進展。
危輝教授的《“深藍”20年之後的人工智能》分享可能從聽眾的感受上有點“反”人工智能熱潮，但是我認為這場分享是給人工智能的門外的我們一個很好的入門介紹，讓我們明白目前人工智能領域的發展狀況，讓我們對遍地的人工智能現象有一個清晰的任務。
另外危輝教授演講的邏輯性、嚴謹性和現場把控能力，真的是單從一場分享能感受到功底的深厚。
這場分享的PPT沒能從QCon網站上下載到，並不能回憶起很多具體的分享內容，以上是個人現場感受的一些體驗。
《免費的性能午餐——Alibaba JDK協程》
這一場是阿裏巴巴技術專家郁磊帶來關於Alibaba JDK協程的介紹。
在參加這次分享之前，我對協程並沒有什麽概念（沒寫過C++程序）。這場分享下來只能說有個簡單的認識，另外就是感嘆於阿裏的同學在這塊技術領域的深入。
不過就目前的狀況，對我們這樣一些小公司而言，可能並沒有技術能力去修改JVM，短期內的編程方式並不會有太大的改變。可能當協程成為一種標準，一種官方提倡的編程方式之後才會慢慢進入大眾程序員的領域（那為什麽不提前學習一些呢？）。
《基於內存的分布式計算》
這是這次QCon去聽的第一個具體問題領域的解決方案。
包含內容如下：
- 背景介紹及問題闡述
- 候選解決方案分析
- 分布式內存計算框架介紹
- 客戶實踐
這裏我簡要的說一下第1點和第3點。
問題背景
Talking Data技術團隊使用bitmap索引技術移動運營各項指標（如日活、留存）的實時計算，因為bitmap索引高效且能節省存儲空間，它能很方便地做指標的實時排重。
上面是日活的一個例子，其實就是用一個二進制位來保存用戶的狀態。比如第一位表示用戶設備1，該位為0表示用戶未登錄過，為1表示用戶登錄過。那麽用戶重復的登錄自然就被忽略了。
Talking Data使用MySQL的blob類型存儲bitmap數據，那麽每次需要更新數據時，如需要更新某一個用戶的狀態，那麽需要將bitmap讀取出來，修改其中一位，之後將數據寫回到MySQL中。那麽就帶來了一個問題，當某個APP的日活數據量特別大時，bitmap數據特別大，頻繁的update導致了產生大量的MySQL binlog。
解決方案
大概思路就是在MySQL之前加上一層緩存，前端的更新操作都在Blade內存中操作，之後定時同步寫到MySQL中，這樣就解決了頻繁更新bitmap導致的大量binlog問題。
幾個組件如上圖：
- APP中使用的Client
- 內存計算服務Blade Server（分為Master和Slave）
- Blade Data Sync負責從Server定時同步數據到MySQL
- Blade Admin提供管控功能
上圖中Blade Server有主備關系，且主備間有交互。
現場提問環節，我提了以下幾個問題：
- 主從復制是怎麽做的、支持一主多從嗎？
- Blade Server是基於內存的，沒有做持久化，那麽可麽保證系統的可靠性，比如如果主從兩個節點宕機了，未同步到MySQL的數據是否就丟失了？
得到的答復是目前他們並沒有做主從復制，當前其實是雙寫的模式，即Client會將數據寫到Master和Slave。這樣也就沒有第二個問題的處理了。
對於分布式系統，認為首先要考慮的就是系統的可靠性和可用性。
我們常常說的一點就是為了保證數據的可靠性，我們需要一式三份，而且是盡量讓三分數據分不到不同機器中，比如同機櫃的機器存一份，跨機櫃的存一份，像HDFS那樣存儲數據。
所以我覺得上面的方案並不是一個很可靠的方案。
比如使用消息中間件的方式是否能代替上面的方案呢？
客戶端將消息發送到消息中間件中，類似於RocketMQ和Kafka這樣的組件中，之後通過Consumer定時從中取消費數據來解決頻繁更新的問題（數據的可靠性通過消息中間件得到了保證）。
也可啟動實時消費的Consumer來消費數據更新到某個內存服務中，這樣可以提供實時的查詢服務。
以上是自己的一些疑問和拍腦袋的一個替代方案，歡迎交流不同的想法。
《餓了麽異地多活的基礎設施建設》
之前我們團隊考慮過一些異地多活的實現方案，所以特地去聽了這場分享。
之前在自己考慮異地多活方案時，遇到的最大的問題是數據同步和數據一致性。
下面看餓了麽是如何實現基地多活的。
首先是餓了麽的業務特點：
其中最重要的一點就是地域性。
餓了麽的業務特點，可以將所有數據按照商戶所在的位置信息來進行劃分。
比如所有南方商戶的數據走上海機房，所有北方商戶的數據走北京機房。對於用戶和訂單信息，都可以關聯到對應的商家，然後訪問商家對應所在的機房的服務。
上面是餓了麽異地多活的數據復制實現。思路就是在兩個機房之間進行雙向的數據復制。
回想一下，因為餓了麽的業務特點，雙向復制的數據中不會有重疊的部分。
- 從北京機房往上海機房復制的是北方商戶的數據
- 從上海機房到北京機房復制的是南方商戶的數據
- 在復制中過濾掉不必要的數據，比如從上海復制到北京的數據，這部分數據應用到MySQL之後也會產生binlog，這部分binlog需要從北京復制到上海的數據中剔除（這個通過改造SQL或者增加標識是可以做到的）
這樣就避免掉了一個數據在兩個機房同時被修改的問題。
擴展
考慮一個問題，比如在電商場景中做異地多活。
對於一個商品，在北京機房和上海機房都會被訪問，這個時候就產生了一個問題：
- 商品的庫存為1，北京機房下了一單，將商品庫存變更為0；同時上海機房也下了一單，也將庫存變更為0。這樣就產生了超賣的問題。
- 另外，如何在雙向數據同步中將上線的數據修復，即使其中一個訂單失效，將庫存修復也會一個問題。
Otter
阿裏巴巴B2B公司，因為業務的特性，賣家主要集中在國內，買家主要集中在國外，所以衍生出了杭州和美國異地機房的需求，同時為了提升用戶體驗，整個機房的架構為雙A，兩邊均可寫，由此誕生了otter這樣一個產品。
Otter在解決數據一致性問題時（同一行記錄多地修改），有兩種方案：
- 事前控制：比如paoxs協議，在多地數據寫入各自數據存儲之前，就已經決定好最後保留哪條記錄
- 事後補救：指A/B兩地修改的數據，已經保存到數據庫之後，通過數據同步後保證兩數據的一致性
兩種方式都是數據最終一致性的保證，具體內容可以參考：Otter數據一致性解決方案
未完待續...
QCon3天，還有挺多想和大家分享的，所以還有下篇，包含《PhxQueue——微信開源高可用強一致分布式隊列的設計與實現》、《Heron的Exactly-Once實現》幾個議題的分享感受。
歡迎關註公眾號交流。
2017QCon上海站PPT下載：PPT
2017上海QCon之旅總結（上）