系统优化设计方案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，这只是我的意见。