系統性能排查方略及大型銀行MySQL性能管控

来源:https://www.cnblogs.com/88223100/archive/2023/01/12/System-performance-troubleshooting-strategy-and-MySQL-performance-control-of-large-banks.html
-Advertisement-
Play Games

一、系統性能問題五大特性 二、系統性能排查方略 三、MySQL開發規範和常見調優策略 四、MySQL性能管控體系 五、未來展望 ...


分享概要

一、系統性能問題五大特性

二、系統性能排查方略

三、MySQL開發規範和常見調優策略

四、MySQL性能管控體系

五、未來展望

 

一、系統性能問題五大特性

 

圖片

 

如果大家瞭解一些方法論的話,應該聽過兩個原則:一個是海恩法則,強調量變引發質變;另一個是老生常談的墨菲定律,強調會出錯的事總會出錯。針對這兩個原則,我總結了系統性能問題的五大特性。

 

1)系統響應慢

 

不論負載情況如何,系統應用程式一直特別慢,響應時間長。

 

2)時間序列日益緩慢

 

負載穩定,但系統隨著時間推進越來越慢,到達某個閾值後,系統可能會被鎖定或因大量錯誤出現而崩潰。

 

3)突發混亂

 

系統穩定運行,在某一時刻突然出現大量錯誤。

 

4)局部功能異常

 

用戶訪問部分頁面異常,上圖右下角圖片是用F12對訪問谷歌頁面進行的截圖,從中可以看出,我們訪問谷歌時一直超時,無法訪問。

 

5)隨負載變化越來越慢

 

用戶量增加時,系統明顯變慢,用戶離開系統後,系統恢複原狀。上圖左下角的圖片展示了CPU的使用情況,其從100%負載恢復到常態化,後續隨著用戶增加又逐漸漲至100%負載。

 

二、系統性能排查方略

 

1、系統性能排查方略方法論

 

圖片

 

系統性能排查方略可總結為以下兩點:

 

1)積極溝通,減小影響

 

  • 利用5W1H原則瞭解問題現象,即什麼問題、在什麼時間、什麼地點、如何發生、何人處理。同時還要收集現場信息,包括常見的日誌信息、流量信息等,儘量做到全面排查。

 

  • 安撫客戶,減小客戶影響。一件小事可能會由於客戶恐慌性的增長釀成大事故。

 

  • 基於歷史經驗緊急應急。

 

2)大膽推敲,合理論證

 

  • 根據異常信息要大膽推斷、合理論證,切忌“我推斷就是這樣,但我就不證明”;

 

  • 進行全鏈路考量,切忌單點揣測,比如直接認定資料庫有問題,但是經分析來看,資料庫負載實際上沒問題,而是網路問題或中間件問題;

 

  • 問題解決必須包含臨時方案和最終方案。用臨時方案以最快的方式消除影響,然後針對問題做最終方案,避免後續類似問題帶來的隱患。

 

為此,我通過魚骨圖進一步描述問題的排查方式:

 

1)消除影響

 

首先需要消除對客戶的影響,其次要消除對系統的影響,可以通過歷史經驗緊急應急或其他方式幫助客戶或系統避開問題。

 

2)收集現場

 

這一步強調日誌的完備,同時我們需要知道發生問題時的問題數據和系統數據,才可通過數據進行重演。

 

3)明確問題範圍

 

判斷發生的是個別交易問題還是普遍性問題。如果是個別交易問題,我們可以很快定位交易當時做過哪些改變;如果是普遍性問題,我們要判斷哪些客戶、客流受到影響,以及這一問題是否會對其他方面造成影響。

 

4)問題分析

 

問題分析包括兩個方面,一方面是系統級鏈路分析,從最早的端到端的鏈路進行統一排查;另一方面是交易級鏈路分析,從交易進來後經過中間件到資料庫返回,對整個交易級鏈路進行分析。

 

5)問題解決方案

 

