1、為什么Controller層注入的是Service接口，而不是ServiceImpl實(shí)現(xiàn)類
Controller層
@Autowired
private TestImpl?testImpl; //注入了實(shí)現(xiàn)類

創(chuàng)新互聯(lián)長(zhǎng)期為1000多家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺(tái)，與合作伙伴共同營(yíng)造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為遵義企業(yè)提供專業(yè)的網(wǎng)站制作、做網(wǎng)站，遵義網(wǎng)站改版等技術(shù)服務(wù)。擁有10余年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。

面向接口編程

? (1）注入的就是實(shí)現(xiàn)類，只不過拿接口來接收，接收的類型為接口，面向接口編程，那么為何要面向接口編程？這就涉及到使用接口做代理，因?yàn)橥ㄟ^@autowired的對(duì)象是通過接口的方式會(huì)使用jdk動(dòng)態(tài)代理，jdk動(dòng)態(tài)代理只能對(duì)實(shí)現(xiàn)接口的類生成代理，而不能針對(duì)類。

? (2）注入的是實(shí)現(xiàn)類對(duì)象，接收的是接口；理解為多態(tài)；

要遵循Controller–Service接口–ServiceImpt實(shí)現(xiàn)類–Mapper接口模式;

2、分布式鎖三種實(shí)現(xiàn)方式
(1)、?基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖；
(2)、基于緩存（Redis等）實(shí)現(xiàn)分布式鎖；
(3)、?基于Zookeeper實(shí)現(xiàn)分布式鎖；

一、基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖
1. 悲觀鎖

利用select … where … for update 排他鎖

注意: 其他附加功能與實(shí)現(xiàn)一基本一致，這里需要注意的是“where name=lock ”，name字段必須要走索引，否則會(huì)鎖表。有些情況下，比如表不大，mysql優(yōu)化器會(huì)不走這個(gè)索引，導(dǎo)致鎖表問題。

2. 樂觀鎖

所謂樂觀鎖與前邊大區(qū)別在于基于CAS思想，是不具有互斥性，不會(huì)產(chǎn)生鎖等待而消耗資源，操作過程中認(rèn)為不存在并發(fā)沖突，只有update version失敗后才能覺察到。我們的搶購、秒殺就是用了這種實(shí)現(xiàn)以防止超賣。
通過增加遞增的版本號(hào)字段實(shí)現(xiàn)樂觀

3：分布式鎖三種實(shí)現(xiàn)方式對(duì)比：

數(shù)據(jù)庫分布式鎖實(shí)現(xiàn)
缺點(diǎn)：

1.db操作性能較差，并且有鎖表的風(fēng)險(xiǎn)
2.非阻塞操作失敗后，需要輪詢，占用cpu資源;
3.長(zhǎng)時(shí)間不commit或者長(zhǎng)時(shí)間輪詢，可能會(huì)占用較多連接資源

Redis(緩存)分布式鎖實(shí)現(xiàn)
缺點(diǎn)：

1.鎖刪除失敗 過期時(shí)間不好控制
2.非阻塞，操作失敗后，需要輪詢，占用cpu資源;

ZK分布式鎖實(shí)現(xiàn)
缺點(diǎn)：性能不如redis實(shí)現(xiàn)，主要原因是寫操作（獲取鎖釋放鎖）都需要在Leader上執(zhí)行，然后同步到follower。

總之：ZooKeeper有較好的性能和可靠性。

從理解的難易程度角度（從低到高）數(shù)據(jù)庫 >緩存 >Zookeeper

從實(shí)現(xiàn)的復(fù)雜性角度（從低到高）Zookeeper >= 緩存 >數(shù)據(jù)庫

從性能角度（從高到低）緩存 >Zookeeper >= 數(shù)據(jù)庫

從可靠性角度（從高到低）Zookeeper >緩存 >數(shù)據(jù)庫

4、Kafka、RocketMQ、RabbitMQ的對(duì)比

RabbitMq

• 由于erlang語言的特性，mq 性能較好，高并發(fā)；
• 吞吐量到萬級(jí)，MQ功能比較完備；
• 健壯、穩(wěn)定、易用、跨平臺(tái)、支持多種語言、文檔齊全；
• 開源提供的管理界面非常棒，用起來很好用；
• 社區(qū)活躍度高；

缺點(diǎn)

• erlang開發(fā)，很難去看懂源碼，基本職能依賴于開源社區(qū)的快速維護(hù)和修復(fù)bug，不利于做二次開發(fā)和維護(hù)；
• RabbitMQ確實(shí)吞吐量會(huì)低一些，這是因?yàn)樗龅膶?shí)現(xiàn)機(jī)制比較重；
• 需要學(xué)習(xí)比較復(fù)雜的接口和協(xié)議，學(xué)習(xí)和維護(hù)成本較高；

