第一篇：從Google Spanner漫談分布式存儲與數據庫技術

從Google Spanner漫談分布式存儲與數據庫技術

文/曹偉

Spanner 的設計反映了 Google 多年來在分布式存儲系統領域上經驗的積累和沉淀，它采用了 Megastore 的數據模型，Chubby 的數據復制和一致性算法，而在數據的可擴展性上使用了 BigTable 中的技術。新穎之處在于，它使用高精度和可觀測誤差的本地時鐘來判斷分布式系統中事件的先后順序。Spanner 代表了分布式數據庫領域的新趨勢——NewSQL。

Spanner 是 Google 最近公開的新一代分布式數據庫，它既具有 NoSQL 系統的可擴展性，也具有關系數據庫的功能。例如，它支持類似 SQL 的查詢語言、支持表連接、支持事務（包括分布式事務）。Spanner 可以將一份數據復制到全球范圍的多個數據中心，并保證數據的一致性。一套 Spanner 集群可以擴展到上百個數據中心、百萬臺服務器和上T條數據庫記錄的規模。目前，Google 廣告業務的后臺（F1）已從 MySQL 分庫分表方案遷移到了 Spanner 上。

數據模型

傳統的 RDBMS（例如 MySQL）采用關系模型，有豐富的功能，支持 SQL 查詢語句。而 NoSQL 數據庫多是在 key-value 存儲之上增加有限的功能，如列索引、范圍查詢等，但具有良好的可擴展性。Spanner 繼承了 Megastore 的設計，數據模型介于 RDBMS 和 NoSQL 之間，提供樹形、層次化的數據庫 schema，一方面支持類 SQL 的查詢語言，提供表連接等關系數據庫的特性，功能上類似于 RDBMS；另一方面整個數據庫中的所有記錄都存儲在同一個 key-value 大表中，實現上類似于 BigTable，具有 NoSQL 系統的可擴展性。

在 Spanner 中，應用可以在一個數據庫里創建多個表，同時需要指定這些表之間的層次關系。例如，圖 1 中創建的兩個表——用戶表（Users）和相冊表（Albums），并且指定用戶表是相冊表的父節點。父節點和子節點間存在著一對多的關系，用戶表中的一條記錄（一個用戶）對應著相冊表中的多條記錄（多個相冊）。此外，要求子節點的主鍵必須以父節點的主鍵作為前綴。例如，用戶表的主鍵（用戶 ID）就是相冊表主鍵（用戶 ID+ 相冊 ID）的前綴。

圖 1 schema 示例，表之間的層次關系，記錄排序后交錯的存儲

顯然所有表的主鍵都將根節點的主鍵作為前綴，Spanner 將根節點表中的一條記錄，和以其主鍵作為前綴的其他表中的所有記錄的集合稱作一個 Directory。例如，一個用戶的記錄及該用戶所有相冊的記錄組成了一個 Directory。Directory 是 Spanner 中對數據進行分區、復制和遷移的基本單位，應用可以指定一個 Directory 有多少個副本，分別存放在哪些機房中，例如把用戶的 Directory 存放在這個用戶所在地區附近的幾個機房中。

這樣的數據模型具有以下好處。

? 一個 Directory 中所有記錄的主鍵都具有相同前綴。在存儲到底層 key-value 大表時，會被分配到相鄰的位置。如果數據量不是非常大，會位于同一個節點上，這不僅提高了數據訪問的局部性，也保證了在一個 Directory 中發生的事務都是單機的。

? Directory 還實現了從細粒度上對數據進行分區。整個數據庫被劃分為百萬個甚至更多個 Directory，每個 Directory 可以定義自己的復制策略。這種 Directory-based 的數據分區方式比 MySQL 分庫分表時 Table-based 的粒度要細，而比 Yahoo!的 PNUTS 系統中 Row-based 的粒度要粗。

? Directory 提供了高效的表連接運算方式。在一個 Directory 中，多張表上的記錄按主鍵排序，交錯（interleaved）地存儲在一起，因此進行表連接運算時無需排序即可在表間直接進行歸并。

復制和一致性

Spanner 使用 Paxos 協議在多個副本間同步 redo 日志，從而保證數據在多個副本上是一致的。Google 的工程師鐘情于 Paxos 協議，Chubby、Megastore 和 Spanner 等一系列產品都是在 Paxos 協議的基礎上實現一致性的。

Paxos 的基本協議很簡單。協議中有三個角色：Proposer、Acceptor 和 Learner，Learner 和 Proposer 分別是讀者和寫者，Acceptor 相當于存儲節點。整個協議描述的是，當系統中有多個 Proposer 和 Acceptor 時，每次 Proposer 寫一個變量就會啟動一輪決議過程（Paxos instance），如圖 2 所示。決議過程可以保證即使多個 Proposer 同時寫，結果也不會在 Acceptor 節點上不一致。確切地說，一旦某個 Proposer 提交的值被大多數 Acceptor 接受，那么這個值就被選中，在整輪決議的過程中該變量就不會再被修改為其他值。如果另一個 Proposer 要寫入其他值，必須啟動下一輪決議過程，而決議過程之間是串行（serializable）的。

圖 2 Paxos 協議正常執行流程

一輪決議過程分為兩個階段，即 prepare 階段和 accept 階段。

? 第一階段A：Proposer 向所有 Acceptor 節點廣播 prepare 消息，消息中只包含一個序號——N。Proposer 需要保證這個序號在這輪決議過程中是全局唯一的（這很容易做到，假如系統中有兩個 Proposer，那么一個 Proposer 使用1，3，5，7，9，??，另一個 Proposer 則使用0，2，4，6，8，??）。

?

第一階段B：Acceptor 接收到 prepare 消息后，如果N是到目前為止見過的最大序號，就返回一個 promise 消息，承諾不會接受序號小于N的請求；如果已接受過其他 Proposer 提交的值，則會將這個值連同提交這個值的請求的序號一同返回。? 第二階段A：當 Proposer 從大多數 Acceptor 節點收到了 promise 消息后，就可以選擇接下來要向 Acceptor 提交的值了。一般情況下，當然選原本打算寫入的值，但如果從收到的 promise 消息中發現已經有其他值被 Acceptor 接受了，那么為了避免造成數據不一致的風險，這時 Proposer 就必須“大義滅親”，放棄自己打算寫入的值，從其他 Proposer 提交的序號中選擇一個最大的值。接下來 Proposer 向所有的 Acceptor 節點發送 accept 包，其中包含在第一階段中挑選的序號N和剛才選擇的值V。

?

第二階段B：Acceptor 收到 accept 包之后，如果N的大小不違反對其他

Proposer 的承諾，就接受這個請求，記錄下值V和序號N，返回一個 ack 消息。反之，則返回一個 reject 消息。

如果 Proposer 從大多數 Acceptor 節點收到了 ack 消息，說明寫操作成功。而如果在寫操作過程中失敗，Proposer 可以增大序號，重新執行第一階段。

基本的 Paxos 協議可以保證值一旦被選出后就一定不會改變，但不能保證一定會選出值來。換句話說，這個投票算法不一定收斂。有兩個方法可以加速收斂的過程：一個是在出現沖突后通過隨機延遲把機會讓給其他 Proposer，另一個是盡量讓系統中只有一個 Proposer 去提交。在 Chubby 和 Spanner 系統中這兩種方法都用上了，先用隨機延遲的方法通過一輪 Paxos 協議，在多個 Proposer 中選舉出一個 leader 節點。接下來所有的寫操作都通過這個 leader 節點，而 leader 節點一般還是比較“長壽”的，在廣域網環境下平均“任期”可以達到一天以上。而 Megastore 系統中沒有很好地解決這個問題，所有的 Proposer 都可以發起寫操作，這是 Megastore 寫入性能不高的原因之一。

基本的 Paxos 協議還存在性能上的問題，一輪決議過程通常需要進行兩個回合通信，而一次跨機房通信的代價為幾十到一百毫秒不等，因此兩個回合的通信就有點開銷過高了。不過幸運的是，絕大多數情況下，Paxos 協議可以優化到僅需一個回合通信。決議過程的第一階段是不需要指定值的，因此可以把 prepare/promise 的過程捎帶在上一輪決議中完成，或者更進一步，在執行一輪決議的過程中隱式地涵蓋接下來一輪或者幾輪決議的第一階段。這樣，當一輪決議完成之后，其他決議的第一階段也已經完成了。如此看來，只要 leader 不發生更替，Paxos 協議就可以在一個回合內完成。為了支持實際的業務，Paxos 協議還需要支持并發，多輪決議過程可以并發執行，而代價是故障恢復會更加復雜。

因為 leader 節點上有最新的數據，而在其他節點上為了獲取最新的數據來執行 Paxos 協議的第一階段，需要一個回合的通信代價。因此，Chubby 中的讀寫操作，以及 Spanner 中的讀寫事務都僅在 leader 節點上執行。而為了提高讀操作的性能，減輕 leader 節點的負載，Spanner 還提供了只讀事務和本地讀。只讀事務只在 leader 節點上獲取時間戳信息，再用這個時間戳在其他節點上執行讀操作；而本地讀則讀取節點上最新版本的數據。

與 Chubby、Spanner 這種讀寫以 leader 節點為中心的設計相比，Megastore 體現了一定的“去中心化”設計。每個客戶端都可以發起 Paxos 寫操作，而讀操作則盡可能在本地執行。如果客戶端發現本地數據不是最新的，會啟動 catchup 流程更新數據，再執行本地讀操作返回給客戶端。

最后，對比下其他系統中 replication 的實現。在 BigTable 系統中每個 tablet 服務器是沒有副本的，完全依賴底層 GFS 把數據存到多臺機器上。數據的讀寫都通過單個 tablet 服務器，在 tablet 服務器出現故障的時需要 master 服務器將 tablet 指派到其他 tablet 服務器上才能恢復可用。Dynamo 系統則貫徹了“去中心化”的思想，將數據保存在多個副本上，每個副本都可以寫入（update everywhere）。而不同副本同時寫入的數據可能會存在不一致，則需要使用版本向量（version vector）記錄不同的值和時間戳，由應用去解釋或合并不一致的數據。盡管 Dynamo 系統還提供了 NWR 的方式來支持有一致性保證的讀寫操作，但總的來說 Dynamo 為了高可用性犧牲了一致性。ZooKeeper、MongoDB 與 Chubby、Spanner 類似，通過 leader 選舉協議從多個副本中選擇一個 leader，所有寫操作都在經過 leader 節點序列化后，同步到其他副本上。ZooKeeper 則是在寫入大多數節點后返回，而 MongoDB 主要采用異步的主從復制方式。