經過之前的一系列步驟,最終我們就可以制定問題的解決方案。在制定解決方案時,一般會進行數據修複和程式修複,在環境中同步驗證,並將修改後的部分歸併至後續版本中,避免導致類似問題重覆發生。

 

6) 問題總結

 

這一步主要是針對問題進行復盤,從中發現優化點,並從問題的處理方式中總結經驗教訓,然後進行一些橫向排查,沉澱為相關經驗。

 

下麵向大家講述性能問題排查,其中包括兩大方面:系統環境和運行環境。

 

圖片

 

1)系統環境

 

我們原則上通過APM工具監控系統環境。業界已經有些很好的開源監控工具,比如Prometheus、Zabbix等,可以利用這些工具監測CPU負荷、lO負荷、記憶體負荷以及網路負荷。

 

2)運行環境

 

可以將運行環境的問題大致分為以下三類:

 

① 資料庫

 

  • 日誌信息

 

對於MySQL,首先查看其錯誤日誌,通過mysql.err直接查看當時到底有什麼問題;如果交易比較緩慢,可以從慢SQL日誌(一般是slow-queries.log)中查看,原則上大於10秒的交易都會在這裡體現;接下來看事務日誌,通過binlog查看當時交易的情況,如果是備庫重演的一些問題,可以看主備中繼日誌,通過relaylog查看備庫重演的狀態。

 

對於Oracle也大體相似,可以通過監聽日誌listener.log、lsnrctl status查看監聽器的狀態,Oracle中有一個報警日誌,通過alert.log可以查看當時發生的事件。我們還可以進一步打AWR報告和ASH報告,對資料庫進行監控,這一點MySQL不如Oracle。除此之外,Oracle也提供了一些歷史快照信息表,比如dba_hist_sqlstat和 dba_hist_snapshot,可以通過這兩張快照表獲取需要的任意快照時間的處理信息。最後,可以通過會話信息,查看當前會話有哪些中間件正在訪問,以及整個會話的狀態。

 

  • 性能分析

 

進行性能分析時,我們可以查看執行計劃。對於MySQL,我們可以通過explain語句看當時的執行計劃,到底有沒有走索引,索引走得好不好。對於Oracle,我們可以通過v$sql_plan和dba_hist _sql_plan查看執行計劃變更的原因,針對執行計劃對索引進行重建。除此之外,我們還要對死鎖進行分析,並處理等待事件。

 

② 中間件

 

對於中間件,例如業界使用較多的WAS、Liberty、Tomcat以及國產的東方通等,我們可以查看它的一些線程信息。這裡建議大家打出3~5個javacore,一般是1分鐘打一個,這樣可以通過IBM的jca4611.jar工具對比分析問題出於哪個線程,或者線程卡在何種情況之下。

 

如果涉及到OOM(記憶體溢出),可以打出heapdump的信息,再通過IBM的ha457.jar工具進行分析。

 

我們可以通過GC信息看是否因為伺服器full gc導致系統持續夯住,如果是,可以對vm信息進行調優。除此之外,中間件還會打一些日誌信息,可以從中發現當時發生的問題。最後可以監控一些中間件的資源信息,包括資料庫連接池、線程池和一些web容器。

 

③ 應用程式

 

若發現資料庫和中間件都沒有問題,我們再看應用程式。

 

對於前臺來說,我們看是不是因為它在前臺做了緩存,沒有實時刷新,因此導致新請求獲得老交易,最終出現問題。除此之外可以看請求連接數,瀏覽器的請求連接數實際上是有限的,請求連接數過大也會導致應用程式出問題。最後可以看一下是否因為資源過大導致網路傳輸量較大,這種問題可以通過兩種方式解決,一種是資源壓縮,另一種是將資源部署在CDN上。

 

