讀構建可擴展分散式系統：方法與實踐09可擴展資料庫基礎

来源:https://www.cnblogs.com/lying7/p/18420392
-Advertisement-
Play Games

1. 可擴展資料庫基礎 1.1. 絕大多數應用程式都是基於關係資料庫技術構建的 1.2. 資料庫必須存儲大量數據，為分佈在全球的客戶端提供快速的查詢響應，並且全天候可用 1.3. NoSQL資料庫採用簡單的數據模型，可以複製和分區以支持海量數據集和請求量 1.4. Facebook以使用MySQL管 ...


1. 可擴展資料庫基礎

1.1. 絕大多數應用程式都是基於關係資料庫技術構建的

1.2. 資料庫必須存儲大量數據，為分佈在全球的客戶端提供快速的查詢響應，並且全天候可用

1.3. NoSQL資料庫採用簡單的數據模型，可以複製和分區以支持海量數據集和請求量

1.4. Facebook以使用MySQL管理PB級社交相關活動（例如用戶評論和點贊）的數據而聞名

  • 1.4.1. 基本架構基於副本集，一個主節點處理所有寫入請求

  • 1.4.2. 數據更新被非同步複製到按地理分佈的只讀副本

  • 1.4.3. 構建自己的存儲技術MyRocks

  • 1.4.3.1. MyRocks提高了寫入性能並節省了50%的存儲空間

1.5. 百度公司從2012年開始使用MongoDB

  • 1.5.1. 使用MongoDB來管理包括地圖、消息和共用照片在內的多項服務的數據

  • 1.5.2. 大概有2000億份文件和超過1 PB的數據，由600個節點管理，並分佈在多個位置以確保可用性

2. 分散式資料庫

2.1. 互聯網大規模的應用程式讓數據集在規模和複雜性上有了長足的增長

  • 2.1.1. 為數千萬用戶創建和管理大量異構數據，包括諸如用戶配置文件、用戶偏好、行為數據、圖像和視頻、銷售數據、廣告、感測器讀數、監控數據等

  • 2.1.2. 許多數據集實在是太大了，無法放在一臺機器上

2.2. 需要演化過的資料庫引擎來管理大量的分散式數據集合

  • 2.2.1. 低成本、功能強大的硬體的發展，使得在數百甚至數千個節點和磁碟上以低成本高效地分發數據成為可能

  • 2.2.2. 在節點間和磁碟上複製數據增強了可擴展性和可用性

2.3. 當今互聯網應用程式需求的不斷變化是資料庫引擎創新的另一個主要驅動力

  • 2.3.1. 關係資料庫的內在優勢（即事務和一致性）是以性能成本為代價的，在Twitter和Facebook等網站中並不總是合適的

  • 2.3.1.1. 這類網站並不要求每個用戶總是看到相同版本的信息

2.4. 當系統擁有數萬乃至數百萬的用戶時，可以放寬關係資料庫的各種數據約束，從而獲得更好的性能和可擴展性

  • 2.4.1. 促使了非關係數據模型和原生分散式資料庫引擎誕生，以支持當今應用程式的各種用例

  • 2.4.2. 魚和熊掌不可兼得，其中的取捨表現在資料庫支持的功能範圍及其編程模型的複雜性上

3. 擴展關係資料庫

3.1. 支持關係模型和SQL查詢語言的資料庫代表瞭如今最成熟、穩定和強大的資料庫軟體平臺

3.2. 關係資料庫是非常複雜且非常成功的技術

  • 3.2.1. 關係資料庫技術是在數據集相對較小（與今天的標準相比）的時候設計和發展成熟的，資料庫可以在一臺機器上運行

3.3. 規範化

  • 3.3.1. 關係資料庫的設計鼓勵規範化

  • 3.3.2. 通過規範化構建業務域數據來消除數據冗餘，並支持數據完整性

  • 3.3.3. 3NF數據模型旨在簡化數據管理

  • 3.3.4. 域數據在多個關係之間拆分，使得每個數據項都有一個條目，在需要時引用唯一標識符

  • 3.3.5. 3NF數據模型中的數據可以機械地轉換為關係模式並由關係資料庫引擎實例化

