web緩存伺服器

⑴ web緩存有哪幾種方式

1 應用程序實現的動態頁面緩存
應用程序把動態文件生成的html文件緩存到文件伺服器，以後用戶請求動態文件，直接從文件伺服器載入對應的靜態緩存的html文件返回給用戶，這裡面主要節省了動態語言的執行時間和資料庫訪問時間。但是會增加了緩存框架的載入和緩存查找的時間。

2 把解釋執行的開發語言編譯成為目標代碼
這個主要把解釋執行的高級語言，例如java，php直接編譯成為平台相關的目標代碼，匯編代碼。在java裡面，比較著名的就是即時編譯器（JIT），其他的語言也要類似的機制。這裡面主要節省了就是解釋執行代碼的時間。這個會增加即時編譯的時間。

3 利用反向代理伺服器的緩存
利用類似nginx的反向代理伺服器，對請求的url對應的輸出的進行緩存。這個緩存和應用程序實現的動態頁面緩存類似，只不過用反向代理充當了應用程序的緩存實現。主要節省了動態余元執行時間和資料庫訪問時間。

4 客戶端瀏覽器緩存
客戶端瀏覽器緩存主要是通過在http頭部增加
Last-Modified,If-Modified-Since,Expires,Cache-Control等標識，和伺服器進行協商，是否是採用客戶的本機緩存來實現。
其中這裡面也會分為三種方式
1 通過Last-Modified，If-Modified-Since方式和伺服器通信，客戶發出http請求中包含If-Modified-Since，如果伺服器端代碼沒有修改，伺服器端返回302響應代碼的請求響應頭（內容不返回）客戶端則直接用本機緩存的內容緩存顯示結果。相當於節省了伺服器執行代碼時間以及數據傳輸時間。
2 通過Expires,Cache-Control控制，客戶端發現如果上次請求的頁面還未過期，通過Expires或者Cache-Control進行辨別，則直接顯示本機緩存的內容，不與伺服器進行通信。

總結一下：1 一般的高並發的應用程序，都在web層採用了以上幾種緩存，一般靜態資源（圖片，js，css）都會採用nginx反向代理+客戶端緩存來實現。
2 對於門戶網站，尤其是首頁的新聞，一般都會緩存起來，可以通過反向代理也可以通過應用程序緩存實現方式
3 對於下載或者視頻網站，由於數據傳輸比較大，直接採用瀏覽器本地緩存實現。

⑵ 緩存對於web開發有什麼重要作用

• 減少網路帶寬消耗。無論對於網站運營者或者用戶，帶寬都代表著金錢，過多的帶寬消耗，只會便宜了網路運營商。當Web緩存副本被使用時，只會產生極小的網路流量，可以有效的降低運營成本。

• 降低伺服器壓力。給網路資源設定有效期之後，用戶可以重復使用本地的緩存，減少對源伺服器的請求，間接降低伺服器的壓力。同時，搜索引擎的爬蟲機器人也能根據過期機制降低爬取的頻率，也能有效降低伺服器的壓力。

• 減少網路延遲，加快頁面打開速度。帶寬對於個人網站運營者來說是十分重要，而對於大型的互聯網公司來說，可能有時因為錢多而真的不在乎。那Web緩存還有作用嗎？答案是肯定的，對於最終用戶，緩存的使用能夠明顯加快頁面打開速度，達到更好的體驗。

⑶ WEB 緩存伺服器

秒開緩存系統
，不過想要
緩存伺服器
自動訪問互聯網資源那是不可取的，佔用
網路帶寬
..用戶上網體驗不好~

⑷ Squid代理緩存的Web伺服器

於IE Internet選項 連接 區域網設置

看有無啟用代理伺服器

..

⑸ 固態硬碟當WEB伺服器緩存這個可行嗎

可行的呀，只要是你的軟體的佔用量沒有固態的容量大。
緩存是緩存在了內存里，內存不是太小，內存空間可以滿足就可以的。
固態的硬碟，轉速快，運算能力好，但是一旦壞掉，數據沒法恢復，建議做好備份。

⑹ web伺服器有自己的緩存嗎

不是說你的文件修改了，就一定會清楚掉緩存，這個是又瀏覽器決定的。強制設置If-Modified-Since，目的是用本地的文件時間作對比，如果早過這個時間，那麼才會強制訪問伺服器上的文件。

⑺ 緩存伺服器的緩存概念

