1. 发现问题
1. 查询慢access日志，发现偶尔有接口时延超过2s，发送概率1%左右
2. 排查
1. 写单元测试，多次测试后，不能重现问题
2. 接口代码里加日志，每隔一行代码加一次日志，等待重现
3. 不断往上游接口加日志后，发现耗时在获取榜单top10的接口
4. top10接口是从数据库获取top50的用户，然后通过多协程到redis里面获取用户信息
5. 发现从数据库获取数据时，没索引，加上索引后，问题依然存在
6. 再次加日志后发现耗时在多协程到redis里面获取用户信息
7. 耗时细节：
1. 接口共用时2.1s（正常只用0.2s）
2. 获取日榜，10个用户，0.01s
3. 获取周榜，50个用户，0.8s
4. 获取总榜，50个用户，0.6s
5. 再次获取总榜，50个用户（缓存不能命中，不知道为什么。不能命中是偶发），0.6s
8. 原因分析：
1. 只需要获取前10，但是获取了前50
2. 上层业务只需要id，但是下层获取了用户信息，无谓操作，同时加剧了第一点
3. 优化方案：
1. 从数据库获取前10
2. 只获取id，不获取用户信息
3. 获取id后，加一层缓存
4. 原来的接口改为连表获取用户数据
4. 学习
1. 多协程下，任务量较大情况下（大于20），访问redis，有概率出现慢的情况。具体原因待分析。(最后定位到是rediscluster库的问题，在redis服务端超时断口连接后，客户端会进行初始化，而且多协程下没有锁)
1. 数量大的情况下（大于20），多次访问redis io，还不如连表从数据库获取数据