CDN緩存服務器現狀,squid、nginx、trafficserver、ATS性能測試
squid本身是單進程架構，基本上大家的處理方式就是起多實例，所謂的多實例，
就是啓動多個squid，通過這樣的方式讓它可以起到多進程的效果。（心好累）
當然除了squid之外，還有一個比較新的cache，就是varnish。varnish的作者曾經在自己的博客上批評過squid中很多過時的思想
。宣稱自己的性能和架構要比squid強大很多。但是作爲一個只支持內存的緩存系統（有可以持久化的外圍手段），使用的場景是有限的。
目前使用varnish的，都是一些小站，或者說熱點很集中，緩存總量不大的業務場景。在前幾年，我瞭解到新浪微博有在用它。
隨着nginx的崛起，cache領域裏也有了它的身影。nginx的proxy_cache功能就是爲cache而設計的
其實有心的話，你去翻開ATS開發團隊，其實跟squid是有交集的。很多在squid中不完善的功能，在trafficserver中得到了完善和強化，
比如squid中的COSS文件系統，就是個公認的半成品。而在ATS中COSS的思想被發揚光大，其設計和架構讓人歎爲觀止。
正是由於ATS的出現，很多在技術上有遠見的公司和CDN廠商開始對ATS的研究和使用。就目前而言，CDN廠商裏網宿和帝聯已經將ATS用於
了生產環境。而很多新興的小CDN服務商或者雲服務提供商也紛紛使用了ATS。藍汛則在調研後放棄了ATS，還是抱着他們的squid不放。
不過近兩年，他們開始拿出一部分精力研究nginx。
現在使用nginx的公司，幾乎都在使用nginx lua。在WAF領域，nginx lua的出現，在技術實現上來說，完全變成了傻瓜式。
由於lua天生跟c，c++的密切性，使得連ATS都支持了lua模塊。所以很多公司的後端服務的架構也隨之發生了改變。他們開
始講純粹的業務邏輯剝離出來，用nginx lua來實現，放在前端。這樣原來必須在cache裏面用c或者c++寫業務邏輯的苦逼狀況得以極大的改善。
所以nginx+ats，nginx+squid的架構開始出現，並得到了廣泛過的應用。而阿里現在的架構也是這樣的：
在上圖中我們可以看到前面的nginx（也即是tengine）充當業務處理和調度，後面的cache（swfit）做緩存。這樣的架構，讓業務開發變得很容易，而且很高效。nginx+lua可以輕鬆搞定。
那麼問題來了，這樣的架構相比較直接用c/c++在cache寫業務處理，性能上肯定會降低，那麼就需要評估下性能降低的情況，如果太多，那麼即使是nginx+lua換來了開發和維護的低成本，可能也是難以接受的。我專門針對這兩種架構，進行了性能測試，cache使用的是ATS。
單純使用ATS:
Nginx+ATS:
通過數據對比我們可以看到，nginx+ats的性能較純ats，要降低大概5%，這個是完全可以接受的。注意這裏的nginx跟ats是放在一臺服務上的，如果分開不同的機器，那就得不償失了，不僅latency增加，機器的數量也隨之增加。
http://www.yidianzixun.com/n/0CoksWct?share_count=2