對伺服器來說消息意味著什麼

『壹』 消息隊列原理及選型

消息隊列（Message Queue）是一種進程間通信或同一進程的不同線程間的通信方式。

Broker（消息伺服器）
Broker的概念來自與Apache ActiveMQ，通俗的講就是MQ的伺服器。

Procer（生產者）
業務的發起方，負責生產消息傳輸給broker

Consumer（消費者）
業務的處理方，負責從broker獲取消息並進行業務邏輯處理

Topic（主題）
發布訂閱模式下的消息統一匯集地，不同生產者向topic發送消息，由MQ伺服器分發到不同的訂閱 者，實現消息的廣播

Queue（隊列）
PTP模式下，特定生產者向特定queue發送消息，消費者訂閱特定的queue完成指定消息的接收。

Message（消息體）
根據不同通信協議定義的固定格式進行編碼的數據包，來封裝業務數據，實現消息的傳輸

點對點模型用於消息生產者和消息消費者之間點到點的通信。

點對點模式包含三個角色：

每個消息都被發送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留著消息，可以放在內存 中也可以持久化，直到他們被消費或超時。

特點：

發布訂閱模型包含三個角色：

多個發布者將消息發送到Topic，系統將這些消息傳遞給多個訂閱者。

特點：

AMQP即Advanced Message Queuing Protocol，是應用層協議的一個開放標准，為面向消息的中間件設計。消息中間件主要用於組件之間的解耦，消息的發送者無需知道消息使用者的存在，反之亦然。AMQP 的主要特徵是面向消息、隊列、路由（包括點對點和發布/訂閱）、可靠性、安全。

優點：可靠、通用

MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）是IBM開發的一個即時通訊協議，有可能成為物聯網的重要組成部分。該協議支持所有平台，幾乎可以把所有聯網物品和外部連接起來，被用來當做感測器和致動器（比如通過Twitter讓房屋聯網）的通信協議。

優點：格式簡潔、佔用帶寬小、移動端通信、PUSH、嵌入式系統

STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息協議，是一種為MOM(Message Oriented Middleware，面向消息的中間件)設計的簡單文本協議。STOMP提供一個可互操作的連接格式，允許客戶端與任意STOMP消息代理（Broker）進行交互。

優點：命令模式（非topicqueue模式）

XMPP（可擴展消息處理現場協議，Extensible Messaging and Presence Protocol）是基於可擴展標記語言（XML）的協議，多用於即時消息（IM）以及在線現場探測。適用於伺服器之間的准即時操作。核心是基於XML流傳輸，這個協議可能最終允許網際網路用戶向網際網路上的其他任何人發送即時消息，即使其操作系統和瀏覽器不同。

優點：通用公開、兼容性強、可擴展、安全性高，但XML編碼格式佔用帶寬大

RabbitMQ 是實現 AMQP（高級消息隊列協議）的消息中間件的一種，最初起源於金融系統，用於在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。 RabbitMQ 主要是為了實現系統之間的雙向解耦而實現的。當生產者大量產生數據時，消費者無法快速消費，那麼需要一個中間層。保存這個數據。

RabbitMQ 是一個開源的 AMQP 實現，伺服器端用Erlang語言編寫，支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等，支持 AJAX。用於在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。

Channel（通道）
道是兩個管理器之間的一種單向點對點的的通信連接，如果需要雙向交流，可以建立一對通道。

Exchange（消息交換機）
Exchange類似於數據通信網路中的交換機，提供消息路由策略。

RabbitMq中，procer不是通過信道直接將消息發送給queue，而是先發送給Exchange。一個Exchange可以和多個Queue進行綁定，procer在傳遞消息的時候，會傳遞一個ROUTING_KEY，Exchange會根據這個ROUTING_KEY按照特定的路由演算法，將消息路由給指定的queue。和Queue一樣，Exchange也可設置為持久化，臨時或者自動刪除。

Exchange有4種類型：direct(默認)，fanout， topic， 和headers。
不同類型的Exchange轉發消息的策略有所區別：

Binding（綁定）
所謂綁定就是將一個特定的 Exchange 和一個特定的 Queue 綁定起來。Exchange 和Queue的綁定可以是多對多的關系。

Routing Key（路由關鍵字）
exchange根據這個關鍵字進行消息投遞。

