1、基于開源技術的移動社交網絡開發實例自我介紹與插播小廣告eBay中國區研發中心(MTS1工程師)螞蟻金服金融核心事業部（支付寶）技術專家點滴號：wangsheng 微信號：博客： http:/josh- 歡迎注冊點滴號，共同討論其中的技術實現 目的：提供相關開源實踐，認識更多朋友，技術無止境，歡迎大家多多提供更好的solution以及指正錯誤的地方。 點滴現狀 內容：以核心框架實踐為主，至于基本框架的使用：如Spring，MyBatis，Hibernate，Shiro，JPA，JTA，JMS等只做簡單介紹或者不介紹。第一部分：應用介紹:具有基本社交應用的功能1.一對一分

2、享和私聊 和好友一對一分享和私聊 2. 建圈子 為親人、密友、同學、團隊建私密圈子，為興趣、奇思妙想、社交組織建公開圈子，吸引志趣相投的人 。3. 找圈子 找志趣相投的圈子，從陌生人到朋友 4. 分享無拘束 - 每個圈子都是私密空間，分享更自由 5. 聊天無干擾 以圈子為單位聊天，圈子間互不干擾 6. 二維碼加好友、加圈子 掃描二維碼加好友、加圈子第一部分：特點介紹1、獨一無二的聊天消息標簽功能。 在其他聊天app里，需要跟進、值得保存的信息，淹沒在流水一樣的聊天消息里，事后難以找回。 在“點滴”，您可以用標簽，在聊天時，輕松地標識出特別的消息，事后通過標簽，方便地找回這些消息。 一旦您和家人

3、朋友同事，在聊生活、聊工作時，使用了話題標簽功能，您會發現，它是您最重要的助手。 特點介紹：2. 聊天和分享保存在云端，換手機時自動同步 3. 可以撤回長達7天內的聊天消息 4. 分享時可以同時指定多個圈子或朋友 5. 所有聊天、分享均經過加密 6. 可為每張圖片添加文字說明和鏈接，每張圖片可以是一個每張圖片可以是一個故事故事。第二部分：技術概況RESTJ2EEJ2EE平臺平臺:JPA/JTA/JMS等MQTT協議Solr全文搜索Shiro安全認證SpringMybatisHibernateRedis緩存FastDFS文件存儲MAVENJetty、Tomcat、GITRESTAndroid I

4、OSNodeJSJqueryHtml5Queue Base onErlangGOAppWeb系統架構 V1.0 ：快速原型，小眾用戶后期增加operation-manager RESTJ2EEJ2EE平臺平臺:JPA/JTA/JMS等S全文搜索Kafka ClusterSTORMCLUSTER點滴點滴系統架構 V2.0 ：Scale Out與大眾用戶群技術點1.MQTT協議在移動端的貢獻：小型傳輸、耗電量小、降低網絡流量。2. Mosquito + Erlang。信息交換平臺1. Solr 自定義增量索引的設計，可提高系統擴展性、可維護性，快速找到失敗索引。2. 基于Redis,MQTT,Fa

5、stDFS構建scale out的圖片管理系統。3、快速敏捷構建： Spring，Maven，Rest簡化平臺間的交互及部署。邏輯架構部署圖:simple is beautiful平臺模塊體系圖: 快速上手與迭代第三部分：詳細實現一基于Solr的圈子活動搜索 廣度與精度的權衡1.基于優先級的增量索引設計。2.mmseg4j中文分詞與詞庫擴展。【壓測結果更甚勝庖丁分詞】3.建立活動/圈子/空間信息各自私有的core。4.配置相關屬性以進行索引和檢索。5.Solr Admin進行索引分析。6.Java的Client包SolrJ。1、為什么不用更簡化，以往性能表現更好的Elastic Search2

6、、為什么用基于正向最大匹配算法的開源實現mmseg4j，而不用精確度更高的基于逆向匹配算法的開源實現 - 廣度與精度之間的權衡3、mmseg4j，代碼維護在github上，可以方便的管理問題與源碼貢獻。獨一無二的基于優先級的增量索引 ： 冪等同步擴展性：按Priority索引（現有均為P1）字段名數據類型長度鍵注釋bidINT 11PK聯合主鍵Business IDtidINT 11PK聯合主鍵表 IDo_statusenum 11 pending,success,failedo_timesINT 2 索引次數priorityINT 11 索引優先級last_update_timeDATETI

