系統優化設計方案3.20週一例會

　　目前媒資的接口系統須要出兩個優化方案出來：一個是短時間的穩定方案，另外一個是長期的改造方案。

　　短時間內要解決的問題主要是：

　　1. 批量mget致使cbase端返回給client響應慢，特別是mget的key數量越大這個現象越明顯。

因mget請求致使總體接口服務響應慢，memc客戶端發起重試2次，若是此時併發稍大些，同時會因沒法從xmemcached鏈接池中獲取鏈接而引起大量的TimeoutException，

出現TimeoutException異常memc客戶端會重試2次，影響其餘接口服務，最終引發雪崩，服務不可用。

　　這個已經經過對moxi參數調優、memcached參數調優，有所緩解。下面須要經過對批量請求mget優化。另外考慮將現有集羣換成redis（由於緩存服務部門cbase集羣是比較成熟的，因此有風險）。可是我15年入職時就聽過一些其餘部門的技術分享，提到了cbase的不穩定因素，最後他們的解決方案也是不使用樂視統一的cbase集羣，本身搭建私有集羣，穩定性獲得很大提升，因此這個是值得嘗試的。目前cbase裏存的是全量緩存，使用redis的mget，基本不存在取不到須要穿透到DB的問題。可是目前要解決的是 mget的性能問題，那麼搭建redis集羣須要考慮採用哪一種集羣：codis, twemporxy, redis cluster能更好的支持這一點。由於在分佈式下涉及怎樣同時取多個Redis上多個key。將多個key按照算法分組，而後再合併多組迴應的問題。就是redis集羣的路由問題。

　　德偉回覆：問過負責redis的徐雷不建議redis使用mget方式

　　2. 數據庫分庫分表問題

　　媒資千萬級數據表的拆分，須要備忘的是將更新時間換成時間戳根據當前時間自動更新的問題。目前其餘業務線的依賴已經由直接的數據庫訪問改爲了消息推送的方式，解決了耦合致使的數據庫結構改變對其餘部門的影響。德偉提出咱們根據時間戳進行更新，那麼更新改爲幾秒鐘一次，數據量會不會增大？會上忘了回覆這一問題：除非對同一數據的修改十分頻繁，否則推送的總量應該是差很少的，那麼時間間隔小，每次對MQ的壓力應該是更小更均勻了。 拆分前須要將中國站的數據進行一次數據遷移到分表，須要和調用方溝通的問題。數據表拆分要解決的問題是：專輯ID可能會變，專輯下面關聯視頻，因此以什麼依據來進行拆分的問題。

　　3. 預告片的接口優化問題

　　預告片是否能夠考慮不走緩存，直接進行數據庫索引來取返回結果。這麼作的緣由是有次線上事故，是因爲預告片取的過多。每次都走緩存mget。mget自己key過多，性能降低快，致使其餘服務處於等待超時。不走緩存，能夠避免這樣的突發狀況形成的緩存瓶頸。

　　德偉回覆：最初想計算完後放到緩存中。走索引每次穿透db按如今量也問題不大，須要壓測出個結果對比下.  生產服務器都有權限 能夠看下， 如今qps很低

　　

　　長期改造:

　　目前媒資接口需求和數據增加量趨於穩定，須要進行一次完全的改造和重構。需不須要將dubbo層的面向服務層去掉？個人偶像馬丁福特說：分佈式的最基本原則是儘可能不要分佈式。well，這只是個人意見。