對於邏輯層來說,我們可以看它有沒有資源釋放,包括資料庫連接、文件讀寫、socket、緩存等。然後可以看事務問題,比如事務長時間沒有結束,這樣會卡死很多線程信息,迴圈處理資料庫也會導致事務的持續時間較長。最後可以看多線程信息中是否包含鎖等待,是否存在數據污染。

 

綜上所述,系統性能排查有四個關鍵點:查看完備的日誌、利用良好的工具、執行計劃和關註邏輯問題。

 

接下來會對java中間件和資料庫性能兩部分進行詳細分析:

 

2、java中間件分析

 

圖片

 

1)通過jca分析javacore

 

我對比了4個javacore文件,發現大部分問題集中在無法獲取連接池,即連接池都已經被占滿且長時間沒有釋放,這時可以結合連接池情況快速定位問題。

 

2)分析oom對象

 

對於oom對象,上圖可以看出有一個情況是BankFunctionTypePool中,oom大約存了1G空間,換言之,已直接將jvm記憶體耗盡。這種情況下,一般建議heapdump加上javacore共同做分析,這樣可以快速定位問題。

 

3、資料庫相關問題分析

 

針對資料庫方面的問題,有如下分析流程。

 

圖片

 

一般出現問題場景後,首先通過日誌分析判斷是不是資料庫無法連接。

 

如果資料庫無法連接,就檢查監聽狀態。如果是Oracle,listener.log並沒有狀態的日誌記錄,可以檢查lsnrctl status,然後配置TNS,啟動監聽器,確保資料庫正常訪問。如果是MySQL,可以檢查mysql.err文件,發現其中有一個access denied報錯,這種情況下我們做好訪問授權並確認防火牆,之後資料庫就可以正常訪問。

 

如果資料庫可以連接,但是資料庫執行時間過長,這種情況下應該按照以下方法解決。

 

如果是Oracle,可以列印問題時刻的AWR報告,定位問題語句(一般關註Logons、Top 5 events、SQL order by Elapsed time等),然後處理問題。如需進一步查勘,可以列印ASH報告,查看歷史同期問題引進的變化情況,從而快速定位一些問題。如果是MySQL,一般檢查mysql.err的錯誤日誌,然後檢查slow-queries.log,如需進一步查勘,可以把performance_schema.events _statements_summary_by_digest表中的數據提取出來進行進一步查勘。

 

一般來說,資料庫相關問題可分為以下4種:

 

1)如果有死鎖,需要調整業務邏輯順序,進行壓測,然後驗證結束。

 

2)如果沒有死鎖,只是執行計劃有問題,例如出現一個全表掃,則在上面增加合適的索引處理。

 

3)如果有索引,需要判斷它的區分度:如果區分度高並且數據變動頻繁,需要更新統計信息;如果區分度低,就決定索引是否合適,如果不合適就重建索引,選擇合適的索引進行處理。

 

4)最後需要看數據量的大小,如果超過了規範的閾值,就要進行分庫分表以及分區策略。

 

我們將邏輯調整後,再進行相關壓測,當壓測滿意時驗證結束,真正上生產去做處理。

 

三、MySQL調優策略

 

1、索引

 

 

 

1)一般建議大家查看執行計劃,從我目前的分析來看,語句問題占90%以上;

 

2)命中索引並不等於ok;

 

3)執行計劃最少應該達到範圍掃,一般建議達到ref程度。

 

對於MySQL的執行計劃,有 id、select_type、table等列,其中我一般會關註表中的type,它表示訪問類型,決定了MySQL在表中找到所需要行的方式。

 

我在上圖右方列出了效率情況:

 

system (無需磁碟IO)> const > eq_ref > ref > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

 

接下來查看key還有key_len的值,使用索引的位元組長度越短越好,可以根據表定義大概計算出索引的最大可能長度,可用於複合索引的實際使用欄位情況。

 

之後查看rows,一般情況下建議rows值越小越好。其他例如filtered和Extra等也是比較關鍵的信息,這裡不再贅述,大家可以參考上圖中的表格。

 

