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

　　撇開這個(gè)項(xiàng)目，先看這邊一般web項(xiàng)目的常用JVM配置。

　　這個(gè)配置resin的服務(wù)器業(yè)務(wù)不是特別復(fù)雜的情況下，承載單臺QPS4k的并發(fā)是不成問題的。下面的圖拿來只是覺得我們鄒老師畫的好看，里面涵蓋了很多系統(tǒng)，只要是web server這個(gè)配置都是夠用的。我們線上機(jī)器都是32G24核高配物理機(jī)。其實(shí)負(fù)載都在2點(diǎn)多。就是說用8G4核虛擬機(jī)完全夠用。但是我們的服務(wù)相當(dāng)重要，運(yùn)維哥哥那邊虛擬化做的不太好，不是很穩(wěn)定的，線上我們都不這么用。所以，JVM配置基本上多一點(diǎn)少一點(diǎn)點(diǎn)線上效果不是很明顯。

　　離線數(shù)據(jù)是推送給樂視視頻的搜索部門，樂視視頻的日活是千萬級。當(dāng)然搜索哥哥那邊也在搞全網(wǎng)搜索，覆蓋廣，再加上快和準(zhǔn)是他們的目標(biāo)。但是最最基本的視頻內(nèi)容來源是我這邊出的。下面圖是整體業(yè)務(wù)架構(gòu)，下面標(biāo)的技術(shù)是主要的性能消耗點(diǎn)。有些紅色的線是我兒子畫的，不想這么浪費(fèi)一張A4紙就當(dāng)手稿用了。提倡環(huán)保，人人有責(zé)。

　　調(diào)優(yōu)之前先說說這個(gè)mysql從庫。因?yàn)檫@個(gè)項(xiàng)目是好多年前就開始做了，依然用的是一主多從的拓?fù)?，binlog復(fù)制的集群模式。從庫用的是通知模式，除非主庫有大的事務(wù)操作，時(shí)延也就是ms級都還好。寫數(shù)據(jù)QPS也就幾十，多加幾個(gè)從庫IO也不會(huì)瓶頸。主要問題是主庫單點(diǎn)，從庫的復(fù)制根據(jù)分布式系統(tǒng)的CAP理論，保證的是可用性和分區(qū)容忍性。一致性級別也就是個(gè)最終一致性。上學(xué)的時(shí)候都學(xué)過，單個(gè)數(shù)據(jù)庫事務(wù)用的是ACID模型，記得當(dāng)年考試的必考點(diǎn)就是事務(wù)的原子性，一致性，隔離性，持久性。我竟然還記得。但是一說集群，特別是如今nosql時(shí)代，說的也就只能是BASE理論了。binlog采用的是DML語句復(fù)制和一旦發(fā)現(xiàn)DML語句無法精確復(fù)制時(shí)就會(huì)采用基于行的復(fù)制。記得出現(xiàn)過一次事故，數(shù)據(jù)庫表結(jié)構(gòu)有更新，導(dǎo)致執(zhí)行語句錯(cuò)誤，數(shù)據(jù)同步停止。

　　我來公司后新開發(fā)的項(xiàng)目都是用的公司的云數(shù)據(jù)庫。這個(gè)稍微高級一點(diǎn)，用的是Percona XtraDB Cluster做的集群。它是一個(gè)mysql高可用和可擴(kuò)展的解決方案?？梢酝綇?fù)制，事務(wù)要么在所有節(jié)點(diǎn)提交或不提交。多主復(fù)制，任意節(jié)點(diǎn)都可以寫操作。缺點(diǎn)，我沒測試過，從原理來說，寫肯定比傳統(tǒng)一主多從慢。因?yàn)閺娜跻恢碌漠惒饺哂嘧兂闪藦?qiáng)一致的同步冗余了嘛。而且必須是innodb引擎。我們的所謂云，也就是做了一個(gè)去中心化。

　　離線服務(wù)是用了兩臺機(jī)器，用memcached緩存一個(gè)更新時(shí)間點(diǎn)的時(shí)間戳做增量實(shí)時(shí)的通訊，定時(shí)全量和手動(dòng)補(bǔ)發(fā)是一個(gè)簡單兩臺服務(wù)器熱備。