vhost（虛擬主機）
在RabbitMq server上可以創建多個虛擬的message broker，又叫做virtual hosts (vhosts)。每一個vhost本質上是一個mini-rabbitmq server，分別管理各自的exchange，和bindings。vhost相當於物理的server，可以為不同app提供邊界隔離，使得應用安全的運行在不同的vhost實例上，相互之間不會干擾。procer和consumer連接rabbit server需要指定一個vhost。

假設P1和C1注冊了相同的Broker，Exchange和Queue。P1發送的消息最終會被C1消費。
基本的通信流程大概如下所示：

Consumer收到消息時需要顯式的向rabbit broker發送basic。ack消息或者consumer訂閱消息時設置auto_ack參數為true。

在通信過程中，隊列對ACK的處理有以下幾種情況：

即消息的Ackownledge確認機制，為了保證消息不丟失，消息隊列提供了消息Acknowledge機制，即ACK機制，當Consumer確認消息已經被消費處理，發送一個ACK給消息隊列，此時消息隊列便可以刪除這個消息了。如果Consumer宕機/關閉，沒有發送ACK，消息隊列將認為這個消息沒有被處理，會將這個消息重新發送給其他的Consumer重新消費處理。

消息的收發處理支持事務，例如：在任務中心場景中，一次處理可能涉及多個消息的接收、處理，這應該處於同一個事務范圍內，如果一個消息處理失敗，事務回滾，消息重新回到隊列中。

消息的持久化，對於一些關鍵的核心業務來說是非常重要的，啟用消息持久化後，消息隊列宕機重啟後，消息可以從持久化存儲恢復，消息不丟失，可以繼續消費處理。

fanout 模式
模式特點：

direct 模式
任何發送到Direct Exchange的消息都會被轉發到routing_key中指定的Queue。

如果一個exchange 聲明為direct，並且bind中指定了routing_key，那麼發送消息時需要同時指明該exchange和routing_key。

簡而言之就是：生產者生成消息發送給Exchange， Exchange根據Exchange類型和basic_publish中的routing_key進行消息發送 消費者：訂閱Exchange並根據Exchange類型和binding key(bindings 中的routing key) ，如果生產者和訂閱者的routing_key相同，Exchange就會路由到那個隊列。

topic 模式
前面講到direct類型的Exchange路由規則是完全匹配binding key與routing key，但這種嚴格的匹配方式在很多情況下不能滿足實際業務需求。

topic類型的Exchange在匹配規則上進行了擴展，它與direct類型的Exchage相似，也是將消息路由到binding key與routing key相匹配的Queue中，但這里的匹配規則有些不同。
它約定：

以上圖中的配置為例，routingKey=」quick.orange.rabbit」的消息會同時路由到Q1與Q2，routingKey=」lazy.orange.fox」的消息會路由到Q1，routingKey=」lazy.brown.fox」的消息會路由到Q2，routingKey=」lazy.pink.rabbit」的消息會路由到Q2（只會投遞給Q2一次，雖然這個routingKey與Q2的兩個bindingKey都匹配）；routingKey=」quick.brown.fox」、routingKey=」orange」、routingKey=」quick.orange.male.rabbit」的消息將會被丟棄，因為它們沒有匹配任何bindingKey。

RabbitMQ，部署分三種模式：單機模式，普通集群模式，鏡像集群模式。

普通集群模式
多台機器部署，每個機器放一個rabbitmq實例，但是創建的queue只會放在一個rabbitmq實例上，每個實例同步queue的元數據。

如果消費時連的是其他實例，那個實例會從queue所在實例拉取數據。這就會導致拉取數據的開銷，如果那個放queue的實例宕機了，那麼其他實例就無法從那個實例拉取，即便開啟了消息持久化，讓rabbitmq落地存儲消息的話，消息不一定會丟，但得等這個實例恢復了，然後才可以繼續從這個queue拉取數據， 這就沒什麼高可用可言，主要是提供吞吐量 ，讓集群中多個節點來服務某個queue的讀寫操作。

鏡像集群模式

queue的元數據和消息都會存放在多個實例，每次寫消息就自動同步到多個queue實例里。這樣任何一個機器宕機，其他機器都可以頂上，但是性能開銷太大，消息同步導致網路帶寬壓力和消耗很重，另外，沒有擴展性可言，如果queue負載很重，加機器，新增的機器也包含了這個queue的所有數據，並沒有辦法線性擴展你的queue。此時，需要開啟鏡像集群模式，在rabbitmq管理控制台新增一個策略，將數據同步到指定數量的節點，然後你再次創建queue的時候，應用這個策略，就會自動將數據同步到其他的節點上去了。