2、分庫分表

 

圖片

 

針對分庫分表,首先要關註一個問題,單表數據量達到多少才需要進行分庫?

 

阿裡手冊中寫到數據量達到500萬進行分庫分表。業界的說法是數據量達到2,000萬進行分庫分表。其源頭是百度的一個DBA進行壓測後,覺得壓到2,000萬沒問題,但是超過2,000萬後性能會出現問題,所以業界流傳的數據量界限是2,000萬。

 

對於我行來說,MySQL規範建議數據量達3,000萬進行分庫分表。

 

MySQL索引分為兩種,一種是聚簇索引,即主鍵索引,索引和數據保持在一起。另一種是secondary Index,即輔助索引。

 

下麵簡單介紹一些基礎知識:

 

  • MySQL的表數據是以頁形式存放,預設16k,innodb_page_size值是16384,除以1024正好是16k。

 

  • 一般索引為B+樹,葉子存儲數據,非葉子存儲主鍵和指向頁號,一般是12byte,因為使用bigint會占8位元組,同時lot0types.h中源代碼有一個指針FIL_PAGE_OFFSET,占了4位元組,所以非葉子存儲大約存儲12位元組。

 

  • 數據頁數據僅有15k左右可以存儲數據,因為頁頭、頁目錄和頁尾也會占1k的空間。

 

  • B+樹扇出率較高,15k除以12byte,它每一個節點可以指向1280個葉子。B+樹一般的建議層級是2~4層,保證查找某一鍵值,最多2~4次IO即可。主鍵索引一般也都在3層左右。

 

  • 這裡還涉及到一個iops知識,因為大家之前用機械硬碟,一般進行一次io操作需要0.01秒,而現在大家普遍常見的SSD都是上萬的ops,MySQL的訪問效率比以前高很多。

 

針對以上基礎知識,作以下具體說明:

 

數據量=扇出值^(B+樹層數-1)*葉子節點存儲行數

 

例如我們行的行占用大小約為850Byte位元組,每個葉子節點可以存儲18行,數據量為2,900萬左右,這也是3,000萬的分庫分表界限的來源。百度行占用大小是1K,每個葉子節點存儲15行數據,數據量為2400萬左右,所以業界才有2,000萬這一說法。阿裡同理,經過計算強調數據量超過500萬進行分庫分表。

 

我們要瞭解規範數字背後的含義,這樣很多問題就會迎刃而解。除此之外,伺服器配置、資料庫版本等因素也會影響查詢速度。

 

3、鎖問題

 

 

 

MySQL官方對鎖有較詳細的介紹,一般常見類型是讀鎖和寫鎖。讀鎖包含兩種鎖:記錄鎖和間隙鎖。我行用READ-COMMITTED規避間隙鎖。

 

大家通過mysql.err看日誌表現,可以看到有lock_mode X和locks rec but not gap,這是記錄鎖的含義。

 

這裡需要關註以下兩點:

 

1)鎖競爭

 

5.7版本中我們從locks、locks_waits表查看鎖,但是8.0版本從infomation_spchema遷至performance_schema。下麵舉一個例子進行說明。

 

事務1是start transaction,更新同一個id=1的值,事務也對它進行更新,50秒後,它會拋一個1205錯誤,直接顯示鎖等待超時。我們建議一個鎖等待超時的時間是5~10秒,從而避免對事務造成較大影響。

 

2)死鎖檢測

 

圖片

 

死鎖檢測本質是哲學家的問題:2個及以上事務,雙方都在等待對方釋放已經持有的資源,最後造成等待迴圈,形成死鎖。

 

針對MySQL實現機制,大家看lock0lock.cc,它本質是進行深度優先機制,如果發現環,則認為是一個死鎖,同時回滾undo log量小的事務。

 

如果大家查看mysql.err,可以發現它第一步有一個deadlock detected,然後事務1會等待另外一個記錄鎖去釋放,事務2也會等待事務1的記錄鎖去釋放,最後因為事務2回滾量較小,所以回滾了事務2。

 

