平时服务端访问db遇到瓶颈的时候、大部分工程师会选择添加缓存、来缓解DB压力、提升程序性能、但一定是有效的吗 ?
添加缓存层.png
理解局部性原理
时间局部性: 若一个数据被访问了、短时间内再次被访问的概率就增加.
eg. 今天读一本小说、还未读完、明天接着读的概率就很大
电商系统中、用户打开一个APP、看到首屏、推断会访问其它页面、将用户的个人信息、从存储在硬盘的数据库读取到内存的缓存中来
利用的就是时间局部性
空间局部性: eg. 存储数据时、数组内的多项数据会存储在相邻位置、
好比图书馆会将同一系列的书放到一个书架上、摆在一起、加载的时候一并加载、
同一数据在短时间内会反复访问.png
相邻的数据被连续访问.png
有了时间和空间局部性、可以不用将数据都放在内场车、也不用都放在HDD上、而是将访问次数多的数据、放在贵但是快一些的存储器、访问次数少、价格便宜的放在慢但容量大的容器里、组合使用各种存储设备
如何花最少的钱满足存储需求？
假设: 需要提供一个亚马逊这样的电商网站、有6亿件商品、每件商品需要4MB 存储空间(共6亿 * 4MB = 2400TB)
1.数据都放在内存、需要3600w美元(2400TB/1MB * 0.015美元)
2.假设内存只存放1%的热门商品600w件、剩下存储到HDD硬盘上、存储成本就下降到 45.6w美元、原来的1.3%
3600w美元*1% + 2400T/1M * 0.00004美元 = 45.6w美元
利用的就是时间局部性、将用户访问过的数据、加载到内存中、一旦内存放不下、就把长时间未访问的数据从内存移走、
其实就是LRU缓存算法、商品访问越频繁、越容易在内存找到、很好的利用了内存的随机访问性
另外还要关注一个指标: 缓存命中率 (Hit Rate / Hit Ratio)
内存的随机访问需要100ns、即: 极限情况下、可以支持1000w次随机访问
假设: 用了24T(8G一条)内存、意味着3000条内存、可以支持每秒300亿次访问
24TB / 8GB * 1s/100ns = 300亿
以2017年3亿的用户来看、每天的活跃用户1亿、平均访问100个商品、平均每秒访问的商品数量12w次
假设数据没有命中缓存、对应的数据请求访问HDD磁盘、一块硬盘每秒只能支撑100次随机访问、
2400TB的数据、4TB一块磁盘的话、有600块、每秒支撑 6w次请求
2400TB/4TB * 1s/10ms
这意味着: 所有的商品都直接到了HDD硬盘、HDD支撑不了这样的压力
至少需要50%的缓存命中率、HDD磁盘才可以支撑对应的访问次数