Kafka 是 Apache 的子項目，是一個高性能跨語言的分布式發布/訂閱消息隊列系統（沒有嚴格實現 JMS 規范的點對點模型，但可以實現其效果），在企業開發中有廣泛的應用。高性能是其最大優勢，劣勢是消息的可靠性（丟失或重復），這個劣勢是為了換取高性能，開發者可以以稍降低性能，來換取消息的可靠性。

一個Topic可以認為是一類消息，每個topic將被分成多個partition(區)，每個partition在存儲層面是append log文件。任何發布到此partition的消息都會被直接追加到log文件的尾部，每條消息在文件中的位置稱為offset（偏移量），offset為一個long型數字，它是唯一標記一條消息。它唯一的標記一條消息。kafka並沒有提供其他額外的索引機制來存儲offset，因為在kafka中幾乎不允許對消息進行「隨機讀寫」。

Kafka和JMS（Java Message Service）實現(activeMQ)不同的是:即使消息被消費，消息仍然不會被立即刪除。日誌文件將會根據broker中的配置要求，保留一定的時間之後刪除；比如log文件保留2天，那麼兩天後，文件會被清除，無論其中的消息是否被消費。kafka通過這種簡單的手段，來釋放磁碟空間，以及減少消息消費之後對文件內容改動的磁碟IO開支。

對於consumer而言，它需要保存消費消息的offset，對於offset的保存和使用，有consumer來控制；當consumer正常消費消息時，offset將會"線性"的向前驅動，即消息將依次順序被消費。事實上consumer可以使用任意順序消費消息，它只需要將offset重置為任意值。(offset將會保存在zookeeper中，參見下文)

kafka集群幾乎不需要維護任何consumer和procer狀態信息，這些信息有zookeeper保存；因此procer和consumer的客戶端實現非常輕量級，它們可以隨意離開，而不會對集群造成額外的影響。

partitions的設計目的有多個。最根本原因是kafka基於文件存儲。通過分區，可以將日誌內容分散到多個server上，來避免文件尺寸達到單機磁碟的上限，每個partiton都會被當前server(kafka實例)保存；可以將一個topic切分多任意多個partitions，來消息保存/消費的效率。此外越多的partitions意味著可以容納更多的consumer，有效提升並發消費的能力。(具體原理參見下文)。

一個Topic的多個partitions，被分布在kafka集群中的多個server上；每個server(kafka實例)負責partitions中消息的讀寫操作；此外kafka還可以配置partitions需要備份的個數(replicas)，每個partition將會被備份到多台機器上，以提高可用性。

基於replicated方案，那麼就意味著需要對多個備份進行調度；每個partition都有一個server為"leader"；leader負責所有的讀寫操作，如果leader失效，那麼將會有其他follower來接管(成為新的leader)；follower只是單調的和leader跟進，同步消息即可。由此可見作為leader的server承載了全部的請求壓力，因此從集群的整體考慮，有多少個partitions就意味著有多少個"leader"，kafka會將"leader"均衡的分散在每個實例上，來確保整體的性能穩定。

Procers
Procer將消息發布到指定的Topic中，同時Procer也能決定將此消息歸屬於哪個partition；比如基於"round-robin"方式或者通過其他的一些演算法等。

Consumers
本質上kafka只支持Topic。每個consumer屬於一個consumer group；反過來說，每個group中可以有多個consumer。發送到Topic的消息，只會被訂閱此Topic的每個group中的一個consumer消費。

如果所有的consumer都具有相同的group，這種情況和queue模式很像；消息將會在consumers之間負載均衡。

如果所有的consumer都具有不同的group，那這就是"發布-訂閱"；消息將會廣播給所有的消費者。

在kafka中，一個partition中的消息只會被group中的一個consumer消費；每個group中consumer消息消費互相獨立；我們可以認為一個group是一個"訂閱"者，一個Topic中的每個partions，只會被一個"訂閱者"中的一個consumer消費，不過一個consumer可以消費多個partitions中的消息。kafka只能保證一個partition中的消息被某個consumer消費時，消息是順序的。事實上，從Topic角度來說，消息仍不是有序的。