3.4. 垂直擴展

  • 3.4.1. 關係資料庫被設計為在一臺機器上運行，這樣就可以利用共用記憶體和磁碟來存儲數據及處理查詢

  • 3.4.2. 用戶可以定製資料庫引擎使其運行在具有多個CPU、磁碟和大容量共用記憶體的機器上

  • 3.4.3. 資料庫引擎可以利用更多的資源並行執行數千個查詢來提供極高的吞吐量

  • 3.4.4. 資料庫遷移到新的、更強大的（虛擬）硬體

  • 3.4.4.1. 我們有資料庫管理手段來執行遷移和調整資料庫配置，使其有效利用新資源，而無須改動應用程式代碼

  • 3.4.5. 主要缺點

  • 3.4.5.1. 成本

>  3.4.5.1.1. 隨著計算資源的增長，硬體成本往往呈指數級增長
  • 3.4.5.2. 可用性
>  3.4.5.2.1. 儘管你擁有很強大的資料庫，但只有一個節點

  >   3.4.5.2.1.1. 如果它不可用，你的系統就要崩潰
  • 3.4.5.3. 擴展
>  3.4.5.3.1. 如果你的資料庫繼續增長，則不可避免地要再次遷移到更強大的硬體

>  3.4.5.3.2. 資料庫增長到超出單個節點的處理能力

>  3.4.5.3.3. 需要低延遲資料庫訪問來服務遍佈全球的客戶

  >   3.4.5.3.3.1. 穿越洲際網路並不能解決問題

3.5. 水平擴展：只讀副本

  • 3.5.1. 增加資料庫處理能力的一個常見策略是使用只讀副本進行水平擴展

  • 3.5.2. 可以將一個或多個節點配置為主資料庫的只讀副本

  • 3.5.2.1. 主資料庫節點稱為主節點，只讀副本稱為輔助節點

  • 3.5.2.2. 輔助資料庫維護主資料庫的副本

  • 3.5.2.3. 應用程式只能對主節點進行寫入操作，然後所有更改都會非同步複製到輔助節點

  • 3.5.3. 只讀副本方法將所有讀取請求定向到只讀副本來增強可擴展性

  • 3.5.3.1. 對於讀取密集型工作負載的應用程式來說，非常有效

  • 3.5.3.2. 可以通過添加更多輔助節點來擴展讀取能力，從而減少主節點的負載，使它能夠更有效地處理寫入請求

  • 3.5.3.3. 如果主節點由於暫時性故障而變得不可用，不會中斷面向輔助節點的讀取請求

  • 3.5.3.4. 由於數據寫入主資料庫和成功複製到輔助資料庫之間存在延遲，客戶端有可能從輔助資料庫讀取陳舊數據

3.6. 水平擴展：數據分區

  • 3.6.1. 在關係資料庫中拆分或分區存儲數據是一種將資料庫分佈在多個獨立磁碟分區和資料庫引擎上的技術

  • 3.6.2. 水平分區將一個邏輯表拆分為多個物理分區

  • 3.6.2.1. 根據某種分區策略將數據行分配給一個分區

  • 3.6.2.2. 常見的分區策略是根據行中的某個值將行分配給分區，或者對行的主鍵進行哈希計算

  • 3.6.3. 垂直分區，也稱為行拆分，按行中的列對錶進行分區

  • 3.6.3.1. 出於物理而非概念優化的原因，垂直分區將一行拆分為一個或多個部分

  • 3.6.3.2. 一種常見的策略是對行中的靜態數據、只讀數據和動態數據進行分區

3.7. 分散式SQL連接

  • 3.7.1. SQL連接在分散式關係資料庫中實現起來很複雜

  • 3.7.2. SQL引擎之所以長時間受到青睞，是因為它們針對單個資料庫上的連接進行了高度優化

  • 3.7.3. 當關係表被分區並分佈在大型電腦集群中時，需要精心設計分散式連接，以儘量減少數據移動，從而降低延遲

  • 3.7.4. 分散式SQL連接的常見策略

  • 3.7.4.1. 定義相對較小、更改頻率低且需要經常連接的引用表

  • 3.7.4.2. 在連接中使用分區鍵或二級索引，允許連接操作使用索引欄位在每個分區本地並行執行

  • 3.7.4.3. 確保連接的一側存在具有高度選擇性的過濾器，可將行集減少為一個小集合

>  3.7.4.3.1. 然後將小集合發送到每個分區節點，像在引用表連接中一樣進行連接操作

>  3.7.4.3.2. 最大限度地減少了數據移動
  • 3.7.4.4. 高吞吐量的查詢需要仔細設計並選擇合適的連接演算法

