看到了大佬的文章：https://zhuanlan.zhihu.com/p/1932613410174014236
学习了一番然后来简单总结一下。感兴趣的可以去这个知乎的文章里看，材料更加完善
核心点还是设计系统的决策点是跟着这些基础设施的能力走的：
* 多核bulabula
* memory便宜，ssd随机读写变快bulabula的
因为之前的five minute rule是基于存储层次来设计的，内存->磁盘，上层的延迟/带宽是大于下一层的。而在云上的S3虽然延迟大，但是带宽也大，也比较便宜。
所以在设计的时候不是简单的分层，而是考虑每一个存储介质的特性。带宽/延迟/成本，或者更细一点Iops, 随机读/顺序写带宽等。
文章结论并不严谨，有个概念就行
非延迟敏感型，随着访问的次数增加，直接访问OSS的成本会上升，此时就不如把数据做一下缓存，放到EBS/ECS的盘上。
这里算出来是每秒7次，超过7次则缓存。这个量级感觉很多计算类任务直接访问OSS好一些。
延迟敏感型，这里是先测了一下用多大的io size比较合适。因为更大的io size可能导致无法满足延迟要求。io size小了则太贵（看了下S3是只根据请求次数收费，不看io size）。结论是用1M的io size，在150ms下比较合适。
成本上，因为如果要满足延迟的需求，会需要用backup read来降低读的延迟。从而提高请求的次数。可以看到图上100ms延迟，基本上很早缓存的效果就会提升了。
每小时2次读取，缓存就已经变得足够高效了。
总结就是根据workload来选择是否选用缓存。这块结论还是符合大家的直觉，延迟敏感就用缓存，不敏感就用OSS。
文章评论