Kafka的設計原理決定，對於一個topic，同一個group中不能有多於partitions個數的consumer同時消費，否則將意味著某些consumer將無法得到消息。

Guarantees

Kafka就比較適合高吞吐量並且允許少量數據丟失的場景，如果非要保證「消息可靠傳輸」，可以使用JMS。

Kafka Procer 消息發送有兩種方式(配置參數 procer.type)：

對於同步方式(procer.type=sync)？Kafka Procer 消息發送有三種確認方式(配置參數 acks)：

kafka的設計初衷是希望作為一個統一的信息收集平台，能夠實時的收集反饋信息，並需要能夠支撐較大的數據量，且具備良好的容錯能力。

持久性
kafka使用文件存儲消息，這就直接決定kafka在性能上嚴重依賴文件系統的本身特性。且無論任何OS下，對文件系統本身的優化幾乎沒有可能。文件緩存/直接內存映射等是常用的手段。因為kafka是對日誌文件進行append操作，因此磁碟檢索的開支是較小的；同時為了減少磁碟寫入的次數，broker會將消息暫時buffer起來，當消息的個數(或尺寸)達到一定閥值時，再flush到磁碟，這樣減少了磁碟IO調用的次數。

性能
需要考慮的影響性能點很多，除磁碟IO之外，我們還需要考慮網路IO，這直接關繫到kafka的吞吐量問題。kafka並沒有提供太多高超的技巧；對於procer端，可以將消息buffer起來，當消息的條數達到一定閥值時，批量發送給broker；對於consumer端也是一樣，批量fetch多條消息。不過消息量的大小可以通過配置文件來指定。對於kafka broker端，似乎有個sendfile系統調用可以潛在的提升網路IO的性能:將文件的數據映射到系統內存中，socket直接讀取相應的內存區域即可，而無需進程再次和交換。 其實對於procer/consumer/broker三者而言，CPU的開支應該都不大，因此啟用消息壓縮機制是一個良好的策略；壓縮需要消耗少量的CPU資源，不過對於kafka而言，網路IO更應該需要考慮。可以將任何在網路上傳輸的消息都經過壓縮。kafka支持gzip/snappy等多種壓縮方式。

生產者
負載均衡: procer將會和Topic下所有partition leader保持socket連接；消息由procer直接通過socket發送到broker，中間不會經過任何「路由層「。事實上，消息被路由到哪個partition上，有procer客戶端決定。比如可以採用「random「「key-hash「「輪詢「等，如果一個topic中有多個partitions，那麼在procer端實現「消息均衡分發「是必要的。

其中partition leader的位置(host:port)注冊在zookeeper中，procer作為zookeeper client，已經注冊了watch用來監聽partition leader的變更事件。
非同步發送：將多條消息暫且在客戶端buffer起來，並將他們批量的發送到broker，小數據IO太多，會拖慢整體的網路延遲，批量延遲發送事實上提升了網路效率。不過這也有一定的隱患，比如說當procer失效時，那些尚未發送的消息將會丟失。

消費者
consumer端向broker發送「fetch」請求，並告知其獲取消息的offset；此後consumer將會獲得一定條數的消息；consumer端也可以重置offset來重新消費消息。

在JMS實現中，Topic模型基於push方式，即broker將消息推送給consumer端。不過在kafka中，採用了pull方式，即consumer在和broker建立連接之後，主動去pull(或者說fetch)消息；這中模式有些優點，首先consumer端可以根據自己的消費能力適時的去fetch消息並處理，且可以控制消息消費的進度(offset)；此外，消費者可以良好的控制消息消費的數量，batch fetch。

其他JMS實現，消息消費的位置是有prodiver保留，以便避免重復發送消息或者將沒有消費成功的消息重發等，同時還要控制消息的狀態。這就要求JMS broker需要太多額外的工作。在kafka中，partition中的消息只有一個consumer在消費，且不存在消息狀態的控制，也沒有復雜的消息確認機制，可見kafka broker端是相當輕量級的。當消息被consumer接收之後，consumer可以在本地保存最後消息的offset，並間歇性的向zookeeper注冊offset。由此可見，consumer客戶端也很輕量級。

對於JMS實現，消息傳輸擔保非常直接:有且只有一次(exactly once)。
在kafka中稍有不同:

