1. 程式人生 > >架構師之路--視頻業務介紹,離線服務架構和各種集群原理

架構師之路--視頻業務介紹,離線服務架構和各種集群原理

目的 -- 自己的 超過 覆蓋 基本上 添加節點 電視 是我

  先聊聊業務。我們媒資這邊目前的核心數據是樂視視頻的樂視meta和專門存儲電視劇,綜藝節目,體育賽事這種長視頻的作品庫。樂視視頻的數據都是多方審核的,需要很多運營。但是作品庫部分卻是弱運營的,運營都不超過10個人。結果做了兩個app,日活都有四五百萬的樣子。我們其實都有各樣的技術儲備,很容易可以抓取人家數據,自己套上一個殼子在線解碼。但是我們逼格很高,都不這麽做的。樂視是個非常註重版權的公司。我名下都有近百個專利了。

  撇開這個項目,先看這邊一般web項目的常用JVM配置。

                    <jvm-arg>-Xms4g</jvm-arg>
                    <jvm-arg>-Xmx4g</jvm-arg>
                    <jvm-arg>-Xss1m</jvm-arg>
                    <jvm-arg>-Xmn1g</jvm-arg> 
                    <jvm-arg>-XX:MaxPermSize=128M</jvm-arg>
                    <jvm-arg>-XX:MaxTenuringThreshold=3</jvm-arg>

  這個配置resin的服務器業務不是特別復雜的情況下,承載單臺QPS4k的並發是不成問題的。下面的圖拿來只是覺得我們鄒老師畫的好看,裏面涵蓋了很多系統,只要是web server這個配置都是夠用的。我們線上機器都是32G24核高配物理機。其實負載都在2點多。就是說用8G4核虛擬機完全夠用。但是我們的服務相當重要,運維哥哥那邊虛擬化做的不太好,不是很穩定的,線上我們都不這麽用。所以,JVM配置基本上多一點少一點點線上效果不是很明顯。

技術分享

  離線數據是推送給樂視視頻的搜索部門,樂視視頻的日活是千萬級。當然搜索哥哥那邊也在搞全網搜索,覆蓋廣,再加上快和準是他們的目標。但是最最基本的視頻內容來源是我這邊出的。下面圖是整體業務架構,下面標的技術是主要的性能消耗點。有些紅色的線是我兒子畫的,不想這麽浪費一張A4紙就當手稿用了。提倡環保,人人有責。

技術分享

  調優之前先說說這個mysql從庫。因為這個項目是好多年前就開始做了,依然用的是一主多從的拓撲,binlog復制的集群模式。從庫用的是通知模式,時延也就是ms級都還好。寫數據QPS也就幾十,多加幾個從庫IO也不會瓶頸。主要問題是主庫單點,從庫的復制根據分布式系統的CAP理論,保證的是可用性和分區容忍性。一致性級別也就是個最終一致性。上學的時候都學過,單個數據庫事務用的是ACID模型,記得當年考試的必考點就是事務的原子性,一致性,隔離性,持久性。我竟然還記得。但是一說集群,特別是如今nosql時代,說的也就只能是BASE理論了。binlog采用的是DML語句復制和一旦發現DML語句無法精確復制時就會采用基於行的復制。記得出現過一次事故,數據庫表結構有更新,導致執行語句錯誤,數據同步停止。

  我來公司後新開發的項目都是用的公司的雲數據庫。這個稍微高級一點,用的是Percona XtraDB Cluster做的集群。它是一個mysql高可用和可擴展的解決方案。可以同步復制,事務要麽在所有節點提交或不提交。多主復制,任意節點都可以寫操作。缺點,我沒測試過,從原理來說,寫肯定比傳統一主多從慢。因為從弱一致的異步冗余變成了強一致的同步冗余了嘛。而且必須是innodb引擎。我們的所謂雲,也就是做了一個去中心化。

  離線服務是用了兩臺機器,用memcached緩存一個更新時間點的時間戳做增量實時的通訊,定時全量和手動補發是一個簡單兩臺服務器熱備。

  說說緩存集群。memcached集群既然使用的moxi代理,那麽它的集群對客戶端來說就是透明的,客戶端沒有辦法自己修改其輪詢和容災策略。但是這種代理的有一個好處就是可以管道處理,合並重復的key,一定程度上提高了效率。關於memcached集群,昨天我們大領導找來雲存儲的大神給我們講講視頻存儲是怎麽做的。其中提到了他們那邊用的SSDB的集群。和memcached集群是一樣的。先說說存儲那邊的大體邏輯,重新在大腦裏膜拜一下大神。發現我兒子有當偵探的潛質,他的塗鴉讓我想起福爾摩斯<血字的研究>。

  技術分享

  我們部門那邊上傳視頻到雲存儲,先要進行一個初始化。這個初始化會采用摘要算法計算一下文件的sha1,如果視頻已經存在,直接返回狀態,這樣對於一些用戶就可以實現秒傳了。但是對於flash因為這個語言要計算其摘要必須將整個文件全都加載到內存,我們是用其他方法來生成sha1的。這個shal傳到雲存儲那邊通過SSDB經過二次開發自己實現的一個nosql數據庫,這些鍵值對的nosql數據庫查找,如果沒初始化過,返回初始化token。這個token裏包含了上傳到哪個節點等信息。用戶上傳的介質就可以直接通過網關與存儲通信了。存儲那邊對於每個上產的視頻都有主備。一個主備作為一個組。組內自己有個程序做磁盤同步。會有磁盤檢查剩余空間。新傳視頻會在未滿的集群中均勻分布。上傳完成後一些熱點視頻會以推送的方法分發到CDN節點上,供CDN加速用。其他視頻需要CND自己來拉取。當然CDN那邊也有自己的策略。先在邊緣節點查找,找不到再來中心節點找,最後沒有在來存儲這邊。

  大體流程就是這樣。問了下大神哥哥SSDB的集群是怎麽做的。他們也是通過代理的。代理上存有映射表。集群各個節點間本身不通信。需要進行一些哈希計算來找節點的bucket。如果需要添加節點,遷移過程中還是先打到原節點。等遷移完成,映射表更新再往新節點上分發。這樣做的好處是避免了rebalance的巨大開銷。

  qpidd的MQ集群。問過管理MQ的運維童鞋,為啥選這個。他說activeMq和rabbitMq太輕量,性能不行。Kafka又丟消息,所以才選的這個。不過去公司外面問問,貌似知道的人不多。我們部門要把支付的業務接過來,他們那邊是自己搭建了一個kafka的Mq用來集中處理日誌的。

  netty部分我在前面的文章中很詳細的介紹了實戰經驗,有感興趣的可以自己找一下。

  gz壓縮主要是遞歸操作,如果線程站開的特別大,壓縮過程中CPU上升會特別快,需要註意。

架構師之路--視頻業務介紹,離線服務架構和各種集群原理