分布式事務

Spanner 系統中的分布式事務通過兩階段提交協議（2PC）實現。2PC 是一類特殊的一致性協議，假設一個分布式事務涉及了多個數據節點，2PC 可以保證在這些節點上的操作要么全部提交，要么全部失敗，從而保證了整個分布式事務的原子性（ACID 里的A）。協議中包含兩個角色：協調者（coordinator）和參與者（participant/cohort）。協調者是分布式事務的發起者，而參與者是參與了事務的數據節點。在協議最基本的形式中，系統中有一個協調者和多個參與者。

顧名思義，2PC 也包含兩個階段，即投票階段和提交階段（如圖 3 所示）。

圖 3 兩階段提交協議 ? 在第一階段，協調者向所有的參與者發送投票請求，每個參與者決定是否要提交事務。如果打算提交的話需要寫好 redo、undo 等日志，并向協調者回復 yes 或 no。

? 在第二階段，協調者收到所有參與者的回復，如果都是 yes，那么決定提交這個事務，寫好日志后向所有參與者廣播提交事務的通知。反之，則中止事務并且通知所有參與者。參與者收到提交/中止事務的命令后，執行相應操作，如果提交的話還需要寫日志。

協議過程包括兩回合的通信，在協調者和參與者端需要多次寫日志，而且整個過程中所有參與者都占有讀鎖、寫鎖，可見 2PC 開銷不菲。

2PC 最令人詬病之處還不在于性能，而是在有些故障條件下，會造成所有參與者占有讀鎖、寫鎖堵塞在第二階段，需要人工干預才能繼續，存在嚴重的可用性隱患。假設故障發生在第二階段，協調者在做出決定后，通知完一個參與者就宕機了，更糟糕的是被通知的這位參與者在執行完“上級指示”之后也宕機了，這時對其他參與者來說，就必須堵塞在那里等待結果。

Spanner 利用基于 Paxos 協議的復制技術，改善了 2PC 的可用性問題。2PC 協議過程中的協調者和參與者生成的日志都會利用 Paxos 協議復制到所有副本中，這樣無論是協調者或參與者宕機，都會有其他副本代替它們，完成 2PC 過程而不至于堵塞。在 Paxos 協議上實現 2PC 這一思路很巧妙，Paxos 協議保證了大多數節點在線情況下的可用性，而 2PC 保證了分布式協議的一致性。

事件的順序

傳統上，在設計一個分布式系統時，都會假設每個節點的運行速度和時鐘的快慢各不相同的情況，并且在節點之間進行同步的唯一方法就是異步通信。系統中的每個節點都扮演著觀察者的角色，并從其他節點接收事件發生的通知。判斷系統中兩個事件的先后順序主要依靠分析它們的因果關系，包括 Lamport 時鐘、向量時鐘等算法，而這一切都存在通信開銷。

因此，Spanner 提出了一種新的思路，在不進行通信的情況下，利用高精度和可觀測誤差的本地時鐘（TrueTime API）給事件打上時間戳，并且以此比較分布式系統中兩個事件的先后順序。利用這個方法，Spanner 實現了事務之間的外部一致性（external consistency）（如圖 4 所示），也就是說，一個事務結束后另一個事務才開始，Spanner 可以保證第一個事務的時間戳比第二個事務的時間戳要早，從而兩個事務被串行化后也一定能保持正確的順序。

圖 4 事務外部一致性的實現

TrueTime API 是一個提供本地時間的接口，但與 Linux 上 gettimeofday 接口不一樣的是，它除了可以返回一個時間戳t，還會給出一個誤差ε。例如，返回的時間戳是 1 分 30 秒 350 毫秒，而誤差是 5 毫秒，那么真實的時間在 1 分 30 秒 345 毫秒到 355 毫秒之間。真實的系統中ε平均下來是 4 毫秒。

利用 TrueTime API，Spanner 可以保證給出的事務標記的時間戳介于事務開始的真實時間和事務結束的真實時間之間。假如事務開始時 TrueTime API 返回的時間是{t1, ε1}，此時真實時間在 t1-ε1到 t1+ε1之間；事務結束時 TrueTime API 返回的時間是{t2, ε2}，此時真實時間在 t2-ε2到 t2+ε2之間。Spanner 會在 t1+ε1和 t2-ε2之間選擇一個時間點作為事務的時間戳，但這需要保證 t1+ε1小于 t2-ε2，為了保證這點，Spanner 會在事務執行過程中等待，直到 t2-ε2大于 t1+ε1時才提交事務。由此可以推導出，Spanner 中一個事務至少需要2ε的時間（平均 8 毫秒）才能完成。

由此可見，這種新方法雖然避免了通信開銷，卻引入了等待時間。為了保證外部一致性，寫延遲是不可避免的，這也印證了 CAP 定理所揭示的法則，一致性與延遲之間是需要權衡的。

最后介紹一下 TrueTime API 的實現。TrueTime API 的實現大體上類似于網絡時間協議（NTP），但只有兩個層次。第一層次，服務器是擁有高精度計時設備的，每個機房若干臺，大部分機器都裝備了 GPS 接收器，剩下少數機器是為 GPS 系統全部失效的情況而準備的，叫做“末日”服務器，裝備了原子鐘。所有的 Spanner 服務器都屬于第二層，定期向多個第一層的時間服務器獲取時間來校正本地時鐘，先減去通信時間，再去除異常值，最后求交集。

NewSQL

六年前，BigTable 展示了一個簡潔、優美、具有高可擴展性的分布式數據庫系統，引起了 NoSQL 浪潮。然而 Spanner 的設計者們指出了 BigTable 在應用中遇到的一些阻力。

? 缺少類似 SQL 的界面，缺少關系數據庫擁有的豐富的功能。? 只支持單行事務，缺少跨行事務。

?

需要在跨數據中心的多個副本間保證一致性。

這些來自應用開發者的需求催生了 Spanner，一個既擁有 key-value 系統的高可擴展性，也擁有關系數據庫的豐富功能（包括事務、一致性等特性）的系統。這類兼顧可擴展性和關系數據庫功能的產品被稱為“NewSQL”，Spanner 的公開會不會開啟 NewSQL 的時代呢？我們拭目以待。

總結

最后從 CAP 定理的角度來分析下 Spanner。

CAP 定理是指在網絡可能出現分區故障的情況下，一致性和可用性不可得兼。形式化地說就是，P => 非(A與P)，可以更進一步地總結為，一致性和延遲之間必須進行權衡。Paxos 協議在C和A之間選擇了嚴格的一致性，而A則降級為大多數一致性（majority available）。

Spanner 還通過在事務中增加延遲的方法實現了外部一致性，每個事務需要至少兩倍的時鐘誤差才能完成。如果時鐘出現故障造成誤差增長，那么完成事務所需的時間也就隨之增長。在這里，時鐘故障也應當認為是P的一種形式。在發生時鐘故障（P）的情況下，為了保證一致性（C），而必須增加延遲（A），這一點充分印證了 CAP 定理。

從 Spanner 系統中，我們可以學習到一些經驗。

? MegaStore、Spanner 和 F1 系統所選擇的樹形、層次化的數據庫 schema 是很精妙的，它能支持高效的表連接，這既提供了類似關系模型的范式，也提供了一個合適的粒度進行數據分區，具有好的可擴展性，H-Store 也采用了這樣的 schema。

? 跨數據中心的多個副本間保持一致是可行的，Paxos 協議的性能可以優化到一個可接受的范圍。

? 在 Paxos 協議的基礎之上實現的兩階段提交的可用性得到了提高。? 在一個分布式系統中，本地時鐘的作用可以比我們之前想象的大很多。

作者曹偉，淘寶核心系統數據庫組技術專家，從事高性能服務器、IM、P2P、微博等各類型分布式系統、海量存儲產品的開發，關注系統高可用性和一致性及分布式事務領域。

第二篇：Google Megastore分布式存儲技術全揭秘

Google Megastore分布式存儲技術全揭秘

導讀：本文根據Google最新Megastore論文翻譯而來，原作者為Google團隊，團隊人員包括：Jason Baker，Chris Bond，James C.Corbett，JJ Furman，Andrey Khorlin，James Larson，Jean-Michel Léon，Yawei Li，Alexander Lloyd，Vadim Yushprakh。翻譯者為國內知名IT人士。

在上個月舉行的創新數據系統研討會上(CIDR)，Google公開了其Megastore分布式存儲技術的白皮書。

Megastore是谷歌一個內部的存儲系統，它的底層數據存儲依賴Bigtable，也就是基于NoSql實現的，但是和傳統的NoSql不同的是，它實現了類似RDBMS的數據模型(便捷性)，同時提供數據的強一致性解決方案(同一個datacenter，基于MVCC的事務實現)，并且將數據進行細顆粒度的分區(這里的分區是指在同一個datacenter，所有datacenter都有相同的分區數據)，然后將數據更新在機房間進行同步復制(這個保證所有datacenter中的數據一致)。Megastore的數據復制是通過paxos進行同步復制的，也就是如果更新一個數據，所有機房都會進行同步更新，因為使用paxos進行復制，所以不同機房針對同一條數據的更新復制到所有機房的更新順序都是一致的，同步復制保證數據的實時可見性，采用paxos算法則保證了所有機房更新的一致性，所以個人認為megastore的更新可能會比較慢，而所有讀都是實時讀(對于不同機房是一致的)，因為部署有多個機房，并且數據總是最新。

為了達到高可用性，megastore實現了一個同步的，容錯的，適合長距離連接的日志同步器 為了達到高可擴展性，megastore將數據分區成一個個小的數據庫，每一個數據庫都有它們自己的日志，這些日志存儲在NoSql中 Megastore將數據分區為一個Entity Groups的集合，這里的Entity Groups相當于一個按id切分的分庫，這個Entity Groups里面有多個Entity Group(相當于分庫里面的表)，而一個Entity Group有多個Entity(相當于表中的記錄)

在同一個Entity Group中(相當于單庫)的多個Entity的更新事務采用single-phase ACID事務，而跨Entity Group(相當于跨庫)的Entity更新事務采用two-phase ACID事務(2段提交)，但更多使用Megastore提供的高效異步消息實現。需要說明的一點是，這些事務都是在同一個機房的，機房之間的數據交互都是通過數據復制來實現的。