at most once: 消費者fetch消息，然後保存offset，然後處理消息；當client保存offset之後，但是在消息處理過程中出現了異常，導致部分消息未能繼續處理。那麼此後"未處理"的消息將不能被fetch到，這就是"at most once"。

at least once: 消費者fetch消息，然後處理消息，然後保存offset。如果消息處理成功之後，但是在保存offset階段zookeeper異常導致保存操作未能執行成功，這就導致接下來再次fetch時可能獲得上次已經處理過的消息，這就是"at least once"，原因offset沒有及時的提交給zookeeper，zookeeper恢復正常還是之前offset狀態。

exactly once: kafka中並沒有嚴格的去實現(基於2階段提交，事務)，我們認為這種策略在kafka中是沒有必要的。

通常情況下「at-least-once」是我們首選。(相比at most once而言，重復接收數據總比丟失數據要好)。

kafka高可用由多個broker組成，每個broker是一個節點；

創建一個topic，這個topic會劃分為多個partition，每個partition存在於不同的broker上，每個partition就放一部分數據。

kafka是一個分布式消息隊列，就是說一個topic的數據，是分散放在不同的機器上，每個機器就放一部分數據。

在0.8版本以前，是沒有HA機制的，就是任何一個broker宕機了，那個broker上的partition就廢了，沒法寫也沒法讀，沒有什麼高可用性可言。

0.8版本以後，才提供了HA機制，也就是就是replica副本機制。每個partition的數據都會同步到其他的機器上，形成自己的多個replica副本。然後所有replica會選舉一個leader出來，那麼生產和消費都跟這個leader打交道，然後其他replica就是follower。

寫的時候，leader會負責把數據同步到所有follower上去，讀的時候就直接讀leader上數據即可。

kafka會均勻的將一個partition的所有replica分布在不同的機器上，從而提高容錯性。

如果某個broker宕機了也沒事，它上面的partition在其他機器上都有副本的，如果這上面有某個partition的leader，那麼此時會重新選舉一個新的leader出來，大家繼續讀寫那個新的leader即可。這就有所謂的高可用性了。

寫數據的時候，生產者就寫leader，然後leader將數據落地寫本地磁碟，接著其他follower自己主動從leader來pull數據。一旦所有follower同步好數據了，就會發送ack給leader，leader收到所有follower的ack之後，就會返回寫成功的消息給生產者。

消息丟失會出現在三個環節，分別是生產者、mq中間件、消費者：

RabbitMQ

Kafka
大體和RabbitMQ相同。

Rabbitmq
需要保證順序的消息投遞到同一個queue中，這個queue只能有一個consumer，如果需要提升性能，可以用內存隊列做排隊，然後分發給底層不同的worker來處理。

Kafka
寫入一個partition中的數據一定是有序的。生產者在寫的時候 ，可以指定一個key，比如指定訂單id作為key，這個訂單相關數據一定會被分發到一個partition中去。消費者從partition中取出數據的時候也一定是有序的，把每個數據放入對應的一個內存隊列，一個partition中有幾條相關數據就用幾個內存隊列，消費者開啟多個線程，每個線程處理一個內存隊列。

『貳』 伺服器有哪些

文件伺服器、資料庫伺服器、郵件伺服器。
文件伺服器是指在計算機網路中,以文件數據的存儲與共告茄享為主要功能的伺服器,負責中央存儲和數據文件管理,處於同一網路環境。資料庫伺服器因為數據文件的重要性及數據的文件都較大,資料庫伺服器一般是指運行在網路中的一台或多台伺服器和資料庫管理系統軟體，郵件伺服器。
文件禪乎伺服器（Fileserver），又稱檔案襪襲察伺服器，是指在計算機網路環境中，所有用戶都可訪問的文件存儲設備，是一種專供其他電腦檢索文件和存儲的特殊電腦。文件伺服器通常比一般的個人電腦擁有更大的存儲容量，並具有一些其他的功能，如磁碟鏡像、多個網路介面。

『叄』 什麼是伺服器，伺服器是什麼意思

伺服器是提供計算服務的設備。通常是指那些具有較高計算能力，能夠提供給多個用戶使用的計算機。由於伺服器需要響應服務請求，並進行處理，因此一般來說伺服器應具備承擔服務並且保障服務的能力。

在網路環境下，根據伺服器提供的服務類型不同，分為文件伺服器、資料庫伺服器、應用程序伺服器、WEB伺服器等。