7、ME 11FK最后一次索引更新時間commentsvarchar60 索引情況說明Solr增量索引信息表：index_nets1. Sync Manager 定時將新增的數據添加到index_nets中。2. Index Manager用于管理基于優先級的Timer對index_nets中的新增數據進行索引。MysqlCircle/Actitiy/messageMysqlIndex_netsSync ManagerSolr Index庫Index ManagerP1 TimerP2 TimerP3 TimerIndex ManagerIndex Manager搜索中的怪事情，首先從Solr A

8、dmin中找答案搜索中的怪事情 從Solr Admin中找答案 - 具體事例1、助詞惹的禍、助詞惹的禍，輸入關鍵字，輸入關鍵字“大師大師的的圈子圈子”進行查詢，進行查詢，搜索搜索出：出：“六六指琴魔指琴魔的的上海上海鋼鋼琴師琴師”。解決。解決方案：配置停止詞：方案：配置停止詞：stopwords.txt，包括語氣組詞等無意義的詞，包括語氣組詞等無意義的詞 實例2、停止、停止詞：詞：“問題問題”惹的禍：惹的禍：有一段有一段description的內容為的內容為:“今天的時間有點緊，下面今天的時間有點緊，下面大家開始問問題吧大家開始問問題吧” 。以“問題問題”為關鍵字沒有輸出結果，只有當輸入“問問

9、”或者輸入“問問題問問題”時才能有結果輸出。解決方案：解決方案：查看stopwords.txt中，果然存在“問題”這個關鍵詞，去掉后解決問題實例3、maxword算法替換complex算法：“臉譜臉譜為員工開放了很多福利，比如員工可以參加各為員工開放了很多福利，比如員工可以參加各種體育活動，為家人提供專屬的空間等。種體育活動，為家人提供專屬的空間等?！比绻褂胏omplex算法，只有輸入“體育活動體育活動”才能搜出結果，但用戶希望輸入“活動活動”即有搜索結果。3.1、complex算法：算法：“體育活動體育活動”是整體是整體3.2、maxword算法：算法：“體育體育”和和“活動活動”分開了分

10、開了實例4、maxword只只最多支持最多支持2個字惹的個字惹的禍：禍：對于內容“林書豪來中國，來北京了”：如果我們只使用關鍵字“林書豪”便可得出上面的結果，這似乎是我們要的結果，但如果索引庫中存在一段內容是“來自華山的林平之練就了葵花寶典”，你會發現我輸入“林書豪”后，上面的內容也會被搜索出來。于是使用SolrAdmin可知，這是因為詞庫中缺少“林書豪”，林書豪被活生生的拆分成了“林”，“書”，“豪”。將將“林書豪林書豪”加入詞庫后，由于加入詞庫后，由于小經驗：小經驗：于是在詞庫words.dic添加“林書豪”，但是添加后還存在同樣的問題，這是因為maxword算法最多只支持2個字，于是在詞

11、庫中同時加上“書豪”和“林書”就可以提高準確度了。實例Solr Cloud 集群 HA與分布式索引SolrCloud中完整索引（中完整索引（Collection）的邏輯圖）的邏輯圖SolrCloud中提供NRT近實時搜索：Redis緩存機制緩解近實時首先來看下索引和首先來看下索引和Solr實體對照實體對照圖圖：Shard更像組的概念，每個更像組的概念，每個Shard存儲的存儲的Doc各不相同，但同一各不相同，但同一Shard下的下的Doc相同，互為副本。相同，互為副本。Solr Cloud 批量添加索引，批量索引路由，需要高并發能力SolrCloud中中創建創建索引可以分為索引可以分為5個步驟

12、（如下圖所示個步驟（如下圖所示）對Solr更新索引和創建索引的幾點總結 1、leader轉發的規則1）請求來自leader轉發說明當前本身為replica：那么就只需要寫到本地ulog,不需要轉發給leader，也不需要轉發給其它replicas。如果replica處于非active狀態，就會將update請求接受并寫入ulog，但不會寫入索引。如果發現重復的更新就會丟棄舊版本的更新。2）請求不是來自leader，但自己就是leader，那么就需要將請求寫到本地，順便分發給其他的replicas。3）請求不是來自leader，但自己又不是leader,也就是該更新請求是最原始的更新請求，那么需

13、要將請求寫到本地ulog，順便轉發給leader,再由leader分發。每commit一次，就會重新生成一個ulog更新日志，當服務器掛掉，內存數據丟失的時候，數據就可以從內存數據丟失的時候，數據就可以從ulog中恢復。中恢復。 2、建索引的時候最好使用CloudSolrServer，因為CloudSolrServer直接向leader發送update請求，從而避免網絡開銷。 3、批量添加索引的時候，建議在客戶端提前做好document的路由，在SolrCloud內進行文檔路由，開銷較大【路由：對索引分類，哪類索引寫到哪個邏輯的Shard上，該邏輯Shard對應多臺Solr core】。Sol