傳統關系型數據庫使用join來滿足用戶的需求，對于Megastore來說，這種模型(也就是完全依賴join的模型)是不合適的。原因包括

1.高負載交互性型應用能夠從可預期的性能提升得到的好處多于使用一種代價高昂的查詢語言所帶來的好處。2.Megastore目標應用是讀遠遠多于寫的，所以更好的方案是將讀操作所需要做的工作轉移到寫操作上面(比如通過具體值代替外鍵以消除join)3.因為megastore底層存儲是采用BigTable，而類似BigTable的key-value存儲對于存取級聯數據是直接的

所以基于以上幾個原因，Megastore設計了一種數據模型和模式語言來提供基于物理地點的細顆粒度控制，級聯布局，以及申明式的不正規數據存儲來幫助消除大部分joins。查詢時只要指定特定表和索引即可。

當然可能有時候不得不使用到join，Megastore提供了一種合并連接算法實現，具體算法這里我還是沒弄清楚，原文是[the user provides multiple queries that return primary keys for the same table in the same order;we then return the intersection of keys for all the provided queries.] 使用Megastore的應用通過并行查詢實現了outer joins。通常先進行一個初始的查詢，然后利用這個查詢結果進行并行索引查詢，這個過程我理解的是，初始查詢查出一條數據，就馬上根據這個結果進行并行查詢，這個時候初始查詢繼續取出下一條數據，再根據這個結果并行查詢(可能前面那個外鍵查詢還在繼續，使用不同的線程)。這種方法在初始查詢數據量較小并且外鍵查詢使用并行方式的情況下，是一種有效的并且具有sql風格的joins。Megastore的數據結構介于傳統的RDBMS和NoSql之間的，前者主要體現在他的schema表示上，而后者體現在具體的數據存儲上(BigTable)。和RDBMS一樣，Megastore的數據模型是定義schema中并且是強類型的。每一個schema有一個表集合，每個表包含一個實體集合(相當于record)，每個實體有一系列的屬性(相當于列屬性)，屬性是命名的，并且指定類型，這些類型包括字符串，各種數字類型，或者google的protocol buffer。這些屬性可以被設置成必需的，可選的，或者可重復的(一個屬性上可以具有多個值)。一個或者多個屬性可以組成一個主鍵。

在上圖中，User和Photo共享了一個公共屬性user_id，IN TABLE User這個標記直接將Photo和User這兩張表組織到了同一個BigTable中，并且鍵的順序(PRIMARY KEY(user_id,photo_id)？是這個還是schema中定義的順序？)保證Photo的實體存儲在對應的User實體鄰接位置上。這個機制可以遞歸的應用，加速任意深度的join查詢速度。這樣，用戶能夠通過操作鍵的順序強行改變數據級聯的布局。其他標簽請參考原文。Megastore支持事務和并發控制。一個事務寫操作會首先寫入對應Entity Group的日志中，然后才會更新具體數據。BigTable具有一項在相同row/column中存儲多個版本帶有不同時間戳的數據。正是因為有這個特性，Megastore實現了多版本并發控制(MVCC，這個包括oracle，innodb都是使用這種方式實現ACID，當然具體方式會有所不同)：當一個事務的多個更新實施時，寫入的值會帶有這個事務的時間戳。讀操作會使用最后一個完全生效事務的時間戳以避免看到不完整的數據.讀寫操作不相互阻塞，并且讀操作在寫事務進行中會被隔離(？)。

Megastore 提供了current，snapshot，和inconsistent讀，current和snapshot級別通常是讀取單個entity group。當開始一個current讀操作時，事務系統會首先確認所有之前提交的寫已經生效了；然后系統從最后一個成功提交的事務時間戳位置讀取數據。對于snapshot讀取，系統拿到己經知道的完整提交的事務時間戳并且從那個位置直接讀取數據，和current讀取不同的是，這個時候可能提交的事務更新數據還沒有完全生效(提交和生效是不同的)。Megastore提供的第三種讀就是inconsistent讀，這種讀無視日志狀態并且直接讀取最后一個值。這種方式的讀對于那些對減少延遲有強烈需求，并且能夠容忍數據過期或者不完整的讀操作是非常有用的。

一個寫事務通常開始于一個current讀操作以便確定下一個可用的日志位置。提交操作將數據變更聚集到日志，并且分配一個比之前任何一個都高的時間戳，并且使用Paxos將這個log entry加入到日志中。這個協議使用了樂觀并發：即使有可能有多個寫操作同時試圖寫同一個日志位置，但只會有1個成功。所有失敗的寫都會觀察到成功的寫操作，然后中止，并且重試它們的操作。咨詢式的鎖定能夠減少爭用所帶來的影響。通過特定的前端服務器分批寫入似乎能夠完全避免競爭(這幾句有些不能理解)[ Advisory locking is available to reduce the effects of contention.Batching writes through session affinity to a particular front-end server can avoid contention altogether.]。完整事務生命周期包括以下步驟：

1.讀：獲取時間戳和最后一個提交事務的日志位置

2.應用邏輯：從BigTable讀取并且聚集寫操作到一個日志Entry 3.提交：使用Paxos將日志Entry加到日志中 4.生效：將數據更新到BigTable的實體和索引中 5.清理：刪除不再需要的數據

寫操作能夠在提交之后的任何點返回，但是最好還是等到最近的副本(replica)生效(再返回)。Megastore提供的消息隊列提供了在不同Entity Group之間的事務消息。它們能被用作跨Entity Group的操作，在一個事務中分批執行多個更新，或者延緩工作(？)。一個在單個Entity Group上的事務能夠原子性地發送或者收到多個信息除了更新它自己的實體。每個消息都有一個發送和接收的Entity Group；如果這兩個Entity Group是不同的，那么傳輸將會是異步的。

消息隊列提供了一種將會影響到多個Entity Group的操作的途徑，舉個例子，日歷應用中，每一個日歷有一個獨立的Entity Group，并且我們現在需要發送一個邀請到多個其他人的日歷中，一個事務能夠原子地發送邀請消息到多個獨立日歷中。每個日歷收到消息都會把邀請加入到它自己的事務中，并且這個事務會更新被邀請人狀態然后刪除這個消息。Megastore大規模使用了這種模式：聲明一個隊列后會自動在每一個Entity Group上創建一個收件箱。Megastore支持使用二段提交進行跨Entity Group的原子更新操作。因為這些事務有比較高的延遲并且增加了競爭的風險，一般不鼓勵使用。

接下來內容具體來介紹下Megastore最核心的同步復制模式：一個低延遲的Paxos實現。Megastore的復制系統向外提供了一個單一的，一致的數據視圖，讀和寫能夠從任何副本(repli ca)開始，并且無論從哪個副本的客戶端開始，都能保證ACID語義。每個Entity Group復制結束標志是將這個Entity Group事務日志同步地復制到一組副本中。寫操作通常需要一個數據中心內部的網絡交互，并且會跑檢查健康狀況的讀操作。current級別的讀操作會有以下保證：

1.一個讀總是能夠看到最后一個被確認的寫。(可見性)2.在一個寫被確認后，所有將來的讀都能夠觀察到這個寫的結果。(持久性，一個寫可能在確認之前就被觀察到)數據庫典型使用Paxos一般是用來做事務日志的復制，日志中每個位置都由一個Paxos實例來負責。新的值將會被寫入到之前最后一個被選中的位置之后。

Megastore在事先Paxos過程中，首先設定了一個需求，就是current reads可能在任何副本中進行，并且不需要任何副本之間的RPC交互。因為寫操作一般會在所有副本上成功，所以允許在任何地方進行本地讀取是現實的。這些本地讀取能夠很好地被利用，所有區域的低延遲，細顆粒度的讀取failover，還有簡單的編程體驗。

Megastore設計實現了一個叫做Coordinator(協調者)的服務，這個服務分布在每個副本的數據中心里面。一個Coordinator服務器跟蹤一個Entity Groups集合，這個集合中的Entity Groups需要具備的條件就是它們的副本已經觀察到了所有的Paxos寫。在這個集合中的Entity Groups，它們的副本能夠進行本地讀取(local read)。

寫操作算法有責任保持Coordinator狀態是保守的，如果一個寫在一個副本上失敗了，那么這次操作就不能認為是提交的，直到這個entity group的key從這個副本的coordinator中去除。(這里不明白)為了達到快速的單次交互的寫操作，Megastore采用了一種Master-Slave方式的優化，如果一次寫成功了，那么會順帶下一次寫的保證(也就是下一次寫就不需要prepare去申請一個log position)，下一次寫的時候，跳過prepare過程，直接進入accept階段。Megastore沒有使用專用的Masters，但是使用Leaders。

