面向业务和面向硬件编程

计算机程序设计思想越来越有意思，充满了哲学的味道，今天总结下分层的设计优化思想：最上层面向业务、和最底层面向硬件。

面向业务编程
面向业务编程，就好比样本决定算法(数据工程师)，而不是拿模型套问题(机器学习工程师)。比如：

1. 如果是做cache，意味着输入的复用高，那么不仅可以做内容缓存，还可以进行计算缓存
2. 调优最有效的往往是减少输入，或者根据输入的特性特殊处理

与其说面向业务编程不如说面向业务设计，同样是短视频业务，客户也会针对不同的业务类型划分不同的域名。比如短视频美女美妆类的命中率能达98%，而个人生活随拍类热点却很低，通过区分域名，从CDN 角度而言，再给CDN加速 成本相对较低。
再举一个例子：
问题
squid 针对磁盘利用率有自己的逻辑统计，用以决定是否删除缓存。分段缓存功能文件可以是不完整的内容，在磁盘上查看可能只有50m，而squid逻辑统计根据cl头100m，逻辑大小和物理大小不一致。如果根据逻辑统计利用率，则会额外删除更多的其他缓存，导致删除过程中是否负载偏高。那么我们是否需要将分段缓存的逻辑统计改为真是占用物理大小呢？这样就不会删除额外更多的缓存了。

为什么当初没有改为真实物理占用大小统计呢？

1. 如果改为真实物理大小统计，那么以后会出现（曾经老东家遇到过）分段缓存无法填充完整。当前是已经预支了完整的大小 所以不会有问题。
2. 需要更改squid 原生的一些接口，我们改动代码尽可能避免。

解决方案
我们抛开“怎么将逻辑统计判断更改为真实物理的统计”问题 ，而是怎么解决“分段缓存预支空间导致删除了更多其他缓存的问题”。再来想想预支一定有错吗？
如果缓存很快被填满并且很热，那么预支是完全没问题的。
但是线上却有很多 短视频 业务 而且 很冷。比如像快手，我刷一个视频不感兴趣可能马上切下一个视频，如此每次只下开头一部分。
那么我们实际要解决的是这种业务问题：
方案一，业务拆分 宏观的解决思路
方案二，程序中热点缓存（降低命中率），或者对那些 只访问一次（refrence），且很久没有（lastreftime）访问 的删除，使用mgr:objects 统计 只访问一次 占比 50% 访问两次占比30%。这也是程序设计运营 mgr:objects 面向业务的一个设计。

如此 我们不用再纠结 “怎么将逻辑统计判断更改为真实物理大小的统计”

面向硬件编程
面向硬件是大部分有追求的程序员重点关注的事情，比如合并顺序写有利于磁盘，循环展开等等，后续再详细描述这些技巧

在开源软件中更改一定要注意设计思想的初衷，如果不遵循这个思想，大家后续代码最终会南辕北辙，臃肿不堪。