背景
功能本身复杂度不高，但业务场景多、QPS高、用户体量、数据量大；最核心、对响应性能要求最高的主要是：用户是否点赞内容、内存点赞数场景
v1.0
实现方案：基于Redis+MySQL架构，MySQL做数据存储和查询支持，Redis撑起业务的高性能响应。
- 缓存构造时要查询动态下所有点赞用户数据，数据量大，容易产生慢SQL，对DB和带宽都可能产生比较大的压力
- 缓存存储结构上为Key-Value结构，每次使用需要先从Redis查询，再反序列化成数组，在in_array和count方法都比较有较大的开销
- 缓存维护上，每次新增点赞都直接清除缓存，热门下缓存将击穿，造成大量DB回查
v2.0
采用集合结构，集合中ID不出现重复，维护动态下的点赞总数，可以查看用户是否在集合中，判断是否点赞
- 将动态下全部点赞记录查询出来，放在一个集合中，当一个热门动态时，点赞用户量非常大，会造成集合变成一个大key，大key的清除容易造成Redis稳定性影响。