伺服器與主機不同，主機是通過終端給用戶使用的，伺服器是通過網路給客戶端用戶使用的，所以除了要有擁有終端設備，還要利用網路才能使用伺服器計算機，但用戶連上線後就能使用伺服器上的特定服務了。

和普通的個人計算機相比， 伺服器需要連續的工作在7X24小時環境。這就意味著伺服器需要更多的穩定性技術RAS，比如支持使用ECC內存。並通常會有多部連接在一起運作。

(3)對伺服器來說消息意味著什麼擴展閱讀

20世紀90年代之後，隨著數據機技術的發展，互聯網由窄帶的電話撥接，升級成為寬頻數據，這代表著以信息高速公路為象徵的網路新時代來臨。

互聯網普及同時改變了計算機用戶習慣，更大大普及網路聯系傳訊的方式，從文字到圖片，再到視頻，伺服器所能完成的工作也越來越復雜；

而雲端、大數據時代造就了各種新類型行業，如網路商店、網路電商、網路拍賣、網路銷售、網路游戲、網路設計及架設，以及越來越普遍性的雲端資料庫或備份庫。標准伺服器(Server)及文件伺服器(NAS)的普及正在時時優化及改變現有人類的生活。

『肆』 無法連接到伺服器，伺服器：消息 18456，級別 16，狀態 1

一般分析的都是這樣：

1、sql server服務沒有啟動；

檢查服務啟動，重新啟動服務故障依然。

2、修改了埠號；

打開網路實用工具，檢查啟用的協議中有TCP/IP協議，查看埠，是1433沒錯。

3、客戶端實用工具作了改動；

打開客戶端實用工具，檢查協議埠正常，重新創建一個別名，依然不行。

4、安裝的問題；

懷疑安裝步驟有問題。遂卸載重裝，一切默認，故障依然。

5、安裝版本的問題；

查看安裝光碟，是久經考驗的安裝盤，應該不會出問題。

6、系統的問題；

也看不出有什麼其它的問題，難道是系統的問題？不過重裝系統可太過麻煩，還是先想想其它的辦法，看能不能找到問題所在。檢查系統日誌，這個應該是一個比較好的習慣。仔細翻了一遍重新安裝後的日誌，赫然發現如下內容：您運行的 Microsoft SQL Server 2000 版本或 Microsoft SQL Server 2000 Desktop Engine (也稱為 MSDE) 和
Microsoft Windows Server 2003 家族使用時存在已知的安全弱點。為了減少計算機被某些病毒的攻擊，Microsoft SQL Server 2000，MSDE 或 兩者的 TCP/IP 和 UDP 網路埠被禁用。要啟用這些埠，您必須從 www.microsoft.com/sql/downloads/default.asp或www.microsoft.com/china/sql/downloads/default.asp安裝一個修補程序， 或 Microsoft SQL Server 2000 或 MSDE 的最新服務包。

有關更多信息，請參閱在 go.microsoft.com/fwlink/events.asp 的幫助和支持
終於找到問題了，原來是Windows的一個小小的安全考慮。那麼為什麼以前就沒遇到過呢，原來搞慣安全的人，安
裝好sql以後，在使用前一定會先修補漏洞，所以一直未注意過這個問題。看來什麼樣的習慣都會有一些弊端！
既然找到問題就簡單了，立刻到微軟網站：http://www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&FamilyID=8E2DFC8D-C20E-4446-99A9-B7F0213F8BC5

下載SP4的「資料庫組件（下載文件：SQL2000-KB884525-SP4-x86.EXE）」
安裝SQL Server SP4後，瀏覽器地址欄測試www.ITstudy.cn一切正常。

附：
連接sql server 2000伺服器的解決方案