　　說說緩存集群。memcached集群既然使用的moxi代理，那么它的集群對客戶端來說就是透明的，客戶端沒有辦法自己修改其輪詢和容災(zāi)策略。但是這種代理的有一個(gè)好處就是可以管道處理，合并重復(fù)的key，一定程度上提高了效率。關(guān)于memcached集群，昨天我們大領(lǐng)導(dǎo)找來云存儲的大神給我們講講視頻存儲是怎么做的。其中提到了他們那邊用的SSDB的集群。和memcached集群是一樣的。先說說存儲那邊的大體邏輯，重新在大腦里膜拜一下大神。發(fā)現(xiàn)我兒子有當(dāng)偵探的潛質(zhì)，他的涂鴉讓我想起福爾摩斯<血字的研究>。

　　我們部門那邊上傳視頻到云存儲，先要進(jìn)行一個(gè)初始化。這個(gè)初始化會(huì)采用摘要算法計(jì)算一下文件的sha1，如果視頻已經(jīng)存在，直接返回狀態(tài)，這樣對于一些用戶就可以實(shí)現(xiàn)秒傳了。但是對于flash因?yàn)檫@個(gè)語言要計(jì)算其摘要必須將整個(gè)文件全都加載到內(nèi)存，我們是用其他方法來生成sha1的。這個(gè)shal傳到云存儲那邊通過SSDB經(jīng)過二次開發(fā)自己實(shí)現(xiàn)的一個(gè)nosql數(shù)據(jù)庫，這些鍵值對的nosql數(shù)據(jù)庫查找，如果沒初始化過，返回初始化token。這個(gè)token里包含了上傳到哪個(gè)節(jié)點(diǎn)等信息。用戶上傳的介質(zhì)就可以直接通過網(wǎng)關(guān)與存儲通信了。存儲那邊對于每個(gè)上產(chǎn)的視頻都有主備。一個(gè)主備作為一個(gè)組。組內(nèi)自己有個(gè)程序做磁盤同步。會(huì)有磁盤檢查剩余空間。新傳視頻會(huì)在未滿的集群中均勻分布。上傳完成后一些熱點(diǎn)視頻會(huì)以推送的方法分發(fā)到CDN節(jié)點(diǎn)上，供CDN加速用。其他視頻需要CND自己來拉取。當(dāng)然CDN那邊也有自己的策略。先在邊緣節(jié)點(diǎn)查找，找不到再來中心節(jié)點(diǎn)找，最后沒有在來存儲這邊。

　　大體流程就是這樣。問了下大神哥哥SSDB的集群是怎么做的。他們也是通過代理的。代理上存有vbucket映射表。集群各個(gè)節(jié)點(diǎn)間本身不通信。需要進(jìn)行一些哈希計(jì)算來找節(jié)點(diǎn)的bucket。如果需要添加節(jié)點(diǎn)，遷移過程中還是先打到原節(jié)點(diǎn)。等遷移完成，映射表更新再往新節(jié)點(diǎn)上分發(fā)。這樣做的好處是避免了rebalance的巨大開銷。在人人網(wǎng)的時(shí)候，7年前我們的memcached集群出過一次事故。當(dāng)時(shí)我們leader升級了客戶端，算法變了，導(dǎo)致全部緩存都不命中。所以這種基于算法和實(shí)質(zhì)上相互關(guān)聯(lián)的集群和gossip的集群不同，對客戶端有依賴。

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

　　netty部分我在前面的文章中很詳細(xì)的介紹了實(shí)戰(zhàn)經(jīng)驗(yàn)，有感興趣的可以自己找一下。

　　gz壓縮主要是遞歸操作，如果線程棧開的特別大，壓縮過程中CPU上升會(huì)特別快，需要注意。

http://www.cnblogs.com/xiexj/p/7041265.html

延伸閱讀

• 路漫漫其修遠(yuǎn)兮，吾將上下而求索 2023-04-18
• 知識和經(jīng)驗(yàn)的重要性 2023-04-15
• 嚴(yán)謹(jǐn)和負(fù)責(zé) 2023-04-15
• 三人行，必有我?guī)?/a> 2023-04-15
• 向上攀爬的那條路是比站在頂峰更讓人熱血澎湃 2022-07-12
• 這條路必定正確，不容懷疑 2022-07-12
• 5 個(gè)被忽視的習(xí)慣，決定了你很難成為高級開發(fā)工程師！ 2022-07-12
• “三人行,必有我?guī)煛? 2022-02-07
• 路漫漫其修遠(yuǎn)兮，吾將上下而求索 2021-12-23
• 這條路必定正確，不容懷疑 2021-06-16

路漫漫其修遠(yuǎn)兮，吾將上下而求索