目前媒資的介面系統需要出兩個優化方案出來：一個是短期的穩定方案，另一個是長期的改造方案。
短期內要解決的問題主要是：
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，這只是我的意見。