這是兩種主要的Web緩存：
直接緩存，將用戶頻繁訪問的來自Internet伺服器的Web對象的拷貝保存在企業本地網路中。
反向緩存，企業內部Web伺服器的Web對象的拷貝保存在企業網路邊緣的代理伺服器上以提高外界訪問企業站點的性能。
Web緩存可以根據不同等級進行配置：
本地緩存：將Web對象緩存的拷貝保存在本地計算機中。大多數流行的Web瀏覽器默認情況下保留一個先前訪問對象的緩存。例如，Internet Explorer稱之為「臨時Internet文件」。本地緩存拷貝只是在用戶頻繁地從同一台機器訪問頁面時有用。
代理緩存：代理伺服器是為公司內的多個用戶/客戶計算機緩存Web對象的單獨機器。它們是位於客戶端和託管的Web伺服器之間的計算機，而且它們比本地緩存效率更高，因為在企業本地網路中的任何用戶或計算機訪問某個Web對象時，緩存拷貝對想訪問該對象的任何其他用戶/計算機是可用的，無需到Internet伺服器上再次下載它。代理緩存可以在網路邊緣與防火牆結合使用。
微軟的ISA Server和BlueCoat的工具一樣，既包括防火牆也包括緩存代理伺服器。緩存伺服器也可以是單獨的機器，運行免費的緩存軟體或商業產品，例如：
Linux版的Squid免費緩存代理
MOWS基於Java分布式web和緩存伺服器
Vicomsoft RapidCache Server for Windows或Macintosh
WinProxy for Windows
可升級的緩存解決方案
隨著公司的擴大，單一的Web緩存伺服器可能無法處理所有的通信或存儲足夠的Web對象。在這種情況下，可以擴展緩存解決方案以建立一個緩存陣列——一組共同工作以便在組內分配緩存負載的緩存代理伺服器。萬一某個緩存伺服器停機，還提供預設的容量。
要在陣列中操作，緩存伺服器必須能夠彼此使用協議進行通信，例如：
WCCP（Web緩存協調協議），Cisco緩存產品以及諸如Squid這樣的開源代理使用。
ICP（Internet緩存協議），被Squid和BlueCoat支持。
CARP（緩存陣列路由協議），被ISA Server Enterprise Edition用來管理緩存伺服器陣列的失效轉移和負載平衡。
CARP能夠支持幾乎無限的線性擴展以滿足快速增長型企業的需求。當向某個陣列中添加或移除一台伺服器時，CARP自動調整並再指定URL以有效地分布負載。
緩存陣列能夠以等級的或分布式的架構排列。在分布式緩存中，陣列中所有代理伺服器處在一個「平等地位」而且負載在它們之間進行分配。在分等級的緩存中，代理以鏈式進行配置，它們處在不同的等級，所以伺服器或陣列連接到其它離Internet更近的伺服器或陣列（離Internet最近的那些伺服器或陣列被看作「上游的」，那些最遠的被看作「下游的」）。這樣，緩存內容會盡可能地靠近需要它的用戶。
陣列是高度可升級的，因為可以向陣列添加伺服器，或向分等級的架構增加陣列等級，而無需擾亂目 前的緩存解決方案。
另一個可擴展性問題是使用緩存減少分支機構網路帶寬的能力。分支機構代理可能沒有直接連接到Internet，但是可以使用撥號連接或辦公室到辦公室的WAN連接以便從總公司的上游代理伺服器上請求Web對象。
另一個選擇是為需要向消費者提供基於Web的應用，可使用諸如由Akamai提供的服務。他們的Web Application Accelerator服務通過下列方法優化性能：
向他們的邊緣伺服器動態映射請求，並監視Internet路由以便在最快和最可靠的路由上傳輸。
利用壓縮技術和預取技術（pre-fetching）以最小化帶寬使用率。
用安全套接層（SSL）保護Web傳輸。
緩存支持的有些硬體標准：
目前緩存支持的硬體標准：
內存不超過4G，超過的只識別4G。
硬碟不超過2T，超過的只識別2T
存儲硬碟數量最大支持4塊（如果系統盤是電子盤不包含在內）
另外推薦使用INTEL的機器和網卡。

⑻ WEB伺服器緩存問題，高手請進

在注冊表新建以下三個DWORD類型十進制數值
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
TcpNumConnections = 2000
MaxUserPort = 65534
TCPTimedWaitDelay = 30

需要重啟，也有可能是內存使用率太高和個人防火牆的原因

⑼ Web緩存伺服器有什麼作用

Fikker 是國內第一款面向廣大站長的專業級網站加速伺服器軟體，全界面化管理，利用頁面緩存技術（webcache），網站管理員或開發人員通過 Fikker 管理平台將指定的頁面緩存起來，其他用戶在訪問相同頁面時候，就不需要網站讀取資料庫後再生成頁面了，Fikker 直接返回用戶需要的頁面，平均響應速度提升 10 倍以上；另外 Fikker 通過 gzip 將頁面（html，asp，php，css，js）壓縮起來，減少了傳輸尺寸，提高傳輸效率和減少帶寬佔用。網站負載將會變的很輕松，是的！Fikker 的目標就是：讓你的網站飛起來。

