好的缓存方案应该从这几个方面入手设计：
1.什么数据应该缓存
2.什么时机触发缓存和以及触发方式是什么
3.缓存的层次和粒度（ 网关缓存如 nginx，本地缓存如单机文件，分布式缓存如redis cluster，进程内缓存如全局变量）
4.缓存的命名规则和失效规则
5.缓存的监控指标和故障应对方案
6.可视化缓存数据如 redis 具体 key 内容和大小

笔记：
书籍：
《高性能Mysql》
《unix编程艺术》：宁花机器一分，不花程序员一秒

提升性能：
先单机，有压力后优先考虑sql优化、db参数调优，还有硬件性能(32核/16G/SSD)优化，不行还可以再考虑业务逻辑优化、缓存。不要一上来就读写分离、集群等，能单库搞定的就毫不犹豫的单库。

---

主从读写分离
适用于单机无法应付所有请求，且读比写多时，读写分离还可以分别针对读写节点建索引来优化。
对实时性要求不高：刚写入就读会有延迟，同步数据特别大时，延迟可能达到分钟级（可用缓存解决：2-8原则，挑选占访问量80%的前20%来缓存）。
TODO主从还能设置自增长key不一样？

分库分表（甚用，增加很多复杂度）
几千万或上亿
分库时机：单机性能瓶颈，1业务不复杂，但整体数据量影响到数据库性能；2业务复杂，需要分系统由不同团队开发，使用分库减少团队耦合。（分库导致不能join和事务（有方案但性能太低用了跟没分库差别不大，用最终一致性/事件驱动））
分表时机：单表数据量大拖慢了sql性能，做垂直（将常用和不常用字段分开）或水平拆分（id分段、hash路由、添加路由表等）提高速度。（那么join、count、分页排序等就变得复杂）
TODO环状hash 一致性hash？

nosql
（nosql——not noly sql 本质上是牺牲ACID中的某个或某几个属性，以解决关系数据库某些复杂的问题）
关系数据库：强大的sql功能和ACID属性，发展了几十年技术相当成熟 Mysql / Postgresql
k-v存储：解决关系数据库无法存储数据结构的问题 Redis / Memcache （redis不太适合key的value特别大，这种情况会导致整个redis变慢，这种场景mc更好->参考IO模型 redis单Reactor单进程读写大value会阻塞所有业务 持久化也会）
文档数据库：解决关系数据库强schema约束，查询不存在的列会报错，扩充很麻烦还会长时间锁表 MongoDB
列式数据库：解决关系数据库处理大数据分析或统计时IO高的问题，关系数据库即使只处理某列也会把整行查询到内存中 HBase / Greenplum
全文搜索引擎：解决关系数据库全文搜索like扫描全表性能问题 ElasticSearch / solr
LevelDB 内存型？
时序数据库？：实时计算统计实时监控 influxDB
OLAP OLTP HTAP？

缓存（千万千万不要设计复杂的缓存，到时候各种不一致问题烦死你）
cdn、nginx缓存、网关缓存、数据层缓存redis、db本身也有缓存(sql结果缓存、读取的磁盘分页缓存)
缓存穿透：1本身无数据(添加默认值缓存/布隆过滤器[整型自增key？]) 2未生成缓存(识别爬虫并禁止 但可能影响seo)
缓存雪崩：缓存实效后大家都在更新缓存导致系统性能急剧下降（1消息队列通知后台更新、2使用分布式更新锁）
缓存热点：大部分业务都会命中的同一份缓存，比如1000w+粉丝的微博消息，复制多分缓存副本，key里面加副本编号将请求分散，且设置过期范围，而不是所有副本固定同一过期时间。
缓存框架看一下设计思路：echcache、网友分享https://github.com/qiujiayu/AutoLoadCache

计算机界两大难题：命名和缓存过期。没用缓存的时候，想着怎么用缓存提升性能，用了缓存又担心数据更新不及时。技术上希望所有的请求都能命中缓存，业务上又恨不得数据实时最新。所以就会引入各种缓存过期策略，如设置过期时间，按规则删除，打版本。这些应该在前期设计缓存系统时规划好，我们最早是将 sql md5 作 key 查询结果存入缓存，结果业务系统数据不一致，要清除缓存简直是噩梦，只能祭出绝招重启 memcache，后面改成按规则删除，在 key 中加上业务和用户的前缀，可以很方便删除某个业务或某个用户的缓存。以上过期策略在前端浏览器也是这样，最简单就是 web 服务器设置静态资源缓存过期时间，如果业务频繁发新版本，过期时间不宜设置太长，但其实每次变动的文件很少，这种策略会导致大部分缓存命中率不高。按规则删除，早期很多网站上会有诊断助手类的东西，页面加载错误点下诊断助手就帮你清除缓存，原理就是对静态文件逐一带上 no-cache 请求头发送 ajax 请求强制覆盖缓存（跟 DevTools 中 disable cache 原理一样）。打版本其实就相当于让浏览器请求一个新版本文件，对于老版本文件就让它在缓存中自生自灭。

上缓存架构的时候，结合以前的实际经历，会有几个值得注意的地方:

1 哪些数据才真正的需要缓存？缓存也并非银弹。既然允许数据缓存，那么在你是可以接受在一定时间区间内的数据不一致性的。(当然可以做到最终一致性)

2 确定好1后，就需要会数据类型进行分类，比如业务数据缓存，http缓存等

3 根据数据类型及访问特点的不同选择不同缓存类型的技术方案。

请问华仔，热点数据存在相当的突发性，临时的扩容似乎也来不及，能否从缓存架构角度如何避免类似微博宕机的事件？

刚好前段时间就有一个问题。
产品反馈：后台更新的配置不生效，需要过几小时到半天不等的时间才能生效。
从数据库确认持久化数据没问题，因此怀疑是缓存问题。

我们的缓存设计是：业务key加一个缓存版本号做key，每次更新数据对应缓存的版本号就+1。
前台定期扫描缓存版本号来实现缓存的更新。

于是我查到了线上最新的版本号去缓存服务器查询，见鬼，数据也是正常的。排查了几天没有结果，无奈上线一个版本打了debug日志，终于找到原因了。

我们的服务是双中心的，两边各存有一份缓存版本号，不知道什么原因，导致一边的缓存版本号比另外一个集群的多了3。由于我们的更新策略不是删掉无效的缓存，而是更新缓存的key，因此旧版本的缓存数据实际上还在缓存服务器上。更要命的是缓存服务器做了双中心同步（为啥同步暂且不提），这样就导致实际上一边集群读取的实际上是另外一个集群几个版本前留下的缓存数据。需要等待这个数据过期后，才能正常从数据库加载数据。