Megastore為每一個日志位置運行一個Paxos算法實例。[ The leader for each log position is a distinguished replica chosen alongside the preceding log position's consensus value.] Leader仲裁在0號提議中使用哪一個值。第一個寫入者向Leader提交一個值會贏得一個向所有副本請求接收這個值做為0號提議最終值的機會。所有其他寫入者必需退回到Paxos的第二階段。

因為一個寫入在提交值到其他副本之前必需和Leader交互，所以必需盡量減少寫入者和Leader之間的延遲。Megastore設計了它們自己的選取下一個寫入Leader的規則，以同一地區多數應用提交的寫操作來決定。這個產生了一個簡單但是有效的原則：使用最近的副本。(這里我理解的是哪個位置提交的寫多，那么使用離這個位置最近的副本做為Leader)Megastore的副本中除了有日志有Entity數據和索引數據的副本外，還有兩種角色，其中一種叫做觀察者(Witnesses)，它們只寫日志，并且不會讓日志生效，也沒有數據，但是當副本不足以組成一個quorum的時候，它們就可以加入進來。另外一種叫只讀副本(Read-Only)，它剛剛和觀察者相反，它們只有數據的鏡像，在這些副本上只能讀取到最近過去某一個時間點的一致性數據。如果讀操作能夠容忍這些過期數據，只讀副本能夠在廣闊的地理空間上進行數據傳輸并且不會加劇寫的延遲。

上圖顯示了Megastore的關鍵組件，包括兩個完整的副本和一個觀察者。應用連接到客戶端庫，這個庫實現了Paxos和其他一些算法：選擇一個副本進行讀，延遲副本的追趕，等等。

Each application server has a designated local replica.The client library makes Paxos operations on that replica durable by submitting transactions directly to the local Bigtable.To minimize wide-area roundtrips, the library submits remote Paxos operations to stateless intermediary replication servers communicating with their local Bigtables.客戶端，網絡，或者BigTable失敗可能讓一個寫操作停止在一個中間狀態。復制的服務器會定期掃描未完成的寫入并且通過Paxos提議沒有操作的值來讓寫入完成。

接下來介紹下Megastore的數據結構和算法，每一個副本存有更新和日志Entries的元數據。為了保證一個副本能夠參與到一個寫入的投票中即使是它正從一個之前的宕機中恢復數據，Megastore允許這個副本接收不符合順序的提議。Megastore將日志以獨立的Cells存儲在BigTable中。

當日志的前綴不完整時(這個前綴可能就是一個日志是否真正寫入的標記，分為2段，第一段是在寫入日志之前先寫入的幾個字節，然后寫入日志，第二段是在寫入日志之后寫入的幾個字節，只有這個日志前綴是完整的，這個日志才是有效的)，日志將會留下holes。下圖表示了一個單獨Megastore Entity Group的日志副本典型場景。0-99的日志位置已經被清除了，100的日志位置是部分被清除，因為每個副本都會被通知到其他副本已經不需要這個日志了。101日志位置被所有的副本接受了(accepted)，102日志位置被Y所獲得，103日志位置被A和C副本接受，B副本留下了一個hole，104日志位置因為副本A和B的不一致，復本C的沒有響應而沒有一致結果。

在一個current讀的準備階段(寫之前也一樣)，必需有一個副本要是最新的：所有之前更新必需提交到那個副本的日志并且在該副本上生效。我們叫這個過程為catchup。省略一些截止超時的管理，一個current讀算法步驟如下：

1.本地查詢：查詢本地副本的Coordinator，判定當前副本的Entity Group是最新的 2.查找位置：確定最高的可能已提交的日志位置，然后選擇一個己經將這個日志位置生效的副本

a.(Local read)如果步驟1發現本地副本是最新的，那么從本地副本中讀取最高的被接受(accepted)的日志位置和時間戳。

b.(Majority read)如果本地副本不是最新的(或者步驟1或步驟2a超時)，那么從一個多數派副本中發現最大的日志位置，然后選取一個讀取。我們選取一個最可靠的或者最新的副本，不一定總是是本地副本

3.追趕：當一個副本選中之后，按照下面的步驟追趕到已知的日志位置: a.對于被選中的不知道共識值的副本中的每一個日志位置，從另外一個副本中讀取值。對于任何一個沒有已知已提交的值的日志位置，發起一個沒有操作的寫操作。Paxos將會驅動多數副本在一個值上打成共識-----可能是none-op的寫操作或者是之前提議的寫操作 b.順序地將所有沒有生效的日志位置生效成共識的值，并將副本的狀態變為到分布式共識狀態(應該是Coordinator的狀態更新)如果失敗，在另外一個副本上重試。4.驗證：如果本地副本被選中并且之前沒有最新，發送一個驗證消息到coordinator斷定(entity group,replica)能夠反饋(reflects)所有提交的寫操作。不要等待回應----如果請求失敗，下一個讀操作會重試。

5.查詢數據：從選中的副本中使用日志位置所有的時間戳讀取數據。如果選中的副本不可用，選取另外一個副本重新開始執行追趕，然后從它那里讀取。一個大的讀取結果有可能從多個副本中透明地讀取并且組裝返回

注意在實際使用中 1和2a通常是并行執行的。

在完整的讀操作算法執行后，Megastore發現了下一個沒有使用的日志位置，最后一個寫操作的時間戳，還有下一個leader副本。在提交時刻，所有更新的狀態都變為打包的(packaged)和提議(proposed)，并且包含一個時間戳和下一個leader 候選人，做為下一個日志位置的共識值。如果這個值贏得了分布式共識，那么這個值將會在所有完整的副本中生效。否則整個事務將會終止并且必需重新從讀階段開始。

就像上面所描述的，Coordinators跟蹤Entity Groups在它們的副本中是否最新。如果一個寫操作沒有被一個副本接受，我們必需將這個Entity Group的鍵從這個副本的Coordinator中移除。這個步驟叫做invalidation(失效)。在一個寫操作被認為提交的并且準備生效，所有副本必需已經接受或者讓這個Entity Group在它們coordinator上失效。寫算法的步驟如下：

1.接受Leader：請求Leader接受值做為0號提議的值。如果成功。跳到第三步

2.準備：在所有副本上執行Paxos Prepare階段，使用一個關于當前log位置更高的提議號。將值替換成擁有最高提議號的那個值。[Replace the value being written withthe highest-numbered proposal discovered, if any] 3.接受：請求余下的副本接受這個值。如果多數副本失敗，轉到第二步。4.失效：將沒有接受值的副本coordinator失效掉。錯誤處理將在接下來描述

5.生效：將更新在盡可能多的副本上生效。如果選擇的值不同于原始提議的，返回沖突錯誤[？]

Coordinator進程在每一個數據中心運行并且只保持其本地副本的狀態。在上述的寫入算法中，每一個完整的副本必需接受或者讓其coordinator失效，所以這個可能會出現任何單個副本失效就會引起不可用。在實際使用中這個不是一個尋常的問題。Coordinator是一個簡單的進程，沒有其他額外的依賴并且沒有持久存儲，所以它表現得比一個BigTable服務器更高的穩定性。然而，網絡和主機失敗仍然能夠讓coordinator不可用。

Megastore使用了Chubby鎖服務：Coordinators在啟動的時候從遠程數據中心獲取指定的Chubby locks。為了處理請求，一個Coordinator必需持有其多數locks。一旦因為宕機或者網絡問題導致它丟失了大部分鎖，它就會恢復到一個默認保守狀態----認為所有在它所能看見的Entity Groups都是失效的。隨后(該Coordinator對應的)副本中的讀操作必需從多數其他副本中得到日志位置直到Coordinator重新獲取到鎖并且Coordinator的Entries重新驗證的。

寫入者通過測試一個Coordinator是否丟失了它的鎖從而讓其在Coordinator不可用過程中得到保護：在這個場景中，一個寫入者知道在恢復之前Coordinator會認為自己是失效的。在一個數據中心活著的Coordinator突然不可用時，這個算法需要面對一個短暫(幾十秒)的寫停頓風險---所有的寫入者必需等待Coordinator的Chubby locks過期(相當于等待一個master failover后重新啟動)，不同于master failover，寫入和讀取都能夠在coordinator狀態重建前繼續平滑進行。除了可用性問題，對于Coordinator的讀寫協議必需滿足一系列的競爭條件。失效的信息總是安全的，但是生效的信息必需小心處理。在coordinator中較早的寫操作生效和較晚的寫操作失效之間的競爭通過帶有日志位置而被保護起來。標有較高位置的失效操作總是勝過標有較低位置的生效操作。一個在位置n的失效操作和一個在位置m

總體來說，使用Coordinator從而能夠在任何數據中心進行快速的本地讀取對于可用性的影響并不是完全沒有的。但是實際上，以下因素能夠減輕使用Coordinator所帶來的問題。1.Coordinators是比任何的BigTable 服務器更加簡單進程，機會沒有依賴，所以可用性更高。

2.Coordinators簡單，均勻的工作負載讓它們能夠低成本地進行預防措施。3.Coordinators輕量的網絡傳輸允許使用高可用連接進行服務質量監控。

4.管理員能夠在維護期或者非安全期集中地讓一批Coordinators失效。對于默寫信號的監測是自動的。

5.一個Chubby qunrum能夠監測到大多數網絡問題和節點不可用。總結

文章總體介紹了下google megastore的實現思路，其主要解決的問題就是如何在復雜的環境下(網絡問題,節點失效等等)保證數據存取服務的可用性。對于多機房，多節點，以及ACID事務支持，實時非實時讀取，錯誤處理等等關鍵問題上給出了具體方案。

第三篇：分布式OA系統的數據庫同步復制技術

分布式OA系統的數據庫同步復制技術

一、背景概述

隨著政府上網、電子政務的不斷普及和深入，IBM公司的Lotus Domino系統在國內得到廣泛的應用。其中不乏大型的、跨地域的企事業單位或集團公司應用案例。這些案例一般采用分布式系統結構，即分布在全國各地的分支機構分別設有獨立的數據庫服務器，各地數據庫服務器采用數據庫同步復制的方式更新本地數據庫復本內容。從而使得各地終端用戶及時、快捷、可靠地訪問到最新公告、新聞等。

本文結合呼和浩特鐵路局客運公司辦公自動化系統案例討論基于IBM公司的Lotus Domino技術構建的分布式OA系統中數據庫之間的同步復制技術。

二、幾個概念

IBM公司的Lotus產品包含Lotus Domino Server，Lotus Notes，Lotus Domino Administrator和Lotus Domino Designer。Lotus Domino Server為后臺數據庫平臺，Lotus Notes為客戶端，Lotus Domino Administrator為系統管理平臺，Lotus Domino Designer設計開發工具。先介紹幾個Domino中和同步復制有關的概念。

1、復制

Notes允許在多個服務器或工作站上保存數據庫的多個拷貝，這些拷貝稱做“復本”。它們使各個地方的不同網絡上的用戶共享相同的信息。復本與文件的拷貝不同之處在于在復制時源文件與其復本具有相同的復本標識符。

復制是在復本之間共享更改信息的過程。復制時，Notes通過把更改信息從一個復本拷貝到另一個復本來更新復本。最終，Notes 使所有復本保持一致。可以選擇在復本拷貝之間進行復制，這時兩個復本都發送并接收更新信息，或者選擇僅從一個復本復制到另一個復本。

也可以定期安排復制，或者根據需要手動進行復制。復制可以在兩臺服務器之間或者在服務器和工作站之間進行。如果設定為定期進行完整復制，那么 Notes會根據時間使所有復本保持同步。

2、復本標識符

復本與源文件或數據庫有相同的復本標識符。這是數據庫的復本與拷貝的區別所在，因為有共同的標識符才能使復本與源數據庫之間可以復制更改信息。如果數據庫的兩個拷貝具有不同的復本標識符，則不能在它們之間進行復制。

3、復制沖突和保存沖突

在復制之間，如果有兩個或多個用戶對相同文檔的不同復本進行了編輯，就會導致復制沖突。而保存沖突則是在兩個或多個用戶同時編輯服務器上同一個數據庫的同一個文檔時發生。當發生復制沖突或保存沖突時，Notes 將在視圖頁面左邊把發生沖突的文檔標注出來。

Notes對復制沖突的處理是這樣的，在兩個或多個用戶編輯并保存同一個文檔之后，下次進行復制時，Notes 將編輯和保存最頻繁的文檔指定為主文檔，而將其他文檔顯示為主文檔的答復文檔，并在視圖頁面左邊用一個菱形符號標注出來。如果用戶在一個復本中編輯并保存了某文檔，然后另一個用戶將該文檔刪除，則認為該文檔是被刪除的。然而，如果文檔被編輯和保存了多次，或者在該文檔被刪除之后又被另一個用戶編輯和保存過，則把編輯過的文檔作為主文檔。

Note對保存沖突的處理如下，當多個用戶同時打開相同的文檔進行編輯時，Notes指定最先保存的文檔為主文檔。當另一個用戶試圖保存同一文檔時，Notes 就會提示該用戶把它作為“保存沖突”文檔來保存。如果用戶這樣做了，那么 Notes 將它顯示為主文檔的答復文檔，并在視圖頁面左邊用一個菱形符號標注出來。

根據筆者的經驗，在實際開發過程中，我們應該通過設計控制保存沖突，避免文檔產生“保存沖突”的答復文檔。對于復制沖突可以設置數據庫合并復制沖突，這樣如果產生增量改動，服務器在復制過程中會自動合并沖突。需要說明的是，Notes在進行復制時，并不是傳統意義上的完全拷貝，而是一系列的規則進行增量的合并。

4、復制類型

Domino中支持四種不同的復制方式

拉入推出：是一個雙向過程。此過程進行時，呼叫服務器從響應服務器拉入更新，然后向響應服務器推出自己的更新。使用“拉入推出”時，呼叫服務器上的 Replicator 任務執行所有的工作。拉入推出是系統缺省的復制方式。

分別拉入：是兩個服務器交換更新的雙向過程。使用“分別拉入”時，兩個復制器（一個在呼叫服務器上，另一個在響應服務器上）共同進行復制工作。

只推出：是呼叫服務器向響應服務器推出更新的單向過程。單向復制總是比雙向復制耗時少。只拉入：是呼叫服務器從響應服務器拉入更新的單向過程。單向復制總是比雙向復制耗時少。

三、案例

筆者曾經參與呼和浩特鐵路局客運公司辦公自動化系統的設計、開發和實施工作。呼和浩特鐵路局客運公司包括三個信息中心，分別在呼和浩特市、包頭市和東河區三個地方，三地之間通過64K的DDN專線連接。因為帶寬的限制，用戶遠程訪問速度成為本系統的瓶頸，經過再三論證，我們決定構建分布式數據庫存儲架構，采用后臺數據庫實時同步復制技術使三個異地服務器內容一致，將遠程訪問轉化為本地訪問，從而提高終端用戶訪問速度。

詳細步驟如下。

1、安裝服務器

在三地信息中心分別安裝Domino服務器，服務器的詳細配置并不復雜，讀者可以參閱相關資料，一般情況下按照安裝配置向導四步就可以快捷配置完畢。注意三臺Domino服務器不要同名，其簡單拓撲結構如下：

圖中呼市處于相對中心的位置，所以呼市和包頭之間，呼市和東河之間分別建立了互推復制機制，為了降低網絡負擔和流通環節，沒有建立包頭和東河之間的復制，各地直接通過與呼市同步來保持三地數據的一致。一般而言，如果各分支機構處于平等位置，互相之間的數據流量相當，也可以兩兩之間建立復制機制。

2、建立服務器之間的連接

對于兩個服務器之間進行的復制，應創建一個“連接”文檔來指定進行信息交換的方式和時間?！斑B接”文檔存儲在“Domino 目錄”中。一次僅使用一個“連接”文檔來處理每對服務器之間的所有復制。創建不必要的“連接”文檔會增加網絡傳輸量和阻塞。

缺省情況下，郵件路由和復制都已被啟用，但是可以更改此設置并使用單獨的“連接”文檔來安排每項任務。這樣，就可以分別控制復制和郵件路由的特定時間、時間范圍或重復間隔，并根據需要增加或減小這些設置。

怎么保證服務器之間的連接能順利的連通？實際上對于物理連接形式Domino并不關心，也就是說物理上無論通過什么連接方式，專線、光纖、X.25、電話撥號等，只要TCP/IP通，簡單說只要能Ping通，就能夠保證服務器之間順利連接。

下面給出了建立服務器之間連接的操作步驟和主要參數的設置說明：

A）在 Domino Administrator 中單擊“配置”附簽。

B）在“使用目錄”域中選擇連接服務器的“Domino 目錄”。

C）單擊“服務器”，然后單擊“連接”。

D）單擊“添加連接”。

F）關鍵域配置描述：

域輸入

源服務器連接服務器的名稱

使用以下端口連接服務器或源服務器使用的網絡端口（或協議）名稱

使用優先級選擇一個：“一般”（缺?。暗汀?/p>

目標服務器響應服務器的名稱

可選網絡地址與所選協議相適應的目標服務器的地址。對于 TCP/IP，應使用完全有效的網絡域名稱（首選）或 IP 地址（例如：HR-E.Acme.com 或者 192.22.256.36）。

對 TCP/IP 或其他需要特定網絡地址的協議，建議填寫此域。

復制類型缺省情況下，Domino 的復制方向為“拉入推出”。但根據實際情況，為了平衡服務器之間的負載，充分發揮每個服務器的性能，我們可以設定雙方互推或者互拉，本例中我們采用服務器雙方互推的方式，即每個服務器上的連接復制類型都是由源服務器向目標服務器推出。

復制文件/目錄如果為空，則服務器將DATA目錄下的所有存在復本的數據庫全部進行復制，否則填寫哪個庫系統就復制哪個庫。

安排在安排中可以設置連接時間、重復間隔、每周復制日期等參數?？筛鶕嶋H情況設定，本例設置為每日8：00到晚上10：00連接，連接期間每一小時進行同步復制或服務器依據增量自動復制，非連接時間服務器處理其他性能調優動作，如更新數據庫索引等。

H）保存文檔。

3、建立數據庫復本

連接建立成功以后，保證服務器之間可以進行通訊了，下一步就是對要進行同步的數據庫建立復本，當建立了復本以后，通過連接設定就能保證異地各個復本之間的數據完全一致。

這里需要說明的是，我們在第一臺服務器上建立了一套數據庫系統，對于需要同步復制的所有數據庫，在其他服務器上只需要產生他們的復本，而不能再在每臺服務器上分別創建相同的數據庫。在本例中我們在呼市客運公司信息中心安裝配置好第一臺服務器后，在包頭信息中心和東河信息中心的Domino服務器上則通過呼市信息中心服務器建立各自本地所有需要的數據庫復本。

如果要在本地Domino服務器上創建源Domino服務器的復本數據庫，需要本地服務器的系統管理員具有對源服務器訪問和創建復本的權限，因為Domino對權限控制很嚴格，尤其是多域用戶之間的訪問，其目的就是為了充分保證系統的安全性。那么怎樣才能具有這樣的創建復本的權限呢？需要具有兩個基本的存取權限就可以在本服務器上創建源服務器的數據庫復本，一是源服務器配置中允許本地服務器的系統管理員訪問，二是允許本地服務器的系統管理員創建數據庫復本，這兩個權限由源數據庫的系統管理員設置給目標數據庫的系統管理員。結合本例，需要在包頭信息中心的服務器上建立呼市信息中心的數據庫復本，則首先在呼市信息中心的服務器上配置“當前服務器”文檔。

A）在 Domino Administrator 中單擊“當前服務器”文檔。

B）單擊“編輯服務器”

C）選擇“安全”標簽頁，填寫以下兩項：

域輸入

訪問服務器本例為包頭信息中心系統服務器名稱及管理員的用戶名稱

創建數據庫復本同樣是包頭信息中心系統管理員的用戶名稱

D保存后退出。

接下來就可以在包頭信息中心的服務器上創建源數據庫的復本了，這步動作比較簡單，選擇源數據庫，從菜單中執行創建復本功能即可，這里不在詳細描述。

同樣的處理在東河的服務器上如法炮制一遍，則所有數據庫復本成功建立完畢。

4、復制測試

完成以上三步，配置就全部完成，接下來就要測試一下配置是否完全成功以及配置是否生效。我們測試主要包括兩個內容：一是測試連接是否成功，能否進行復制動作。二是測試設置的復制安排是否按照預定生效。

A）進行第一項測試的辦法是在Domino的控制臺上，使用Domino的系統命令，進行數據庫的推、拉測試，檢查復制是否能成功進行，命令格式如下：

拉入復制

語法：Pull servername [databasename]

描述：強制從指定服務器到本地服務器進行單向復制。通過在命令行中包括單個數據庫名稱，將其從特定服務器單向復制到本地服務器。發起復制的服務器從指定的服務器接受數據，但不能申請將自己的數據復制到其他服務器上。該命令重設在“Domino 目錄”中預定的任何復制，而強制一臺服務器與發起復制的服務器立即進行復制。如果可能，請輸入服務器完整的層次結構名稱。

推出復制

語法：Push servername [databasename]

描述：強制進行從本地服務器到指定服務器的單向復制。也可以通過在命令行中包括要復制的單個數據庫名稱，來將其從本地服務器單向復制到特定服務器。發起復制的服務器將數據發送到指定的服務器，但不申請獲得數據。該命令可以重設在“Domino 目錄”中預定的任何復制，而強制一臺服務器立即與發起復制的服務器進行復制。如果可能的話，請指定服務器完整的層次結構名稱。

B）第二項測試通過將連接文檔的安排時間設置為兩分鐘進行一次，同時觀察Domino的系統控制臺，查看服務器的動作，以確保安排設定生效。正確的結果是從控制臺上能看到系統報告復制過程。

按照以上實例說明進行，沒有任何問題。

四、結束語

我們同樣可以在客戶端利用復制技術，例如在本地客戶端建立郵件文件數據庫的復本，以便與我們在外出或者脫機狀態下還可以訪問郵件文件。本地復本要求沒有在服務器之間進行復制的要求那么高，本地復本的作用體現在通過本地復本，可以在沒有通過網絡連接服務器時對數據庫進行操作。當設置 Notes 為遠程工作站時，就可以通過調制解調器呼叫服務器并在本地復本和服務器數據庫之間交換更新信息。

第四篇：網絡存儲技術優缺點與發展趨勢

網絡存儲技術優缺點與發展趨勢

隨著不斷加速的信息需求使得存儲容量飛速增長，存儲系統網絡平臺已經成為一個核心平臺，同時各種應用對平臺的要求也越來越高，不僅在存儲容量上，還包括數據訪問性能、數據傳輸性能、數據管理能力、存儲擴展能力等等多個方面。可以說，存儲網絡平臺的綜合性能的優劣，將直接影響到整個系統的正常運行。因此，發展一種具有成本效益的和可管理的先進存儲方式就成為必然。下面就當前的存儲技術及發展趨勢進行分析和探討。信息量的飛速發展使得存儲容量也飛速增長，發展一種具有成本效益和可管理和先進存儲方式就成為必然。本文就幾種傳統的網絡存儲框架進行探討，之后介紹了新的存儲技術，并分析了網絡存儲體系結構的發展趨勢。

隨著不斷加速的信息需求使得存儲容量飛速增長，存儲系統網絡平臺已經成為一個核心平臺，同時各種應用對平臺的要求也越來越高，不僅在存儲容量上，還包括數據訪問性能、數據傳輸性能、數據管理能力、存儲擴展能力等等多個方面?？梢哉f，存儲網絡平臺的綜合性能的優劣，將直接影響到整個系統的正常運行。因此，發展一種具有成本效益的和可管理的先進存儲方式就成為必然。下面就當前的存儲技術及發展趨勢進行分析和探討。

一、網絡存儲技術概述

所謂網絡存儲技術(Network Storage Technologies)，就是以互聯網為載體實現數據的傳輸與存儲，數據可以在遠程的專用存儲設備上，也可以是通過服務器來進行存儲。網絡存儲技術是基于數據存儲的一種通用網絡術語。實際上，我們可以將存儲技術分為三個階段：①總線存儲階段；②存儲網絡階段；③虛擬存儲階段。以存儲網絡為中心的存儲是對數據存儲新需求的回答。它采用面向網絡的存儲體系結構，使數據處理和數據存儲分離；網絡存儲體系結構包括了網絡和I/O的精華，將I/O能力擴展到網絡上，特別是靈活的網絡尋址能力，遠距離數據傳輸能力，I/O高效的原性能；通過網絡連接服務器和存儲資源，消除了不同存儲設備和服務器之間的連接障礙；提高了數據的共享性、可用性和可擴展性、管理性。

二、幾種傳統的網絡存儲架構

網絡存儲架構大致分為三種：直連附加存儲、網絡附加存儲、存儲區域網絡。這幾種網絡存儲方式特點各異，應用在不同的領域。下面我們來做簡單的介紹并分析其中區別。

2.1 直連附加存儲(DAS：Direct Attached Storage)

直接網絡存儲(DAS)是指將存儲設備通過SCSI接口或光纖通道直接連接到服務器上的方式。這種連接方式主要應用于單機或兩臺主機的集群環境中，主要優點是存儲容量擴展的實施簡單，投入成本少，見效快。DAS主要應用于：

①服務器在地理分布上很分散，SAN或NAS在它們之間進行互連非常困難時；

②存儲系統必須被直接連接到應用服務器時；

③包括許多數據庫應用和應用服務器在內的應用時。

缺點：

①不能提供跨平臺的文件共享功能；

②用戶要備份數據和存儲數據，都要占用服務器CPU的時間，降低了服務器的管理效能；

③由于各個主機之間的數據獨立，數據需要逐一備份，使數據備份工作較為困難；

④隨著服務器的增多，數據管理會越來越復雜；增加存儲設備，擴展存儲容量，需要對服務器進行重新配置，這樣做容易中斷單位的業務連接性，造成數據丟失。

2.2 網絡附加存儲(NAS：Network Attached Storage)

網絡附加存儲(NAS)是一種將分布、獨立的數據整合為大型、集中化管理的數據中心，以便于對不同主機和應用服務器進行訪問的技術。NAS中服務器與存儲之間的通信使用TCP/IP協議，數據處理是“文件級”。NAS可附加大容量的存儲內嵌操作系統，專門針對文件系統進行重新設計和優化以提供高效率的文件服務，降低了存儲設備的成本，數據傳輸速率也很高。

NAS應用于電子出版、CAD、圖像、教育、銀行、政府、法律環境等那些對數據量有較大需求的應用中。多媒體、Internet下載以及在線數據的增長，特別是那些要求存儲器能隨著公司文件大小規模而增長的企業、小型公司、大型組織的部門網絡，更需要這樣一個簡單的可擴展的方案。

缺點：

①NAS采用File I/O方式，因此當客戶端數目或來自客戶端的請求較多時，NAS服務器仍將成為系統的瓶頸；

②進行數據備份時需要占用LAN的帶寬，造成資源浪費；

③NAS只能對單個存儲(單個NAS內部)設備中的磁盤進行資源整合，目前還無法跨越不同的NAS設備，只能進行單獨管理，不適合密集型大規模的數據傳輸。

2.3 存儲區域網絡(SAN：Storage Area Network)

SAN(Storage Area Network，存儲區域網)，通常SAN由RAID陣列連接光纖通道(Fibre Channel)組成，SAN和服務器以及客戶機的數據通信通過SCSI命令而非TCP/IP，數據處理是“塊級”。

應用：

①數據共享由于存儲設備的中心化，大量的文件服務器可以低成本的存取和共享信息，同時也不會使系統性能有明顯下降；

②存儲共享兩個或多個服務器可以共享一個存儲單元，這個存儲單元在物理上可以被分成多個部分，而每個部分又連接在特定的服務器上；

③數據備份通過使用SAN，這些操作可以獨立于原來的網絡，從而能夠提高操作的性能；

④災難恢復傳統方法，當災難發生時，使用磁帶實現數據恢復。通過使用SAN，可采用多種手段實現數據的自動備份，而且這種備份是熱備份形式，也就是說，一旦數據出錯，立即可以獲得該數據的鏡像內容。

三、新的網絡存儲技術IP—SAN

網絡存儲的發展產生了一種新技術IP—SANt。IP—SAN是以IP為基礎的SAN存儲方案，是IP存儲技術應用的第三階段，是完全的端到端的、基于IP的全球SAN存儲。它充分利用了IP網絡的技術成熟、性能穩定、傳輸距離遠、安裝實施簡單、后期維護量少的特點，可為用戶提供一個運行穩定、實施簡單方便、價格低廉的大容量存儲系統，是一種可共同使用SAN與NAS，并遵循各項標準的純軟件解決方案。IP—SAN可讓用戶同時使用GigabitEtherne SCSI與Fibre Channel，建立以IP為基礎的網絡存儲基本架構，由于IP在局域網和廣域網上的應用以及良好的技術支持，在IP網絡中也可實現遠距離的塊級存儲，以IP協議替代光纖通道協議，IP協議用于網絡中實現用戶和服務器連接，隨著用于執行1P協議的計算機的速度的提高及G比特的以太網的出現，基于IP協議的存儲網絡實現方案成為SAN的更佳選擇。

四、虛擬存儲

所謂虛擬存儲，就是把內存與外存有機的結合起來使用，從而得到一個容量很大的“內存”。以存儲網絡為中心的存儲解決不了全部的數據存儲問題，如存儲資源共享、數據共享、數據融合等。不少先進存儲系統的倡導者都提出，存儲作為一種資源，應該像我們日常生活中的自來水和電力一樣，隨時可以方便的存取和使用，這就是存儲公用設施模型，也是網絡存儲的發展目標。實現存儲公用設施模型的關鍵就是在網絡存儲基礎上實現統一虛擬存儲系統。目前存儲技術還處于存儲網絡階段，虛擬存儲才剛剛起步。

五、云存儲

云存儲是在云計算(Cloud computing)概念上延伸和發展出來的一個新的概念。云計算是是分布式處理(Distributed Computing)、并行處理(Parallel Computing)和網格計算(Grid Computing)的發展，是透過網絡將龐大的計算處理程序自動分拆成無數個較小的子程序，再交由多部服務器所組成的龐大系統經計算分析之后將處理結果回傳給用戶。

云存儲的概念與云計算類似，它是指通過集群應用、網格技術或分布式文件系統等功能，將網絡中大量各種不同類型的存儲設備通過應用軟件集合起來協同工作，共同對外提供數據存儲和業務訪問功能的一個系統。云存儲的核心是應用軟件與存儲設備相結合，通過應用軟件來實現存儲設備向存儲服務的轉變。

云存儲對使用者來講，不是指某一個具體的設備，而是指一個由許許多多個存儲設備和服務器所構成的集合體。用戶使用云存儲，并不是使用某一個存儲設備，而是使用整個云存儲系統帶來的一種數據訪問服務。所以嚴格來講，云存儲不是存儲，而是一種服務。

六、結束語

數據的重要性越來越得到人們的廣泛認同，未來網絡的核心將是數據，網絡化存儲正是數據存儲的一個發展方向。目前網絡存儲技術沿著三個主要的方向發展：NAS、SAN、IP—SAN。而SAN和NAS的融合將更有利于數據的存儲和備份，因此，SAN和NAS的融合、統一虛擬存儲技術是未來網絡存儲技術發展的兩個趨勢。

第五篇：數據庫技術與應用課程設計

? 數據庫技術與應用課程設計

一、課程設計的教學目的

1、使學生掌握數據庫的基本概念，結合實際的操作和設計，鞏固課堂教學內容；

2、使學生掌握數據庫系統的基本概念、原理和技術，將理論與實際相結合，應用現有的數據建模工具和數據庫管理系統軟件，規范、科學地完成一個小型數據庫的設計與實現

3、把理論課與實驗課所學內容做一綜合，并在此基礎上強化學生的實踐意識、提高其實際動手能力。

一、課程設計的任務：

使用現行教流行的開發工具和SQL Server進行數據庫應用的開發，主要完成：

1、創建所用的數據庫，創建所需要的表并設置好整性約束。

2、開發出有相當完善功能并有一定規模的數據庫應用系統，系統中要能實現對數據的插入、刪除、修改、簡單查詢、復雜查詢、數據的統計等。?

三、數據庫課程設計內容及要求

1、設計內容：

? 選題：按自由組合原則，以1-2人一組，每一組從所給題目中任選一個合作完成，并且一個題目只能由一個組選作。

? 系統的開發與實現：對所選課題進行調查研究，完成系統的功能分析、結構設計、數據庫的概念要設計和邏輯結構設計、數據庫的物理實現、用戶界面設計等，最后采用程序開發工具（C#、Java、VC、VB、Delphi、ASP等）完成系統開發。

2、設計要求

（1）采取課內上機和業余上機相結合的方式進行，合理安排設計進度（可按以下建議的進度進行），在規定時間內完成系統的開發和設計報告的編寫。

（2）提交比較詳細的課程設計報告和設計作品。

A、課程設計報告至少2000字以上（原代碼除外），報告所包含的內容及格式見《數據庫原理——課程設計指導書》

B、所開的數據庫應用系統應具有可運行、功能較完整、界面較美觀、操作較方便等特點。

C、每位同學至少完成所選課題設計工作量的50% ?

四、設計方法與設計過程

1、設計方法 1）學習研究課程設計指導書，確定設計題目

2）確定開發目標及初步方案；選擇、準備及試用開發開發平臺。

3）學習與搜集素材，借閱、購置必要的書籍與材料：根據自己承擔的任務利用各種途徑（圖書館、因特網、書店、同學親友等）進行針對性的學習并收集相關素材，包括精選、購置必要的書籍。

2、設計步驟：

（1）需求分析：根據設計任務書的要求，查閱資料，對系統進行功能分析和數據分析。

（2）數據庫概念結構設計：設計系統的E-R模型，描述實體的屬性和實體之間的聯系，消除不必要的冗余。

（3）數據庫邏輯結構設計：實現E-R圖向關系模型的轉換，優化數據模型。（4）數據庫的物理實現：創建數據庫、表、視圖等，并設計表的完整性約束。（4）應用程序開發 ：創建新的工程——連接數據庫——編寫程序代碼 ?

五、SQLSERVER數據庫課程設計時間 SQLSERVER數據庫課程設計時間為一周，具體安排如下： ?

六、課程設計交付成果說明(1)個人報告： 每個學生提交個人課程設計報告(A4打印稿，原代碼除外至少2000字以上，不少于20頁)。

（2）軟件與電子文檔：把完成的所有文檔（設計文檔、設計報告及程序）一并交由指導老師處。

? 注：文檔目錄按照如下統一命名規則建立，“課題名/個人子目錄名”，比如“圖書管理系統/張三/張三_課程設計報告”。? 考核方式與成績評定標準

? 考核方式：考察平時表現，注重設計結果演示和實習報告的書寫 ? 評定內容：設計結果和設計報告 ? 教材及主要參考資料

[1]張莉 《SQL SEVER數據庫原理及應用 》

[2]薩師煊 王珊著.《數據庫系統概論》第三版.高等教育出版社

[3] 施伯樂 丁寶康 汪衛.《數據庫系統教程》 高等教育出版社2003年第2版

[4]莊成三等.《數據庫系統原理及其應用》.電子工業出版社 ? 設計報告按照以下提綱書寫 1)摘要。