14、r Cloud索引的檢索 基于索引的Shard的個數，把查詢轉為多個子查詢Solr Shard Splitting /Re Sharding：將原有Shard的Replica均勻的分布到更多的Shard的更多的Solr節點上去Solr Cloud與Zookeeper 配置比較簡單SolrCloud索引索引操作的基本架構圖操作的基本架構圖二FAST DFS集群架構：為小圖片管理系統而生視頻網站，相冊網站 動態擴容相對相對GoogleFS：輕量級輕量級對等：沒有對等：沒有leader分組分組/分卷分卷冗余備份冗余備份負載均衡負載均衡線性擴容線性擴容應用應用級分布式級分布式文件存儲文件存儲基于Fas

15、tDFS的文件上傳與下載文件上傳：文件上傳：1.Client詢問Tracker server上傳到哪個Storage server2. Tracker server返回一臺可用的Storage server(IP地址和端口)3. Client直接和該Storage server建立連接，進行文件上傳，Storage server返回新生成的文件ID（包括組/卷名和文件名），文件上傳結束。文件文件下載下載：1.Client詢問Tracker server可以從哪臺Storage server上下載指定的文件，參數為文件ID（包括組名和文件名）2. Tracker server返回一臺可用的Sto

16、rage server(IP地址和端口)3. Client直接和該Storage server建立連接，完成文件下載。簡單的配置和API 線下配置事例：connect_timeout = 2network_timeout = 30charset = UTF-8http.tracker_http_port = 8080http.anti_steal_token = nohttp.secret_key = FastDFS1234567890tracker_server = 56:22122storage_server = 55:23000String f

17、ileAbsolutePath = PROTOCOL + trackerServer.getInetSocketAddress().getHostName() + uploadResults = storageClient.upload_file(file.getContent(), file.getExt(), meta_list); private static TrackerClient trackerClient; private static TrackerServer trackerServer; private static StorageServer storageServer

18、; private static StorageClient storageClient;實踐之：基于FastDFS、MQTT，Mysql/Redis的文件、圖片管理系統的開源實現三MQTT協議 轉發消息： Mosquito，ErLang輕量級移動應用系統的首先MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）是一套輕量級跨平臺的基于發布/訂閱消息傳輸協議，其設計思想開放、簡單、輕量、易于實現。專門為低帶寬、不穩定網絡以及計算和處理能力受限的設備所設計, 該協議采用小型傳輸,耗電量小,能大大降低網絡流量,最小化數據包并有效分配與傳輸, 非常適合

19、移動系統上面的應用。MQTT協議提供了3種類別的信息傳遞服務質量，值分別是0、1、2。其中At most once （值是0）至多一次，消息發布完全依賴于底層的TCP/IP網絡，會發生消息丟失；At least once（值是1）至少一次，確保消息到達，但可能發生消息重復；Exactly once（值是2）只有一次，確保消息只到達一次。經過壓測發現，使用經過壓測發現，使用IBM自身提供的自身提供的Java library以及以及mosquito broker性能并沒性能并沒有官網上聲稱的出色，而使用有官網上聲稱的出色，而使用Go/Erlanng編寫的編寫的broker性能更加出色，但性能更加出

20、色，但IBM自身提供的自身提供的API具有可讀性強和可維護行好的優點，但由具有可讀性強和可維護行好的優點，但由Erlang編寫的編寫的broker屬屬于我們的產品的一大技術點，準備以后發布開源實現，此處暫不作更深的討于我們的產品的一大技術點，準備以后發布開源實現，此處暫不作更深的討論。論。MQTT協議 多次握手/簽約確保信息發送成功: exactly oncedameon service, callback, retry, 握手模塊分布式、跨JVM責任鏈模式處理用戶rest call請求 ：rest call通知Advisor1. 基于責任鏈模式，使每個相關的URL請求都有機會被相應的hand

21、ler處理，從而大大提高了可擴展性。2. ActionMeditor基于調停者模式，使得調用者只與meditor交互，不直接與各個Handler交互,降低業務邏輯模塊之間的耦合度。 事實事實： 對于每一種用戶請求的URL，應該有相應的handler進行處理。 問題問題： 當前請求應該由哪個handler處理？擴展性？ 四對組件間rest call Say No Linkedin分布式的消息隊列KafkaMQTT/ActiveMQKafka busZookeeper，可以將其想象成它維持了一張表，記錄了各個節點的IP、端口等配置信息。每個Consumer啟動后會在Zookeeper上注冊一個臨時

