對外提供的API如何保證冪等?
舉例說明:銀聯提供的付款接口:需要接入商戶提交付款請求時附帯: source來源,seq序列號source+seq在數據庫里面做準一索引,防止多次付款（井發）時,只能處理一個請求
重點:對外提供接口為了支持寫等調用,接口有兩個字段必須傳,一個是來源 source,個是來源方序列號seq,這個兩個字段在提供方系統里面做聯合唯一索引,這樣當第三方調用時,先在本方系統里面查詢一下,是否已經處理過,返回相應處理結果;沒有處理過,進行相應處理,返回結果
注意,為了冪等友好,一定要先查詞一下,是否處理過該筆業務,不查詢直接插入業務系統,會報錯,但實際已經處理

先做一個說明,從理論上來說,給緩存設置過期時間,是保證最終一致性的解決方案。這種方案下,我們可以對存入始存的る據置過期時間,所有的寫操作以數據庫為準,對媛存操作只是盡最大努力更新即可。也就是說如果數據寫成功,存更新失敗,那么只要到達過明時間,則后面的讀請求自然會從數據庫中讀取新值然后回填媛存因此,接下來討論的思路不依賴于給媛存設置過明時間這個方察在這里,我們討論三種更新策略:
1.先更新緩存,再更新數據庫。(不可取)
2.先更新數據庫,再更新媛存。(不可取)
3.先刪除緩存,再更新數據庫。(不可取)
4.先更新數據庫,再刪除緩存,(可取,有問題情解大前提:
先讀緩存,如果緩存沒有,才從數據庫讀取
(1)先更新數據庫,再更新緩存
這套方案,大家是普遍反對的,為什么呢?有如下兩點原因。原因一(線程安全角度)
同時有請求A和請求B進行更新操作,那么會出現
(1)線程A更新了數據庫
(2)線程B更新了敬據庫
(3)線程B更新了緩存
(4)線程A更新了緩存
這就出現請求A更新存應該比請求B更新存早才對,但是因為網絡等原因,B卻比A更早更新緩了存。這就導致了臟數據,因此不考慮。原因二(業務場景角度)有如下兩點:
tn日
寫數據庫場比較多

(3守據庫,再刪緩存
首先,先說一下。老外提出了一個緩存更新套路,名為《 Cache- Aside pattern》。其中就指出
?失效:應用程序先從 cache取數據,沒有得到,則從數據庫中取數據,成功后,放到媛存中。
?命中:應用程序從 cachet中取數據,取到后返回。
?更新:先把數據存到數據庫中,成功后,再讓緩存失效。
另外,知名社交網站 facebook也在論文《 Scaling Memcache at Facebook》中提出,他們用的也是先更新數據庫,再媛存的策略。這種情況不存在井發問題么?
不是的。假設這會有兩個請求,一個請求A做查詢操作,一個請求B做更新操作,那么會有如下情形產生
(1)緩存剛好失效
(2)請求A查詢數據庫,得個舊值
(3)請求B將新值寫入數據庫
4)請求B除媛存
(5)請求A將查到的日值寫入媛存
ok,如果發生上述情況,確實是會發生臟數據。然而,發生這種情況的概率又有多少呢?
發生上述情況有一個先天性條件,就是步驟(3)的寫數據庫操作比步驟(2)的讀數據庫操作耗時更短,才有可能使得步驟(4)先于步驟(5)?？墒?大家想想,數據庫的讀操作的速度遠快于寫操作的(不然做讀寫分離干嘛,做讀寫分離的意義就是因為讀操作比較快,耗資源少),因此步驟(3)耗時比步驟(2)更短,這一情形很難出現
假設,有人非要抬杠,有強迫癥,一定要解決怎么辦?如何解決上述井發問題?
首先,給存設有效時間是一種方案。其次,采用策略(2)里給出的異步延時除策略,保證讀請求完成以后,再進行刪除操作。

認證和授權的區別Authentication(認證)是驗證您的身份的憑據(例如用戶名和密碼),通過這個憑據,系統得以知道你就是你,也就是說系統存在你這個用戶。所以, Authentication被稱為身份/用戶驗證
Authorization(授權)發生在 Authentication(認證)之后。授權,它主要掌管我們訪問系統的權限。比如有些特定資源只能具有特定權限的人才能訪問比如 admin,有些對系統資源操作比如期除、添加、更新只能特定人才具
這兩個般在我們的系統中被結合在一起使用,目的就是為了保護我們系統的安全性

什么是 Token?什么是JMT?如何基于 Token進行身份驗證?
我們知道 Session信息需要保存一份在服務器端。這種方式會帶來一些麻煩,比如需要我們保證保存 Session信思服務器的可用性、不適合移動端(不依賴 Cookie)等
有沒有一種不需要自己存放 Session信息就能實現身份驗證的方式呢?使用 Token即可!WT( SON Web
Token)就是這種方式的實現,通過這種方式服務器端就不需要保存 Session數據了,只用在客戶端保存服務端返回給客戶的 Token就可以了,擴履性得到提升
MT本質上就一段簽名的SON格式的數據。由于它是帯有簽名的,因此接收者便可以驗證它的真實性
下面是RFC7519對MT做的較為正式的定義。
JSON Web Token (WT) is a compact, Url-safe means of representing claims to be transferred between twoparties. The claims in a WT are encoded as a JSON object that is used as the payload of a )SON Web
Signature UWS)structure or as the plaintext of a JSON Web Encryption(WE)structure, enabling the claimsto be digitally signed or integrity protected with a Message Authentication Code(MAC)and/or encrypted.
–JSON Web Token (WT)
MT由3部分構成
Header描述MT的元數據。定義了生成簽名的算法以及 Token的類型。
Payload(負載):用來存放實際需要傳進的數據
Signature(簽名):服務器通過 Payload、 Header和一個密鑰 secret)使用 Header里面指定的簽名算法(認是
HMAC SHA256)生成
在基于 Token進行身份驗證的的應用程序中,服務器通過 Payload、 Headers和一個密鑰 secret)的建令牌( Token)并將 Token發送給客戶端,客戶端將 Token保存在 Cookie或者 totalstorage里面,以后客戶端發出