3.8. Oracle RAC

  • 3.8.1. Oracle的RAC（Real Application Cluster，實時應用集群）資料庫

  • 3.8.2. Oracle的RAC資料庫於2001年發佈，為大容量、高可用系統提供分散式版本的Oracle資料庫引擎

  • 3.8.3. Oracle公司讓部署一個由多達100個Oracle資料庫引擎組成的集群成為可能，這些引擎都訪問同一個物理資料庫

  • 3.8.4. 為避免數據分區問題，Oracle RAC是一個共用一切資料庫的示例

  • 3.8.5. 所有節點都通過SAN（存儲區域網路）來訪問物理存儲

  • 3.8.5.1. SAN提供對Oracle資料庫的高速網路訪問

  • 3.8.6. 兩個專有軟體組件

  • 3.8.6.1. Clusterware

>  3.8.6.1.1. 支持集群中資料庫引擎之間的通信和協調

>  3.8.6.1.2. 支持集群中資料庫引擎之間的通信和協調
  • 3.8.6.2. Cache Fusion（緩存融合）
>  3.8.6.2.1. 使每個集群資料庫節點中的緩存能夠有效共用，從而最大限度地減少對持久存儲的訪問

  • 3.8.7. Oracle RAC展示了一種用於擴展關係資料庫的架構方法，即共用一切

  • 3.8.7.1. 增強了Oracle部署的處理能力和高可用性，同時（在理論上）無須更改應用程式代碼

  • 3.8.7.2. 資料庫需要多個專有的Oracle軟體組件以及昂貴的冗餘存儲和互連硬體

  • 3.8.7.3. 加上Oracle許可成本，無論如何你都沒有低成本的解決方案

  • 3.8.7.4. 是一種以高成本換取有限的按需擴展能力的架構

4. 向NoSQL轉變

4.1. 廣泛可用的低成本商業計算節點和存儲的非共用架構

  • 4.1.1. 功能強大、低成本的商業硬體的發展，包括多核CPU，速度更快、容量更大的磁碟，以及更高速的網路

  • 4.1.2. 處理非結構化數據類型的應用程式的出現，及其業務和數據模型的快速發展

  • 4.1.3. 面向互聯網的應用程式在可擴展性和可用性方面的需求激增

  • 4.1.4. 收集原始數據並將其用於新業務洞察和分析的新機會

4.2. 向NoSQL轉變的核心特征

  • 4.2.1. 簡化的數據模型，可以輕鬆擴展

  • 4.2.2. 專有的查詢語言，限制或不支持連接

  • 4.2.3. 原生支持低成本商業硬體的水平擴展

4.3. NoSQL連接查詢

  • 4.3.1. 數據模型的規範化(normalization)

  • 4.3.1.1. 由於SQL和連接的強大功能，你不必過多考慮訪問數據時所使用的怪異而奇妙的方式，無論是立即訪問還是將來訪問

  • 4.3.2. 使用NoSQL，建模重點從問題域建模轉變為方法域(solution domain)建模

  • 4.3.3. 方法域建模的另一種方法是為每個用例創建一個表

  • 4.3.4. 數據分區和數據分發變得更加容易，並且這些優勢在大規模使用中累積

4.4. NoSQL數據模型

  • 4.4.1. 鍵值資料庫

  • 4.4.1.1. 鍵值(Key-Value，KV)資料庫基本上是一個哈希映射表

  • 4.4.1.2. Redis

  • 4.4.1.3. Oracle NoSQL

  • 4.4.2. 面向文檔資料庫

  • 4.4.2.1. 面向文檔資料庫建立在鍵值模型之上，同理，資料庫中的每個文檔都需要一個唯一的鍵

  • 4.4.2.2. 與鍵關聯的值對資料庫來說是透明的

  • 4.4.2.3. 它通常以JSON格式進行編碼，從而可以在查詢中引用文檔中的各個元素，並讓資料庫在文檔欄位上建立索引

  • 4.4.2.4. MongoDB

  • 4.4.2.5. Couchbase

  • 4.4.3. 列存儲資料庫

  • 4.4.3.1. 列存儲資料庫是對鍵值模型的擴展，管理與命名列中的鍵相關聯的數據

  • 4.4.3.2. 本質上是一個二維哈希映射，使行中的列能夠使用列名進行唯一標識和排序

  • 4.4.3.3. Apache Cassandra

  • 4.4.3.4. Google Bigtable

  • 4.4.4. 圖資料庫

  • 4.4.4.1. 圖是一種很好理解的數據結構，用於存儲和查詢高度連接的數據

  • 4.4.4.2. 圖資料庫在概念上最接近關係資料庫

  • 4.4.4.3. Neo4j

  • 4.4.4.4. Amazon Neptune