22、的consumer registry：包含Consumer所屬的Consumer Group以及訂閱的topics。每個Consumer Group關聯一個臨時的owner registry和一個持久的offset registry。對于被訂閱的每個partition包含一個owner registry，內容為訂閱這個partition的consumer id，同時包含一個offset registry，內容為該consumerid上一次訂閱的offset。Zookeeper、Producer、Broker、Consumer的協同工作為了便于理解，假定此時Kafka集群中有兩臺Producer

23、，但只有一臺Kafka的Broker、Zookeeper和Consumer。如下圖所示的部署集群。整個系統運行的順序可簡單歸納為：整個系統運行的順序可簡單歸納為：1、啟動Zookeeper的server。2、啟動Kafka的server。3、Producer如果生產了數據， 會先通過Zookeeper找到Broker，然后將數據存放進Broker。4、Consumer如果要消費數據，會先通過Zookeeper找對應的Broker，然后消費。Producer代碼實例：代碼實例：producer = new Producer(.); message = new Message(Hello.getB

24、ytes(); set = new MessageSet(message); producer.send(topic1, set);發布消息時，Producer先構造一條消息，將消息加入到消息集set中（Kafka支持批量發布，可以往消息集合中添加多條消息，然后一次性發布), send消息時，client需指定消息所屬的topic。Consumer代碼實例：代碼實例：streams = Consumer.createMessageStreams(topic1, 1);for (message : streams) bytes = message.payload(); / do somethin

25、g with the bytesKafka的存儲策略1、Kafka以topic來進行消息管理，每個topic包含多個partition，一個partition對應一個邏輯log，由多個segment組成。2、每個segment中存儲多條消息，消息id由其邏輯位置決定，即從消息id可直接定位到消息的存儲位置，避免id到位置的額外映射。 3、每個partition在內存中對應一個index，記錄每個segment中的第一條消息偏移。 4、發布者發到某個topic的消息會被均勻的分布到多個part上（隨機或根據用戶指定的回調函數進行分布），broker收到發布消息往對應part的最后一個segmen

26、t上添加該消息，當某個segment上的消息條數達到配置值或消息發布時間超過閾值時配置值或消息發布時間超過閾值時，segment上的消息會被flush到磁盤，只有flush到磁盤上的消息訂閱者才能訂閱到，segment達到一定達到一定的大小后將不會再的大小后將不會再往該往該segment寫數據，寫數據，broker會創建新的會創建新的segment。為什么不要ActiveMQ - Kafka的HA機制（性能與數據持久化之間的權衡）1、Data Replication Kafka分配Replica的算法-盡可能均衡（假設總共有n個broker）：將所有Broker和待分配的Partition排序

27、 將第i個Partition分配到第（i mod n）個Broker上 將第i個Partition的第j個Replica分配到第（(i + j) mode n）個Broker上2、Kafka傳播（傳播（Propagate）消息消息、Follower與與Leader的的ACK的的過程過程（性能與可靠性之間的權衡）（性能與可靠性之間的權衡）3、Partition Follower和和Leader間的間的ISR復制復制機制機制（時間和條數）（時間和條數）4、Partition的重新分配的重新分配5 5、Leader Leader Election Election （Kafka借助借助Zookeep

28、er和和ISR選擇選擇Leader）6 6、有了Replication機制后，每個Partition可能有多個備份。某個Partition的Replica列表叫作 AR（Assigned Replicas），AR中的第一個Replica即為“Preferred Replica”。創建一個新的Topic或者給已有Topic增加Partition時，Kafka保證Preferred Replica被均勻分布到集群中的所有Broker上。理想情況下，Preferred Replica會被選為Leader。以上兩點保證了所有以上兩點保證了所有Partition的的Leader被均勻分布被均勻分布到了集

29、群當中，這一點非常重要，因為所有的讀寫操作都由到了集群當中，這一點非常重要，因為所有的讀寫操作都由Leader完成，若完成，若Leader分布過于集分布過于集中，會造成集群負載不均衡中，會造成集群負載不均衡。但是，隨著集群的運行，該平衡可能會因為Broker的宕機而被打破，Preferred Replica Leader Election Tool工具就是用來幫助恢復Leader分配的平衡。五Storm實時圈子推薦：根據用戶的行為、興趣愛好以及圈子的變化情況實時為新注冊用戶、定期為新用戶推薦最合適的圈子當前:簡單的圈子weigh計算排名推薦： weightManager, cronJob ni