2)需求分析。

3)數據庫概念結構設計。

4)數據庫邏輯結構設計。

5)數據流圖及程序結構框圖。

6)程序原代碼及其說明。

7)總結。

? 課題一：學生不及格學分管理系統開發（1人）

（1）基本信息管理：能夠向數據庫中添加、刪除、修改不及格學生的科目、學分及成績等記錄。

（2）數據查詢：能夠按照查詢條件（學期、學生姓名、班級、不及格科目）查詢瀏覽查詢結果。

（3）數據計算及統計：計算每個學生不及格科目，累計學分并進行降序排列。? 提供數據：學分累計統計表

? 課題二：圖書出版管理系統開發（1-2人）

(1)所出版圖書的信息管理：數據錄入、修改和刪除功能；

(2)所出版圖書的查詢與統計：可以按各種分類方式（如圖書的出版信息、出售信息等）對出版圖書信息進行查詢與統計(3)系統維護：如數據的備份、用戶的管理等。? 課題三：產品庫存管理系統開發（１-2人）

1、用戶信息管理：至少三類以上的用戶，不同的用戶對產品的錄入、修改和刪除具有不同的權利。

2、產品信息管理：錄入、修改和刪除產品的基本信息，要求：對產品名稱是否為空進行檢驗；部份用戶可以修改與刪除產品信息；修改時，要求先根據查詢列出滿足條件的產品信息，然后進行修改。刪除時，要先確認再進行刪除。

