web 开发中为了增加接口的响应速度或者业务逻辑的处理速度，会对写使用频率比较高，或者对实时性要求比较高的数据做缓存
1、mysql 的使用
- mysql 使用查询语句获取数据时，应秉持尽量少的查询次数，将查询参数尽量拼接的原则。
- 如用户表，在已知多个用户id，查询其某些属性时，应使用and语句一次性将多个用户的属性查出，而非对用户进行单个属性的查询
2、需要使用缓存的数据具有以下特征
- 基础服务数据
- 比如证券行业使用的股票行情数据，需要频繁为其他业务提供服务。
- 独立数据
- 比如官网首页数据，和用户或账号无关的数据，并且访问频率比较高的数据。
- 冷数据
- 此部分数据更新频率较低或不更新
3、缓存的时机
- 项目启动时缓存
- 自活能力:：如果使用缓存，则需要缓存很强的自活能力，比如项目运行时发现缓存丢失，可以自行初始缓存，以保证项目的正常运行。
- 异步缓存： 项目启动不宜耗时太久，如果项目启动时的缓存数据过多，则建议将数据内容进行分类，在项目启动时将独立的数据进行异步初始化缓存处理。
- 缓存日志： 缓存完成时将缓存结果输出到日志中，以便获取项目启动时的缓存进度和结果。
- 定时缓存
- 满足业务需求：根据数据的实时性和有效性，对数据进行定时缓存(注意对服务器资源的占用处理，尽量优化处理部分的代码)。
- 保证数据的准确性：需要及时清理或覆盖历史缓存数据。
- 事件触发缓存
- 具体逻辑具体分析
- 手动调用缓存
3、redis & ssdb 的选择
- 允许丢失且读取频率较高的数据使用 redis
- 需要持久化的数据 ssdb
4、redis & ssdb 的使用
- 数据结构的设计
- 不建议将包含迭代的数组或字典转换为json串作为value值进行存储。value在读取频率不高的情况下，建议最大单位为 2 层字典或数组嵌套的json串。
- key-value
- 存储简单数据类型，或访问频率以及数据量都很小的复杂数据类型
- hash-map
- 存储数据量比较多，读写频率比较高的数据
- set
- 集合数据，多涉及到业务数据
- zset
- 支持排序的集合，多涉及到具体业务