RocketMQ:

優(yōu)點(diǎn)：

• 單機(jī)吞吐量：十萬級(jí)；
• 可用性：非常高，分布式架構(gòu)；
• 消息可靠性：經(jīng)過參數(shù)優(yōu)化配置，消息可以做到0丟失；
• 功能支持：MQ功能較為完善，還是分布式的，擴(kuò)展性好；
• 支持10億級(jí)別的消息堆積，不會(huì)因?yàn)槎逊e導(dǎo)致性能下降；
• 源碼是java，我們可以自己閱讀源碼，定制自己公司的MQ，可以掌控；

缺點(diǎn)

• 支持的客戶端語言不多，目前是java及c++，其中c++不成熟；
• 社區(qū)活躍度一般；
• 沒有在 mq 核心中去實(shí)現(xiàn)JMS等接口，有些系統(tǒng)要遷移需要修改大量代碼；

Kafka：

優(yōu)點(diǎn)：

• 性能卓越，單機(jī)寫入TPS約在百萬條/秒，大的優(yōu)點(diǎn)，就是吞吐量高；
• 時(shí)效性：ms級(jí)；
• 可用性：非常高，kafka是分布式的，一個(gè)數(shù)據(jù)多個(gè)副本，少數(shù)機(jī)器宕機(jī)，不會(huì)丟失數(shù)據(jù)，不會(huì)導(dǎo)致不可用；
• 消費(fèi)者采用Pull方式獲取消息, 消息有序, 通過控制能夠保證所有消息被消費(fèi)且僅被消費(fèi)一次;
• 有優(yōu)秀的第三方Kafka Web管理界面Kafka-Manager；
• 在日志領(lǐng)域比較成熟，被多家公司和多個(gè)開源項(xiàng)目使用；
• 功能支持：功能較為簡(jiǎn)單，主要支持簡(jiǎn)單的MQ功能，在大數(shù)據(jù)領(lǐng)域的實(shí)時(shí)計(jì)算以及日志采集被大規(guī)模使用；

缺點(diǎn)：

• Kafka單機(jī)超過64個(gè)隊(duì)列/分區(qū)，Load會(huì)發(fā)生明顯的飆高現(xiàn)象，隊(duì)列越多，load越高，發(fā)送消息響應(yīng)時(shí)間變長(zhǎng)；
• 使用短輪詢方式，實(shí)時(shí)性取決于輪詢間隔時(shí)間；
• 消費(fèi)失敗不支持重試；
• 支持消息順序，但是一臺(tái)代理宕機(jī)后，就會(huì)產(chǎn)生消息亂序；
• 不支持延遲隊(duì)列
• 不支持死信隊(duì)列
• 社區(qū)更新較慢；

三者主要區(qū)別：

