聊聊Dataguard的三種保護模式實驗(上)
保護模式(Protection Mode),分別為:最大保護(Maximum Protection)、最大可用(Maximum Availability)和最大效能(Maximum performance)。在實際應用場景下,我們需要根據不同的業務場景和資料可用性需求,來設定DG環境的保護型別。
1、三種保護模式Protection Mode
三種保護模式是DG的核心概念。DG本質上是一種基於Redo Log的資料同步機制。Undo和Redo是Oracle早期奠定行業地位的核心技術。Undo負責記錄事務操作的前映象,而Redo負責記錄事務操作的後鏡像。在Oracle事務commit的動作中,寫入日誌檔案是一個一定需要完成的動作。寫入日誌檔案之後,即使立刻出現嚴重的例項終止事件,在重新啟動例項的時候也會進行例項恢復動作,將事務落實。
在DG環境中,無論採用何種初始化方法,都是確保一個Primary和Standby的初始化資料一致,之後Primary一端接收的事務型別操作,均會以歸檔日誌串列的方式傳遞到Standby端的standby redo log和歸檔日誌列表中,最後重複應用這些日誌,實現Primary和Standby端一致。
Primary和Standby是相互為備份的冗餘結構,Standby跟隨Primary的情況,反映了HA結構的可用性級別。理論上,最保險的策略是一個事務要保證在Primary和Standby上都提交了,才返回給使用者說已經完成。這樣是可以保證主備庫完全一致的最保險做法。另一個極端情況,就是主庫“自顧自”進行事務處理,獨立將日誌進行傳輸,也不用管日誌是否傳輸到或者應用到。
針對不同的傳輸情況,DG區分為三種保護型別:
ü 最大可用模式Maximum Availability
在官方文件中,對這種模式的描述如下:
“This protection mode provides the highest level of data protection that is possible without compromising the availability of a primary database. Transactions do not commit until all redo data needed to recover those transactions has been written to the online redo log and to the standby redo log on at least one synchronized standby database. If the primary database cannot write its redo stream to at least one synchronized standby database, it operates as if it were in maximum performance mode to preserve primary database availability until it is again able to write its redo stream to a synchronized standby database.”
Maximum Availability模式下,事務只有在所有相關日誌都被傳輸到至少一個Standby端日誌的時候,才可以正式提交。但是,如果Primary在傳輸日誌的過程中,發現所有standby端都不能進行傳輸,模式會退化到最大效能模式(Maximum Performance)工作方式。應該說,Maximum Availability是一種自適應的保護模式,當出現問題的時候,DG會退而求其次,確保Primary主庫事務進行。
ü 最大效能模式(Maximum Performance)
官方文件中介紹如下:“This protection mode provides the highest level of data protection that is possible without affecting the performance of a primary database. This is accomplished by allowing transactions to commit as soon as all redo data generated by those transactions has been written to the online log. Redo data is also written to one or more standby databases, but this is done asynchronously with respect to transaction commitment, so primary database performance is unaffected by delays in writing redo data to the standby database(s).
This protection mode offers slightly less data protection than maximum availability mode and has minimal impact on primary database performance.
This is the default protection mode.”
最大效能模式是在不影響主庫工作情況下,可以提供的最高資料保護級別。當事務進行提交的時候,主庫不會去確認日誌是否寫入到備庫中,更不會確認是否被apply。這種方式下,主庫的工作效能是不會收到備庫提交應用的影響的。當然,這種保護模式會有一定的事務資料丟失,但是絕對不會出現資料誤提交的情況。
對DG而言,最大效能模式是預設的保護模式。當我們完成了DG安裝之後,就自動進入了Maximum Performance模式。
ü 最大保護模式(Maximum Protection)
最大保護模式在官方中的描述為:
“This protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover a transaction must be written to both the online redo log and to the standby redo log on at least one synchronized standby database before the transaction commits. To ensure that data loss cannot occur, the primary database will shut down, rather than continue processing transactions, if it cannot write its redo stream to at least one synchronized standby database.
Transactions on the primary are considered protected as soon as Data Guard has written the redo data to persistent storage in a standby redo log file. Once that is done, acknowledgment is quickly made back to the primary database so that it can proceed to the next transaction. This minimizes the impact of synchronous transport on primary database throughput and response time. To fully benefit from complete Data Guard validation at the standby database, be sure to operate in real-time apply mode so that redo changes are applied to the standby database as fast as they are received. Data Guard signals any corruptions that are detected so that immediate corrective action can be taken.”
最大保護模式是完全HA架構理想中的事務模式。如果Primary資料庫進行一個事務,連帶Standby資料庫也要同步進行操作。如果由於網路、執行模式等原因,Standby不能夠跟上主庫的操作,那麼主庫會放棄事務,並且強制停庫。
保護模式的三種和資料庫之間傳輸日誌的機制是密切相關的。主要體現是否同步傳輸Redo日誌和對日誌進行確認兩個方面。我們配置三種日誌模式,一定要以Log_Archive_Config引數配置為基礎。
Maximum Availability |
Maximum Performance |
Maximum Protection |
AFFIRM |
NOAFFIRM |
AFFIRM |
SYNC |
ASYNC |
SYNC |
DB_UNIQUE_NAME |
DB_UNIQUE_NAME |
DB_UNIQUE_NAME |
下面通過一系列的測試,來分析三種保護模式的工作行為方式。
2、環境介紹
筆者使用環境為Oracle 11gR2,具體版本為11.2.0.4。主備庫環境已經搭建完成,同步保護模式是採用預設方式。
主庫資訊:
SQL> select name, open_mode, database_role, protection_mode from v$database;
NAME OPEN_MODE DATABASE_ROLE PROTECTION_MODE
--------- -------------------- ---------------- --------------------
VLIFE READ WRITE PRIMARY MAXIMUM PERFORMANCE
SQL> select instance_name from v$instance;
INSTANCE_NAME
----------------
vlife
主庫與備庫連線方式,採用預設的非同步非確認方式。
SQL> select dest_id, dest_name, TRANSMIT_MODE, ASYNC_BLOCKS, AFFIRM TYPE, VALID_NOW, VALID_TYPE, VALID_ROLE, DB_UNIQUE_NAME from v$archive_dest where status<>'INACTIVE';
DEST_ID DEST_NAME TRANSMIT_MODE ASYNC_BLOCKS TYPE VALID_NOW VALID_TYPE VALID_ROLE DB_UNIQUE_NAME
---------- -------------------- ------------- ------------ ---- ---------------- --------------- ------------ ---------------
1 LOG_ARCHIVE_DEST_1 SYNCHRONOUS 0 NO YES ALL_LOGFILES ALL_ROLES NONE
2 LOG_ARCHIVE_DEST_2 ASYNCHRONOUS 61440 NO YES ONLINE_LOGFILE PRIMARY_ROLE vlifesb
此時,傳輸通道配置。
SQL> show parameter LOG_ARCHIVE_DEST_2;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2 string SERVICE=vlifesb valid_for=(online_logfiles,primary_role) db_unique_name=vlifesb
log_archive_dest_20 string
log_archive_dest_21 string
備庫資訊如下:
SQL> select name, open_mode, database_role, protection_mode from v$database;
NAME OPEN_MODE DATABASE_ROLE PROTECTION_MODE
--------- -------------------- ---------------- --------------------
VLIFE READ ONLY WITH APPLY PHYSICAL STANDBY MAXIMUM PERFORMANCE
SQL> select instance_name from v$instance;
INSTANCE_NAME
----------------
vlifesb
SQL> col dest_name for a20;
SQL> select dest_id, dest_name, TRANSMIT_MODE, ASYNC_BLOCKS, AFFIRM TYPE, VALID_NOW, VALID_TYPE, VALID_ROLE, DB_UNIQUE_NAME from v$archive_dest where status<>'INACTIVE';
DEST_ID DEST_NAME TRANSMIT_MODE ASYNC_BLOCKS TYPE VALID_NOW VALID_TYPE VALID_ROLE DB_UNIQUE_NAME
---------- -------------------- ------------- ------------ ---- ---------------- --------------- ------------ ------------------------------
1 LOG_ARCHIVE_DEST_1 SYNCHRONOUS 0 NO YES ALL_LOGFILES ALL_ROLES NONE
2 LOG_ARCHIVE_DEST_2 ASYNCHRONOUS 61440 NO WRONG VALID_TYPE ONLINE_LOGFILE PRIMARY_ROLE vlife
32 STANDBY_ARCHIVE_DEST SYNCHRONOUS 0 NO YES ALL_LOGFILES ALL_ROLES NONE
SQL> show parameter LOG_ARCHIVE_DEST_2;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2 string SERVICE=vlife valid_for=(online_logfiles,primary_role) db_unique_name=vlife
log_archive_dest_20 string
log_archive_dest_21 string
3、最大可用模式Maximum Availability Mode測試
當前從預設的最大效能切換到最大可用模式,首先需要滿足將日誌傳輸模式進行修改。
SQL> alter system set log_archive_dest_2='SERVICE=vlifesb sync affirm net_timeout=30 valid_for=(online_logfiles,primary_role) db_unique_name=vlifesb';
System altered
SQL> select dest_id, dest_name, TRANSMIT_MODE, ASYNC_BLOCKS, AFFIRM TYPE, VALID_NOW, VALID_TYPE, VALID_ROLE, DB_UNIQUE_NAME, NET_TIMEOUT from v$archive_dest where status<>'INACTIVE';
DEST_ID DEST_NAME TRANSMIT_MODE ASYNC_BLOCKS TYPE VALID_NOW VALID_TYPE VALID_ROLE DB_UNIQUE_NAME NET_TIMEOUT
---------- -------------------- ------------- ------------ ---- ---------------- --------------- ------------ ------------------------------ -----------
1 LOG_ARCHIVE_DEST_1 SYNCHRONOUS 0 NO YES ALL_LOGFILES ALL_ROLES NONE 0
2 LOG_ARCHIVE_DEST_2 PARALLELSYNC 0 YES YES ONLINE_LOGFILE PRIMARY_ROLE vlifesb 30
此時,將保護模式使用alter database進行設定。
SQL> alter database set standby database to maximize availability;
Database altered
SQL> select name, open_mode, database_role, protection_mode from v$database;
NAME OPEN_MODE DATABASE_ROLE PROTECTION_MODE
--------- -------------------- ---------------- --------------------
VLIFE READ WRITE PRIMARY MAXIMUM AVAILABILITY
在切換動作的時候,主庫日誌情況如下:
Wed Oct 21 15:13:48 2015
alter database set standby database to maximize availability
Completed: alter database set standby database to maximize availability
Wed Oct 21 15:13:49 2015
Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED –發現沒有同步,需要補充。
******************************************************************
LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
******************************************************************
Wed Oct 21 15:13:49 2015
NSS2 started with pid=34, OS id=9186
LGWR: Standby redo logfile selected to archive thread 1 sequence 82
LGWR: Standby redo logfile selected for thread 1 sequence 82 for destination LOG_ARCHIVE_DEST_2
Thread 1 advanced to log sequence 82 (LGWR switch)
Current log# 3 seq# 82 mem# 0: /u01/app/oracle/oradata/VLIFE/onlinelog/o1_mf_3_c1kb1c24_.log
Current log# 3 seq# 82 mem# 1: /u01/app/oracle/fast_recovery_area/VLIFE/onlinelog/o1_mf_3_c1kb1c43_.log
Wed Oct 21 15:13:53 2015
Archived Log entry 104 added for thread 1 sequence 81 ID 0xfad4f44b dest 1:
Wed Oct 21 15:13:54 2015
ARC3: Archive log rejected (thread 1 sequence 81) at host 'vlifesb'
FAL[server, ARC3]: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance vlife - Archival Error. Archiver continuing.
Wed Oct 21 15:14:42 2015
Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
LGWR: Standby redo logfile selected to archive thread 1 sequence 83
LGWR: Standby redo logfile selected for thread 1 sequence 83 for destination LOG_ARCHIVE_DEST_2
Thread 1 advanced to log sequence 83 (LGWR switch)
Current log# 1 seq# 83 mem# 0: /u01/app/oracle/oradata/VLIFE/onlinelog/o1_mf_1_c1kb19q4_.log
Current log# 1 seq# 83 mem# 1: /u01/app/oracle/fast_recovery_area/VLIFE/onlinelog/o1_mf_1_c1kb19sb_.log
Wed Oct 21 15:14:42 2015
Archived Log entry 107 added for thread 1 sequence 82 ID 0xfad4f44b dest 1:
在Primary端,在進行切換之後,Oracle發現傳輸狀態不是同步情況。於是自動加快進行日誌傳輸和同步動作。在Standby端,也可以看到後續追趕動作。
SQL> select name, open_mode, database_role, protection_mode from v$database;
NAME OPEN_MODE DATABASE_ROLE PROTECTION_MODE
--------- -------------------- ---------------- --------------------
VLIFE READ ONLY WITH APPLY PHYSICAL STANDBY MAXIMUM AVAILABILITY
Standby端上的日誌追趕動作。
Wed Oct 21 08:27:05 2015
Primary database is in MAXIMUM PERFORMANCE mode
Re-archiving standby log 4 thread 1 sequence 80
Wed Oct 21 08:27:05 2015
Media Recovery Waiting for thread 1 sequence 81
RFS[14]: Assigned to RFS process 31500
RFS[14]: Selected log 5 for thread 1 sequence 81 dbid -87496857 branch 892734889
Wed Oct 21 08:27:05 2015
Archived Log entry 76 added for thread 1 sequence 80 ID 0xfad4f44b dest 1:
Recovery of Online Redo Log: Thread 1 Group 5 Seq 81 Reading mem 0
Mem# 0: /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_5_c265gqd8_.log
Mem# 1: /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_5_c265gqj0_.log
Wed Oct 21 15:13:52 2015
Primary database is in MAXIMUM AVAILABILITY mode
Changing standby controlfile to MAXIMUM AVAILABILITY mode
Changing standby controlfile to RESYNCHRONIZATION level
Standby controlfile consistent with primary
RFS[15]: Assigned to RFS process 969
RFS[15]: Selected log 4 for thread 1 sequence 82 dbid -87496857 branch 892734889
Wed Oct 21 15:13:53 2015
Archived Log entry 77 added for thread 1 sequence 81 ID 0xfad4f44b dest 1:
Wed Oct 21 15:13:53 2015
Media Recovery Waiting for thread 1 sequence 82 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 82 Reading mem 0
Mem# 0: /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_4_c265gc9q_.log
Mem# 1: /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_4_c265gcfk_.log
Wed Oct 21 15:14:41 2015
Archived Log entry 78 added for thread 1 sequence 82 ID 0xfad4f44b dest 1:
Wed Oct 21 15:14:41 2015
Media Recovery Waiting for thread 1 sequence 83
Wed Oct 21 15:14:42 2015
Primary database is in MAXIMUM AVAILABILITY mode
Changing standby controlfile to MAXIMUM AVAILABILITY level
Standby controlfile consistent with primary
RFS[16]: Assigned to RFS process 976
RFS[16]: Selected log 4 for thread 1 sequence 83 dbid -87496857 branch 892734889
Recovery of Online Redo Log: Thread 1 Group 4 Seq 83 Reading mem 0
Mem# 0: /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_4_c265gc9q_.log
Mem# 1: /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_4_c265gcfk_.log
此時,兩個庫由於網路通暢,同步狀態正常,同步測試正常。
(Maximium Availiablity模式下使用)
--主庫下
SQL> create table t_m as select * from dba_objects where rownum<10;
Table created
--Standby下
SQL> select count(*) from t_m;
COUNT(*)
----------
9
如果此時中斷應用日誌,Standby情況如下:
SQL> alter database recover managed standby database cancel;
Database altered
SQL> select name, open_mode, database_role, protection_mode from v$database;
NAME OPEN_MODE DATABASE_ROLE PROTECTION_MODE
--------- -------------------- ---------------- --------------------
VLIFE READ ONLY PHYSICAL STANDBY MAXIMUM AVAILABILITY
日誌情況如下:
Wed Oct 21 15:20:49 2015
alter database recover managed standby database cancel
Wed Oct 21 15:20:49 2015
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /u01/app/oracle/diag/rdbms/vlifesb/vlifesb/trace/vlifesb_pr00_17539.trc:
ORA-16037: user requested cancel of managed recovery operation
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Recovered data files to a consistent state at change 1692263
Wed Oct 21 15:20:49 2015
MRP0: Background Media Recovery process shutdown (vlifesb)
Managed Standby Recovery Canceled (vlifesb)
Completed: alter database recover managed standby database cancel
如果此時再中斷監聽器,中斷連線。此時資料庫不能做到實時同步。
[[email protected] ~]$ lsnrctl stop
LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 21-OCT-2015 15:24:17
Copyright (c) 1991, 2013, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))
The command completed successfully
--主庫
***********************************************************************
Fatal NI connect error 12541, connecting to:
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=172.16.19.90)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=vlifesb)(CID=(PROGRAM=oracle)(HOST=vLIFE-URE-OT-DB-PRIMARY)(USER=oracle))))
VERSION INFORMATION:
TNS for Linux: Version 11.2.0.4.0 - Production
TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
Time: 21-OCT-2015 15:24:38
Tracing not turned on.
Tns error struct:
ns main err code: 12541
TNS-12541: TNS:no listener
ns secondary err code: 12560
nt main err code: 511
TNS-00511: No listener
nt secondary err code: 111
nt OS err code: 0
Error 12541 received logging on to the standby
Check whether the listener is up and running.
PING[ARC2]: Heartbeat failed to connect to standby 'vlifesb'. Error is 12541.
強制日誌切換。
SQL> alter system switch logfile;
System altered
SQL> alter system switch logfile;
System altered
SQL> alter system switch logfile;
System altered
SQL> select * from v$archive_dest_status;
DEST_ID DEST_NAME STATUS TYPE DATABASE_MODE RECOVERY_MODE PROTECTION_MODE DESTINATION STANDBY_LOGFILE_COUNT STANDBY_LOGFILE_ACTIVE ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# ERROR SRL DB_UNIQUE_NAME SYNCHRONIZATION_STATUS SYNCHRONIZED GAP_STATUS
---------- -------------------- --------- -------------- --------------- ----------------------- -------------------- -------------------------------------------------------------------------------- --------------------- ---------------------- ---------------- ------------- --------------- ------------ -------------------------------------------------------------------------------- --- ------------------------------ ---------------------- ------------ ------------------------
1 LOG_ARCHIVE_DEST_1 VALID LOCAL OPEN IDLE MAXIMUM PERFORMANCE /u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch 0 0 1 85 0 0 NO NONE CHECK CONFIGURATION NO
2 LOG_ARCHIVE_DEST_2 ERROR PHYSICAL OPEN_READ-ONLY IDLE RESYNCHRONIZATION vlifesb 3 0 1 82 1 82 ORA-12541: TNS: ???à?????ò YES vlifesb CHECK CONNECTIVITY NO RESOLVABLE GAP
SQL> select recid, name, sequence# from v$archived_log where sequence#>82;
RECID NAME SEQUENCE#
---------- -------------------------------------------------------------------------------- ----------
108 vlifesb 83
109 /u01/app/oracle/fast_recovery_area/VLIFE/archivelog/2015_10_21/o1_mf_1_83_c2ghkz 83
110 /u01/app/oracle/fast_recovery_area/VLIFE/archivelog/2015_10_21/o1_mf_1_84_c2ghl0 84
111 /u01/app/oracle/fast_recovery_area/VLIFE/archivelog/2015_10_21/o1_mf_1_85_c2ghl4 85
而standby端,歸檔日誌就沒有傳輸到。
SQL> select recid, name, sequence# from v$archived_log where sequence#>82;
RECID NAME SEQUENCE#
---------- -------------------------------------------------------------------------------- ----------
79 /u01/app/oracle/fast_recovery_area/VLIFESB/archivelog/2015_10_21/o1_mf_1_83_c2gh 83
SQL> select group#, dbid, archived from v$standby_log;
GROUP# DBID ARCHIVED
---------- ---------------------------------------- --------
4 UNASSIGNED NO
5 UNASSIGNED NO
6 UNASSIGNED YES
此時,Primary和Standby的連線明顯被中斷,日誌不能傳送,也就達不到同步確認的設定要求。但是此時,Primary還是可以進行事務操作。
(事務可以進行)
SQL> insert into t_m select * from dba_objects where rownum<10;
9 rows inserted
SQL> commit;
Commit complete
此時,如果恢復兩者連線,啟動監聽器和日誌應用。
[[email protected] ~]$ lsnrctl start
LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 21-OCT-2015 15:51:46
Copyright (c) 1991, 2013, Oracle. All rights reserved.
Starting /u01/app/oracle/product/11.2.0/dbhome_1/bin/tnslsnr: please wait...
TNSLSNR for Linux: Version 11.2.0.4.0 - Production
System parameter file is /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
Log messages written to
(篇幅原因,有省略…….)
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered
之後主庫和從庫日誌上進行歸檔日誌傳輸和後續同步動作,篇幅原因,日誌資訊省略。
從上面實驗中,我們可以看到最大可用性模式的核心即使“可用”。所謂可用,即使保證Primary和Standby整體的可用。如果在日誌傳輸通路順暢,兩者之間會維持嚴格的同步關係,行為類似於最大保護模式。但是,如果連線或者同步動作不能滿足要求,DG是不會終止例項執行,而是退而求其次,進行一種類似最大效能模式的工作方式。
相關推薦
聊聊Dataguard的三種保護模式實驗(上)
保護模式(Protection Mode),分別為:最大保護(Maximum Protection)、最大可用(Maximum Availability)和最大效能(Maximum performance)。在實際應用場景下,我們需要根據不同的業務場景和資料可用性需求,來設定
聊聊Dataguard的三種保護模式實驗
http://blog.itpub.net/17203031/viewspace-1821550/ Data Guard是Oracle高可用性HA的重要解決方案。針對不同的系統保護需求,DG提供了三種不同型別的保護模式(Protection Mode),分別
dataguard 三種保護模式
1、最大保護 這種保護模式在主庫出現問題時不會有資料的丟失,為了提供這種保護模式,一個事物必須同時寫本地的online redo log,和至少一個備庫的redo log同步,才能commit; 為了確保資料不會丟失,如果備庫至少有一個日誌不能寫入,
vmware三種網路模式配置(轉載)
虛擬機器系統安裝的是Linux系統 首先,在本機上檢視所有網路配置連線,使用命令:ipconfig Microsoft Windows [版本 6.1.7600]版權所有 (c) 2009 Microsoft Corporation。保留所有權利。 C:\Users\Administrator>ip
探索Oracle11gR2 之 DataGuard_03 三種保護模式
探索Oracle11gR2 之 DataGuard_03 三種保護模式 作者:吳偉龍 Oracle的DataGuard技術有三種實現模式,分別是max performance、max availability、maxprotection這三種模式。 以下是來自Or
23種設計模式介紹(一)---- 創建型模式
接口 ret static 深復制 return 對象 相互 object c png 由於設計模式篇幅比較大,如果在一篇文章講完所有的設計模式的話不利於閱讀。於是我把它分為三篇文章 23種設計模式介紹(一)---- 創建型模式 23種設計模式介紹(二)---- 結構型模
java23種設計模式3(轉)
訂閱 esp 兩個類 叠代器 請求 是個 plus 集合類 統一 本章是關於設計模式的最後一講,會講到第三種設計模式——行為型模式,共11種:策略模式、模板方法模式、觀察者模式、叠代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。
java23種設計模式2(轉)
是把 希望 sources 23種設計模式 接口 聯系 適合 () 創建 我們接著討論設計模式,上篇文章我講完了5種創建型模式,這章開始,我將講下7種結構型模式:適配器模式、裝飾模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。其中對象的適配器模式是各種模式的起源,我
億級PV請求的三種負載均衡技術(轉)
直接 轉發 指向 nfs admin ip地址 cnblogs 當前 求和 http://www.360doc.com/content/17/1126/23/50145453_707419125.shtml 目錄 DNS輪詢 LVS負載均衡 DR模式 NAT
原生js三種選項卡效果(滑動)
window solid nts html opacity ont cor rip show 第二種:鼠標移入切換效果實現 <!DOCTYPE html> <html> <head> <meta charset
python全棧開發基礎【第二十一篇】互斥鎖以及進程之間的三種通信方式(IPC)以及生產者個消費者模型
ipc 例子 清空 ase 多個進程 art 並且 star als 一、互斥鎖 進程之間數據隔離,但是共享一套文件系統,因而可以通過文件來實現進程直接的通信,但問題是必須自己加鎖處理。 註意:加鎖的目的是為了保證多個進程修改同一塊數據時,同一時間只能有一個修改,即串行的修
23種設計模式介紹(二)---- 結構型模式
implement weight 代碼 介紹 定義 裝飾器模式 大量 技術分享 記憶 由於設計模式篇幅比較大,如果在一篇文章講完所有的設計模式的話不利於閱讀。於是我把它分為三篇文章 23種設計模式介紹(一)---- 創建型模式 23種設計模式介紹(二)---- 結構
Python selenium —— 一定要會用selenium的等待,三種等待方式解讀(轉)
我們 嚴重 -s ber 約定 fire locate ror nbsp 發現太多人不會用等待了,博主今天實在是忍不住要給大家講講等待的必要性。 很多人在群裏問,這個下拉框定位不到、那個彈出框定位不到…各種定位不到,其實大多數情況下就是兩種問題:1 有frame,2 沒有加
json的三種反序列方式(轉載)
JSON(JavaScript Object Notation),在實際的開發中非常常用,甚至一個json就可以儲存所有需要的信心呢。 物件:一個物件以花括號"{"開始,並以"}"結束,json儲存使用key:value形式,每一個鍵後 有一個冒號
23種設計模式之(六)代理模式(python_c++實現)
23種設計模式之(六)代理模式(Proxy) 本文主要介紹23種設計模式之原型模式,附詳細python/c++示例程式碼。 - 概念 - 應用場景 - 注意事項 - 程式碼示例 - 總結 - 程式碼連結 代理模式(Proxy) 概念
23種設計模式之(九)裝飾模式(python_c++實現)
23種設計模式之(九)組合模式(Composite) 本文主要介紹23種設計模式之組合模式,附詳細python/c++示例程式碼。 - 概念 - 應用場景 - 注意事項 - 程式碼示例 - 總結 - 程式碼連結 組合模式(Composit
23種設計模式之(十)橋接模式(python_c++實現)
23種設計模式之(十)橋接模式(Bridge) 本文主要介紹23種設計模式之組合模式,附詳細python/c++示例程式碼。 - 概念 - 應用場景 - 注意事項 - 程式碼示例 - 總結 - 程式碼連結 橋接模式(Bridge)
23種設計模式之(十三)模板模式(python_c++實現)
23種設計模式之(十三)模板模式(TemplateMethod) 本文主要介紹23種設計模式之模板模式,附詳細python/c++示例程式碼。 - 概念 - 應用場景 - 注意事項 - 程式碼示例 - 總結 - 程式碼連結 模板模式(Te
Spring學習之Spring三種裝配機制:(二)顯示裝配bean
今天我們介紹一下Spring三種裝配機制中的另外兩種裝配方式:JavaConfig和XML配置,這兩種方式區別於自動化裝配方式都屬於顯示裝配。 1、Java程式碼裝配bean 首先,我們通過在Config類中使用@Bean註解來宣告bean; @Bean註
java23種設計模式-門面(外觀)模式
定義 外觀模式為子系統的一組介面提供一個一致的介面,此模式定義了一個高層介面,這個介面使得這一子系統更加容易使用。 UML 角色 子系統(SubSystem): 表示一個系統的子系統或者模組 門面(Facade): 客戶端通過門面間接控制子系統。門面遮蔽