怎么提高api接口的穩(wěn)定性？這個問題我就結合著自己的項目來說一說。我們現(xiàn)在的項目是沒有前臺頁面的，只對外提供接口服務，甚至我們項目都沒有交易類的服務，都是單純的查詢類服務。項目最初的建設目標就是為了緩

怎么提高api接口的穩(wěn)定性？

這個問題我就結合著自己的項目來說一說。

我們現(xiàn)在的項目是沒有前臺頁面的，只對外提供接口服務，甚至我們項目都沒有交易類的服務，都是單純的查詢類服務。項目最初的建設目標就是為了緩解核心系統(tǒng)數(shù)據(jù)查詢的壓力，或者你們可以把我們項目看成幾個核心項目的緩存層(因為有多個核心系統(tǒng)，我們項目還可以提供跨系統(tǒng)的查詢，這一點也很重要)。

打鐵還需自身硬，要提高接口的穩(wěn)定性和響應速度，首先代碼要寫好：

我們項目采用了關系型數(shù)據(jù)庫做中間庫，數(shù)據(jù)經(jīng)過加工后落地到MongoDB和Redis，對外的提供的服務，只會查詢MongoDB和Redis；

數(shù)據(jù)加工很重要，關系型數(shù)據(jù)庫中需要多表關聯(lián)的查詢，現(xiàn)在只查詢MongoDB的一個collection就可以了。（因為要做數(shù)據(jù)加工，所以數(shù)據(jù)和生產庫比，有一定的延遲，這個一定要看業(yè)務場景是否允許有延遲）；

MongoDB采用副本集 分片的部署，副本集保證數(shù)據(jù)庫的穩(wěn)定性，掛掉一臺，還有其他幾臺可以使用；分片保證數(shù)據(jù)量增大后，可以平行擴容。（現(xiàn)在數(shù)據(jù)量大概在億級，個位數(shù)）；

服務部署還采用比較傳統(tǒng)的，N臺服務器前面掛負載均衡；上各種監(jiān)控，隨時關注接口調用和資源使用情況；

嚴格的參數(shù)校驗，避免做無用的查詢；

大原則就是：【能查緩存就不要查數(shù)據(jù)庫，能不查的話就更好】

除了自身架構之外，還有些非自身的控制：

內部系統(tǒng)在調用接口的時候，主要通過網(wǎng)絡權限的控制，除此之外不做任何的限制，包括鑒權；

如果是互聯(lián)網(wǎng)端的接入，還是需要依賴網(wǎng)關；由網(wǎng)關做鑒權、限流、降級、熔斷等；

參與對方系統(tǒng)功能的設計（這一點很神奇），因為大多數(shù)時候都是公司內部的系統(tǒng)，所以在做需求討論的時候，最好能看一下對方系統(tǒng)的調用場景；很有可能調整一下什么時候調用接口，就能大大減少接口的調用次數(shù)；

建議調用方設置合理的超時時間，并有合理的重試機制；

如果可以的話，最好可以采用異步調用的機制；

如果接口要依賴于另外系統(tǒng)的接口，也需要額外的做一些考慮（依賴的接口返回慢或者報錯，自己的接口肯定會有問題）；比如數(shù)據(jù)時效性要求不高的話，可以考慮把對方接口返回的數(shù)據(jù)緩存下來（設置失效時間，保證一段時間后能把最新的數(shù)據(jù)刷新回來），但如果數(shù)據(jù)時效性要求非常高，可以考慮使用熔斷；不過說實話，還沒見過誰敢用熔斷的....

希望我的回答，能夠幫助到你！我將持續(xù)分享Java開發(fā)、架構設計、程序員職業(yè)發(fā)展等方面的見解，希望能得到你的關注。

oral數(shù)據(jù)庫讀寫速度怎么提升？

優(yōu)化數(shù)據(jù)庫大幅度提高Oracle的性能

幾個簡單的步驟大幅提高Oracle性能–我優(yōu)化數(shù)據(jù)庫的三板斧。

數(shù)據(jù)庫優(yōu)化的討論可以說是一個永恒的主題。資深的Oracle優(yōu)化人員通常會要求提出性能問題的人對數(shù)據(jù)庫做一個statspack，貼出數(shù)據(jù)庫配置等等。還有的人認為要抓出執(zhí)行最慢的語句來進行優(yōu)化。但實際情況是，提出疑問的人很可能根本不懂執(zhí)行計劃，更不要說statspack了。而我認為，數(shù)據(jù)庫優(yōu)化，應該首先從大的方面考慮：網(wǎng)絡、服務器硬件配置、操作系統(tǒng)配置、Oracle服務器配置、數(shù)據(jù)結構組織、然后才是具體的調整。實際上網(wǎng)絡、硬件等往往無法決定更換，應用程序一般也無法修改，因此應該著重從數(shù)據(jù)庫配置、數(shù)據(jù)結構上來下手，首先讓數(shù)據(jù)庫有一個良好的配置，然后再考慮具體優(yōu)化某些過慢的語句。我在給我的用戶系統(tǒng)進行優(yōu)化的過程中，總結了一些基本的，簡單易行的辦法來優(yōu)化數(shù)據(jù)庫，算是我的三板斧，呵呵。不過請注意，這些不一定普遍使用，甚至有的會有副作用，但是對OLTP系統(tǒng)、基于成本的數(shù)據(jù)庫往往行之有效，不妨試試。