產(chǎn)品	建議
Kafka	Kafka主要特點(diǎn)是基于Pull的模式來處理消息消費(fèi)，追求高吞吐量，一開始的目的就是用于日志收集和傳輸，適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)收集業(yè)務(wù)。 大型公司建議可以選用，如果有日志采集功能，肯定是選kafka了。
RocketMQ	天生為金融互聯(lián)網(wǎng)領(lǐng)域而生，對(duì)于可靠性要求很高的場(chǎng)景，尤其是電商里面的訂單扣款，以及業(yè)務(wù)削峰，在大量交易涌入時(shí)，后端可能無法及時(shí)處理的情況。 RoketMQ在穩(wěn)定性上可能更值得信賴，這些業(yè)務(wù)場(chǎng)景在阿里雙11已經(jīng)經(jīng)歷了多次考驗(yàn)，如果你的業(yè)務(wù)有上述并發(fā)場(chǎng)景，建議可以選擇RocketMQ。
RabbitMQ	結(jié)合erlang語言本身的并發(fā)優(yōu)勢(shì)，性能較好，社區(qū)活躍度也比較高，但是不利于做二次開發(fā)和維護(hù)。不過，RabbitMQ的社區(qū)十分活躍，可以解決開發(fā)過程中遇到的bug。 如果你的數(shù)據(jù)量沒有那么大，小公司優(yōu)先選擇功能比較完備的RabbitMQ。

5、分布式事務(wù)--》CAP理論和BASE理論

1）CAP理論
1998年，加州大學(xué)的計(jì)算機(jī)科學(xué)家 Eric Brewer 提出，分布式系統(tǒng)有三個(gè)指標(biāo)：

• Consistency（一致性）
• Availability（可用性）
• Partition tolerance （分區(qū)容錯(cuò)性）
  
  CAP定理- Consistency
  Consistency（一致性）：用戶訪問分布式系統(tǒng)中的任意節(jié)點(diǎn)，得到的數(shù)據(jù)必須一致
• 
  
  CAP定理- Availability
  Availability （可用性）：用戶訪問集群中的任意健康節(jié)點(diǎn)，必須能得到響應(yīng)，而不是超時(shí)或拒絕
  

?CAP定理-Partition tolerance

• Partition（分區(qū)）：因?yàn)榫W(wǎng)絡(luò)故障或其它原因?qū)е路植际较到y(tǒng)中的部分節(jié)點(diǎn)與其它節(jié)點(diǎn)失去連接，形成獨(dú)立分區(qū)。
• Tolerance（容錯(cuò)）：在集群出現(xiàn)分區(qū)時(shí)，整個(gè)系統(tǒng)也要持續(xù)對(duì)外提供服務(wù)
  
• 

2）BASE理論
BASE理論是對(duì)CAP的一種解決思路，包含三個(gè)思想：

• Basically Available （基本可用）：分布式系統(tǒng)在出現(xiàn)故障時(shí)，允許損失部分可用性，即保證核心可用。
• Soft State（軟狀態(tài)）：在一定時(shí)間內(nèi)，允許出現(xiàn)中間狀態(tài)，比如臨時(shí)的不一致狀態(tài)。
• Eventually Consistent（最終一致性）：雖然無法保證強(qiáng)一致性，但是在軟狀態(tài)結(jié)束后，最終達(dá)到數(shù)據(jù)一致。

而分布式事務(wù)大的問題是各個(gè)子事務(wù)的一致性問題，因此可以借鑒CAP定理和BASE理論：

• AP模式：各子事務(wù)分別執(zhí)行和提交，允許出現(xiàn)結(jié)果不一致，然后采用彌補(bǔ)措施恢復(fù)數(shù)據(jù)即可，實(shí)現(xiàn)最終一致。
• CP模式：各個(gè)子事務(wù)執(zhí)行后互相等待，同時(shí)提交，同時(shí)回滾，達(dá)成強(qiáng)一致。但事務(wù)等待過程中，處于弱可用狀態(tài)

你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機(jī)房具備T級(jí)流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級(jí)服務(wù)器適合批量采購，新人活動(dòng)首月15元起，快前往官網(wǎng)查看詳情吧

新聞標(biāo)題：java--那些事-創(chuàng)新互聯(lián)
分享鏈接：http://vcdvsql.cn/article26/cecgcg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、外貿(mào)建站、微信小程序、靜態(tài)網(wǎng)站、ChatGPT、App開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)