為什么 Cookie無法防止CSRF攻擊,而 token可以
CSRF( Cross Site Request Forgery)-般被甜譯為站請求偽造。那么什么是站請求偽造呢?說簡單一點用你的身份去發送一些對你不友好的請求,舉個簡單例子:
小壯登錄了某網上銀行,他來到了網上銀行的帖子區,看到一個帖子下面有一個鏈接寫著科學理財,年收益率70%°,小杜好奇的點開了這個鏈接,結果發現自己的賬戶少了10000元,這是這么回事呢?原來黑客在鏈接中藏了一個請求,這個請求直接利用小社的身份給銀行發送了一個轉賬請求也就是通過你的 Cookie向銀行發出請求<asrc=htpi/www.mybank.com/Transfer?banked=11&money.=10000科學理財,年收益率70%<,原因是進行 Session認證的時候,我們一般使用 Cookie來存儲 Session,當我們登陸后后端生成個 Session放在
Cookie中返回給客戶端,服務端通過 Redis或者其他存儲工具記錄保存著這個5 ession,客戶端登錄以后每次請求都會帶上這個 Session,服務端通過這個 Session來標示你這個人。如果別人通過 cookie拿到了 Session后就可以代皆你的身份訪問系統了
Session認證中 Cookie中的 Session是由覽器發送到服務端的,借助這個特性,攻擊者就可以通過讓用戶誤點攻擊鏈接,達到攻擊效果
但是,我們使用 token的話就不會存在這個問題,在我們登錄成功獲得 token之后,一般會選擇存放在locastorage中。然后我們在前端通過某些方式會始每個發到后端的請求加上這個 token.這樣就不會出現CSRF同的問題。因為,即使有個你點擊了非法鏈接發送了請求到服務端,這個非法請求是不會攜帯 token的,所以這個請求將是非法的。

分布式架構下, Session共享有什么方案?
1.不要有 session:但是確實在某些場景下,是可以沒有 session的,其實在很多接口類系統當中,都提倡【API無狀態服務】:也就是每一次的接口訪問,都不依于 session、不依賴于前一次的接口訪問,用W的
2.存入 cookies中:將 session存儲到 cookie中,但是缺點也很明顯,例如每次請求都得帶著 session,數據存儲在toker
客戶端本地,是有風險的
3. session同步:對個服務器之間同步 session,這樣可以保證每個服務器上都有全部的 session信息,不過當服
務器數量比較多的時候,同步是會有延退甚至同步失敗
4.我們現在的系統會把 session放到 Redis.中存儲,雖然架構上変得復雜,并且需要多訪問一次 Redis,但是這種方案來的好處也是很大的:實現 session共享,可以水平擴展(増加加 Redis服務器),服務器重啟 session不丟失(不過也要注意 session在 Redist中的刷新/失效機制),不僅可以跨服務器 sessi0n共享,甚至可以跨平臺
(例如口網頁端和AP端滿)進行共享
5.使用 Nginx(或其他復雜均衡軟硬件)中的p綁定策略,同個p只能在指定的同一個機器訪問,但是這樣做風險也比較大,而且也是去了負載均的意

springcloudi核心組件有哪些,分別有什么作用
服務注冊與發現ー- Netflix Eureka、 Nacos、 Zookeeper客戶端負載均衡一一 Netflix Ribbon、 Springcloud Loadbalancer
服務熔斷
Netflix Hystrix、 Alibaba Sentinel、 Resilience.4服務網關ー- Netflix Zuu、 Springcloud Gateway服務接口調用一- Netflix Feign、 Resttemplate、 Openfeint鏈路追琮ー- Netflix Sleuth、 Skywalking、 Pinpoint聚合 Hystrix監控數據一- Netflix Turbine監控中心- Springboot Admin
配置中心ー- Spring Cloud Config、 Apollo, nacos

注冊中心的原理是什么
服務啟動后向 Eureka注冊, Eureka Server會將注冊信息向其他 Eureka Server進行同步,當服務費者要調用服務提供者,則向務注冊中心獲取服務提供者地址,然后會將服務提供者地址存在本地,下次再調用時,則直接
從本地存中獲取服務列表來亮成服務調用

總結

以上是生活随笔為你收集整理的一些题目以及答案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。