計算機程序設計思想越來越有意思，充滿了哲學的味道，今天總結下分層的設計優化思想：最上層面向業務、和最底層面向硬件。
面向業務編程
面向業務編程，就好比樣本決定算法(數據工程師)，而不是拿模型套問題(機器學習工程師)。比如：
- 如果是做cache，意味着輸入的複用高，那麼不僅可以做內容緩存，還可以進行計算緩存
- 調優最有效的往往是減少輸入，或者根據輸入的特性特殊處理
與其說面向業務編程不如說面向業務設計，同樣是短視頻業務，客戶也會針對不同的業務類型劃分不同的域名。比如短視頻美女美妝類的命中率能達98%，而個人生活隨拍類熱點卻很低，通過區分域名，從CDN 角度而言，再給CDN加速 成本相對較低。
再舉一個例子：
問題
squid 針對磁盤利用率有自己的邏輯統計，用以決定是否刪除緩存。分段緩存功能文件可以是不完整的內容，在磁盤上查看可能只有50m，而squid邏輯統計根據cl頭100m，邏輯大小和物理大小不一致。如果根據邏輯統計利用率，則會額外刪除更多的其他緩存，導致刪除過程中是否負載偏高。那麼我們是否需要將分段緩存的邏輯統計改爲真是佔用物理大小呢？這樣就不會刪除額外更多的緩存了。
爲什麼當初沒有改爲真實物理佔用大小統計呢？
- 如果改爲真實物理大小統計，那麼以後會出現（曾經老東家遇到過）分段緩存無法填充完整。當前是已經預支了完整的大小 所以不會有問題。
- 需要更改squid 原生的一些接口，我們改動代碼儘可能避免。
解決方案
我們拋開“怎麼將邏輯統計判斷更改爲真實物理的統計”問題 ，而是怎麼解決“分段緩存預支空間導致刪除了更多其他緩存的問題”。再來想想預支一定有錯嗎？
如果緩存很快被填滿並且很熱，那麼預支是完全沒問題的。
但是線上卻有很多 短視頻 業務 而且 很冷。比如像快手，我刷一個視頻不感興趣可能馬上切下一個視頻，如此每次只下開頭一部分。
那麼我們實際要解決的是這種業務問題：
方案一，業務拆分 宏觀的解決思路
方案二，程序中熱點緩存（降低命中率），或者對那些 只訪問一次（refrence），且很久沒有（lastreftime）訪問 的刪除，使用mgr:objects 統計 只訪問一次 佔比 50% 訪問兩次佔比30%。這也是程序設計運營 mgr:objects 面向業務的一個設計。
如此 我們不用再糾結 “怎麼將邏輯統計判斷更改爲真實物理大小的統計”
面向硬件編程
面向硬件是大部分有追求的程序員重點關注的事情，比如合併順序寫有利於磁盤，循環展開等等，後續再詳細描述這些技巧
在開源軟件中更改一定要注意設計思想的初衷，如果不遵循這個思想，大家後續代碼最終會南轅北轍，臃腫不堪。
