# Microsoft Azure - Azure、Web API 和 Redis 如何有助于加快數據交付 通過?[Johnny Webb](https://msdn.microsoft.com/zh-cn/magazine/mt149362?author=Johnny+Webb), ，[Sean Iannuzzi](https://msdn.microsoft.com/zh-cn/magazine/mt149362?author=Sean+Iannuzzi)?|2015 年 12 月 在今天的 worldof 實時營銷、 死亡的旋轉圓，經常伴隨等待加載或搜索查詢以填充的頁面真正意味著銷售的死亡。隨著越來越多的數據記錄的創建、 存儲和分析，生成的豐富，實時數據洞察力增長不斷更具挑戰性。問題就是如何選擇適當的技術工具和體系結構，以便最好地篩選數以百萬計的數據記錄并交付更好的客戶體驗的即時結果。 本文將探討我們在其中幫助實現 Redis 和 Web API 的客戶端最新的用例。我們將討論我們實現的方法，我們遇到的難題和如何我們最終實現的性能要求。 ## 業務挑戰 幾個月前，財富 100 強多樣的保險和金融服務組織接近 Harte 衷心感謝，一家全球性市場營銷公司，使用的新計劃。該公司希望在線的保險報價過程提供更好、 更豐富的客戶體驗。若要執行此操作，它需要以啟用對客戶的策略數據的快速、 積極主動的訪問。 目標是以使客戶能夠查看和選擇一個或多個保險策略是通過 Internet 自助服務或代理面向應用程序。從根本上講，這將導致更高版本的業務價值、 提高了客戶滿意度、 更快的報價單綁定速率和改進的代理授權過程。為了使這成為現實，在報價過程中進行處理時所需的客戶的存儲的詳細信息和數據匹配，并且主動，提供幾乎即時的方式。 客戶端的數據庫包含超過 50 萬條記錄，這意味著與任何傳統數據庫這種性質的請求通常會需要多長時間加載。我們已任務提供支持此較大的數據源上執行查詢并將結果傳送到幾毫秒的時間的使用者的 Web 服務。 對于此任務中，我們計算的 Redis 和 Web API 的實現。總體的度量值因素是: * 事務請求 * 對象的請求 * 每秒的響應 * 數據的總帶寬 * 總吞吐量的站點 ## 實現過程: 我們是如何做到了 構建 Web 服務來公開數據，要求提供特定功能的組件的多個層。隨著 Web 服務的需求的發展，支持這些層的基礎結構必須修改并快速縮放。和可伸縮性是必需的但同樣重要的是可用性，并必須始終被視為為了讓使用者滿意。此外，還必須監視和使用特定的身份驗證協議，以確保受保護的數據并將數據與最大性能安全地傳遞包裝公開的終結點。為了滿足這些要求對于我們的解決方案，我們就利用了 Microsoft Azure。在 Azure 中，我們部署了資源包括虛擬機、 Web 應用程序、 虛擬網絡、 資源組的組合和可用性集來構建一個完備、 高質量的解決方案。 ## 數據層 由于我們的解決方案的大部分都生成使用 Microsoft 堆棧，因此我們在大多數情況下利用 Microsoft SQL Server 一點非常有意義。但是，此解決方案的 SLA 要求在具有超過 50 萬條記錄的數據集上指定的服務響應時間是小于 1 秒，每個請求，以每小時，大約 6000 請求的速率。類似于 SQL Server 的傳統數據庫將數據存儲到磁盤和 IOPS 的瓶頸，因為我們無法保證每個查詢將通過這一要求。若要進一步復雜化了，我們已公開所需的數據子集屬于傳統的數據庫包含千吉字節的不相關的數據。為此，我們開始評估可能快速支持大型數據集的解決方案。即，當我們發現 Redis。 Redis 是內存中數據結構存儲，支持多個數據類型。關鍵的服務器要求包括 Linux 分發，足夠的 RAM 來封裝你的數據和實現數據持久性足夠的磁盤空間。Redis 也可配置為群集中，但這是更適合于具有千吉字節的數據的解決方案。由于我們的數據集是小于 50 GB，所以我們決定使其保持簡單并且設置了單一的主/從配置。若要托管此配置，我們在虛擬網絡內的兩個 CentOS 7.1 虛擬機在 Azure 上創建。每個虛擬機包含為 56 GB 內存、 靜態 IP 地址和 SSH 終結點使用 AES256 加密。由于這兩個 Vm 共享提供的一組，Azure 將提供 99.95 %sla 保證正常運行時間。另一個好處，我們創建的所有資源被都附加到資源組創建專為此解決方案，使我們能夠監視和管理在每月的基礎上計費。在幾分鐘內，我們的虛擬機已部署并對我們可用。 站著我們的 Redis 服務器是簡單和造詣頗也在一小時內。在下載并安裝到我們新創建的服務器上的最新穩定版本之后, 我首先想知道我們修改了配置文件以允許 Redis 所調用的僅限追加的文件 (說明) 持久性。簡單地說，這意味著發送到我們的實例的每個命令會存儲到磁盤。如果要重新啟動服務器，所有則重新執行命令，將服務器還原到其原始狀態。若要消除臃腫的說明，BGREWRITEAOF 命令，將觸發有時，重寫命令重新生成內存中的當前數據集所需的最短序列的文件。此外，我們配置了 50 GB，創建一個緩沖區，并且如果加載的數據過多占用了所有的系統內存會阻止 Redis 的最大內存用途。這一點，如果我們的解決方案曾經需要更多內存，我們可以輕松地調整 VM 使用 Azure 門戶的大小和更新配置更高版本。接下來，我們配置了要確認創建的數據復制到主機的從屬服務器實例。如果主實例變得不可用，從設備實例會準備好為客戶端提供服務。最后，我們重新啟動 Redis 服務器進行配置后，才會生效。下面是我們使用的配置: ~~~ appendonly yes maxmemory 50000000000 slaveof 10.0.0.x 6379 # cluster-enabled no ~~~ ## 數據加載和基準測試 我們需要從我們的傳統數據庫加載到 Redis 的數據包含大約 4 GB 的客戶的元數據。此元數據是每日更新，因此我們需要創建一個進程定期將其轉換成 Redis 數據類型和大容量加載它以使我們的解決方案保持最新。若要執行此操作，我們創建自動化的過程以提取到 Redis 協議格式的文件中的每日更改集，并傳輸到使用可用的 SSH 終結點的主服務器。在主實例中，我們創建了 bash 腳本，以進行大容量加載文件使用管道模式。若要強調，管道模式是解決方案的因為我們很快就在 5 分鐘內加載 28 萬條記錄我們的關鍵元素。請注意，但是，該管道模式下尚不可用群集實現兼容。在我們最初的原型設計階段，我們發現，將 28 萬條記錄加載到群集需要花費大量時間因為記錄已單獨傳輸。這是在我們的決策，以保持簡單的主/從實現的設計中一個重要的因素。管道模式命令和響應的單個實例如下所示: ~~~ $ cat data.txt | redis-cli –pipe All data transferred. Waiting for the last reply... Last reply received from server. errors: 0, replies: 1000000 ~~~ 在管道模式下執行之后, 響應指示接收到多少個錯誤和答復。我們分析的腳本中此響應、 存檔的文件和電子郵件通知發送給相應的技術團隊。對于每個錯誤，技術無法評估提取并快速確定需要重新加載任何數據。在完成后的日常處理腳本，我們計算速度達到我們使用 Redis 基準檢驗實用程序的實現。圖 1?顯示我們的解決方案，它會滿足我們的 SLA 要求 reassuring 我們的性能結果。  圖 1 Redis 基準 ## 服務層 它非常重要，我們的客戶端是我們的解決方案的唯一消耗者。幸運的是，Azure 可簡化此任務使用訪問控制服務使我們能夠創建 OAuth 提供程序專用于我們的解決方案。實現后，我們的服務所需的每個請求，使用新令牌在 5 分鐘后重新生成特定的令牌。同時也請注意，該令牌應始終保持不變到期前。請求新令牌為每個服務調用將實質上是妨礙您的解決方案或者，更糟糕的是，使其無法訪問如果超過指定由 Azure 的請求限制。我們強烈建議任何人利用讀取 Azure 的文檔，然后再在生產環境中實現此功能。 有多個 C# Redis 客戶端，但我們使用 StackExchange.Redis，因為我們認為它是最流行且成熟。因為所有的數據存儲在組中，我們使用 LRANGE 命令來查詢數據。若要防止每個查詢的重新連接，使用 StackExchange.Redis 的連接將在一個單獨模式中管理。中的示例?圖 2?演示我們如何檢索數據。 圖 2 連接到 Redis 和檢索數據 ~~~ private static Lazy<ConnectionMultiplexer> lazyConnection = ? new Lazy<ConnectionMultiplexer>(() => { ? return ConnectionMultiplexer.Connect( ??? ConfigurationManager.AppSettings[Constants.AppSettings.RedisConnection]); }); public static ConnectionMultiplexer Connection { ? get ? { ??? return lazyConnection.Value; ? } } public async static Task<MemberResponse> MemberLookup(MemberRequest request) { ? MemberResponse response = new MemberResponse(); ? try ? { ??? if (request != null && request.customer != null && request.customer.Count() > 0) ??? { ????? foreach (var customer in request.customer) ????? { ??????? Customer c = customer; ??????? RedisKey key = GetLookupKey(c); ???? ???IDatabase db = Connection.GetDatabase(); ??????? c.policies = await db.ListRangeAsync(key, 0, -1, CommandFlags.None); ??????? response.customer.Add(c); ????? } ????? response.success = true; ??? } ??? else ??? { ????? response.exceptions = new List<ServiceException>(); ????? response.exceptions.Add(Classes.ErrorCodes.Code_101_CustomerRequired); ????? response.success = false; ??????? } ? } ? catch (Exception ex) ? { ??? response.exceptions = new List<ServiceException>(); ??? response.exceptions.Add(Classes.ErrorCodes.Code_100_InternalError); ??? response.success = false; ??? Logging.LogException(ex); ? } ? response.executedOn = ??? Utils.FormatEST(DateTime.UtcNow).ToString(Constants.DateTimeFormat); ? return response; } ~~~ 若要承載我們在 Azure 中的解決方案，我們創建了一個 Web 應用程序。為獲得最佳性能非常重要，我們部署 Web 應用程序到 Redis 實例所在的同一區域。一旦部署該應用程序后，我們創建 VNET 連接到我們 Redis 虛擬網絡，允許服務以獲取對數據的直接訪問權限。此連接中進行了演示?圖 3。  圖 3 VNET 集成連接 配置此 Web 應用擴展到基于 CPU 使用情況的 10 個實例。因為我們的解決方案的流量很多種，Web 應用程序才可縮放在必要時。一層額外的安全，SSL 證書被應用到應用程序，以及 IP 篩選專門為我們的客戶端。盡管應用程序被配置為自動縮放，但它不自動故障轉移。為了最大化到我們的客戶端的解決方案的可用性，我們創建的主 Web 應用程序中，克隆，但放在不同的區域。這兩個應用程序已添加到 Azure Traffic Manager，后者我們利用進行自動故障轉移。 最后，我們購買自定義域，并創建一個指向完成我們的實現我們流量管理器 URL 的 CNAME 記錄。若要監視的每日我們的解決方案的性能，我們已購買 New Relic 直接從 Azure 應用商店的實例。通過使用 New Relic 中，我們無法快速確定需要改進，以及服務器的可用性的方面。 ## 總結 通過將此解決方案部署到 Azure，我們學到了如何使不同的技術堆棧配合快速以提供一個功能強大、 成功的解決方案。盡管將解決方案部署到 Azure 不會清除服務器維護，如果您按照位置中的模式，則必須成功。根據您的解決方案的平均持續時間，您可以保存對硬件成本的所有解決方案都遷移到云。 實現結束時，平均響應時間為 25 毫秒為 50 個并發用戶。根據這些結果，響應時間是每 15 添加的并發用戶的擴展大約 10 毫秒。 * * * Sean Iannuzzi?*是 Harte 衷心感謝 h e a d 的技術，已在發揮著關鍵作用中的大量的社交網絡，大數據的技術和業務前景之間的隔閡 20 多年來，本技術行業中數據庫解決方案，云計算、 電子商務和今天的財務應用程序。Iannuzzi 具有與 50 多個獨特的技術平臺的體驗、 已取得了很多技術的獎勵認證和專門從事推動技術指導和解決方案來幫助實現業務目標。* Johnny Webb?*是 Harte 衷心感謝的軟件架構師和已經實施了尖端技術為人所熟知的客戶端使用過去十年中的高質量解決方案。他的專業知識包括完整的軟件開發生命周期，以及 Microsoft.NET Framework 中，軟件體系結構、 云計算，Web 開發、 移動開發、 API 開發、 SQL 數據庫和 NoSQL 數據庫。*