4.5. NoSQL資料庫通常被稱為無模式資料庫

  • 4.5.1. 不可避免的代價是應用程式有責任解析它讀取的數據的結構，需要將數據對象與元數據（用於解析結構，基本上是欄位名稱）一起存儲在資料庫中

  • 4.5.2. 寫時模式（schema-on-write，定義模式）

  • 4.5.3. 讀時模式（schema-on-read，無模式）

4.6. 查詢語言

  • 4.6.1. NoSQL資料庫查詢語言幾乎總是特定資料庫專有的，並且與基於顯式API和類似SQL的聲明性語言有所不同

  • 4.6.2. 由供應商和第三方實現的支持不同語言的客戶端庫可供應用程式使用

  • 4.6.3. 鍵值資料庫可能只提供支持基於單個鍵值的CRUD操作的API

  • 4.6.4. 文檔資料庫通常支持單個文檔欄位的索引

  • 4.6.4.1. 使得檢索結果集和更新文檔等查詢能夠高效實現，並滿足不同的文檔搜索標準

  • 4.6.5. 列存儲資料庫具有多種查詢功能

  • 4.6.6. 圖資料庫支持更豐富的查詢功能

  • 4.6.6.1. Cypher，最初是為Neo4j圖資料庫設計的，並通過openCypher項目

4.7. 分散式數據存儲

  • 4.7.1. NoSQL資料庫通常為方便分散式計算節點水平擴展而設計，節點配備了本地存儲

  • 4.7.2. 由於沒有共用狀態，性能瓶頸和單點故障被消除，性能、可擴展性和可用性均得到增強

  • 4.7.3. 分散式圖資料庫

  • 4.7.3.1. 由圖資料庫實現的圖數據結構明確表示圖中節點之間的關係

  • 4.7.3.2. 水平擴展圖資料庫以提高性能並非易事

  • 4.7.4. 分區，通常稱為分片，需要一種演算法來跨多個伺服器節點實現分散式存儲邏輯資料庫集合中的數據對象

  • 4.7.4.1. 分片需要一個分片或分區鍵，將給定數據對象分配到特定分區

  • 4.7.4.2. 散列鍵

>  4.7.4.2.1. 任何給定數據對象的分區都是將分片鍵散列（即應用哈希函數）後，再將結果映射到分區

>  4.7.4.2.2. 使用模數方法或名為一致性哈希的演算法
  • 4.7.4.3. 基於分片鍵值
>  4.7.4.3.1. 分區是根據分片鍵的值進行選擇的
  • 4.7.4.4. 基於分片鍵值範圍
>  4.7.4.4.1. 分區托管特定範圍內分片鍵值所在的數據對象

>  4.7.4.4.2. 分區可以通過增加處理資源和磁碟容量，併在額外的資源中分佈數據來擴展資料庫

4.8. 引入副本來解決可用性問題

  • 4.8.1. 每個分區中的數據對象通常被覆制到兩個或更多節點

  • 4.8.2. 如果其中一個節點變得不可用，應用程式可以通過訪問其他副本繼續執行

  • 4.8.3. 副本增強了可用性和可擴展性

  • 4.8.3.1. 存儲副本的額外資源也可用於處理來自應用程式的讀取和寫入請求

  • 4.8.3.2. 當發生數據更新請求時，資料庫需要更新所有的副本

  • 4.8.4. 領導者-追隨者模式(leader-follower)

  • 4.8.4.1. 其中一個副本被指定為領導者，它始終持有任何數據對象的最新值

  • 4.8.5. 無領導模式(leaderless)

  • 4.8.5.1. 所有副本都可以處理讀取請求和更新請求

  • 4.8.6. 如果一個資料庫可以確保所有副本始終具有相同的值，那麼它可以對外提供強一致性(strong consistency)

  • 4.8.6.1. 所有客戶端訪問都會針對每個數據對象返回相同的值

  • 4.8.7. 將資料庫允許副本不一致的行為稱為最終一致性(eventually consistent)

5. CAP定理