作為網站的前置伺服器，Fikker 還提供了強大的實時監控功能，防盜鏈，源站負載均衡，偽靜態（URL靜態化），Ajax跨域操作，黑名單管理等一站式解決方案，網站管理簡單到極致，但功能強悍到難以想像。
Fikker 從原始架構開始設計，跨平台（支持 Windows 和 Linux）和面向伺服器類軟體方向設計，經過多年的精雕細琢，穩定性，功能性和易用性大大提升，一些功能特點，在很多設計和實現上是國內甚至是國際上的創新，例如：會員緩存加速，一些 SNS 和 BBS 網站，只針對登錄會員用戶開放，要實現加速，就需要針對登錄會員加速，而且全界面化配置和操作等等。

⑽ web伺服器怎麼使用redis分步式緩存

Redis復制流程概述
Redis的復制功能是完全建立在之前我們討論過的基於內存快照的持久化策略基礎上的，也就是說無論你的持久化策略選擇的是什麼，只要用到了Redis的復制功能，就一定會有內存快照發生，那麼首先要注意你的系統內存容量規劃，原因可以參考我上一篇文章中提到的Redis磁碟IO問題。
Redis復制流程在Slave和Master端各自是一套狀態機流轉，涉及的狀態信息是：
Slave 端：
REDIS_REPL_NONEREDIS_REPL_CONNECTREDIS_REPL_CONNECTED
Master端：
REDIS_REPL_WAIT_BGSAVE_STARTREDIS_REPL_WAIT_BGSAVE_ENDREDIS_REPL_SEND_BULKREDIS_REPL_ONLINE
整個狀態機流程過程如下：
Slave端在配置文件中添加了slave of指令，於是Slave啟動時讀取配置文件，初始狀態為REDIS_REPL_CONNECT。
Slave端在定時任務serverCron(Redis內部的定時器觸發事件)中連接Master，發送sync命令，然後阻塞等待master發送回其內存快照文件(最新版的Redis已經不需要讓Slave阻塞)。
Master端收到sync命令簡單判斷是否有正在進行的內存快照子進程，沒有則立即開始內存快照，有則等待其結束，當快照完成後會將該文件發送給Slave端。
Slave端接收Master發來的內存快照文件，保存到本地，待接收完成後，清空內存表，重新讀取Master發來的內存快照文件，重建整個內存表數據結構，並最終狀態置位為 REDIS_REPL_CONNECTED狀態，Slave狀態機流轉完成。
Master端在發送快照文件過程中，接收的任何會改變數據集的命令都會暫時先保存在Slave網路連接的發送緩存隊列里（list數據結構），待快照完成後，依次發給Slave,之後收到的命令相同處理，並將狀態置位為 REDIS_REPL_ONLINE。

整個復制過程完成，流程如下圖所示：

