个性化推荐系统又与其他系统有着相似大流量考验，还有一些和其他业务系统差异地方。核心交易系统更多面临高并发交易可用性，高并发交易不出错，系统稳定性。个性化推荐面临问题是及其复杂线上算法逻辑，多次缓存redis调用，各个业务线面临线上将近20倍流量暴涨，因为个性化每个用户逻辑均不相同，暴涨的流量对于redis等存储压力也是巨大类似DDoS。挑战是相当之大，最近上下游联合压测、全链路压测系统均未达到预估流量，压力山大。
流量大、系统多、问题复杂，整个事情怎么做，还是要梳理思路，按节奏进行备战，开展各项工作。首先是梳理线上服务依赖存储、依赖上游接口、线上服务逻辑是否可优化，然后单机压测、上下游压测、全链路压测，线上服务扩容，线上各种redis、数据库、ES等资源扩容。详细备战可见我的618备战文章618电商大促备战以及总结。
这次双11出现新情况以及面临主要问题是第一次压测多个redis集群性能严重下降并持续整个压测过程，后来进行查找分析定位是网络异常导致，因为redis目前也是在虚拟机中，两个物理机网络出问题，物理机上的多个redis集群出现性能持续下降。
第二次上下游压测依然是redis性能下降，redis单个集群性能持续下降，导致整个集群性能降，线上业务基本都依赖这个集群，全线业务性能受影响。经查是存在大key或热key导致单个分片性能差。以及线上业务流量过于集中，全部集中单个redis集群，每分钟流量过亿。
解决办法最好是redis数据复制进行拆分，一部分业务读原有redis集群，一部分读新集群，这是个方法但资源消耗大。二是在定位查找热key将热key进行定时处理或分散处理，大key value值大小进行控制，避免集群节点压力过大，导致集群性能下降。三是线上业务自查看是否有redis通用数据是定时拉取，实时拉取通用数据导致热点key，通用数据一定采用定时器拉取。空用户信息访问直接返回通用数据，避免空信息时出现热点key。
redis资源不可扩容情况下，线上服务可以进行一下优化，主要是redis集群连接配置调大、单个客户端连接调小，避免消耗尽redis连接。集群超时调小，避免redis性能差导致线上服务不可用。
该做工作认真做好，尽量做到线上业务大流量不降级。但外一出现风险的情况怎么办？这时降级预案要做好，做好降级准备，降级预案提前演练做到万无一失。
微信搜索：debugme123