|
項目一：數據庫實時同步
|
|
項目簡介（功能與用途）： 功能：將系統平臺需要訪問或者產生的數據每10分鐘寫入備份數據庫上。 用途：由於備份數據庫和系統數據庫的結構完全相同，在數據庫服務器發生災難性破壞時，可以將數據庫訪問指向備份數據庫服務器。 說明：一方面彌補全備份和差異備份的時間連貫性不夠，另一方面也在最短的時間恢復平臺的正常運行。
項目難點與解決方案： 難點：數據量大，讀出和寫入的頻率非常高。操作最頻繁的地方數據量最大，高達2000多萬的數據量。同時，數據同步非常消耗系統性能，況且單位時間產生的數據量非常大，所以要預先估計數據庫服務器的負載能力。另外，數據同步隨着時間的偏移，可能會有些數據不能真實的同步。 解決方案： 數據產生的數量大，就要進行測試還判斷多少時間來同步一次纔不至於影響了服務器的正常工作。 關於數據同步的可靠性，相關的技術文檔並沒有提過ms sql server的數據複製會100%正確。所以需要定期生成快照，重新初始化所有數據。這樣才能儘量保證數據的正確性。 經過多次測試後，我選擇的是事物複製，因爲它可以滿足實時的特徵，然後選擇每週初始化一次備份數據庫，因爲初始化的時候，需要重新生成快照，數據庫的數據量又很大，並且服務器上是有幾十個數據庫相互關聯，所以生成快照的時候最容易讓鎖升級成庫鎖，從而讓數據庫服務器停止響應。 項目成功與失敗的經驗歸納： 我做這個同步的時候，查閱了網上的朋友做過的類似的工作。找了幾篇相關的文章出來。但似乎這文章要麼是用觸發器來實現，要麼是複製了微軟相關的文檔，並沒有經過自己的實踐。所以文章中提到了有些東西，服務運行的帳號，和服務器之間的信任關係，這些實際上分散了實施人員的精力，我測試後發現這些其實是不需要必備的東西。我最初做這個任務的時候，設置的是每天初始化一次備份數據庫，所以會出現鎖死的現象，數據庫的正常運行，在出現阻塞的時候，會不斷讓鎖升級，當庫鎖發生的時候，系統儘管會犧牲部分事物，但短時間是無法恢復的。所以我選擇了1周初始化一次，並且系統中的多個數據庫分散在不同的日期。
你在項目中崗位與貢獻： 獨立完成。現在同步運行的很好，並且對數據庫服務器的正常運行沒造成破壞。很好地保障了 平臺對對數據的要求。
|
|
項目二：用戶表擴容 |
|
項目簡介（功能與用途）： 功能：保障用戶量升級爲目前數量10倍的時候，系統依然可以平穩運行。 用途：滿足平臺運行需要，在線人數在突破性增長，需要提前做好準備。
項目難點與解決方法： 由於平臺屬於遊戲平臺，對用戶基本信息的操作非常頻繁，尤其是在線人數很高的時候。對於一個用戶信息表來講，當它的數據量超過500萬的時候，性能會明顯下降。現在已經約400萬的信息，目前是靠刪除部分過期帳號來保持。但是每天新增用戶的數量越來越大，必須要讓數據庫對用戶信息的處理方式在結構上調整，來滿足平臺的需要。 難點：該數據庫服務器同時跑兩個數據庫實例。每個實例約25個數據庫。服務器是4cpu,3G內存。所以要儘可能做到最優化的結構，以最小的硬件需要來滿足最大的數據操作需要。 我首先是參考了各個大型網絡遊戲對用戶信息的處理方式。主要是兩種方式：一種是直接做數據庫羣集，以最大化的硬件條件來徹底解決性能限制。第二種是分表，將用戶歸類，這就體現在網遊的登陸需要選擇登陸區這個地方了。他們把用戶基本限制在某個固定的區域，跨區域的很少，所以就相當於把數據需要都分散了，這樣做的好處很明顯，一個1000萬的表容易發生阻塞，但分成三個300萬的表就幾乎不可能阻塞了。 解決方安：顯然，做羣集現在不行，沒有這個硬件條件是主要因素，況且平臺底層所劃分的結構也需要進行調整。現在的要求單方面從數據庫調整來對用戶容量進行擴展。然後我考慮的是使用分表的方式，那麼如果像其他遊戲那樣對用戶進行分區登陸，現在也不行，因爲那也需要修改遊戲運行的平臺。所以分區登陸，只能存在於數據庫的邏輯中，對遊戲平臺和遊戲用戶來講，應該是透明的纔對。那麼在數據庫中對用戶進行分類，存儲在不同的表中，就有個問題，用戶的唯一標誌怎麼處理。所有的遊戲數據庫，全都會給每個帳號一個唯一ID,並且是自增長這樣的ID,如果劃分成多個表那麼這個ID該怎麼處理。這一步的操作必須保證用戶ID是由同一接口生成纔行。經過思考後，我決定在邏輯上給用戶一個新的唯一標誌，做一個遊戲通行證。 那麼這個通行證表，只保留用戶的邏輯區編號和用戶的ID，當然，用戶的ID就改成在這裏生成。然後根據範圍，交到不同的分區用戶表，他們的相關處理流程，也根據ID值走向各自的處理過程。
項目成功與失敗的經驗歸納： 儘管我採用的也是分表的思想，我經過考慮後，加上一個遊戲通行證之後，就對以後保留了很大個操作空間。現在可以加一個400萬的區，需要的時候，再加就很容易，只需要在通行證生成編號的時候再加一個邏輯區，然後在用戶信息處理請求接收的接口那裏加一個流轉方向就可以了，因爲所有用戶的處理接口實際是一樣的，只需要修改對應的表名就可以了。
你在項目中崗位與貢獻： 獨立設計。（目前該策略還在測試和修改的過程，還沒有投入使用）
|
|
項目三：數據庫性能調優 |
|
項目簡介（功能與用途）： 檢查存儲過程在數據庫中的操作。優化這些操作，儘可能提高數據操作的性能。避免數據阻塞的出現。不允許庫鎖的出現。
項目難點與解決方法： 由於遊戲平臺的特徵，現在數據庫實例上有三十個用戶數據庫，現在首先要找出對系統性能影響比較大的操作。如果一個個的數據操作接口進行調試，需要花費的時間很長才能找到主要問題。所以我考慮先找在目前對系統影響最大的接口。那麼首先是從數據庫中查看當前所有的鎖，主要是看錶鎖，因爲幾乎所有的庫鎖都是由表鎖升級而來，一般來講超過1000條記錄處理的操作會有表鎖，超過10000條的就會有庫鎖，當然，在實際的情況中，這些是比較隱含的，只能對存儲過程這些操作，查看流程，單步調試，在能找出在哪一步消耗的資源最大。所以如果對系統性能影響比較大的話，這個操作一定會引起表鎖，那麼我可以直接從引起表鎖的進程列表中查看，來確定一個比較小的數據操作列表了。可以對這個列表中出現的存儲過程進行調試，檢查是否比較合理的利用了索引，是否對數據的操作比較合理。 優化的方式還是照一般的方法，就是讀操作比較多的，根據查詢條件建立索引，寫操作多的儘量減少索引。
項目成功與失敗的經驗歸納： 如果做這個工作的人數比較多的話，實際是應該檢查所有的操作，對每一個數據操作就進行細緻的調試和優化，但在這樣特殊的條件下，沒有其他人一起，自己面對大量的存儲過程需要分析的情況下，可以按照我的方式，先解決主要問題，就是從數據庫反映出的有表級鎖的操作來查找問題所在。
你在項目中崗位與貢獻： 獨立完成。現在系統中已經避免了大數據量的操作，數據庫的性能處於很平穩的狀態。
|