3、倉庫信息管理：倉庫基本信息的錄入、修改和刪除。

4、產品庫存管理：產生存儲表，對每種產品的庫存信息進行管理，入庫時，庫存增加、出庫時庫存減少。

5、信息查詢與統計：對產品的基本信息及庫存信息進行單條件與組合條件的查詢與統計。

? 課題四：職工工資管理系統開發（１－2人）某單位員工分為管理員、財務員、技術員和銷售員等。該單位下設經理室、財務科、技術科和銷售科4個科室。工資由基本工資、福利補貼和獎勵工資構成，失業保險和住房公積金在工資中扣除。每個員工的基本資料有姓名、性別、年齡、單位和職業（如經理、工程師等）。工資按月發放，1）職工的基本信息管理：錄入、修改與刪除職工信息。2）職工的基本工資管理：錄入、修改與刪除職工工資信息

3）職工的工資計算：計算每個人的實際發放工資。實際發放的工資金額為工資減去扣除。4）工資的查詢：按職工所在的部門、職工名及職工編號等條件查詢每個職工的工資 5）工資的統計：按科室、職業分類統計人數和工資金額。? 課題五：**市地下水常規監測 信息管理系統開發（1-2人）

（1）基本信息管理：能夠向數據庫中添加、刪除、修改地下水常規監測數據。（2）數據查詢：能夠按照條件（監測點、監測因子、監測時間）進行查詢；能夠選擇監測因子查詢所有該因子超標的監測點，指定一個監測點判斷該監測點所有常規監測因子的狀態（是否超標）