解決方案步驟：
一 看ping 伺服器IP能否ping通。
這個實際上是看和遠程sql server 2000伺服器的物理連接是否存在。如果不行，請檢查網路，查看配置，當然得
確保遠程sql server 2000伺服器的IP拼寫正確。
二 在Dos或命令行下輸入telnet 伺服器IP 埠，看能否連通。
如telnet 202.114.100.100 1433
通常埠值是1433，因為1433是sql server 2000的對於Tcp/IP的默認偵聽埠。如果有問題，通常這一步會出問
題。通常的提示是「……無法打開連接,連接失敗"。
如果這一步有問題，應該檢查以下選項。
1 檢查遠程伺服器是否啟動了sql server 2000服務。如果沒有，則啟動。
2 檢查伺服器端有沒啟用Tcp/IP協議，因為遠程連接（通過網際網路）需要靠這個協議。檢查方法是，在伺服器上
打開開始菜單->程序->Microsoft SQL Server->伺服器網路實用工具，看啟用的協議里是否有tcp/ip協議，如果
沒有，則啟用它。
3 檢查伺服器的tcp/ip埠是否配置為1433埠。仍然在伺服器網路實用工具里查看啟用協議裡面的tcp/ip的屬
性，確保默認埠為1433，並且隱藏伺服器復選框沒有勾上。
事實上，如果默認埠被修改，也是可以的，但是在客戶端做telnet測試時，寫伺服器埠號時必須與伺服器配
置的埠號保持一致。如果隱藏伺服器復選框被勾選，則意味著客戶端無法通過枚舉伺服器來看到這台伺服器，
起到了保護的作用，但不影響連接，但是Tcp/ip協議的默認埠將被隱式修改為2433，在客戶端連接時必須作相
應的改變。
4 如果伺服器端操作系統打過sp2補丁，則要對windows防火牆作一定的配置，要對它開放1433埠，通常在測試
時可以直接關掉windows防火牆（其他的防火牆也關掉最好）。
5 檢查伺服器是否在1433埠偵聽。如果伺服器沒有在tcp連接的1433埠偵聽，則是連接不上的。檢查方法是在
伺服器的dos或命令行下面輸入 netstat -a -n 或者是netstat -an，在結果列表裡看是否有類似 tcp 127.0.0.1
1433 listening 的項。如果沒有，則通常需要給sql server 2000打上至少sp3的補丁。其實在伺服器端啟動查詢
分析器，輸入 select @@version 執行後可以看到版本號，版本號在8.0.2039以下的都需要打補丁。
如果以上都沒問題，這時你再做telnet 伺服器ip 1433 測試，將會看到屏幕一閃之後游標在左上角不停閃動。恭
喜你，你馬上可以開始在企業管理器或查詢分析器連接了。

三 檢查客戶端設置
程序->Microsoft SQL Server-> 客戶端網路使用工具。像在伺服器網路實用工具里一樣，確保客戶端tcp/ip協議
啟用，並且默認埠為1433（或其他埠，與伺服器端保持一致就行）。

四 在企業管理器里或查詢分析器連接測試
企業管理器->右鍵SQlserver組->新建sqlserver注冊->下一步->寫入遠程IP->下一步-> 選Sqlserver登陸->下一
步->寫入登陸名與密碼（sa,password）->下一步->下一步->完成
查詢分析器->文件->連接->寫入遠程IP->寫入登錄名和密碼（sa,password）->確定
通常建議在查詢分析器里做，因為默認情況下，通過企業管理器注冊另外一台SQL Server的超時設置是4秒，而查
詢分析器是15秒。
修改默認連接超時的方法：
企業管理器->工具->選項->在彈出的"SQL Server企業管理器屬性"窗口中，點擊"高級"選項卡->連接設置->在 登
錄超時（秒） 後面的框里輸入一個較大的數字
查詢分析器->工具->選項->連接->在 登錄超時（秒） 後面的框里輸入一個較大的數字
通常就可以連通了，如果提示錯誤，則進入下一步。
五 錯誤產生的原因通常是由於SQL Server使用了"僅 Windows"的身份驗證方式，因此用戶無法使用SQL Server的
登錄帳戶（如 sa ）進行連接。解決方法如下所示：
1 在伺服器端使用企業管理器，並且選擇"使用 Windows 身份驗證"連接上 SQL Server。
2 展開"SQL Server組"，滑鼠右鍵點擊SQL Server伺服器的名稱，選擇"屬性"，再選擇"安全性"選項卡。
3 在"身份驗證"下，選擇"SQL Server和 Windows "。
4 重新啟動SQL Server服務。（在dos或命令行下面net stop mssqlserver停止服務，net start
mssqlserver啟動服務，也是一種快捷的方法）。

註：在連接本地伺服器時，通常使用的是命名管道協議（在伺服器網路實用工具里可以看到啟用的協議有這個）
，默認埠是445，因此在本地能連通是不能說明什麼問題的，連接遠程伺服器是完全不同的協議）。