網易雲社群
映象技術實現了位於不同物理伺服器上的兩個sql server例項資料同步，在映象集群中，sql server例項具有三種角色；
在映象集群中，principal和mirror的資料同步是依靠事務日誌來實現的，與oracle和mysql 不同，sql server的事務日誌是database級別的，不是例項級別的，每個database都單獨的事務日誌，這也就使得sql server的映象是可以基於database層面實現。乙個sql server例項中的兩個database，乙個可以作為principal，乙個可以作為mirror，分別與其他sql server例項組建映象關係；另外，sql server 乙個database只能有乙個mirror節點，乙個mirror的database不可以再有mirror節點，這點與mysql級聯複製不同；
sql server的事務日誌是物理記錄級別的，記錄了對資料庫某個頁的某行記錄(slot)的操作，principal建立映象後，會啟動乙個單獨的事務日誌傳送執行緒，維護乙個虛擬的傳送佇列，然後讀取事務日誌，將其進行壓縮，根據官方公布的測試資料，壓縮比不低於12.5%，然後傳送給mirror節點，mirror節點接收到以後，會將其寫入本地在磁碟上的乙個重做佇列檔案中，然後再通過另外的乙個執行緒非同步的方式，從重做佇列中獲取事務日誌，然後分發給應用執行緒（process unit）進行回放。
不同於mysql binlog，由於sql server的事務日誌在principal上事務執行過程中就已經源源不斷的寫入（mysql binlog僅在事務提交階段生成），在principal事務執行的同時事務日誌就已經傳遞給了mirror，所以基於事務日誌的sql server的複製效能會更理想，同時，在mirror回放的過程中，可以基於頁（page）級別進行併發更新(redo parallel)，在sql server的標準版中，僅提供乙個執行緒進行事務日誌回放（roll forward），在企業版中，如果當前伺服器cpu大於5核，則每4個核，增加乙個並行執行緒，如果低於5個核，則仍然使用單執行緒回放。同時，基於頁的事務日誌的併發執行，還有乙個好處就是對於同乙個頁面的更新可以合併重新整理，減少髒頁重新整理數量；
映象集群提供了三種執行模式：
映象集群故障轉移最複雜場景就是帶見證伺服器的支援自動故障轉移的高安全模式，所以我們重點討論該模式下的故障處理流程。
初始狀態下，witness、principal和mirror三個節點兩兩之間均保持長連線會話，現在討論其中一方連線中斷情況：
最後mirror會通過後台執行緒，將未提交的事務回滾（基於binlog的mysql複製由於binlog是在事務提交階段生成的，所以不存在事務回滾的階段）。
從整個故障切換的流程來看，故障切換時間主要包括三個部分：檢測到principal宕機的時間、mirror上重做佇列中事務日誌的回放時間以及回滾未提交事務的時間，其中前面兩段時間服務不可用，尤其時重做佇列的回放時間，直接決定了服務不可用時間。
下面來考慮三方會話兩個會話同時中斷情況：
乙個完整的高可用機制除了後端節點的切換選主，還包括發生故障轉移後，客戶端如何能夠快速的連線到冗餘節點，繼續業務讀寫。常用的實現，包括driver層解決方案，例如mongodb replication set，也有通過二層內的廣播方式實現vip，例如keepalived，當然還包括proxy，以及三層dns的實現。
sql server的實現採用了driver層處理的方式，開發者要實現自動的故障轉移，在連線資料庫時，除了必須要指定初始節點的ip和埠，還要指定故障轉移的節點的ip和埠。客戶端首先嘗試使用初始節點建立連線，如果初始節點指向的例項當前為principal，則連線會建立成功，可以正常的讀寫。當發生故障切換時，principal會切斷所有已有客戶端連線，然後客戶端建立到初始節點連線也會失敗，通過一定的重試策略失敗後，會嘗試連線之前指定的故障轉移節點，從而實現服務入口的切換。
sql server常用的訪問介面：ole db、odbc、ado均支援指定故障轉移節點，格式如下：
server=250.65.43.21,4734; failover_partner=250.65.43.22,4734;映象集群的監控可以通過sql server management stdio啟動映象監視器，或者系統內建的儲存過程來實現，監控的主要指標包括：
網易雲新使用者大禮包：
Activity Intent深入解析
學習android sdk有段時間了，對activity intent的學習與使用都比較了解。第一次完整的學習activity intent後，我就感覺這似乎與windows com技術有些似曾相識的感覺，寫了一篇將activity 與 com 做了比較，但是一直感覺意猶未盡，前幾天在程式設計師雜誌...
深入解析IOCP
1.介紹 1.1 高併發伺服器 1 要求大規模的連線 會話可能同時進行 2 列子 web 伺服器,郵件伺服器 1.2 執行緒池架構 1 每個連線分配乙個執行緒，將導致過多的執行緒。2 執行緒消耗記憶體,比如堆疊等等。2.執行緒模型 2.1 基於會話模型 1 每個執行緒服務於乙個客戶端,比如http ...
HTTP 深入解析
1.cookie 儲存在客戶端 cookie 的類別 cookie 的屬性 了解 cookie 的應用場景 同源http請求 攜帶cookie 原生ajax請求方式 xhr.withcredentials true 支援跨域傳送cookies xhr.send jquery的ajax的post方法請...