平时服务端访问db遇到瓶颈的时候、大部分工程师会选择添加缓存、来缓解DB压力、提升程序性能、但一定是有效的吗 ?
理解局部性原理
1 2 3 4 5 6 7
| 时间局部性: 若一个数据被访问了、短时间内再次被访问的概率就增加. eg. 今天读一本小说、还未读完、明天接着读的概率就很大 电商系统中、用户打开一个APP、看到首屏、推断会访问其它页面、将用户的个人信息、从存储在硬盘的数据库读取到内存的缓存中来 利用的就是时间局部性
空间局部性: eg. 存储数据时、数组内的多项数据会存储在相邻位置、 好比图书馆会将同一系列的书放到一个书架上、摆在一起、加载的时候一并加载、
|
有了时间和空间局部性、可以不用将数据都放在内场车、也不用都放在HDD上、而是将访问次数多的数据、放在贵但是快一些的存储器、访问次数少、价格便宜的放在慢但容量大的容器里、组合使用各种存储设备
如何花最少的钱满足存储需求?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
| 假设: 需要提供一个亚马逊这样的电商网站、有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磁盘才可以支撑对应的访问次数
|