5.1. Eric Brewer著名的CAP定理優雅地闡述了使用分散式資料庫時副本一致性和可用性的選擇

5.2. 描述了資料庫系統在存在網路分區時的選擇，即當資料庫節點之間發送的消息存在網路延遲和丟失時

5.3. 如果網路運行正常，系統就可以同時保持一致性和可用性

5.4. 如果發生網路分區，系統可以是一致的(CP)或可用的(AP)

  • 5.4.1. 返回錯誤，因為它無法確保副本一致性(CP)

  • 5.4.2. 將更新應用於可見的副本子集(AP)

  • 5.4.2.1. 意味著在資料庫通過分區修複使所有副本一致之前，副本是不一致的

  • 5.4.2.2. 在解決不一致問題之前，客戶端可能會看到同一數據對象的不同值


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

-Advertisement-
Play Games
更多相關文章
  • Angular 18+ 高級教程 – 國際化 Internationalization i18n
    title: Nuxt Kit 中的上下文處理 date: 2024/9/16 updated: 2024/9/16 author: cmdragon excerpt: Nuxt Kit 提供的上下文處理工具，尤其是 useNuxt 和 tryUseNuxt，為模塊化開發提供了極大的便利。通過這些函 ...
  • duxapp：基於Taro使用模塊化開發，提升開發效率
    duxapp是基於Taro二次開發的模塊化框架 使用這個框架，結合框架提供的UI庫和工具庫，能幫助你快速且高質量的完成項目，且能實現同時開發小程式、H5、APP（React Native），並且保證各個端的一致性 ...
  • 雲設計模式介紹
    雲設計模式介紹以及它們如何幫助應對分散式計算的謬誤 作為構建分散式系統的軟體工程師，我們經常遇到諸如不可靠的網路、延遲問題和安全問題等挑戰。"分散式計算的謬誤"描述瞭如果未解決，可能導致系統故障的常見誤解。但認識到這些陷阱只是開始。真正的問題是：我們如何有效地剋服它們？這就是雲設計模式發揮作用的地方 ...
  • 讀構建可擴展分散式系統：方法與實踐12分散式資料庫案例
    1. Redis 1.1. 2009年首次發佈 1.1.1. 更註重原始性能和簡單性，而不是數據安全性和一致性 1.2. 主要吸引力在於它能夠同時充當分散式緩存和數據存儲 1.3. 維護一個記憶體中的數據存儲，也稱為數據結構存儲(data structure store) 1.4. 配置Redis將每 ...
  • SaaS業務架構：業務能力分析
    大家好，我是湯師爺~ 今天聊聊SaaS業務架構的業務能力分析。 業務能力概述 簡單來說，業務能力是企業“做某事的能力”。 業務能力描述了企業當前和未來應對挑戰的能力，即企業能做什麼或需要做什麼。業務能力建模的關鍵在於定義了企業做什麼，而不是如何做（由業務流程描述）。 以人才招聘為例，大多數公司都需要 ...
  • 讀構建可擴展分散式系統：方法與實踐11強一致性
    1. 強一致性 1.1. 最終一致資料庫通過跨多台機器分區和複製數據集來獲得可擴展性，其代價是要跨副本維持強數據一致性以及允許衝突寫入 1.1.1. 在更新數據對象後，不同的客戶端可能會看到該對象的舊值或新值，直到所有副本都收斂到最新值 1.2. 另一類分散式資料庫提供一種可替代的模型，即強一致性數 ...
  • 讀構建可擴展分散式系統：方法與實踐10最終一致性
    1. 最終一致性 1.1. 在一些應用領域，通常談論的是銀行和金融行業，最終一致性根本不合適 1.2. 事實上，最終一致性在銀行業已經使用了很多年 1.2.1. 支票需要幾天時間才能在你的賬戶上進行核對，而且你可以輕鬆地開出比賬戶餘額多的支票 1.2.2. 當處理檢查並建立一致性後，你才能看到一些後 ...
  • SaaS架構：流程架構分析
    大家好，我是湯師爺~ 今天聊聊SaaS架構中的流程架構分析。 業務流程的概念 業務流程是企業為實現目標而制定的一套系統化的工作方法。它由一系列有序的業務活動組成，按照既定規則將資源（輸入）轉化為有價值的結果（輸出）。這一過程需結合企業的具體情況和可用資源，旨在為客戶創造價值，同時達成企業目標。 通過 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 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 ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類