Redis復制機制的缺陷
從上面的流程可以看出，Slave從庫在連接Master主庫時，Master會進行內存快照，然後把整個快照文件發給Slave，也就是沒有象Mysql那樣有復制位置的概念，即無增量復制，這會給整個集群搭建帶來非常多的問題。
比如一台線上正在運行的Master主庫配置了一台從庫進行簡單讀寫分離，這時Slave由於網路或者其它原因與Master斷開了連接，那麼當Slave進行重新連接時，需要重新獲取整個Master的內存快照，Slave所有數據跟著全部清除，然後重新建立整個內存表，一方面Slave恢復的時間會非常慢，另一方面也會給主庫帶來壓力。
所以基於上述原因，如果你的Redis集群需要主從復制，那麼最好事先配置好所有的從庫，避免中途再去增加從庫。
Cache還是Storage
在我們分析過了Redis的復制與持久化功能後，我們不難得出一個結論，實際上Redis目前發布的版本還都是一個單機版的思路，主要的問題集中在，持久化方式不夠成熟，復制機制存在比較大的缺陷，這時我們又開始重新思考Redis的定位：Cache還是Storage？
如果作為Cache的話，似乎除了有些非常特殊的業務場景，必須要使用Redis的某種數據結構之外，我們使用Memcached可能更合適，畢竟Memcached無論客戶端包和伺服器本身更久經考驗。
如果是作為存儲Storage的話，我們面臨的最大的問題是無論是持久化還是復制都沒有辦法解決Redis單點問題，即一台Redis掛掉了，沒有太好的辦法能夠快速的恢復，通常幾十G的持久化數據，Redis重啟載入需要幾個小時的時間，而復制又有缺陷，如何解決呢？
Redis可擴展集群搭建1. 主動復制避開Redis復制缺陷。
既然Redis的復制功能有缺陷，那麼我們不妨放棄Redis本身提供的復制功能，我們可以採用主動復制的方式來搭建我們的集群環境。
所謂主動復制是指由業務端或者通過代理中間件對Redis存儲的數據進行雙寫或多寫，通過數據的多份存儲來達到與復制相同的目的，主動復制不僅限於用在Redis集群上，目前很多公司採用主動復制的技術來解決MySQL主從之間復制的延遲問題，比如Twitter還專門開發了用於復制和分區的中間件gizzard(https://github.com/twitter/gizzard) 。
主動復制雖然解決了被動復制的延遲問題，但也帶來了新的問題，就是數據的一致性問題，數據寫2次或多次，如何保證多份數據的一致性呢？如果你的應用對數據一致性要求不高，允許最終一致性的話，那麼通常簡單的解決方案是可以通過時間戳或者vector clock等方式，讓客戶端同時取到多份數據並進行校驗，如果你的應用對數據一致性要求非常高，那麼就需要引入一些復雜的一致性演算法比如Paxos來保證數據的一致性，但是寫入性能也會相應下降很多。
通過主動復制，數據多份存儲我們也就不再擔心Redis單點故障的問題了，如果一組Redis集群掛掉，我們可以讓業務快速切換到另一組Redis上，降低業務風險。
2. 通過presharding進行Redis在線擴容。
通過主動復制我們解決了Redis單點故障問題，那麼還有一個重要的問題需要解決：容量規劃與在線擴容問題。
我們前面分析過Redis的適用場景是全部數據存儲在內存中，而內存容量有限，那麼首先需要根據業務數據量進行初步的容量規劃，比如你的業務數據需要100G存儲空間，假設伺服器內存是48G，那麼根據上一篇我們討論的Redis磁碟IO的問題，我們大約需要3~4台伺服器來存儲。這個實際是對現有業務情況所做的一個容量規劃，假如業務增長很快，很快就會發現當前的容量已經不夠了，Redis裡面存儲的數據很快就會超過物理內存大小，那麼如何進行Redis的在線擴容呢？
Redis的作者提出了一種叫做presharding的方案來解決動態擴容和數據分區的問題，實際就是在同一台機器上部署多個Redis實例的方式，當容量不夠時將多個實例拆分到不同的機器上，這樣實際就達到了擴容的效果。
拆分過程如下：
在新機器上啟動好對應埠的Redis實例。
配置新埠為待遷移埠的從庫。
待復制完成，與主庫完成同步後，切換所有客戶端配置到新的從庫的埠。
配置從庫為新的主庫。
移除老的埠實例。
重復上述過程遷移好所有的埠到指定伺服器上。

以上拆分流程是Redis作者提出的一個平滑遷移的過程，不過該拆分方法還是很依賴Redis本身的復制功能的，如果主庫快照數據文件過大，這個復制的過程也會很久，同時會給主庫帶來壓力。所以做這個拆分的過程最好選擇為業務訪問低峰時段進行。
Redis復制的改進思路
我們線上的系統使用了我們自己改進版的Redis,主要解決了Redis沒有增量復制的缺陷，能夠完成類似Mysql Binlog那樣可以通過從庫請求日誌位置進行增量復制。
我們的持久化方案是首先寫Redis的AOF文件，並對這個AOF文件按文件大小進行自動分割滾動，同時關閉Redis的Rewrite命令，然後會在業務低峰時間進行內存快照存儲，並把當前的AOF文件位置一起寫入到快照文件中，這樣我們可以使快照文件與AOF文件的位置保持一致性，這樣我們得到了系統某一時刻的內存快照，並且同時也能知道這一時刻對應的AOF文件的位置，那麼當從庫發送同步命令時，我們首先會把快照文件發送給從庫，然後從庫會取出該快照文件中存儲的AOF文件位置，並將該位置發給主庫，主庫會隨後發送該位置之後的所有命令，以後的復制就都是這個位置之後的增量信息了。

Redis與MySQL的結合
目前大部分互聯網公司使用MySQL作為數據的主要持久化存儲，那麼如何讓Redis與MySQL很好的結合在一起呢？我們主要使用了一種基於MySQL作為主庫，Redis作為高速數據查詢從庫的異構讀寫分離的方案。
為此我們專門開發了自己的MySQL復制工具，可以方便的實時同步MySQL中的數據到Redis上。

（MySQL-Redis 異構讀寫分離）
總結：
Redis的復制功能沒有增量復制，每次重連都會把主庫整個內存快照發給從庫，所以需要避免向在線服務的壓力較大的主庫上增加從庫。
Redis的復制由於會使用快照持久化方式，所以如果你的Redis持久化方式選擇的是日誌追加方式(aof),那麼系統有可能在同一時刻既做aof日誌文件的同步刷寫磁碟，又做快照寫磁碟操作，這個時候Redis的響應能力會受到影響。所以如果選用aof持久化，則加從庫需要更加謹慎。
可以使用主動復制和presharding方法進行Redis集群搭建與在線擴容。