（3）數據統計：能夠按照時間段等條件對監測數據進行統計。? 課題六：商品銷售管理系統開發（１－2人）(1)用戶管理：用戶的基本信息及權限的錄入、修改和刪除管理

(2)商品信息管理：商品基本信息錄入、修改和刪除，注意各類完整性約束的設計與檢驗。

(3)進貨信息管理：進貨信息的錄入、修改和刪除。

(4)銷售信息管理：商品銷售信息的錄入、修改和刪除管理。

（5）各類信息的查詢：按簡單條件、組合條件及模糊條件對各類信息進行查詢。（6）各類信息的統計：按簡單條件、組合條件及模糊條件對各類信息進行統計。? 課題七：電子相冊管理系統開發（1人）(1)照片基本信息的管理：照片的上傳、顯示與刪除。（2）照片的瀏覽與查詢：按不同條件實現對照片的瀏覽與查詢(3)用戶的管理：不同的用戶對照片的上傳與查詢等權限不同。? 課題八：人事管理系統開發（１－2人）（1）員工信息管理：員工的姓名、性別、工作崗位、所在部門、學歷、婚姻狀況、專業、畢業時間、學校、外語情況、職稱等基本信息的錄入、修改與刪除。

（2）企業工作崗位信息和部門信息管理：企業中的工作崗位信息和部門信息的錄入、修改與刪除（如轉出、辭職、辭退、退休）。

（3）職稱信息的管理：所有職稱的種類、專業等信息的錄入、修改與刪除。（4）職工的檔案管理：對職工檔案信息的錄入、修改與刪除。（4）信息的查詢：對各類信息按不同的條件進行查詢。（5）信息的統計：對各類信息按不同的條件進行統計 ? 課題九：教職工簽到管理系統開發（1人）

(1)教職工基本信息管理：教職工基本信息的增加、修改與刪除；

(2)教職工簽到管理：教職工輸入編號后，簽到，系統自動記錄其簽到的時間，并注明是否遲到。

（3）教職工簽到情況的查詢與統計：按不同的條件對工簽到情況進行查詢與統計

? 課題十：通訊簿信息管理系統開發（1人）

(1)地址信息的管理：對新地址的姓名、性別、家庭住址、手機、住址電話、辦公電話、電子信箱、個人簡介、照片等基本信息的錄入，對原有地址信息的修改與刪除，在修改與刪除時，應先查詢出相關信息，再進行修改與刪除；

(2)地址信息的查詢與統計：可以按姓名等不同的條件對地址信息進行查詢與統計；

（3）用戶管理：錄入、修改與刪除用戶信息以及對用戶授權的管理。? 課題十一：網上圖書銷網站設計與開發（１－2人）

?(1)圖書信息管理：可以在管理后臺錄入、修改與刪除圖書的基本信息； ?(2)圖書內容簡介管理：錄入、修改與刪除圖書的內容簡介；

?（3）圖書內容簡介的查詢：可以在前臺按關鍵字查詢圖書的內容簡介 ?（4）用戶注冊管理：前臺提供用戶注冊界面，后臺可以對注冊的用戶進行查詢與刪除，但不能修改用戶的注冊信息。

?(5)購物車管理：前臺用戶可以將感興趣的圖書放入購物車，也可以刪除與查詢購物車內的圖書；

?(6)各類信息的查詢：學生自己設計按不同條件對各類信息進行查詢與統計。

?（7）各類信息需要用數據庫存儲。? 課題十二：客房管理信息系統開發（１－2人）

（1）用戶管理：錄入、修改與刪除用戶信息以及對用戶授權的管理。(2)客房基本信息的管理：添加、修改、刪除客房的基本信息；

（3）客戶住宿登記信息的管理：添加、修改、刪除客戶住宿登記的基本信息；(4)客戶預定管理：對預定客房的基本信息進行管理（5）客戶退房處理：對退房信息進行管理；

(6)各類信息的查詢與統計：按不同的條件對各類信息進行查詢與統計。? 課題十三：高?？蒲泄芾硐到y開發（１－2人）(1)科研人員管理：科研人員基本信息的錄入、修改與刪除。(2)科研項目管理；科研項目基本信息的錄入、修改與刪除。

(3)獲獎情況管理：對獲獎的科研科研成果、科研項目及相關的科研人員的信息進行管理；

(4)科研成果管理：對科研論文、學術著作等科研成果的基本信息進行錄入、修改與刪除管理。

(5)學術期刊管理：對各種學術期刊的基本信息進行錄入、修改與刪除管理。(6)各類信息的查詢與統計：按不同的條件對各類信息進行查詢與統計。? 課題十四：旅游管理系統開發（１－2人）

(1)景點管理：對各個景點基本信息的錄入、修改與刪除。(2)導游管理：對每個導游的姓名、專業、所在景點等基本信息的錄入、修改與刪除。

