Dubbo Cluster叢集那點你不知道的事。
這是why技術的第33篇原創文章
本週是在家辦公的一週,上面的圖就是我在家的工位。
工欲善其事,必先利其器。在家辦公,我是認真的。
在家裡開發的時候有需求是這樣的:一個如果介面呼叫失敗,需要自動進行重試。
雖然關係不大,但是我還是想到了Dubbo的叢集容錯策略:Failover Cluster,即失敗自動切換。
(這個轉折是不是有點生硬.......)
所以借本文對於Dubbo的Cluster叢集和Failover Cluster(失敗自動切換)策略進行一個詳細分析。
本文如果沒有特別說明的地方,原始碼均是來自最新的2.7.5版本。
在閱讀之前先丟擲幾個問題:
1.Dubbo Cluster叢集的作用是什麼?
2.Dubbo Cluster的10個實現類你能說出來幾個,其中哪幾個是叢集容錯的方法實現?
3.預設的叢集實現類是什麼呢?
4.Failover Cluster呼叫失敗之後,會自動進行幾次重試呢?
5.什麼是Dubbo的粘滯連線?
6.粘滯連線在Cluster中是怎麼應用的?
7.Cluster選擇出一個可用的Invoker最多要進行幾次選擇?
8.請問幾次選擇分別是什麼?
注意:上面的8個問題,前3個是非常常見的面試題。後面的都是你閱讀完本文後就可以知道問題的答案,面試中並不常見,但是後面的問題可以綜合成一個非常高頻的面試題:有看過什麼原始碼嗎,能給我講講嗎?
本文會對上面的問題進行逐一的、詳細的解讀。文章的最後會進行一個問題和答案的彙總。
廢話不多說,看完之後覺得不錯,還求個關注。抱拳了,老鐵。
Dubbo Cluster叢集的作用是什麼?
在生產環境,我們常常是多個伺服器跑相同的應用,這種做的目的其一是為了避免單點故障。
為了避免單點故障,現在的應用通常至少會部署在兩臺伺服器上。而對於一些負載比較高的服務,比如閘道器服務,會部署更多的伺服器。
這樣,在同一環境下的服務提供者數量會大於1。對於服務消費者來說,同一環境下出現了多個服務提供者。
這時會出現幾個問題:對於一次請求,我作為消費者到底呼叫哪個提供者呢?服務呼叫失敗的時候我怎麼做呢?是重試?是丟擲異常?或者僅僅是打印出異常?
為了處理這些問題,Dubbo定義了叢集介面Cluster以及Cluster Invoker。
叢集Cluster的用途是將多個服務提供者合併為一個Cluster Invoker,並將這個Invoker暴露給服務消費者。
這樣的好處就是對服務消費者來說,只需通過這個Cluster Invoker進行遠端呼叫即可,至於具體呼叫哪個服務提供者,以及呼叫失敗後如何處理等問題,現在都交給叢集模組去處理。
叢集模組是服務提供者和服務消費者的中間層,為服務消費者遮蔽了服務提供者的情況,這樣服務消費者就可以專心處理遠端呼叫相關事宜。比如發請求,接受服務提供者返回的資料等。這就是Dubbo Cluster叢集的作用。
Dubbo Cluster的10個實現類是什麼?
根據配置可以知道Dubbo叢集介面Cluster有10種實現方法如下:
需要注意的是,十種實現方法其中只有failover、failfast、failsafe、failback、forking、broadcast這6種才屬於叢集容錯的範疇。另外的實現均有其他的應用場景。
下面我們先說6種叢集容錯的實現方法:
Failover Cluster:
failover=org.apache.dubbo.rpc.cluster.support.FailoverCluster
失敗自動切換,在呼叫失敗時,失敗自動切換,當出現失敗,重試其它伺服器。通常用於讀操作,但重試會帶來更長延遲。可通過retries="2"來設定重試次數(不含第一次)。
Failfast Cluster:
failfast=org.apache.dubbo.rpc.cluster.support.FailfastCluster
快速失敗,只發起一次呼叫,失敗立即報錯。通常用於非冪等性的寫操作,比如新增記錄。
Failsafe Cluster:
failsafe=org.apache.dubbo.rpc.cluster.support.FailsafeCluster
失敗安全,出現異常時,直接忽略。通常用於寫入審計日誌等操作。
Failback Cluster:
failback=org.apache.dubbo.rpc.cluster.support.FailbackCluster
失敗自動恢復,後臺記錄失敗請求,定時重發。通常用於訊息通知操作。
Forking Cluster:
forking=org.apache.dubbo.rpc.cluster.support.ForkingCluster
並行呼叫多個伺服器,只要一個成功即返回。通常用於實時性要求較高的讀操作,但需要浪費更多服務資源。可通過 forks="2" 來設定最大並行數。
Broadcast Cluster:
broadcast=org.apache.dubbo.rpc.cluster.support.BroadcastCluster
廣播呼叫所有提供者,逐個呼叫,任意一臺報錯則報錯。通常用於通知所有提供者更新快取或日誌等本地資源資訊。
所以對於這個問題你也可以回答上來了:10個實現類中有哪幾個是叢集容錯的方法實現?
接下來再說說另外四個實現類:
Available Cluster:
available=org.apache.dubbo.rpc.cluster.support.AvailableCluster
獲取可用的服務方。遍歷所有Invokers通過invoker.isAvalible判斷服務端是否活著,只要一個有為true,直接呼叫返回,不管成不成功。
Mergeable Cluster:
mergeable=org.apache.dubbo.rpc.cluster.support.MergeableCluster
分組聚合,將叢集中的呼叫結果聚合起來,然後再返回結果。比如選單服務,介面一樣,但有多種實現,用group區分,現在消費方需從每種group中呼叫一次返回結果,合併結果返回,這樣就可以實現聚合選單項。
Mock Cluster:
mock=org.apache.dubbo.rpc.cluster.support.wrapper.MockClusterWrapper
本地偽裝,通常用於服務降級,比如某驗權服務,當服務提供方全部掛掉後,客戶端不丟擲異常,而是通過 Mock 資料返回授權失敗。
zone-aware Cluster:
zone-aware=org.apache.dubbo.rpc.cluster.support.registry.ZoneAwareCluster
上面的幾種Cluster策略在官網都能找到對應的說明,但是對於這個zone-aware目前官網上是沒有介紹的,因為這是前段時間釋出的2.7.5版本才支援的內容,如下圖所示:
所以對於zone-aware這個策略我多說兩句。具體可以參照下面的這個issue: https://github.com/apache/dubbo/issues/5399
zone-aware的應用場景是下面這樣的。
業務部署假設是雙註冊中心:
則對應消費端,先在註冊中心間選擇,再到選定的註冊中心選址:
所以,和之前相比,在Dubbo 2.7.5以後,對於多註冊中心訂閱的場景,選址時的多了一層註冊中心叢集間的負載均衡。
這個註冊中心叢集間的負載均衡的實現就是:zone-aware Cluster。
對於多註冊中心間的選址策略,根據類上的註釋可以看出,目前設計的有下面四種:
1.指定優先順序:
來自preferred="true"註冊中心的地址將被優先選擇,只有該中心無可用地址時才Fallback到其他註冊中心
<dubbo:registry address="zookeeper://${zookeeper.address1}" preferred="true" />
2.同 zone 優先:
選址時會和流量中的zone key做匹配,流量會優先派發到相同zone的地址
<dubbo:registry address="zookeeper://${zookeeper.address1}" zone="beijing" />
3.權重輪詢:
來自北京和上海叢集的地址,將以10:1的比例來分配流量
<dubbo:registry id="beijing" address="zookeeper://${zookeeper.address1}" weight="100" />
<dubbo:registry id="shanghai" address="zookeeper://${zookeeper.address2}" weight="10" />
4.預設方法:
選擇第一個可用的即可。
預設的叢集方法是什麼呢?
原始碼之下無祕密。我們從原始碼中尋找答案:
首先我們可以看到,Cluster是一個SPI介面。其預設實現是FailoverCluster.NAME,如下原始碼所示:
所以預設的實現方法就是:
org.apache.dubbo.rpc.cluster.support.FailoverClusterInvoker
由於Cluster是一個SPI介面,所以我們也可以根據實際需求去擴充套件自己的實現類。
FailoverCluster doInvoke原始碼解析
接下來我們就對FailoverClusterInvoker的doInvoke方法的原始碼進行解析。
這一小節主要回答這一個問題:Failover Cluster呼叫失敗之後,會自動切換Invoker進行幾次重試呢?
通過原始碼,我們可以知道預設的重試次數是2次。
有人就問了:為什麼第61行的最後還有一個"+1"呢?
你想一想。我們想要在介面呼叫失敗後,重試n次,這個n就是DEFAULT_RETRIES,預設為2。那麼我們總的呼叫次數就是n+1次了。所以這個"+1"是這樣來的,很小的一個點。
另外圖中標記了紅色五角星★的地方,第62到64行。也是很關鍵的地方。對於retries引數,在官網上的描述是這樣的:
不需要重試請設為0。我們前面分析了,當設定為0的時候,只會呼叫一次。
但是我也看見過retries配置為"-1"的。-1+1=0。呼叫0次明顯是一個錯誤的含義。但是程式也正常執行,且只調用一次。
這就是標記了紅色五角星★的地方的功勞了。防禦性程式設計。哪怕你設定為-10086也只會呼叫一次。
接下來對doInvoke方法進行一個全面的解讀,下面是2.7.5版本的原始碼,我基本上每一行主要的程式碼都加了註釋,可以點開大圖檢視: org.apache.dubbo.rpc.cluster.support.FailoverClusterInvoker#doInvoke
如上所示,FailoverClusterInvoker的doInvoke方法主要的工作流程是:
首先是獲取重試次數,然後根據重試次數進行迴圈呼叫,在迴圈體內,如果失敗,則進行重試。
在迴圈體內,首先是呼叫父類AbstractClusterInvoker的select方法,通過負載均衡元件選擇一個Invoker,然後再通過這個Invoker的invoke方法進行遠端呼叫。如果失敗了,記錄下異常,並進行重試。
注意一個細節:在進行重試前,重新獲取最新的invoker集合,這樣做的好處是,如果在重試的過程中某個服務掛了,可以通過呼叫list方法可以保證copyInvokers是最新的可用的invoker列表。
整個流程大致如此,不是很難理解。
什麼是Dubbo的粘滯連線?
接下來我們要看的是父類AbstractClusterInvoker的select方法的邏輯。但是在看select方法的邏輯之前,我必須得先鋪墊一下Dubbo粘滯連線特性的知識。
官網上的解釋是這樣的:
可以看出,這是一個服務治理型別的引數。當設定true時,該介面上的所有方法使用同一個provider。官方文件中說明可以用在介面和方法級別。
這些都是一些比較簡單的服務治理的規則。如果需求更復雜,則需要使用路由功能。
官方文件已經說的很清楚了。我就只簡單的解釋一下第一句話:粘滯連線用於有狀態服務。
那麼什麼是有狀態服務,什麼又是無狀態服務呢?
根據我簡單的理解。對服務提供者來說,究竟是有狀態的服務提供者,還是無狀態服務,其判斷依據就一句話: 從客戶端發起的兩個或者多個請求,在服務端是否具備上下文關係。
舉個例子,我們經常會用到的session。
眾所周知,HTTP協議是無狀態的。那麼當在一個電商場景下,將使用者挑選的商品放到購物車,儲存到session裡,當付款的時候,再從購物車裡取出商品資訊。這樣通過session就實現了有狀態的服務。
當一個服務被設計為無狀態的時候,對於客戶端來說,可以隨意呼叫。所以無狀態的服務可以很容易的進行水平擴容。
當一個服務被設計為有狀態的時候,想要水平擴容的時候就不是那麼簡單了。因為客戶端和服務端存在著上下文關係,所以客戶端每次都需要請求那一臺服務端。
把一個有狀態的服務修改為無狀態的服務的方案也很簡單。還是拿session舉例,這個時候,我們的分散式session就呼之欲出了。把session集中儲存起來,比如放到redis中,弄一個獨立於服務的session共享層。這樣,一個有狀態的服務就可以變為一個無狀態的服務。
AbstractClusterInvoker select原始碼解析
看完這一小節,你也就知道了粘滯連線在Cluster中是怎麼應用的了。
有了粘滯連線的知識儲備後,再看select方法就比較輕鬆了,首先需要知道的是select方法是一個關鍵的公共方法,其作用就是選擇出一個可用的invoke,有下面這幾個Cluster的實現類都在呼叫:
程式碼片段不長,邏輯也比較清楚,具體程式碼解析如下:
根據程式碼畫出select方法的流程圖如下:
結合程式碼和流程圖,再進行一個文字描述。
先介紹一下select的四個入參,分別是:
loanbalance:負載均衡策略。
invocation:它持有呼叫過程中的變數,比如方法名,引數等。
invokers:這裡的invokers列表可以看做是存活著的服務提供者列表。
selected:已經被選擇過的invoker集合。
通過原始碼我們可以看出,select方法的主要邏輯集中在了對粘滯連線特性的支援上。
首先是獲取sticky配置,然後再檢測invokers列表中是否包含 stickyInvoker,如果不包含,則認為該stickyInvoker不可用,此時將其置空。
為什麼可以置空?
因為這裡的invokers列表是存活著的服務提供者列表,如果這個列表不包含stickyInvoker,那自然而然的認為stickyInvoker掛了,所以置空。
接下來,如果stickyInvoker存在於invokers列表中,說明stickyInvoker還活著,此時要進行下一項檢測。檢測selected(選擇過的服務提供者列表)中是否包含 stickyInvoker。
如果包含的話,說明stickyInvoker在此之前沒有成功提供服務(但其仍然處於存活狀態)。此時我們認為這個服務不可靠,不應該在重試期間內再次被呼叫,因此這個時候不會返回該stickyInvoker。
如果selected不包含stickyInvoker,此時還需要進行可用性檢測,比如檢測服務提供者網路連通性等。當可用性檢測通過,才可返回 stickyInvoker,否則呼叫doSelect方法選擇Invoker。
如果sticky為true,此時會將doSelect方法選出的Invoker賦值給stickyInvoker。
關於粘滯連線和可用性檢測的預設配置如下:
即預設情況下粘滯連線是關閉狀態。當粘滯連線開啟時,預設會進行可用性檢查。
關於select方法先分析這麼多,繼續向下分析。
AbstractClusterInvoker doSelect原始碼解析
讀完這一小節你可以回答出這兩個問題:
1.Cluster選擇出一個可用的Invoker最多要進行幾次選擇?
2.請問幾次選擇分別是什麼?
doSelect方法的原始碼解析如下:
Failover Cluster選擇出一個可用的Invoker最多要進行三次選擇,也是doSelect的主要邏輯,三次分別是(圖中標號了①②③的地方):
①:通過負載均衡元件選擇 Invoker。
②:如果選出來的 Invoker 不穩定,或不可用,此時需要呼叫reselect 方法進行重選。
③:reselect選出來的Invoker為空,此時定位invoker在invokers列表中的位置index,然後獲取index+1處的 invoker。
AbstractClusterInvoker reselect原始碼解析
下面我們來看一下 reselect 方法的邏輯。
根據原始碼做出流程圖如下:
所以,reselect方法總結下來其實做了四件事情:
第一:查詢可用的invoker,並將其新增到reselectInvokers集合中。這個reselectInvokers集合你可以理解為裡面放的是所有的可用的invoker的集合與selected集合的差集。
第二:如果經過篩選後,reselectInvokers不為空,則通過負載均衡元件再次進行選擇並返回。
第三:如果經過篩選後,reselectInvokers為空,則再從selected集合(已經被呼叫過的集合)中選出所有可用的invoker,放到reselectInvokers中,再次通過負載均衡元件進行選擇並返回。
第四:如果進過上面的步驟後,沒有選擇出合適的invoker,reselectInvokers還是為空,說明所有的invoker都不可用了,返回為null。
好了,到這裡就把最開始丟擲的8個問題都解答完畢了,接下來對問題、答案進行一個彙總。
問題、答案彙總
1.Dubbo Cluster叢集的作用是什麼?
簡單來說:叢集模組是服務提供者和服務消費者的中間層,為服務消費者遮蔽了服務提供者的情況,這樣服務消費者就可以專心處理遠端呼叫相關事宜。比如發請求,接受服務提供者返回的資料等。這就是Dubbo Cluster叢集的作用。
2.Dubbo Cluster的10個實現類你能說出來幾個,其中哪幾個是叢集容錯的方法實現?
根據配置可以知道Dubbo叢集介面Cluster有10種實現方法如下:
其中failover、failfast、failsafe、failback、forking、broadcast這6種才屬於叢集容錯的範疇。另外的實現均有其他的應用場景。還需要注意的是zone-aware是2.7.5版本後才支援的實現類,之前是registryaware。
3.預設的叢集實現類是什麼呢?
失敗自動切換: org.apache.dubbo.rpc.cluster.support.FailoverClusterInvoker
4.Failover Cluster呼叫失敗之後,會自動切換Invoker進行幾次重試呢?
自動進行2次重試,共計呼叫3次。
5.什麼是Dubbo的粘滯連線?
粘滯連線用於有狀態服務,儘可能讓客戶端總是向同一提供者發起呼叫,除非該提供者掛了,再連另一臺。粘滯連線將自動開啟延遲連線,以減少長連線數。
6.粘滯連線在Cluster中是怎麼應用的?
參照AbstractClusterInvoker select原始碼解析。select方法的主要邏輯集中在了對粘滯連線特性的支援上。
7.Cluster選擇出一個可用的Invoker最多要進行幾次選擇?
最多進行三次選擇。
8.請問幾次選擇分別是什麼?
①:通過負載均衡元件選擇 Invoker。 ②:如果選出來的 Invoker 不穩定,或不可用,此時需要呼叫reselect 方法進行重選。 ③:reselect選出來的Invoker為空,此時定位invoker在invokers列表中的位置index,然後獲取index+1處的 invoker。
最後說一句(求個關注)
之前也寫過幾篇Dubbo相關的文章,有興趣的可以看一看:
《Dubbo 2.7.5線上程模型上的優化》
《快速失敗機制&失敗安全機制》
《夠強!一行程式碼就修復了我提的Dubbo的Bug。》
《Dubbo加權輪詢負載均衡的原始碼和Bug,瞭解一下?》
《Dubbo一致性雜湊負載均衡的原始碼和Bug,瞭解一下?》
《一文講透Dubbo負載均衡之最小活躍數演算法》
《參加Dubbo社群開發者日成都站後,帶給我的一點思考。》
《Dubbo 2.7新特性之非同步化改造》
才疏學淺,難免會有紕漏,如果你發現了錯誤的地方,還請你留言給我指出來,我對其加以修改。
感謝您的閱讀,原創不易,求個關注.
以上。
歡迎關注公眾號【why技術】,堅持輸出原創。願你我共同進步。
相關推薦
Dubbo Cluster叢集那點你不知道的事。
這是why技術的第33篇原創文章 本週是在家辦公的一週,上面的圖就是我在家的工位。 工欲善其事,必先利其器。在家辦公,我是認真的。 在家裡開發的時候有需求是這樣的:一個如果介面呼叫失敗,需要自動進行重試。 雖然關係不大,但是我還是想到了Dubbo的叢集容錯策略:Failover Cluster,即失敗自動
凌晨3點了作為程式設計師需求還沒思路?那是你不會這項技能!
同學們,你們知道學習程式設計最重要的是什麼嗎?沒錯,就是實踐。實踐的過程無外乎:寫程式碼,看別人寫的程式碼,然後在寫程式碼。 拿到需求,是不是總沒有思路,凌晨3點了還在電腦前發呆?那就去看別人寫的程式碼吧。 看別人寫程式碼可以讓我們吸收前輩的經驗,找到程式設計的思路,站在巨人的肩膀上,開啟自
如果你不知道做什麼,那就學一門雜學吧
多年以後,面對人工智慧研究員那混亂不堪的程式碼,我會想起第一次和 S 君相見的那個遙遠的下午。那時的 B 公司,還是一個僅有 6 個人的小團隊,Mac 和顯示器在桌上依次排開,大家坐在一起,不需要稱呼姓名,轉過臉去,對方就知道你在和他說話。一切看起來都那麼美好,我們所有人,都
Alibaba Cluster Data 開放下載:270 GB 資料揭祕你不知道的阿里巴巴資料中心
開啟一篇篇 IT 技術文章,你總能夠看到“大規模”、“海量請求”這些字眼。如今,這些功能強大的網際網路應用,都執行在大規模資料中心上。然而,對於大規模資料中心,你又瞭解多少呢?實際上,除了閱讀一些科技文章之外,得到關於資料中心的資訊非常難得。資料中心每個機器的執行情況如何?這些機器上執行著什麼樣的應用?這些應
Alibaba Cluster Data 開源:270GB 資料揭祕你不知道的阿里巴巴資料中心
開啟一篇篇 IT 技術文章,你總能夠看到“大規模”、“海量請求”這些字眼。如今,這些功能強大的網際網路應用,都執行在大規模資料中心上,然而,對於大規模資料中心,你又瞭解多少呢?實際上,除了閱讀一些科技文章之外,你很難得到更多關於資料中心的資訊。資料中心每個機器的執行情況如何?這些機器上執行著什麼樣的
Alibaba Cluster Data 開放下載:270GB 資料揭祕你不知道的阿里巴巴資料中心
開啟一篇篇 IT 技術文章,你總能夠看到“大規模”、“海量請求”這些字眼。如今,這些功能強大的網際網路應用,都執行在大規模資料中心上,然而,對於大規模資料中心,你又瞭解多少呢?實際上,除了閱讀一些科技文章之外,你很難得到更多關於資料中心的資訊。資料中心每個機器的執行情況如何?這些機器上執行著什麼樣的
你不知道的SVD 演算法------點雲配準+絕對定向+座標轉換
Sfm那篇部落格已經介紹,3D-3D的變換,不同學科稱呼不同。 在測繪領域,稱作為座標轉換,即七引數轉換—(3個旋轉,3個平移,1個尺度),通常尺度因子可以不計。最常見的情景諸如,54座標到80座標,80到CGS200座標等。 在攝影測量學科裡,稱為絕對定向
深入JDK源碼,這裏總有你不知道的知識點!
方法 int com 運行時異常 form 成對 adl 拷貝 般的 Java的基礎知識有很多,但是我認為最基礎的知識應該要屬jdk的基礎代碼,jdk的基礎代碼裏面,有分了很多基礎模塊,其中又屬jdk包下面的lang包最為基礎。 我們下面將總結和分析一下lang包下面最為基
1.一男子在路邊一根接著一根地抽煙。一個女士走過來對他說:“嘿,你不知道你是在慢性自殺嗎?註意看看煙盒上的警告信息。”“沒關系”, 男子悠然自得地又吸了一口:“我是個程序員。”“嗯?這和你是程序員有什麽關系?...
我不知道 不知道 對他 上網 是我 .com 一個 但是 err 1.一男子在路邊一根接著一根地抽煙。一個女士走過來對他說:“嘿,你不知道你是在慢性自殺嗎?註意看看煙盒上的警告信息。”“沒關系”,男子悠然自得地又吸了一口:“我是個程序員。”“嗯?這和你是程序員有什麽關系?”
【轉載】史上最全:TensorFlow 好玩的技術、應用和你不知道的黑科技
tube map 高性能 知識 seq 出現 執行時間 mes lex 【導讀】TensorFlow 在 2015 年年底一出現就受到了極大的關註,經過一年多的發展,已經成為了在機器學習、深度學習項目中最受歡迎的框架之一。自發布以來,TensorFlow 不斷在完善並增加新
你不知道的 flex 技巧
hacker https ems add init 實踐 事情 pwa 需要 一、使用 Auto Margins 對齊 不需要給圖片使用任何的 flex,也不需要給父容器設置 space-between,只需要給 ‘ BUY-BUY-BUY‘ 按鈕設置
你不知道的javaScript筆記(2)
是否 foreach 函數 嚴格模式 console spa new 簡單的 否則 this和對象原型 this是一個很特別的關鍵字,被自動定義在所有函數的作用域中 // foo.count 是0,字面理解是錯誤的 function foo(num) {
微信聊天記錄要怎麽恢復刪除的記錄?這一小妙招你不知道嗎
說到男人出軌,女人就有話要說了。相信絕大數女人聽到自己男人在外面有小三,一定是非常的暴跳如雷,電話不停的轟擊男人的手機,直到男人接聽為止。這事第一件事,獲得男人目前所在的具體位置。 那麽第二件事就是等男人回到家後拷問男人以及關於小三的事
你不知道的javaScript筆記(4)
作用域 能夠 max rip 指數 upper 是否 進制 spa 類型: JavaScript 有7種內置類型 空值 (null) 未定義(undefined) 布爾值(boolean) 數字(number) 字符串(string) 對象(object)
或許你不知道的10條SQL技巧
提高效率 經驗 查詢 中國 nbsp 結果集 復雜 移動 前綴 這幾天在寫索引,想到一些有意思的TIPS,希望大家有收獲。 一、一些常見的SQL實踐 (1)負向條件查詢不能使用索引 select * from order where status!=0 and st
你不知道的JavaScript學習筆記1——作用域
模式 引用 語法分析 訪問 要素 並不會 參數 嵌套 ron 處理程序三要素: 引擎:編譯與執行過程。 編譯器:語法分析與代碼生成等。 作用域:收集並維護由所有聲明的標識符(變量)組成的一系列查詢,並實施一套非常嚴格的規則,確定當前執行的代碼對這些標識符的訪問權限。 示
[肯定不知道]PeopleSoft中PSADMIN你不知道的秘密
相同 菜單 gty 隱藏 選項 更新 nds log hrn PeopleSoft psadmin工具是用於管理PS App server,process scheduler 和 web server節點的。可以使用一些設置菜單選項來管理或配置上面提到的任何組件。要是用任何
你不知道的Google Search
data- 手工 title swe 第一次 tro quest .exe 列表 0.導讀 這篇文章講了這三個事兒: 如何訪問Google?----------什麽?不是直接輸入地址麽?Google的地址是什麽?------ 你在逗我?難道不是w
你不知道網絡安全有多嚴峻
nat cti effective etc effect uil msbuild net 不知道 %E6%96%B0%E6%89%8B%E5%AE%89%E8%A3%85adt%E8%A3%85%E4%B8%8D%E4%BA%86%E6%B1%82%E5%8A%A9%21%
你不知道的javascript(中卷)筆記
沒有 light char 布爾值 都是 sin 執行 new 內容 <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>你不