这是我参与「第三届青训营-后端场」笔记创作活动的第4篇笔记，是关于参与项目的优化方面队内探讨
- 使用协程并行的处理多条查询 将一个业务接口的查询任务并行处理访问数据库，结合查询结果并返回，这样岂不是更快。
这里想法虽然好，但是实现起来还是要注意很多细节，比如对于一个业务要返回的多条信息，如果其中一个协程查询失败，那么剩下的协程查询的数据如何处理，这样做又是否会增大数据库本事的查询压力，是否用一条查询语句就可以解决？这些都是这个策略的值得质疑的地方
- 使用redis优化评论列表的查询 这里使用redis连接池，优化redis的连接建立与释放，在评论列表响应接口里，先判断是否开启redis，如果开启，就以视频的id作为key查询redis是否存有数据，如果没有再到mysql里去查询，查询成功，再将结果顺带存入redis，这样下次再请求接口，就可以直接从redis获取，避免了mysql的访问，经过测试，发现redis的查询要比通过mysql的查询快5倍。
但是这里也个问题，对于过时的评论列表如何处理，我这里的策略就比较简单粗暴，为了保证redis和mysql的数据保持一致性，首先以mysql为主，增加评论和删除评论都将对应redis的数据删除，这样，当客户端再次访问评论列表接口的时候，就会去mysql查询，那么redis也就会更新与其保持一致了
这里我认为还有优化的余地，但是受限于客户端，上面的策略在评论列表频繁变化的情况下，基本没什么优势，所以可以再细分评论列表，这里可以评论时间细分，因为很少用户翻看所有评论，在客户端实现懒加载，按照时间或者数量动态拉取评论列表。