4、Google Trends & DB-Engines

 

圖片

 

MySQL和PostgreSQL這兩個資料庫都很好,但是對於我們國家來說,在Google Trends上MySQL的熱度更高一點,占比大概是89%,PostgreSQL占比是11%左右。我們搜索關鍵字時,最多的是怎麼編譯MySQL,這說明我國對源碼的掌握和編譯有較為熱切的需求。從DB-Engines Rank中可以看到MySQL和Oracle一直不相上下,PostgreSQL的熱度也在逐步上升。

 

四、MySQL性能管控體系

 

接下來分享我們行的性能管控體系。

 

圖片

 

“免費的午餐並不好吃”,隨著MySQL的廣泛應用,大家並不註意開發規範,這會導致慢SQL數量呈爆髮式增長。一條慢SQL就可以導致服務不可用,降低用戶幸福指數。我們為此構建管控體系確保開發合規和性能管控。

 

1、性能管控體系

 

1)研發流水線 (DevOps) +  QA定期檢查 (線下)

 

首先我們通過研發流水線(DevOos)和QA定期檢查對整個研發環節進行處理。具體可分為以下環節:

 

  • 設計環節

 

在設計環節,我們建立了設計指引,做了一些元數據管理,並設置了能力提升課程提升大家的資料庫使用能力。我們也會推動一些表結構設計工具和元數據管理系統,限定大家局面處理問題,同時我們在這一環節設置了門禁。

 

  • 開發環節

 

這一環節我們將一些規範做到自動化,包括SQL註入檢查和SQL寫法的規則。SonarQube有SonarLint插件可以做伺服器端的同步,這也有利於在開發環節做性能管控。

 

  • 測試環節

 

這一環節我們通過安全測試、性能測試和混沌測試進行性能管控。

 

  • 發佈環節

 

發佈環節會由我們的SRE發佈一些態勢感知報告,從技術以及安全等層面對業務提出針對性建議及後續整改措施。

 

  • 運營環節

 

在這一環節我們首先會進行慢SQL的監控治理,逐步減少大事務數據;大家可以看到上圖某部門有2個應用,慢SQL數量12個,最大耗時246秒,平均耗時11.414秒。

 

其次,我們會進行生產案例分析,將相關規則沉澱到知識庫,並將技術組件放入技術模型。除此之外,我們還會做一些AIOps根因分析。

 

最後我們會進行一些慢SQL的監控和查殺,將大事務提前扼殺,避免其對系統產生影響。

 

2)性能運維事件響應及溯源

 

我們會針對每一個問題反省並溯源,看到底是哪一環節出現問題,哪些環節可以進行優化。例如判斷:語句是否因為沒有限定時間範圍的存在需求缺失情況?設計功能是否考慮到大表關聯這種設計缺陷?開發環節是否存在代碼缺陷?

 

檢查開發環節後我們會檢查測試環節是否有測試用例缺失、測試工具漏報等缺陷,最後檢查發佈環節是否有發佈標準等缺陷。

 

3)能力沉澱

 

最後我們會進行能力沉澱,例如問題閉環追蹤、根因橫向排查,最後沉澱為知識庫、技術組件、度量模型。

 

2、MySQL開發規範

 

1)設計原則

 

圖片

 

在設計方面,我們有以下三大原則:

 

① 復用原則

 

在系統架構時,應考慮將相同或類似作用的信息使用同一套數據結構來存儲。例如:通用參數表、通用字典表。

 

② 前瞻性原則

 

  • 設計應基於完整的產品定義和業務要素,而非當前具體功能需求設計表結構;

     

  • 設計應基於完整的生命周期和業務流程設計表結構。如:事件類表,可以適當增加種類、狀態欄位以便後續擴展。

 