30、ghtly不知道Strom，自己如何實現實時推薦？1、需要考慮的因素：低延遲。實時計算系統，延遲是一定要低的。高性能。性能不高就是浪費機器，浪費機器就是浪費￥。分布式?？紤]多機復雜應用問題。可擴展。伴隨著業務的發展，我們的數據量、計算量可能會越來越大，所以希望這個系統是可擴展的。 容錯。這是分布式系統通用問題。一個節點掛了不能影響我們的應用。 2、實現方案： 消息隊列+分布在各個機器上的工作進程易用性不夠。需要開發人員考慮各個處理組件的分布、消息的傳遞。消息不丟失。用戶發布的一個消息不能在實時處理的時候給丟了，對吧？更嚴格一點，如果是一個精確數據統計的應用，那么它處理的消息要不多不少才行。 消

31、息嚴格有序。有些消息之間是有強相關性的，如果處理時搞亂順序完全是不一樣的效果了。當我們使用JDK中的Executor框架/Fork Join框架,Queue以及一系列的跨JVM的操作之后，基本上就是實現了一個Storm的雛形。Storm基本架構Spout（消息源）Bolt（消息處理者）Stream grouping（數據的分發方式）Topology（拓撲）Worker（工作進程）Task（執行具體邏輯的任務）Executor（執行Task的線程）Configuration（配置）Storm 消息源: Spout、計算拓補：Topology、消息處理者: Bolt消息源Spouts是storm里

32、面一個topology里面的消息生產者。一般來說消息源會從一個外部源讀取數據并且向topology里面發出消息: tuple。 消息源Spouts可以是可靠的也可以是不可靠的。一個可靠的消息源可以重新發射一個tuple，如果這個tuple沒有被storm成功的處理。但是一個不可靠的消息源Spouts一旦發出一個tuple就把它徹底忘了 也就不可能再發了。消息源Spouts可以發射多條消息流stream。要達到這樣的效果， 使用OutFieldsDeclarer.declareStream來定義多個stream, 然后使用SpoutOutputCollector來發射指定的stream.一個實時

33、計算應用程序的邏輯在storm里面被封裝到topology對象里面， 我把它叫做計算拓補. Storm里面的topology相當于Hadoop里面的一個MapReduce Job, 它們的關鍵區別是：一個MapReduce Job最終總是會結束的， 然而一個storm的topoloy會一直運行 除非你顯式的殺死它。 一個Topology是Spouts和Bolts組成的圖狀結構， 而鏈接而鏈接Spouts和和Bolts的則是的則是Stream groupings。所有的消息處理邏輯被封裝在bolts里面。 Bolts可以做很多事情： 過濾， 聚合， 查詢數據庫等等。Bolts的主要方法是exec

34、ute, 它以一個tuple作為輸入，Bolts使用OutputCollector來發射tuple, Bolts必須要為它處理的每一個tuple調用OutputCollector的ack方法，以通知storm這個tuple被處理完成了。 從而我們通知這個tuple的發射者Spouts。 一般的流程是： Bolts處理一個輸入tuple, 發射0個或者多個tuple, 然后調用ack通知storm自己已經處理過這個tuple了。storm提供了一個IBasicBolt會自動調用ack。Storm集群結構在Storm的集群里面有兩種節點：控制節點和工作節點?？刂乒濣c上面運行一個叫Nimbus進程，

35、Nimbus負責在集群里面分發代碼，分配計算任務，并且監控狀態。每一個工作節點上面運行一個叫做Supervisor進程。Supervisor負責監聽從Nimbus分配給它執行的任務，據此啟動或停止執行任務的worker進程Nimbus和Supervisor之間的所有協調工作都是通過Zookeeper集群完成。Storm： Worker、Task 、消息流（Stream）、消息分發策略：Stream groupings1、Supervisor會監聽分配給它那臺機器的工作，根據需要啟動/關閉工作進程，這個工作進程就是worker，每一個worker都會占用工作節點的一個端口，這個端口可以在stor

36、m.yarm中配置。一個topology可能會在一個或者多個工作進程里面執行，每個工作進程執行整個topology的一部分，所以一個運行的topology由運行在很多機器上的很多工作進程組成。2、每一個Spout和Bolt會被當作很多task在整個集群里面執行。默認情況下每一個task對應到一個線程（Executor），這個線程用來執行這個task，而stream grouping則是定義怎么從一堆task發射tuple到另外一堆task。3、消息流是storm里面的最關鍵的抽象。一個消息流是一個沒有邊界的tuple序列， 而這些tuples會被以一種分布式的方式并行地創建和處理。 對消息流的定義主要是對消息流里面的tuple的定義， 我們會給tuple里的每個字段一個名字。 并且不同tuple的對應字段的類型必須一樣。 也就是說： 兩個tuple的第一個字段的類型必須一樣，