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

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

面向接口編程

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

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

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

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

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

利用select … where … for update 排他鎖

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

2. 樂觀鎖

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

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

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

1.db操作性能較差，并且有鎖表的風險
2.非阻塞操作失敗后，需要輪詢，占用cpu資源;
3.長時間不commit或者長時間輪詢，可能會占用較多連接資源

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

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

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

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

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

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

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

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

4、Kafka、RocketMQ、RabbitMQ的對比

RabbitMq

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

缺點

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

RocketMQ:

優(yōu)點：

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

缺點

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

Kafka：

優(yōu)點：

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

缺點：

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

三者主要區(qū)別：

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

5、分布式事務--》CAP理論和BASE理論

1）CAP理論
1998年，加州大學的計算機科學家 Eric Brewer 提出，分布式系統(tǒng)有三個指標：

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

?CAP定理-Partition tolerance

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

2）BASE理論
BASE理論是對CAP的一種解決思路，包含三個思想：

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

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

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

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

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

成都網(wǎng)站建設公司_創(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)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)