③ 元數據原則

 

  • 列名應遵循統一的數據標準,即同一類型欄位應對應同一個元數據;欄位類型和長度應相同,如同一產品線下所有表的機構編號應該對應同一個元數據;

     

  • 常用的欄位應建立應用級的標准定義,指明元數據,確定欄位命名。如所有表 的“最新維護時間”欄位都統一命名為last_modify_time,這樣能夠確保我們後續在資料庫挖掘以及做知識圖譜時,可以將整個鏈路串起來。

 

2)典型規範示例

 

圖片

 

① 操作:方法論

 

方法論是萬物之基石,例如每個表我們必須要建立一個主鍵,如果不顯示設置主鍵,會自動生成一個rowid(6 byte)作為隱藏主鍵,且所有表共用此空間,造成性能下降。

 

② 量化:精細化的理性思維

 

我們建議掃描命中比原則上應該是100:1,事物大小方面我們行的要求是10萬,業界一般一萬即可。

 

③ 避坑:規避 MySQL Bug

 

大表truncate改為drop + create table,這在5.7中效果非常明顯,但是在8.0中公司已經對其進行了修改優化。

 

針對以上規範,我們要讓開發人員潛移默化地知其然也知其所以然,避免出現一些問題。

 

3、質量門禁自動化

 

圖片

 

我們基於druid,擴展了Sonarqube插件,實現本地檢查規則和雲端雲同步。

 

我們之前大概定了27條規則,其中包含了常見的一些錯誤,例如有人在update語句的set關鍵字後面,誤將分隔符逗號(“,”)寫成“and”,導致出現預期之外的結果。

 

4、大事務查殺

 

圖片

 

大事務的相關問題主要有以下幾點:

 

  • binlog的寫入、傳輸、回放緩慢問題。之前我曾看到一個應用,備庫24小時都未完成回放,萬一主庫出問題,都沒辦法回切,只能等備庫處理完後再回切;

 

  • 交易寫入堵塞;

 

  • 在主庫故障博弈的情況下,到底切還是不切?

 

我們行以及業界都採用了自動查殺方式。

 

  • 在show engine innodb status中,我們可以進行監控,如果一個事物沒有結束,會提示這個事務更新的記錄數;

 

  • 超過什麼樣的閾值時,我們可以進行自動kill。對於聯機以及批量來說,閾值是不一樣的,所以我們自動執行kill時,必須規避一刀切的問題。

 

我們當時做過兩步操作,第一步是將交易的聯機庫跟批量庫進行區分。對於聯機庫,超過三秒以上的交易可以進行自動查殺;對於批量庫,通過小範圍試點,然後做到全面推廣。

 

後續我們應該會將MySQL的主動同步做到不降級,去掉降級時間,但這一點依賴於我們治理完善、大事務不存在的情況。

 

五、未來展望

 

圖片

 

1、全鏈路監控

 

希望可以做到全套端到端的全鏈路監控,這樣可以快速定位哪個節點出了什麼問題。

 

2、進一步發展AIOps

 

希望進一步發展AIOps,實現業界所說的1-5-10目標,1分鐘發現,5分鐘處置,10分鐘恢復。

 

3、掌握源碼

 

最後希望各位可以掌握一些開源組件的源碼,做到“他山之石,可以攻玉”,瞭解其中隱藏的bug風險,有利於我們後續對開源組件進行維護。

 

Q&A

 

Q1:貴司在MySQL調優過程中,會用到相關輔助工具嗎?老師能簡單分享一下嗎?

A1:沒有用到輔助工具,我們更多還是通過explain直接查看執行計劃,然後進行一些分析。

 

Q2:MySQL規範已經在貴司普及了嗎?落地一整套規範需要多長時間?

A2:我們大概從17年開始建立MySQL規範,因為我們當時引入MySQL5.7時,必須建立方法論這套基石。我們建立規範後,在SonarQube上建立檢查組件,進而做到門禁,實現規範的落地。在只有規範,沒有落地的情況下,我們很難把控,所以必須要通過硬性方式進行把控。

 

