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