技术解决方案储备（摘自rrc-wiki）
| 编号 | 名称 | 描述 | 解决问题 | 适用场景 | 绝对不可用场景 | 衍生问题 | 优点 | 缺点 | 推荐开源项目 |
| 1 | 缓存 | 在数据源之前增加一层或多层数据缓存，降低访问低性能数据源的频次或减少网络/IO开销，以达到提升性能的目的。 | 1. 高并发性能 | 1. 读多写少的业务 2. 读场景下热点数据命中率高 3. 多数据的更新展示时延要求较低 |
1. 热点数据分布不均匀，还是可能导致 cache 物理机成为访问热点，引发问题 2. 如果存在回源策略，则在 cache 失效时，要注意短时间内大量回源请求发生，引发雪崩 3. 要考虑 cache 的整体容量 |
1. 目前最常见的解决方案，整体技术栈成熟，相关资料丰富 | 1. [YAC](https://github.com/laruence/yac) 2. [redis](https://redis.io) 3. [memcached](https://memcached.org) |
||
| 2 | 离线数据预热 | 将复杂计算逻辑从实时处理中抽离，提升实时访问时的性能。 | 1. 高并发性能 | 1. 数据更新频率低 2. 数据更新入口可控 3. 整体数据容量可控 |
1. 读写逻辑比较分散，会降低代码可读性 2. 所有预热的逻辑需要做统一管理，还需要和读取逻辑做关联 |
||||
| 3 | 压测 | 如何做压测？ | 评估性能、资源预分配 | 任何新增接口或较大变更的接口建议做压测 | 1. 如何加压？ 2. 配置差异的影响 3. 上下游依赖的情况下怎么压 |
||||
| 4 | 重传和超时 | 不同场景下重传和超时策略？ | 可靠性、响应时间可控 | 1. 合理超时避免异常时负载飙升 | 1. 非幂等接口避免重传 2. 超时参数要考虑上游的超时情况？ |
||||
| 5 | 性能监控 | 现有工具有哪些？（阿里云、openfalcon、线上日志或Kafka、命令等） | 日常运维、性能优化 | ||||||
| 6 | 服务发现和注册 | 业务平台有用Consul做统一路由中心，但有单点风险，利弊 | 1. 接口分散 2. 加密认证方式各不相同 |
是个大单点 | |||||
| 7 | 降级机制 | 目前我们用的Etcd+Confd，但用于db的账号和地址的变更；另外通过SLB做后端服务器流量控制 | 容灾方案 | ||||||
| 8 | 异步化 | 异步处理的方式有哪些（队列、DB、fastcgi_finish_request?）？适用范围？可能问题 | 解耦 | 触发事件 | 1. 异步任务通知 | ||||
| 9 | SQL vs. NoSQL |
数据存储方案有哪些？ 什么场景选用什么方案有什么评判标准么？ |
数据存储 | 数据存储 |