(3)游客管理：對各個游客基本信息的錄入、修改與刪除。(4)用戶管理：錄入、修改與刪除用戶信息以及對用戶授權的管理。(5)各類信息的查詢：按不同的條件對各類信息進行查詢。（6）各類信息的統計：按不同的條件對各類信息進行統計。? 課題十五：民航訂票管理系統開發（１－2人）（1）航班信息管理：每個航班基本信息的錄入、修改與刪除。

（2）航班坐位信息管理：每個航班坐位信息的錄入、修改與刪除。

（3）機票預定管理：輸入旅客基本信息，系統為旅客安排航班，打印取票通知和帳單；（4）退訂機票管理：對退訂機票信息進行判斷、錄入、修改與刪除。

（5）查詢信息：能夠查詢每個航班的基本信息、預定情況、旅客的基本信息等。（6）統計信息：計算每個航班的滿座率，統計旅客的乘坐次數數、乘坐總金額等。

? 課題十六：圖書借閱管理系統開發（1-2人）（1）讀者信息管理：對借閱者的借書證號、姓名、性別、出生日期、身份證號、聯系電話、辦證日期、借閱范圍（書庫）、所在單位、職業等基本信息的錄入、修改與刪除。

（2）圖書基本信息管理：對每種圖書的書名、書號（ISBN）、作者（譯者）、出版社、定價和內容簡介等基本信息的錄入、修改與刪除。

（3)借閱管理：借閱者的個人資料和所借圖書的書名、書號數據等基本信息的錄入、修改與刪除。憑借書證借書，每次最多能借8本書。借書期限最長為60天。輸入借書證號后，能根據借書證號判斷該讀者可以借書的書庫，借書是否超出最大允許借書冊數，書庫中是否還有該書可借。

（4）還書管理：對過期未還圖書進行罰款，對歸還的圖書能從借書登記表中取消，對丟失的圖書進行登記。

（5)對所有購進圖書的分類查詢和分類統計，能夠按書名、作者等分類查詢現有圖書的數量。

（6)能根據書號、書名、作者、出版單位、內容提要關鍵字、分類號、索書號、每冊圖書館藏注冊號等進行查詢。

? 課題課題十七：類QQ留言系統開發（1人）

1、QQ號基本信息的管理：能夠向數據庫中添加、刪除QQ號記錄，能夠修改記錄中的字段值。

2、能夠按照條件（好友呢稱、QQ號）留言或瀏覽。

3、能夠按好友呢稱、QQ號等條件對QQ號進行查詢 與統計 ? 課題十八：中小學智能排課系統開發（１-2人）

? 能根據教師要求(如某天不得排課)、課程約束(如體育不能排在上午第一節課)、班級約束(如某班星期五下午最后一節課不排課)、校級約束(如全校所有班級星期一下午第一節課都為班會)等信息自動為班級和教師生成課程表，要求主課盡量排在上午和下午一、二節課，副課盡量排在上午和下午的最后一節課，如體育課排在上午第一節課是不太合適的。對于軟件不能安排的少數課程，教務工作者能夠在自動排出的課程表上進行手工調課。? 具體要求：

(1)系統可以進行兩節連課處理，如作文課可以連課上；(2)排出的課程表中不允許有教師沖突的情況，比如，一個教師同時給兩個班級上課是不允許的；

(3)要求課程表中的課程要有所變化，比如一個班級的所有數學課總是排在上午第一節課是不好的課程表。

(4)每周上課天數為5天，每天上課節數可以是7節或是8節；(5)每個年級所開課程是一樣的；(6)一個教師可以教授多門課程；

(7)系統可以為每個班級和每位教師打印課程表；(8)在課表生效后，教師可以要求調課；

(9)教師數量是動態的，所開課程的數量也是動態的。

? 課題十九：學生學籍管理信息系統開發（1人）

(1)學生檔案的管理，即錄入、修改、查詢、輸出學生檔案信息，這些信息包括學生基本情況、學生簡歷情況、學生獎勵情況、學生處分情況、學生家庭信息、學生體檢情況。

(2)學生學籍管理，能夠錄入、修改、查詢、輸出學生學籍信息，這些信息包括學生獎貸學金情況、學生注冊、學生異動情況、學生軍訓情況、學生畢業情況。

(3)學生成績管理，能夠錄入修改、查詢、輸出學生入校成績，各學期、各門課程的成績信息，并支持按年級、班級等條件的統計、查詢、報表輸出。

? 課題二十：網上訂貨發貨系統開發（1-2人）

1）合同管理：合同的合同編號，客戶的名稱，地址，簽定時間，帳號，總金額及產品清單等基本信息的錄入、修改、刪除和查詢。一個合同可簽訂多種產品，合同簽訂必須為現有的庫存產品，但產品庫存量不夠時，可允許先簽訂合同；

2）客戶管理：客戶網上注冊、登錄、修改個人資料等。

3）發貨管理：根據合同簽訂的情況發貨，不得超出合同簽訂的產品品種，數量及庫存量；每個合同的發貨可分次完成，并保留發貨的歷史記錄。

4）庫存管理：可完成產品入庫、出庫（合同發貨）信息的錄入、修改與刪除。5）查詢信息：各類基本信息的分類查詢 6）統計信息：各類基本信息的分類統計。

? 課題二十一：超市管理系統開發（１－2人）1）超市員工信息管理：超市員工的姓名、家庭住址、學歷、婚姻狀況信息等基本的錄入、修改和刪除； 2）超市貨物信息管理：超市貨物的的名稱，編號，價格，生產廠家，庫存量等基本信息的錄入、修改和刪除；

3）銷售情況管理：超市貨物銷售信息的錄入、修改和刪除； 4）用戶管理：用戶基本信息的的錄入、修改和刪除； 5）查詢信息：各類基本信息的分類查詢

6）統計信息：各類基本信息的分類統計。

? 課題二十二：教師網上成績錄入系統開發(１－2人)

1）教師信息的管理：教師的基本信息、所教課程、授課時間、教師密碼等信息的錄入、修改和刪除；

2）學生信息的管理：學生基本信息的錄入、修改和刪除；

3）課程信息的管理：課程基本信息的錄入、修改和刪除；

4）選課信息的管理：生所選課程基本信息的錄入、修改和刪除；

5）成績管理：成績的錄入和修改

6）信息的查詢與統計：能按不同條件對各類信息進行查詢，能按多個條件對成績信息、選課信息等進行統計；

? 課題二十三：網上考試系統開發(１－2人)1）考生信息管理：考生基本信息的錄入、修改和刪除。

2）試題庫管理：試題庫（試題及答案）基本信息的錄入、修改和刪除。

3）試卷生成：根據規則從試題庫抽出試題形成試卷

4）試卷提交：學生做完題目以后，能夠對自己的答案進行提交，提交以后，信息不能再修改；

5）試卷評分：對試卷進行自動評分，并記錄試卷分數。學生將所有題目全部提交以后，能夠查看標準答案與評分標準。

6）查詢與統計信息：能對試卷的難易度、成績等各類基本信息進行分類查詢與統計。

? 課題二十四：網上選課系統開發(１－2人)（1）學生信息管理：學生基本信息的錄入、修改和刪除。

（2）可選課程信息管理：課程的課程號、課程名、可選專業及開課學期學分等基本信息的錄入、修改和刪除。

（3）學生選課：學生登錄后，根據學生的專業及開課學期生成可選的課程表，讓學生完成選課，并自動生成選課信息表。（4）選課信息表的查詢與修改：所選課的課程號、課程名、學號、選課時間、所修學期等基本信息在一定的時間段內可刪除。（5）查詢信息：各類基本信息的分類查詢

（6）統計信息：各類基本信息的分類統計。

? 課題二十五：學生黨員管理系統開發（1人）

（1）學生黨員信息的管理；能夠增加、修改和刪除學生黨員的基本信息；（2）查詢黨員的基本信息：能夠按照查詢條件（班級、年級、專業、入黨時間）查詢黨員的數量；也能夠實現多個條件的組合查詢

（3）統計黨員的基本信息：統計按照查詢條件（班級、年級、專業、入黨時間）查詢黨員的數量；

? 課題二十六：學生綜合評定積分管理系統開發（1人）

（1）學生綜合成績的管理：能夠按照學年記錄增加、修改和刪除學生各項分值（德育素質分各項、體育素質分各項、智育素質分各項），并能夠進行自動運算求出學生該學年的綜合積分。

（2）成績查詢：能夠按照查詢條件（學年、專業、班級）對各項信息進行查詢。（3）能夠按照設定條件進行綜合積分排序（學年、專業、班級）和對成績的統計

注：提供數據：系各班綜合評定表；學生學籍信息統計表； ? 課題二十七：畢業論文管理系統開發（1人）

（1）畢業論文基本信息管理：能夠向數據庫中添加、修改、刪除論文記錄。?（2）數據查詢：能夠按照查詢條件（指導教師、選題性質、題目類型、成績、專業班級、年級、學生姓名、難度、指導教師職稱）進行論文的查詢并能瀏覽查詢結果。

?（3）數據統計：能夠按照設定條件進行相關數據的統計（成績百分率（優秀、良好、中等、及格、不及格），可以以專業來統計也可以以班級來統計）。

? 課題二十八：學生宿舍查詢系統開發（1-2人）

（1）學生宿舍信息管理：能夠向數據庫中添加、刪除和修改宿舍記錄。（2）宿舍信息查詢：能夠按照查詢條件（學生姓名、學號、宿舍、電話、班級）進行查詢并能瀏覽查詢結果。

（3）宿舍信息統計：能夠按照條件（學生人數、專業、是否住滿或是否為空等）進行統計并能瀏覽統計結果。

? 注：提供的數據有學生宿舍信息匯總表、學生學籍信息統計表 ? 課題二十九：考試監考管理系統開發（1人）（1）基本信息管理：能夠向數據庫中添加、刪除、修改監考安排相關的信息。（2）數據查詢：能夠按照條件（教師姓名、監考校區）進行查詢；

（3）數據統計：按照教師姓名統計教師每一學期監考的次數和監考費，往返新老兩個校區的監考費為13元/次，否則為10元/次； ? 課題三十：氣象信息管理系統開發（1人）

（1）基本信息管理：能夠向數據庫中添加、刪除、修改氣象記錄。

（2）數據查詢：能夠按照查詢條件（月份、地名、氣溫類別）進行查詢并能瀏覽查詢結果

（3數據統計：能夠按照統計條件（月份、地名、氣溫類別）進行統計并能瀏覽統計結果。