Q3:貴司是採用什麼方式對MySQL進行監控的?

A3:包括兩種層面,第一層面,我們在MyBatis上做了擴展,會對語句進行審核,判斷語句是否有問題。第二層面,對MySQL的performance schema 和Information schema相關表進行監控,查找並處理其中的慢SQL。

 

Q4:老師,自動查殺的準確率能達到多高?

A4:自動查殺的準確率其實可以達到100%。大事務很容易就可以監控出來,但很多時候不敢查殺,我們把聯機跟批量分離完以後,對聯機大事務查殺的準確率就相當於是100%了。

 

Q5:老師能推薦個好用的開發工具嗎?比如Workbench?這塊總行有要求嗎?

A5:業界其實有很多工具,例如收費的Navicat、免費的MySQL Workbench等,我一般會用Workbench多一點,因為我們行引入軟體受到管控,必須要進行登記處理。

 

作者:魏亞東

本文來自博客園,作者:古道輕風,轉載請註明原文鏈接:https://www.cnblogs.com/88223100/p/System-performance-troubleshooting-strategy-and-MySQL-performance-control-of-large-banks.html


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 過濾數據 使用WHERE子句 搜索條件也稱為過濾條件(filter condition)。在SELECT語句中,數據根據WHERE子句中指定的搜索條件進行過濾: SELECT prod_name, prod_price FROM products WHERE prod_price = 2.50; 註 ...
  • 排序檢索數據 排序數據 不明確規定排序順序,則不應該假定檢索出的數據的順序有意義。 子句(clause) SQL語句由子句構成,有些子句是必需的,而有的是可選的。一個子句通常由一個關鍵字和所提供的數據組成。子句的例子有SELECT語句的FROM子句。 為了明確地排序用SELECT語句檢索出的數據,可 ...
  • 1、合作背景 萬里開源軟體有限公司 ​ 北京萬里開源軟體有限公司,是專註於國產自主可控資料庫產品研發超 20年的國家高新技術企業,參與多個國家級的資料庫行業標準制定工作。本次用於測試的 GreatSQL 開源資料庫是適用於金融級應用的國內自主 MySQL 版本,專註於提升 MGR 可靠性及性能,支持 ...
  • Calcite在大數據系統中有著廣泛的運用, 比如Apache Flink, Apache Drill等都大量使用了Calcite,理解Calcite的原理可以說已經成為理解大數據系統中SQL訪問層實現原理的必備條件之一。 但是不少人在學習Calcite的過程中都發現關於Calcite的實踐案例其實 ...
  • 摘要:通過雲服務形式提供資料庫功能的雲資料庫應運而生,但這還僅僅是資料庫變革的開端。 本文分享自華為雲社區《透視華為云云原生資料庫的前世今生及未來演進,能給行業帶來哪些啟發?》,作者:萬佳。 自雲計算出現後,風雲變幻十餘載,硬體、軟體行業都經歷了重構變革所帶來的機遇與激蕩。企業 IT 基礎設施逐漸雲 ...
  • Day1 選擇 595. 大的國家 World表: + + + | Column Name | Type | + + + | name | varchar | | continent | varchar | | area | int | | population | int | | gdp | in ...
  • 如果入職一些中小型公司,往往需要接手一些很“坑”的項目,到底多坑就不牢騷了,只講一下,如果破解這些歷史遺留的項目問題。項目代碼可能短時間無法進行通讀研究,我們就需要從底層資料庫進行挖掘問題,有經驗的老開發工程師,他會開啟Sql Server Profiler 這個功能,進行語句的跟蹤。這個是一個很好 ...
  • 對於一個集中式緩存的分散式能力構建,必須要額外提供一些機制,來保障數據在各個節點上的安全與一致性。本文以Redis為代表,看下集Redis面對上述問題交出的是怎樣一份答卷。 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...